Wie man von der Einrichtung eines einzelnen Servers wächst

Ich suche nach Ressourcen, um unser Server-Setup zu erweitern.

Wir haben derzeit einen dedizierten Server mit Rackspace in Großbritannien mit der folgenden Spezifikation:

HPDL385_G2_PrevGen
HP Single Dual Core Opteron 2214 (2,2 GHz)
4 GB RAM
2x 10.000 SCSI-Laufwerke in RAID 1

Unser Verkehr beträgt bis zu 550.000 UVs pro Monat.

Die Site läuft über ein PHP- und MySQL-Setup. Die Datenbank wird absolut hämmernd, wir haben viele komplexe Abfragen, die Multilpe-Tabellen verbinden.

Wir verwenden APC für das PHP-Caching.

Ich komme zu dem Punkt, an dem ich so viel DB- und Abfrageoptimierung wie möglich durchgeführt habe, und frage mich, was der nächste Schritt sein soll.

Ich habe mir Memcache angesehen, aber ich habe den Eindruck, dass er viel RAM und im Idealfall eine dedizierte Box benötigt.

Also ist der nächste Schritt, zwei Boxen zu haben; eine für die Datenbank, eine für Apache? Oder gibt es einen Schritt, den ich übersehen habe?

Unsere Ladung liegt normalerweise bei 2, aber im Moment ist es bei 20!

Einige Grafiken aus Munin:

Kaufen Sie Hardware, aber legen Sie sie in Ihr Testlabor und nicht in das Rechenzentrum. Betonen Sie dann Ihre Anwendung mit verschiedenen Hardware- / Softwarekombinationen, bis Sie eine vernünftige finden, die das tut, was Sie wollen.

Natürlich müssen Sie etwas entwickeln, das gefälschten Datenverkehr für eine produktionsähnliche Datenbank erzeugen kann, in der eine Testkopie Ihrer App ausgeführt wird. Aber wer hat gesagt, dass es einfach sein würde?

Wenn Sie dies nicht tun und einfach einige Dinge in der Produktion erledigen, wissen Sie nicht, ob es funktionieren wird oder nicht, und Sie haben möglicherweise eine Menge technischer Anstrengungen unternommen, um Dinge wie Caches zu implementieren (die mit ihrem gerechten Anteil einhergehen) von Fehlern!) auf etwas, das nicht hilft.

Testen, testen und testen Sie mehr. Werfen Sie keine Hardware- / Softwareänderungen in die Produktion, bis Sie gute Leistungsdaten haben, die zeigen, dass sich die Situation wahrscheinlich erheblich verbessern wird. Der Engineering-Aufwand ist teuer, die Testhardware nicht (besonders).

Memcached ist nur eine Option, und Sie müssen sie wahrscheinlich erst in Betracht ziehen, wenn das Caching der Datenbank optimal funktioniert. Dies bedeutet, dass Sie es auf eine dedizierte (natürlich 64-Bit) Box mit einer angemessenen Menge an RAM stellen (nicht 4G - Laptops haben das heutzutage; 32G ist definitiv erschwinglich) und es entsprechend abstimmen.

Sie haben noch nicht erwähnt, wie groß Ihre Datenbank ist, aber wenn dies überhaupt machbar ist, sollten Sie versuchen, sie vollständig in RAM (oder zumindest in den Hot Bits) zu speichern. Wenn Sie Ihre Datenbank vollständig in RAM speichern, werden Lese-E / A-Vorgänge vollständig ausgeblendet und sind somit kein Engpass mehr.

Profilieren Sie Ihre Datenbankabfragen. Hierfür gibt es Tools - Sie sollten in der Lage sein, die Produktionslast in Ihrer Testumgebung zu simulieren. Der Trick besteht darin, langsame Abfragen zu vermeiden und sicherzustellen, dass die häufig ausgeführten schnell sind.

