nicht angemeldet
Moin!
Ich würde es jetzt so machen:
3 Server.
1x Texas, 1x HongKong, 1x UK
Dort steht jeweils ein Rechenzentrum von Rackspace.
Naja, ist dein Geld.
Nur auf einem Server ist zusätzlich die Datenbank + memcached installiert. Dort greife ich entweder auf PGSQl zurück oder auf Cassandra. Letzteres ist denke ich deutlich schneller.
Fail Nummer 1: Die Datenbank ist weit von zwei Servern weg. Das sorgt für lange Wartezeiten. Und Memcached ist auch weit von zwei Servern weg, das sorgt ebenfalls für lange Wartezeiten.
Ist das System so möglich? Ich möchte davor nen LoadBalance schalten welcher dann den nächsten Server raussucht und von dort die Dateien liefert.
Fail Nummer 2: Ein Loadbalancer sitzt vor einer Gruppe von Webservern, misst deren Auslastung und verteilt hereinkommende Requests gleichmäßig. Es hat absolut keinen Sinn, in UK einen Loadbalancer hinzustellen, zu dem die gesamte Welt connected, um dann den Loadbalancer feststellen zu lassen, dass er zwei Drittel der Requests wieder nach Texas und Hongkong weiterleiten muss.
Sprich: Ein Loadbalancer hilft nur, wenn die Webserver lokal sind. Mit deinem auf die Welt verteilten Setup willst du keinen Request, der bei einem Server ankommt, intern weiterleiten, sondern direkt abarbeiten.
Dein Konzept erlaubt kein Loadbalancing zwischen den drei Serverstandorten.
Außerdem ist Loadbalancing eine Methode zur Gewährleistung von Hochverfügbarkeit. Bedeutet: Man setzt nicht EINEN Loadbalancer ein, denn wenn der ausfällt, ist die Site komplett down, sondern man hat mindestens ZWEI.
Die Auktionen würden natürlich nur über den mit der Datenbank und memcached laufen.
Wozu dann die sinnlosen zwei anderen Server auf der Welt? Du handelst dir damit mehr Probleme ein, als dass du sie löst.
Worauf sollte ich achten wenn ich die Webapp in PHP code. Muss ich auf irgendwas Rücksicht nehmen wenn alle DB-Anfragen über einen anderen Server kommen?
Klar musst du was beachten: Dass deine Datenbankabfragen nicht in einigen Mikrosekunden aus dem lokalen Cache beantwortet wird, sondern dass du pro DB-Abfrage mindestens 100 Millisekunden wartest, weil die Datenpakete rund um die Welt geschickt werden. Sprich: Es ist - außer in einem Skript wird mal keine Datenbank benutzt - absolut irrelevant, ob der Browser des Users sich direkt mit dem weit entfernten DB-Zentralserver verbindet, oder ob er sich mit dem dichter lokalisierten Server verbindet, welcher sich seinerseits mit dem weit entfernten DB-Zentralserver verbindet. Im Gegenteil: Die zweite Variante wird vermutlich für einen größeren Teil der User sogar der noch deutlich langsamere sein, weil diese zwei Connections insgesamt einen Umweg darstellen, der länger braucht, als der eine, direkte Weg.
Nur mal so als Rechenexempel: Ich hab von mir (Deutschland) via DSL eine Ping-Zeit von 45 Millisekunden zum SELFHTML-Server im deutschen Rechenzentrum. Zu Servern in den USA beträgt die Zeit 150 Millisekunden von mir, und 140 Millisekunden vom SELFHTML-Server.
Wenn jetzt ein Konstrukt aus Server und entferner Datenbank nur einen einzigen Roundtrip machen muss, dann bedeutet das:
Kontaktiere ich direkt den Servern in den USA, verbraucht das 150 Millisekunden, gehen ich über die Zwischenstation, habe ich die Summe aus beiden Einzelstrecken: 140 + 45 = 185 Millisekunden.
Und hier geht's erstmal nur um die Latenzzeiten eines Requests. Die Lage wird natürlich noch schlimmer, wenn zu beachten ist, dass der direkte Query zum entfernten Server mehr oder weniger ohne große Latenzen direkt die Anfrage bearbeitet, insbesondere die Datenbank direkt zur Verfügung hat, während die Methode mit entfernter Datenbank mindestens ZWEIMAL die Latenzzeit zwischen Web- und DB-Server erfordert: Einmal für den Aufbau der DB-Connection (ein Handshake braucht 140 Millisekunden), und dann nochmal zum Hin- und Hersenden eines Requests (erneute 140 Millisekunden). Die Zeit der Datenbank, den Query zu parsen, die Daten zu finden und zurückzusenden, ist in beiden Fällen identisch und braucht daher nicht gesondert betrachtet zu werden.
Schon sind wir bei der Direktverbindung bei einer Latenz von weiterhin nur 150 Millisekunden, bei deinem Verteilungs-Konstrukt addiert es sich aber auf 325 Millisekunden - mehr als doppelt soviel Zeit fur eine Aktion. Das ist schon eine Drittel-Sekunde, die da draufgeht.
Lässt sich das System noch optimieren?
Klar: Überlass die überflüssige Verteilung der Server über den Erdball jemandem, der sich mit sowas auskennt. Alle wichtigen Webauftritte mit Hochlastsituationen nutzen irgendeine Art von lokaler Distribution ihres Webangebotes - für sowas gibts Dienstleister wie Akamai - WENN denn tatsächlich irgendwann der entsprechende Bedarf nach deiner Website besteht.
Im Moment passt der Auftritt offenbar ja noch locker auf einen einzelnen Server. Es erscheint absolut blödsinnig, sich in dieser Situation die Probleme eines auf der Welt verteilten Serverparks ans Bein binden zu wollen. Das ist den fünften Schritt vor dem ersten tun. Schritt eins wäre vermutlich, tatsächliche Lastprobleme abzufangen durch mehr Serverkapazität in dem einen Rechenzentrum - eventuell, indem die Datenbank einen eigenen Server kriegt. Schritt zwei wäre, Redundanz und Ausfallsicherheit durch Load-Balancing hinzukriegen. Sowohl für die Web- als auch die Datenbankserver, je nach Bedarf.
Und wenn das Projekt dann immer noch weiter wächst, wäre Schritt 3, sich einen kompetenten DB-Administrator ins Boot zu holen, der die Lastprobleme der Datenbankserver durch geeignete Maßnahmen entschärft.
Die Wahl deines Nicknames legt allerdings nahe zu glauben, dass es hier weniger um die Lösung eines technischen Problems, denn vielmehr um die Schaffung eines möglichst protzenden Setups geht. Kannst du natürlich so machen.
- Sven Rautenberg