Ich weiß, dass diese Fragen schwer zu beantworten sind :) Aber ich möchte mir ein Bild davon machen, welche Auswirkungen die Aufteilung der Dienste auf unterschiedliche Server hat.
Genauer gesagt richte ich eine Website ein, die über einen Medienserver (Apache stellt statische Dateien bereit), einen App-Server (Apache verarbeitet PHP-Dateien), einen Master-DB-Server und einen Slave-DB-Server verfügen wird.
Ich wollte Memcached sowohl auf dem Medien- als auch auf dem App-Server als gemeinsamen Pool ausführen, fragte mich aber, ob dies kostspielig (in Bezug auf Zeit und Ressourcen) wäre. Natürlich muss jedes Mal, wenn ein Memcached-Aufruf (vom App-Server) angefordert wird, eine TCP-Verbindung zum Medienserver hergestellt werden, ermittelt werden, wo die Ergebnisse liegen, und diese dann zurückgeben.
Wäre es für eine kleine Website-Konfiguration wie diese besser, den RAM auf dem App-Server zu erhöhen und Memcached NICHT auf mehreren Servern zu verteilen? Oder ist der Unterschied so gering, dass man sich darüber keine Gedanken machen muss?
Obwohl ich Memcached als Beispiel verwendet habe, wäre es mir lieber, wenn die Antworten relativ allgemein gehalten wären, da das gleiche Szenario auch auf andere Dienste (wie eine Datenbank) angewendet werden könnte.
Antwort1
Wenn es sich um eine kleine Website handelt, halte ich diesen Grad der Optimierung für übertrieben.
Aber es gibt einen Weg, das sicher herauszufinden:Probier es aus.
Wir haben benutztWCATin der Vergangenheit, um Fragen wie diese zu beantworten. Es ist ein großartiges Tool, um zu sehen, wie die Site unter verschiedenen Belastungen funktioniert.JMeterist ein weiteres großartiges Tool für so etwas.
Bei der Verwendung von WCAT haben wir uns beispielsweise letztendlich dazu entschieden, einen separaten Hyper-V-Server zu verwenden, um unsere DB-VM getrennt von unserer Web-App-VM (in diesem Fall Fogbugz) zu hosten. Der Test zeigte, dass selbst bei einer geringen Anzahl gleichzeitiger Benutzer die Anwendung unbrauchbar wurde, wenn sich die DB-VM auf derselben Maschine wie die App-VM befand (der Engpass war die CPU).
Antwort2
Ich brauche die Antworten auf einige Fragen, um Ihre besser beantworten zu können.
- Handelt es sich um eine einzelne Website?
- Werden intensive Ressourcen genutzt (intensive serverseitige Programmierung, Video-Streaming usw.)?
- Verwenden Sie nur Video, Datenbank und PHP/.net?
- Wie gut sind die Server ausgestattet?
- Welche Geschwindigkeit haben die Festplatten und sind sie in einer RAID-Konfiguration?
- Wie viele Prozessoren?
- Wie viel RAM?
- Verwenden Sie Netzwerkkarten und Switches mit 100 MB oder 1000 GB?
- Wie hoch ist Ihre Upstream-Geschwindigkeit?
- Ist Ihr Betriebssystem rationalisiert und optimiert?
Antwort3
Die Informationen reichen bei weitem nicht aus, um eine Antwort zu geben, die mit einiger Wahrscheinlichkeit auch richtig ist. Und die einzige Möglichkeit, um sicherzugehen, dass Sie die richtige Antwort erhalten, wäre, einige Tests/Benchmarks durchzuführen.
Aus Ihrer Beschreibung schließe ich, dass durch das Pooling die Latenzzeit einer einzelnen Anfrage zunimmt, die Gesamtlast jedoch zunimmt, die Sie bewältigen können, bevor es zu einem Engpass kommt.
Aber wenn ich sage, dass ich vermute, dass es die Latenz einer einzelnen Anfrage erhöhen könnte, meine ich damit einen Wert zwischen einem Bruchteil einer Millisekunde und vielleicht einigen zehn Millisekunden, abhängig von Ihrer Netzwerkkonfiguration. Wenn Ihre Site stark ausgelastet ist, wird dies durch die Geschwindigkeitsvorteile, die sich aus weniger DB-Aufrufen mit doppelt so viel Cache ergeben, bei weitem aufgewogen. Wenn der Medienserver und der App-Server ungefähr die gleiche Hardware aufweisen, ist es durchaus wahrscheinlich, dass Ihr App-Server eine hohe CPU-Auslastung hat und die CPU des Medienservers ziemlich im Leerlauf ist, was bedeutet, dass Sie möglicherweise tatsächlich die beste Leistung erzielen, wenn Sie Memcached nur auf dem Medienserver und nicht auf dem App-Server verwenden.
Die einzige Möglichkeit, sich einer Optimierung sicher zu sein, ist das Testen. Testen, Benchmarken, Profilieren usw. Ohne Testen werden Sie nie wissen, ob Sie die Leistung verbessern oder verschlechtern. Führen Sie End-to-End-Tests durch (mit anderen Worten simulierte Webclients, die alle Dateianfragen stellen, die ein echter Webclient stellen würde) mit einer realistischen Mischung von Benutzern (damit Sie die richtige Mischung aus Cache-Treffern und -Fehlschlägen erhalten), sowohl bei mäßiger Belastung als auch bei „wir haben gerade Slashdotted“-Belastungen. Automatisieren Sie Ihren Test, damit er leicht wiederholbar ist. Testen Sie mit Memcached auf beiden/allen Servern, nur auf einem Server, nur auf dem anderen Server, mit mehr RAM auf einem Server als auf dem anderen usw.