Wenn Ihre Leistungsprobleme mit E / A-Synchronisierungen zusammenhängen, weil Sie einfach zu viele Transaktionen für die Datenbank ausführen, stellen Sie sicher, dass Sie einen batteriegepufferten RAID-Controller verwenden, der sich richtig verhält (sprechen Sie mit Ihrem Anbieter darüber). Sie bieten viel mehr E / A-Schreibvorgänge als nicht batteriegepufferte (da die Daten nur in den Cache gelangen müssen, bevor das Betriebssystem die Bestätigung erhält). Wenn Ihre Daten nicht so wichtig sind, können Sie alternativ die Haltbarkeitsparameter der Datenbank lockern (innodb sync on commit).

Wenn Sie sich mit Caching-Lösungen befassen, wie viele andere hier vorgeschlagen haben, können Sie davon ausgehen, dass Sie ungefähr 10% der heutigen Last haben, vielleicht sogar weniger.

Dies hängt jedoch davon ab, welche Art von Diensten Sie auf Ihrem Computer ausführen. Mit memcached können Sie viel tun, ohne sehr viel RAM.

Sie sollten versuchen zu profilieren, welche Datenbankabfragen am längsten dauern, entweder mithilfe des langsamen Abfrageprotokolls von MySQL (oder des entsprechenden Protokolls für Ihre Datenbank) oder mithilfe eines Tools wie mytop . Auch die EXPLAIN SELECTSyntax von MySQL kann hilfreich sein.

Das Zwischenspeichern der Ergebnisse einiger ausgewählter MySQL-Abfragen (auch nur für einen kurzen Zeitraum) kann Ihre Leistung erheblich verbessern.

Ich mache viel Leistung und skaliere die Arbeit und was ich entdeckt habe, ist Folgendes:

Jede Anwendungslast ist einzigartig

Generische Antworten wie das Hinzufügen von mehr RAM, das Erhalten eines anderen Servers, das Ausführen von y und das Ausprobieren von x sind häufig frustrierende Lektionen und überlassen komplizierten Setups.

Messen Sie die richtigen Dinge

Eine der größten Herausforderungen besteht darin, festzustellen, welche Benchmarks wichtig sind. Dies erfordert oft einen Schritt zurück und Sie müssen sich in die Lage Ihres Kunden versetzen. Manchmal ändert sich das vereinfachte Design der Website und bedeutet für den Webbesucher enorme Vorteile. Deshalb mag ich Tools wie YSlow! die sich mehr auf die Erfahrung des Endbenutzers als auf die Serverebene konzentrieren. Sobald Sie sich für den richtigen Benchmark für Ihre Website entschieden haben, können Sie mit der Optimierung beginnen. Benchmarks können die gesamte Ladezeit der Seite, die Gesamtseitengröße, die Cache-Effektivität, die Site-Latenz usw. sein. Sie müssen diejenige auswählen, die für Ihre Anwendung sinnvoll ist.

Schrauben und Muttern

Wenn Sie die richtigen Benchmarks verfolgen, beginnen Sie auf einem sehr niedrigen Niveau. Ich benutze gerne sysstat. Sie können eine Fülle von Informationen von sysstat erhalten und dabei helfen, herauszufinden, welches System die Gesamtanwendungsleistung möglicherweise einschränkt. Im Allgemeinen koche ich Leistungsprobleme in:

• Netzwerkstapel
• Speicherstapel
• Festplatte io
• Anwendungsschicht
• os Schicht

Mit sysstat und anderen Tools können Sie beginnen, Haare zu spalten und das System zu finden, das die Leistung einschränkt.

Ich habe beispielsweise festgestellt, dass hoch ausgelastete Server aufgrund der Konfiguration ihrer Anwendung ausfallen. Schlechtes Caching, fehlende abgelaufene Header für statische Inhalte, Verwendung von HTTP im Vergleich zu Datei-Includes usw. trugen alle zu einer schlechten Anwendungsleistung bei. Das Beheben dieser Anwendungsprobleme erforderte keine Hardwareänderungen. In anderen Fällen habe ich gesehen, dass die Festplatten trotz tonnenweise Caching voll sind. Das Verschieben auf schnellere Festplatten hat das Problem behoben.

Spülen und wiederholen

Während der Anwendungsoptimierung entkorken Sie häufig einen Engpass, um nur einen anderen zu finden. Aus diesem Grund empfehle ich, zu überwachen, was Sie gerade einstellen.

