Schnurpsel 

Höher, schneller, weiter

Mit den Google-Webmastertools bekommt man einen guten Überblick, wie oft der Googlebot vorbeischaut und wieviele Daten er in welcher Zeit Abfragt.

Pro Tag gecrawlte Seiten

Auf dem Diagramm ist noch das Ende vom November, der ganze Dezember und Januar und der Anfang vom Februar zu sehen. Scheinbar tritt der Googlebot auch über den Jahreswechsel etwas kürzer, feiert Weihnachten und Silvester und legt dann erst Mitte Januar wieder richtig los.

Pro Tag heruntergeladene Kilobyte

In etwa parallel dazu verläuft normlerweise die Kurve zu den täglich heruntergeladenen Datenmengen. Klar, je mehr Seiten angefragt werden, um so mehr Daten fallen da durchschnittlich an.

Eines fällt aber auf, denn obwohl die Anzahl der pro Tag abgefragten Seiten ab Mitte Januar und im Februar höher liegen als noch im November, ist die Datenmenge nicht in gleichem Maße angestiegen. Der Grund ist recht einfach. Ich hatte Anfang/Mitte Dezember die gzip-Komprimierung für die Seiten aktiviert.

Dauer des Herunterladens einer Seite (in Millisekunden)

Die Geschwindigkeit der Seitenauslieferung ist die für den normalen Nutzer, also den Besucher einer Website der wohl wichtigste, technische Wert. Wenn erstmal ein paar Sekunden nach dem Aufrufen einer Seite oder länger nichts passiert, ist das aus Anwendersicht eher unerfreulich.

Der Wert lag im November bei etwa 1,5 Sekunden und schließt damit an die Zahlen vom Oktober an. Anfang Dezember bin ich dann Dank SpeedPlus wieder zu Strato zurückgekehrt und seitdem liegen die Ladezeiten fast immer bei erfreulichen 0,8 Sekunden. Aber eben nur fast. Wie man im Diagramm sieht, gab es schon im Dezember und Anfang Januar Ladezeitspitzen, die dann im Februar nochmal deutlich zunahmen. Allerdings ist das eher darin zu sehen, daß durch die größere Anzahl der pro Tag abgefragten Seiten auch die Wahrscheinlichkeit für den Googlebots auf eine Lastspitze zu treffen, größer war.

Ungeachtet dessen gibt es aber diese Lastspitzen, die nicht nur der Googlebot “sieht”, sondern auch der normale Nutzer bemerkt. Wenn man Pech hat, dauert das Laden einer Seite wieder 4 bis 6 Sekunden, ganz so wie vor der SpeedPlus-Zeit bei Strato. Diesmal ist es aber meiner Meinung nach nicht die schlechte PHP-Performance, sondern eher die Datenbank. Die Datenbankserver sind zwar grundsätzlich nicht wirklich lahm, legen aber ab und zu ein paar Gedenkminuten ein, wie mir scheint. Und genau dann dauert der Seitenaufruf wieder mehrere Sekunden. Kürzlich gab es auch wieder mal einen Totalausfall, der dann zu einem 500er Fehler führt.

Hin und weg

Nun sind zwar PHP und Webserver bei Strato schnell, aber die Datenbank klemmt mitunter. Deshalb bin ich vorerst wieder zu meiner externen Datenbank zurückgekehrt. Das eigentlich langsame ist hierbei die Datenübertragung über das Internet zwischen Strato (Karlsruhe/Berlin) und Host-Europe (Köln). Um das etwas abzudämpfen, habe ich zusätzlich ein Datenbank-Cache-Plugin installiert, welches häufig benötigte Daten auf dem Webspace bei Strato im Dateisystem ablegt, um diese nicht jedesmal neu übertragen zu müssen. Zumal sich viele Daten, z.B. die Artikel und Seiten normalerweise eh nicht ändern.

Nun werde ich das Alles mal weiter beobachten, wie das mit den Ladezeiten so aussieht und hoffe aber trotzdem, das Strato die Datenbankaussetzer in den Griff bekommt.

Geschwindigkeit ist keine Hexerei

