Nach nun 2 wöchiger Tortour, Testwahn und rum probiererei haben die Jungs der LAMP Solutions GmbH nach diversen Testfällen sehr wichtige Erkenntnisse in der Optimierung von hochfrequentierten WordPress-Systemen herausgefunden. Es geht um die Website www.dsds-superstar.com, auf der insbesondere am Wochenende > 40k Uniques / Tag unterwegs sind und für uns bis voraussichtlich heute unverständlicherweise immer kurz nach der Entscheidung (ca. 10-15 Min. danach) der Load des Servers an die Decke knallte und nur ein Reboot Rettung brachte. Nun mögen die meisten denken, > 40k Uniques ist zwar schon etwas, aber doch noch net richtig viel.. tja, so denken wir ebenfalls, allerdings mit dem Hintergedanken, dass WordPress auf einem 64bit betriebenen dedizierter Server mit 8GB Ram dennoch mengig RAM benötigt und deshalb auch die aktiven Prozesse sich selbstverständlich hier reduzieren. Und schließlich kann es ja nicht sein, dass wenn man hochfrequentierte Blogs betreibt, gleich ein High-Performance-Cluster-System für mehrere Tausend Euros nutzen zu müssen. Also ging es an die Analyse wo es hier hakt.
1. Optmierungen
Die erste Vermutung war, hier den Blog aktiv zu cachen und zwar möglichst viel. Also wurde das WP-Plugin W3TotalCache installiert und aktiviert, brachte aber nicht sonderlich merklich etwas. Die Vermutung, dass hier die Mehrsprachigkeit respektive Gettext-Parser den höchsten Ram-Verbrauch verzeichneten ist logisch und allseits bekannt. Also war die Überlegung, schlicht die Mehrsprachigkeit abzuschalten und mit einem reinen englischen WP zu arbeiten und schlicht alle Teile des Themes passend einzudeutschen. Nachteil war allerdings, dass auch alle Frontend-Plugins wie Umfragen, etc. ebenfalls dann in Englisch rausspucken und eingedeutscht werden müssten, wo nach allerdings wieder ein Rattenschwanz entsteht sobald Updates für die Plugins kommen. Also war diese Maßnahme auch nicht das Wahre vom Ei und brachte schlussendlich auch nicht die Lösung.
Die Lampen stellten die Serverstruktur komplett im Hause nach, jagten via Ab-Tests Tausende gleichzeitige Besucher auf die gleiche Umgebung wie auf dem Live-System und spielten mit APC-Cache, W3TotalCache und diversen anderen Optimierungen rum. Im Hause war klar, der Server sollte normalerweise mit nahezu absolut identischen Bedingungen gut und gern 750 Apache-Instanzen und somit gleichzeitige Zugriffe erlauben und verkraften, ohne das der Load an die Decke knallt. Also war immer wieder ein Warten am Ende der Optimierungen angesagt bis der bibbernde Samstag nahte.
2. Analyse und Auswertungen
Grundsätzlich waren in den letzten 3 Nächten (Samstags auf Sonntags) wenn DSDS lief die Lampen standhaft und testeten unter den realen Bedingungen. Es wurden permanent verschiedenste Analysen, Benchmarks und Auswertungen vorgenommen und schlussendlich war es uns allen absolut unverständlich, wieso ausgerechnet in dieser Zeit (0:00 bis 1:00 Uhr) bei ca. 2.200 Uniques der Server an die Decke ging. Allein Sonntags von 9:00 bis ca. 18:00 waren gute 30.000 Uniques auf der Seite, das macht in den 9 Stunden gute 3.000 Uniques pro Stunde. Allein deshalb war es unerklärlich, wieso ausgerechnet genau zwischen 0:00 und 1:00 Uhr der Server rebootet werden musste.
Schlussendlich fiel den Lampen an diesem Wochenende auf, dass exakt gegen 6:00 Uhr morgens nach dem die Logs gepackt wurden urplötzlich der Load sowie der Festplattenspeicher sich rapide reduzierte und wieder alles absolut im grünen Bereich war. Der Geschäftsführer teilte mir heute morgen nun mit, dass dies nun ein eindeutiges Zeichen ist, dass offenbar der Apache um diese Zeit sehr viele Schreibzugriffe für die Logs erzeugt, die voraussichtlich bis dahin schon aber nun nicht mehr gerade klein sind und deshalb natürlich erheblichen Mehr-Zeitaufwand verursachten. Andererseits kann das auch ein Problem mit dem Software-Raid sein. Fakt ist, diesen kommenden Samstag werden die Logs für die Seite deaktiviert. Sollte nun der Serverload im minimalen Bereich bleiben, ist die Ursache definitiv gefunden und es bleibt eine Kommunikation mit dem Hoster, ob dort möglicherweise ein Hardware-Defekt besteht.
Die Resultate mit WordPress, APC-Caching und W3TotalCache findet Ihr bei Foobar und das nächste Update dieses Themes erfolgt dann in der kommenden Woche.
