Meine letzten Abende bestanden zu größeren Teilen aus der Ursachenforschung für die mitunter doch erheblichen Performancepotenziale dieser Seite. Nachdem Google die Kenngröße nun sichtbar in die Webmaster Tools integriert hat und mein schlechtes Gewissen vorher schon grenzenlos war, musste ich mir doch etwas Zeit dafür gönnen.
Kurze Vorgeschichte: nach langer Zeit des Shared Hostings habe ich die Domain (nicht zuletzt der großartigen Möglichkeiten hinsichtlich der Konfiguration) auf einen VPS (Virtual Private Server) umgezogen. Getreu dem Motto “nur Mut” war dies schnell getan. Leider waren die Defizite doch erheblicher als ich vermutet hatte.
Nach einigen Sessions, in denen die Konfiguration noch einen deutlichen “Schliff” erhielt, war es für den Moment erträglich wenn auch nicht zufriedenstellend.
Die Stellschrauben sind begrenzt – angreifen kann man prinzipiell:
- am Webserver selbst (Apache2) – apache2.conf, httpd.conf
- am Datenbankserver (MySQL) – my.cnf
- an der Skriptsprache (PHP) – php.ini
- an der Anwendung (WordPress) – Caching, Plugins, …
Damit wären die wesentlichen Punkte behandelt. Sie fragen sich nach dem Effekt? Gefühlt schonmal deutlich – in Zahlen schwer messbar, da die Umgebungsparameter (Gesundheitszustand Hostsystem, Anzahl zeitgleicher Zugriffe,… ) einen nicht unwesentlichen Beitrag leisten.
Nun stellt sich die Herausforderung auf eine etwas andere Art und Weise: in Abhängigkeit von der Tageszeit ist die Performance mal ok und eben mal nicht. In Zahlen bedeutet das, dass Sie, werter Leser, zwischen 0,7 und durchaus auch mal 10 Sekunden warten müssen, bis die Inhalte auf dem Server zusammengesetzt sind – der Download ist (breitbandig) in einer wenig spürbaren Zeitspanne abgeschlossen – die Bandbreite sollte also nicht der Flaschenhals sein. Bis zwei, vielleicht auch drei Sekunden liegt man damit ansich im WordPress-Schnitt – zumindest bei etwas besser besuchten Seiten. Mehr erscheint mir allerdings ungünstig, fühlt sich der geneigte Surfer doch schon nach wenigen Sekunden genötigt, nochmal zu klicken oder die Seite zu verlassen.
Und nun? Ich werde die Szenarie noch etwas beobachten – wenn alles nix hilft, muss eben doch eigene Hardware her. Sofern Sie diese Zeilen gerade lesen und Interesse an “Hardware-Sharing” haben, können Sie gern per Mail mit mir in Kontakt treten :-)
Das ganze hat gefühlt etwas von “Simons Cat” – frustrierend und erheiternd zugleich – in diesem Sinne also einen schönen Abend!
Related posts:
- WordPress 2.8 – Galerie – funktioniert – schön Im Text etwas ausführlicher als in der Überschrift: die neu erschienene Version 2.8 des tollen WordPress-Projekts hat mich dazu bewogen,...
- Tool-Tip für MySQL-Backups Etwas erstaunt war ich letztens als ich feststellen musste, dass es Hoster gibt, die kein Backup der Inhalte über das...
- Coltrane alias WordPress 2.7 ist da! Wer ab und an bei Perun vorbeischneit, dem wird nicht entgangen sein, dass sich das Upgrade auf WordPress 2.7 schon...
- SAP, MaxDB und MySQL Wie bei heise-open nachzulesen ist, haben SAP und MySQL die Rückkehr der Datenbank MaxDB zu SAP bekanntgegeben. Im Jahr 2000...
- MySQL 5.1 – wieder ein großer Schritt vorwärts Die fast fertige (momentan noch als RC) verfügbare Version 5.1 des Opensource-DBMS MySQL wartet mit einigen interessanten und nützlichen Neuerungen...
In etwa habe ich das gleiche Problem.
Bei mir spitzte es sich sogar so weit zu, dass wenn ich einen Post in WP veröffentlichte mein Ram und danach der SWAP zugeballert wurde. So schlimm, dass nichts weiter hielf als den apache neu zu starten (wenn der noch reagierte). Also habe ich erst mal WP neu gemacht, aber das war auch nicht DIE Erlösung.
Mich würden deine Anpassungen an den oben genannten Dateien interessieren :)
Gruß
Sebastian
Also: die Anpassungen im groben: Logging auf ein Minimum reduzieren, Speicher zur Verfügung stellen, InnoDB ausstellen, Modulkonfiguration des Apachen prüfen und dann prüfen, ob sich das Ladeverhalten ändert.
Dass die Veröffentlichung von Posts nicht funktioniert könnte auch an der Pingfunktion sowie möglicherweise installierten Plugins liegen. Wenn diese auf die Reaktion anderer Seiten warten (bsp. Suchmaschinen), kann das auch zu deutlichen Verzögerungen führen.
So langsam manifestiert sich bei mir der Eindruck, dass das Performanceproblem auf der mir zur Verfügung stehenden Konfigurationsebene nicht lösbar ist. Ich glaube, ich werde mich mal auf die Suche nach einer anderen Lösung zum Betrieb der Seite begeben.