Sind clouds eigentlich träge?

[Sind clouds eigentlich träge]

Ich hab mal das nicht ganz so verwandet Appspot etwas ausprobiert und musste verstellen das manchen Aktion manchmal erstmal 340-900 ms brauchen und bei wiederholten male dann plötzlich 34 ms.

Eigentlich ja auch ganz logisch. Festplatetn brauchen ja erstmal etwas zeit. Und dann landet es im Cache.

Doch wie ist das bei dem verteilten Rechner in größere Projekten. Da müsste es doch eigentlich ständig Haken da die Daten immer hin und her gehen.

[Siga29472947]

Ich vermute, die müssen "hochfahren"/"warmlaufen" und Daten sammeln und dann erst laufen die "normal".

Auf parallel-cpus ist es eh normalerweise nicht schlau bzw. verlangsamt, wenn man Algorithmen mit sehr viel Kommunikation laufen lässt weil dann ständig CPUs auf andere CPus warten müssen.

Bei Business-Clouds hat man aber beim Online-Shoppen oder Webservern einfach viele Kunden die alle was verschiedenes wollen und sehr UNABHÄNGIG voneinander sind, wodurch sie gut skalieren, wenn man sie verteilt. Wenn sie z.b. Produkte anschauen oder ihren Einkaufswagen bezahlen, sind die anderen Kunden recht egal.
Andere Probleme wie Optimierung, Statistiken usw. brauchen speziellere Optimierungen damit sie schnell oder latenz-kurz laufen. Dafür sind einfache Clouds evtl ungeeignet.

Sowas wie J2EE bietet sich für Clouds vermutlich besonders gut an. Aber auch für Multithreads und/oder MultiCores. Halt wo viele Arbeiter-Objekte etwas eigenständig mit nicht zu viel Interaktion mit zu vielen anderen Objekten erledigen können. Sowas läuft inhärent gut auf parallelen Systemen.
Solche Systeme muss man aber erst mal "hochfahren" wie eine Fabrik und dann warten die auf Aufträge.
Man läuft oder fährt mit Fahrrad/PKW zum Zigarettenautomaten. Mit einem LKW dort hin zu fahren für nur ein Paket Zigaretten gibt eine große Latenz.

Das Kapital von China sind die Arbeiter. Die sind so günstig, das Chinesen eher selten/kaum Maschinen kaufen sondern viele Chinesen ans Fliessband setzen die (übertrieben ausgedrückt) jeder nur einen Handgriff machen.
In einer "deutschen" Porzellan-Manufaktur hingegen malt jeder nur ein Motiv und ist auf eine bestimmte Menge von Motiven spezialisiert. Zerlegung in Einzelschritte würden Chinesen daraus machen.
D.h. je nach Umgebungsbedingungen muss/kann das Problem unterschiedlich gelöst/optimiert werden.
Dementsprechend verhält sich die Latenz.

Andere Optimierungen wie "wo sitzt der Client" und "wir verschieben nach ein paar Jobs den Client-Thread/Workspace in Richtung besserer Anbindung an den Client" gingen auch als Erklärung für Deine Beobachtung.

Oder man lässt den Client die ersten Jobs in einem Pool mit vielen Klein-Clients laufen. Wenn man die Verhaltensparameter kennt (Ram-Bedarf, wie groß sind die Time-Slices, IO-Bedarf, TCP-Verhalten...) verschiebt man es auf eine geeignetere Plattform. Z.b. weil dort die L1/L2/L3-Cache-Size der CPUs gut passt oder die Netz-Anbindung ausreicht.

Ob es Clouds gibt, die bestimmte Anforderungen an Latenz spezifizieren lassen, weiss ich nicht. Gegen Aufpreis gibt es das vielleicht. Oder die müssen erst noch drauf kommen.
Dann sucht man sich online für die Images/Programme die Parameter aus und bezahlt dann dementsprechend mehr oder weniger.
Eine Webserver-Cloud in Oklahoma hat dann als erfundenes Beispiel z.B. eine höhere Latenz zu deutschen T-DSL-Routern aber ist dafür halb so teuer pro Gigabyte.