Daß das Strato-Shared-Webhosting und Wordpress derzeit nicht gut zusammenpassen und warum das so ist, hatte ich vor einiger Zeit geschrieben. Auf Grund der schlechten PHP-Performance dauert das Laden einer Wordpress-Seite mindestens 3,5 bis 4 Sekunden, auch wenn keine umfangreichen Plugins oder fette Themes installiert sind.

In den Google-Webmastertools kann man sich die Ladezeiten in einem Diagramm für die letzten drei Monate ansehen. Die Grafik oben zeigt den Verlauf für meine Seite schnurpsel.de. Bis Mitte Juli hatte ich alles bei Strato in meinem Webhostingpaket liegen. Allerdings nutzte ich bereits zu dieser Zeit eine externe Datenbank (bei Host-Europe), da es zeitweise bei Strato auch erhebliche Probleme mit dem Datenbankserver gab.

Im Juli bin ich dann schließlich mit der Wordpressinstalltion zu All-Inkl umgezogen, hatte aber weiterhin die externe Datenbank bei HE im Zugriff. Der Umzug verlief bis auf die 410-Gone-Panne auch ganz gut. Die Geschwindigkeit hatte sich schon deutlich verbessert. Einen kleinen Performance-Schub gab es dann nochmal Anfang/Mitte September, da hatte ich dann auch die Datenbank zum Webhoster mit der Wordpressinstallation geholt.

Die Geschwindigkeit liegt nun bei 1 bis 1,5 Sekunden für den Seitenabruf. Das ist zwar kein Spitzenwert, aber durchaus akteptabel. Gut, Wordpress ist keine ganz kleine Webapplikation und erfordert schon einiges an Ressourcen vom Webserver, aber trotzdem ist es auch auf mittleren Shared-Webhostingpaketen fernünftig einsetzbar. Dazu muß allerdings der Webserver ordentlich konfiguriert sein. Ich weiß ehrlich gesagt nicht, was da bei Strato die PHP-Performance so ausbremst, normal ist das aber nicht. Selbst auf einem vergleichbaren 1&1-Paket ist WP schneller, und 1&1 gilt allgemein auch nicht grad als Gschwindigkeits-Überflieger.

Man kann nur hoffen, daß sich da bei Strato mal etwas tut, vielleicht ja unter der Regie eines möglichen, neuen Besitzers.

Warum Wordpress bei Strato so langsam ist

Eigentlich müßte ich besser sagen, was ist kein Grund dafür, daß Wordpress beim Strato-Shared-Webhosting so langsam ist. Denn an einer vermeintlich schlechten Datenbankanbindung bzw. Datenbankperformance, wie man es oft in Foren oder auf Blogs lesen kann, liegt es nicht.

Datenbankgeschwindigkeit, der Test

Bei Wordpress kann man sich alle Datenbankabfragen als SQL-String mit Ausführungszeiten und Aufrufhierarchie in Datenbank-Objekt unter $wpdb->queries speichern lassen. Dazu muß man in der wp-config.php die Konstante ‘SAVEQUERIES’ mit true definieren:

define( 'SAVEQUERIES', true );

Genau das habe ich für die Startseite von schnurpsel.de gemacht und mir die Daten als PHP-Array in eine Datei geschrieben:

global $wpdb;
ob_start();
var_export( $wpdb->queries );
$out1 = ob_get_contents();
ob_end_clean();
plw123_debugfile_write( $out1 );

Diese Liste mit 51 SQL-Abfragen habe ich in ein einfaches PHP-Skript eingebunden und arbeite die Abfragen hintereinander ab. Es wird zunächst ein Connect zur Datenbank ausgeführt und anschließend folgende Schleife durchlaufen:

foreach( $sql_queries as $query ) {
	$dbd = @mysql_query( $query[0], $dbh );

	while( $row = @mysql_fetch_object( $dbd ) ) {
		$last_result[$num_rows] = $row;
		$num_rows++;
	}
	@mysql_free_result( $dbd );
	$num_queries++;
}

Es werden natürlich nicht nur die SQL-Abfragen ausgeführt, sondern auch die Ergebnisdatensätze mit mysql_fetch_object abgeholt. Nur die Ausgabe der Daten spare ich mir, das hat dann aber sowieso nichts mehr mit der Datenbank zu tun.