Angenommen, Sie beheben ein Problem mit der Festplatten-E / A, aber Ihre App ist immer noch langsam. Sie denken vielleicht, Sie haben Ihre Anstrengungen verschwendet, aber was passiert, ist, dass Sie einfach einen anderen Engpass treffen. Wenn Sie die Festplatten-E / A sorgfältig überwachen, können Sie sicher sein, dass Sie die Festplatten-E / A verbessern, auch wenn sich Ihre wichtigen Anwendungsleistungsmonitore nicht ändern.

Holen Sie sich die richtigen Werkzeuge

Stellen Sie sicher, dass Sie die richtigen Werkzeuge für den Job verwenden. Überwachung, Test, Benchmarking, Profilerstellung und andere Optimierungstechniken verfügen über eine Vielzahl von Tools. Finden Sie das Werkzeug, das am besten zu Ihrer Situation passt.

Faustregeln

Obwohl jede App einzigartig ist, finde ich einige Standardstartpunkte:

• Speicherdatenbanken lieben das Gedächtnis
• Festplatte io alles andere als RAID 10 kann die Datenbankleistung beeinträchtigen
• falsche Optimierungen - große Werte führen nicht zu großer Leistung
• Anwendung - Schuld am Server für schlechtes App-Design

Ihre nächsten Schritte

Wenn Sie Ihren Engpass nicht finden, hilft das Hinzufügen eines Servers möglicherweise nicht viel. Zum Lösen von Festplatten-E / A benötigen Sie möglicherweise einen anderen Server oder ein anderes SAN. Wenn Sie einen RAM-Engpass haben, löst ein anderer Server das Problem nur, indem er mehr RAM hinzufügt. Ziemlich kostspieliger Umzug im Vergleich zum Hinzufügen von mehr RAM zu Ihrem vorhandenen Server.

Schnelle Lösung

Über Bereitstellung. Ich musste dies tun, wenn es scheint, dass der Anwendungsstapel das Problem ist. Laden Sie grundsätzlich CPU, RAM und Festplatten-E / A (RAID 10, 15K SCSI oder SSD) auf. Gehen Sie groß auf die Hardware und beginnen Sie dann mit der Abstimmung. So bleiben Sie über Wasser, bis Sie die Probleme gelöst haben.

Ich würde sagen, der nächste Schritt sollte das Caching sein (Daten-Caching und / oder Seiten-Caching, abhängig von Ihrer Funktionalität). Wenn memcached zu komplex erscheint, können Sie mit einfachen Daten-Caching-Lösungen wie PEAR Cache Lite beginnen, die nur ein paar Codezeilen erfordern, aber einen großen Unterschied machen können. Das Zwischenspeichern von Seiten (oder Seitenteilen) wird beispielsweise von der Smarty Template Engine unterstützt .

Sobald das Caching nicht mehr funktioniert, können Sie die Servermenge erhöhen, da nichts mehr übrig ist.

Wenn Sie über genügend freien Arbeitsspeicher verfügen, hilft Ihnen memcached sogar auf derselben Box. Versuchen Sie, mehrere schwerste Abfragen zwischenzuspeichern und zu sehen, was passieren wird. Außerdem ist Apache zu schwer. Verwenden Sie stattdessen nginx oder lighttpd (bei PHP-Anwendungen, die über FastCGI arbeiten, siehe php-fpm ).

Starten Sie das Caching, aber ignorieren Sie MySQL für den Moment. Ernsthaft.

Die Regel sollte lauten: Stoppen Sie eine Anfrage so früh wie möglich. Ein Reverse-Proxy oder ein korrektes Caching auf Apache-Ebene liefert die besten Ergebnisse, dann das Zwischenspeichern von Ergebnissen auf SQL-Ebene INNERHALB der Anwendung und dann das Zwischenspeichern auf SQL-Ebene;)

Je früher Sie eine Anfrage stoppen, desto weniger Overhead haben Sie. Ausgabe-Cache-Level - nicht einmal PHP muss sozusagen ausgeführt werden.