Wenn man den Titel dieses Artikels vorher gekannt hätte, hätten wir uns viele Stunden und viel Ärger erspart.
Das Problem:
Ein Webserver der höheren Güteklasse mit Linux Debian und XAMPP 1.5.1 .
Verwendung von ProFTPD, PHP5.x, Apache2 und MySQL 5.0.20 ist aktiviert.
Der eAccelerator funktioniert auf Grund von Inkompatibilitäten leider nicht aber trotzdem sollte dieses System für ausreichend performante Webapplikationen ausreichen.
Auf diesem Webserver werden mehrere osCommerce Shops mit derweil einigen Individualisierungen betrieben, die zusammen ca. 3500-5000 Unique Visitors besuchen und nutzen.
Also normaler Weise noch keinerlei Grund sich über Engpässe der Serverlast Sorgen zu machen.
Aber leider weit gefehlt.
Innerhalb von der letzten 2 Wochen stieg die Last derart stark an und wurde unzumutbar für Anbieter und vor allem für den Kunden.
Doch wo war das Problem?
Schlecht programmierte Scripte? DDoS? Hitze? Falsche Config im Apache2? osCommerce?
Die Ursachenforschung:
Da es dem Shopbetreiber sowie den Endkunden der Shops nicht zumutbar war und die Shops bereits Umsatzeinbußen einstecken mussten, die auf die Performance zurückzuführen wären, war es höchste Zeit das Problem zu finden und zu Lösen.
Nicht immer ist es das Beste, einfach einen weiteren Server hinzustellen, die Hardware aufzurüsten oder gleich ein Round-Robin-System aufzusetzen.
Erstmal ist es wichtig Ursachenforschung zu betreiben, denn sonst kommt es schnell vor, das das Problem wieder vorkommt.
U.a. wurden Test ähnlicher und gleicher Applikationen und Configs auf Testservern vorgenommen. Teilweise lief es besser, teilweise nicht. Ursache unbekannt!
Es wurden die eingehenden sowie ausgehenden Verbindungen gecheckt. DDoS ist es auch nicht!
Zu Hohe Anzahl Zugriffe? Nein, 5000 Unique Visitors sollte ein zehntel oder weniger des Maximum sein.
Sind es RewriteRules oder andere schlechte Einstellungen im Apache? Nein, nichts zu entdecken.
Der httpd war der einzige Prozess, der die Überlast verursachte, also muss das Problem beim Apache liegen. Benchmarks halfen aber auch nicht, sie zeigten nur auf, das das System auf ähnlich konfigurierten Servern viel mehr leistete.
Die Lösung:
Dann, nach 2-3 Tagen Ratlosigkeit, zwei Dumme – ein Gedanke! 😉
Zwei Techniker hatten zeitgleich aber unabhängig voneinander den gleichen Tip: Was ist eigentlich mit MySQL Cache? Wird das verwendet? Könnte das helfen?
Kurz mal gegoogelt, und im Manual von MySQL 5.0 gelandet, ist ein Lichtblick zu finden.
Dort wird verdeutlicht, was bei MySQL 5 neu ist und was das aktivieren vom caching bewirken kann.
Searches for a single row in a single-row table are 238% faster with the query cache than without it. This can be regarded as close to the minimum speedup to be expected for a query that is cached
Man sollte halt vor dem Umstieg von MySQL 4 zu 5,vorher wissen, das es derartige Neuerungen gibt.
Aber da der mysqld nie mit hoher CPU Leistung in der Prozessliste aufgefallen ist, hat man die Ursache dort nicht vermutet.
Einzig der Gedanke im Hinterkopf, das osCommerce dafür bekannt ist, alles andere als Performant zu sein und leicht mal über 100 SQL Abfragen pro Seitenaufruf verursacht, brachte uns auf die Idee des cachen.
Nur wer sollte wissen, das das per Default ausgeschaltet ist?
Alleine die Aktivierung des Caches mit standard 10MB brachte die Load von teilweise 5-9 auf 0,4 bis 0,6 wobei 1=100% Last sind.
Also keine "fetteren" Server, keine bessere Software, keine Verteilung der Shops auf mehrere Server, nein, nur eine kleine Variable in dem MySQL DB Server…
puhh, waren wir dann erleichtert.
Nun laufen alle Applikationen wieder einwandfrei, wie man es kannte und erwartete.