Datenbankgeschwindigkeit, das Ergebnis

Mal von ein paar Lastspitzen abgesehen, werden die 51 Abfragen und 539 Ergebnisdatensätze vom Strato MySQL 5 Server in etwa 0,2 Sekunden abgearbeitet. Man kann das hier [test-db-mysql5] live testen.

Ich habe das auch mal mit MySQL 4 probiert, da sind die Werte sogar noch etwas besser und liegen meist bei 0,1 Sekunden oder darunter [test-db-mysql4].

Und als dritten Test habe ich eine externe Datenbank (bei Host-Europe) eingebunden [test-db-ext]. Die 0,5 bis 0,6 Sekunden sind gar nicht mal so schlecht wenn man bedenkt, daß alle Daten über das Internet von Strato (Karlsruhe/Berlin) zu Host-Europe (Köln) und wieder zurück befördert werden müssen.

Mein Fazit

Die schlechte Geschwindigkeit von Wordpress (und anderen umfangreichen PHP-Applikationen wie z.B. Joomla) liegt ursächlich nicht an einer schlechten Datenbankperformance, sondern vielmehr an einem nicht besonders schnellen Webserver/PHP.

Was hier nun im einzelnen das Problem ist, kann ich nicht sagen. Ein Geschwindigkeits-Nachteil ist sicher die Tatsache, daß PHP bei Strato als CGI läuft. Das bedeutet, daß für jeden Seitenaufruf ein neuer PHP-Prozeß gestartet werden muß. Konfigurationen, bei denen PHP als Apache-Modul läuft, haben da natürlich einen Geschwindigkeitsvorteil.
Vielleicht muß ja auch jede PHP-Datei bei Strato erst einen Sicherheitcheck durchlaufen, bevor sie geladen wird oder was auch immer.

Ein weiterer Hinweis für die mäßige PHP/Webserver-Performance sind auch die nicht besseren Ladezeiten des Strato Weblog-Basic, denn da ist überhaupt kein MySQL-Datenbankserver im Spiel. Die Daten liegen auf dem Webspace des Users und werden per SQLite eingebunden.

Trotz eigentlich nicht schlechter MySQL Datenbankgeschwindigkeit wird meine Startseite hier nicht schneller als in etwa 3,5 Sekunden geladen, dabei verwende ich fast eine WP-Standardkonfiguration ohne umfangreichen Plugins.

Meine Ausführungen tragen zwar nicht zur Lösung des Geschwindigkeitsproblems bei, aber vielleicht zum Verständnis der Ursache und Problematik an sich.

Sicher ist sicher – Datenbanksicherung bei Strato

Datenbank-Sicherung

Regelmäßige Datensicherungen sind das Bloggers erste Bürgerpflicht, besonders vor einem Update auf eine neue Wordpress-Version. Bei Strato gibt es dafür eine über den Kundenbereich erreichbare Version von phpMyAdmin. Diese habe ich bisher auch ohne Probleme genutzt, auch wenn sie bisweilen etwas träge daherkam.

Vor dem Update auf Wordpress 2.7 habe ich natürlich auch erstmal eine Datenbanksicherung gemacht, zum Herunterladen wähle ich gewohnheitsmäßig die Option “GZip-komprimiert”. Die Datei ’schnurpsel_251_create.sql.gz’ wurde gespeichert, alles in Ordnung, dachte ich, dann kann es mit dem Update ja losgehen.

Das Update auf WP 2.7 lief zunächst erstmal ohne Probleme, ich konnte mich in Adminbereich anmelden, das Blog selbst sah auf gut aus. Doch dann plötzlich gibt es beim Speichern eines neuen Artikels einen bösen Fehler 500, mit das schlimmste, was so passieren kann. Der Server hat da ein schwerwiegendes Problem. Nachdem ich zunächst nur einen kurzen Schwächeanfall des Servers oder der Datenbank vermutete wurde es aber leider nicht besser. Auch das Blog selbst meldete nur noch den 500er.

Sollte Wordpress 2.7 etwa die Fehlerursache sein? Na gut, ist auch kein Beinbruch, ich hatte ja meine Kopie vom alten Wordpress, also einfach die Verzeichnisse wieder umbenennen, die Datenbanktabellen löschen und die Datenbanksicherung zurückspielen. Doch was ist das? Da fehlen Tabellen, die Liste hört irgendwo bei ‘wp_posts’ auf, da kommen doch eigentlich noch die Tag/Kategorie-Sachen (wp_term*) und die User-Tabellen (wp_user*). Hat beim Datenimport was nicht geklappt?
Die Datenbank-Sicherung ist praktisch eine Textdatei mit SQL-Anweisungen, also ganz normal als Text lesbar. Sie wird nur mit GZip gepackt. Beim Doppelklick auf die Datei meldet mir 7Zip jedoch nur:

Das Problem

Ein Blick in die .sql.gz-Datei offenbarte dann das Dilemma, die Daten dort sind überhaupt nicht gepackt, sie stehen da als lesbare SQL-Anweisungen drin, und was noch viel schlimmer ist, die Daten sind direkt nach dem Artikel mit der ID 27 zu Ende, da kommt nichts mehr, EOF.
Dann fiel mir das “Strato Backup-Control” ein, da werden regelmäßg meine Daten gesichert auf die ich dann über eine spezielles FTP-Login zugreifen kann. Vielleicht gibt es da auch eine Datenbank-Sicherung. Nein, ist leider nichts von Datenbanken zu finden, die Sicherung betrifft nur die Dateien im Webspace.

Das bestätigt mir telefonisch auch ein Support-Mitarbeiter von Strato, der mir dann aber gleich noch zu einem Upgrade auf das Paket “PowerPlus L” (€ 14,90 im Monat) rät, da wäre dann auch ein Datenbank-Backup enthalten.

Dumm gelaufen, würde ich sagen. So habe ich halt meine letzte Sicherung vom April 2008 eingespielt und da ich in der Zwischenzeit hier nicht besonders aktiv war einfach die verlorengegangenen Artikel per Hand (aus dem Google-Cache) nachgetragen.

Aber was war passiert, hatte ich mich einfach nur zu blöd angestellt, mit phpMyAdmin eine Sicherung zu machen? Nun wollte ich der Sache auf den Grund gehen.
Also habe ich die unterschiedlichen Varianten bei der Sicherung durchgespielt, einmal unkomprimiert, dann Zip und auch GZip. Bei unkomprimiert und Zip ist alles in Ordnung, nur bei GZip tritt der Fehler reproduzierbar auf. Die Daten werden nicht komprimiert und fatalerweise irgendwann einfach abgeschnitten.

Also rufe ich nochmal beim Strato Support an und schildere meine Beobachtung. Der Supportmitarbeiter kann nach meiner Anweisung das Problem sogar reproduzieren, hat aber auch keine Erklärung dafür und gibt es per Service-Ticket an die Technik weiter. Die Antwort kommt ein paar Tage später per E-Mail:

Sie haben berichtet, dass Datenbanken über die MYSQL-Datenbankverwaltung nicht komprimiert werden können.
Wir haben diesen Sachverhalt geprüft und konnten keine Beeinträchtigung feststellen. Die Datenbank DBXXYYZZ wird gzip komprimiert als *gz Archiv mit 196KB (entpackt 894KB) angeboten…
Eventuell wird die Übertragung clientseitig angebrochen.

Langsam kamen mir Zweifel, habe ich doch etwa selbst irgendeinen Fehler gemacht? Oder ist mein Anliegen bei der Technikabteilung nicht richtig angekommen? Also rufe ich zum dritten mal an und werde schließlich zur Technik weiterverbunden.
Nach einigem hin und her fragt mich der Techniker, was ich denn eigentlich wolle. Wenn ich meine Daten sichern will, würde das schließlich funktionieren, halt nur unkomprimiert und mit Zip, und das GZip nicht funktioniert sei eher mein Problem. Der “WebDatabase Manager” sei ohnehin nur eine Zugabe und nicht Vertragsbestandteil. Er rät mir sogar für die Datenbanksicherung selber entsprechende Tools zu installieren, etwa mySQLDumper. Egal, es hilft ja nicht weiter, sich zu streiten, nach 20 Minuten war das Gepräch beendet.

Im übrigen wird mit dem “WebDatabase Manager” (phpMyAdmin) als “Strato Profi Feature” geworben, dann sollte sowas auch richtig und vor allem zuverlässig funktionieren. Und auch die Tatsache, das der Datenexport mit Zip-Komprimierung funktioniert, hilft nicht wirklich weiter, denn beim Datenimport wird Zip nicht unterstützt.

Die Ursache

Irgendeinen Grund muß es ja haben, das bei mir, und auch beim zweiten Support-Mitarbeiter die GZip-komprimierung fehlschlägt. Mehr durch Zufall bin ich dann drauf gestoßen, denn überraschenderweise trat genau das Problem auch bei meiner lokalen phpMyAdmin-Installation auf, die noch eine relativ alte 2.6er Version war (2.6.3, bei Strato immer noch 2.6.4).

Sollte es doch irgendwie am Client, sprich Browser, liegen? Also probierte ich die GZip-Sicherung mal testweise mit dem Internet-Explorer und siehe da, alles ist bestens. Hmmm, eigentlich hatte das immer auch mit dem Firefox funktioniert, warum denn nun auf einmal nicht mehr? Könnte es am neuen Firefox 3 liegen, lange Zeit noch hatte ich den 2er in Benutzung. Die Vermutung bestätigt sich nach einem kurzen Test, auch mit dem Firefox 2.x gibt es keine Probleme, eine ordentliche GZip-Datei wird gespeichert.

Der Rest ist dann schnell ermittelt, es gibt tatsächlich eine Problem mit phpMyAdmin und dem Firefox der 3er Reihe im Zusammenhang mit GZip, welches vermutlich bei allen phpMyAdmin-Versionen bis Version 2.11.6 auftritt und mit Version 2.11.7 gefixt wurde.

Und was kann Strato nun dafür? Ganz einfach, die haben da einen mehr als drei Jahre alten phpMyAdmin zu laufen, auf den sich der Kunde möglicherweise verläßt. Dabei schreibt Strato in den FAQ zu phpMyAdmin sogar unter Anmerkung, daß man regelmäßig, etwas einmal jährlich, Updates bereitstellen will:

Evtl. auftretende Sicherheitsrisiken oder bekannte Bugs in phpMyAdmin werden von uns selbstverständlich sofort entfernt.
Updates oder Versionsänderungen werden voraussichtlich einmal im Jahr durchgeführt.

Im übrigen sieht es bei 1&1 bezüglich der Datenbanksicherung auch nicht besser aus, dort läuft ebenfalls noch die alte phpMyAdmin-Version 2.6.4-pl3 als “MySQL-Control-Center” und auch dort funktioniert der Export mit GZip-Komprimierung nicht. Immerhin gibt es bei 1und1 noch eine funktionierende BZip-Kompression, die man dann sogar wieder importieren kann.

Keine Probleme gibt es hingegen bei All-Inkl, da läuft phpMyAdmin in der Version 2.11.7 und Host-Europe mit dem der fast ganz akuellen 2.11.9.1er Version.

Fazit

Zunächst muß ich mir an die eigene Nase fassen, denn man sollte grundsätzlich überprüfen, ob die Datenbanksicherung auch tatsächlich lesbar ist. Nur darauf zu vertrauen, das alles geklappt hat, wenn die Datei auf dem eigenen Rechner liegt, reicht nicht.

Andererseits muß ich die Nutzer von Shared-Webhosting-Paketen bei Strato und 1und1 davor warnen, auf die vorinstallierten Datenbanktools der Anbieter zu vertrauen. Die derzeit dort laufende phpMyAdmin-Version 2.6.4-pl3 ist mehr als drei Jahre alt und hat reproduzierbare Fehler, die zu Datenverlusten führen können.
Man sollte sich entweder selbst eine aktuelle phpMyAdmin-Version installieren oder auch andere Werkzeuge zur Datenbanksicherung, wie mySQLDumper, verwenden.