Schnurpsel 

Ticket 1034031

Manchmal bekommt man Antworten auf Fragen, die man gar nicht gestellt hat.

So kam vor einer Woche eine E-Mail vom Strato-Support zum oben genannten Ticket. Also von mir ist das nicht, meine letzte Supportanfrage war im Dezember 2008 und damals ging es um das Problem mit dem Datenbank-Backup und der veralteten und damit fehlerhaften phpMyAdmin-Version.

… wir möchten Sie mit dieser E-Mail über den Bearbeitungsstand Ihres Troubleticket informieren.
Ich habe Ihre Internetpräsenz aufgerufen und dabei festgestellt, dass die Ladezeiten aktuell im Rahmen liegen.

Die Frage ist, welche Internetpräsenz er aufgerufen hat. Wenn es meine Strato-Hauptdomain, als Schnurpsel-Seite hier ist, dann wundert es mich nicht, daß “die Ladezeiten aktuell im Rahmen liegen”. Schließlich bin ich vor ein paar Monaten mit der Seite umgezogen.

Punktuelle Engpäße können wir im Shared Webhosting Bereich leider nicht ganz ausschliessen. … Mit dem Wordpress-Plugin Super Cache oder DB Cache kann die Anzeige der Seiten von Wordpress beim wiederholten Aufruf des Benutzers beschleunigt werden. In den entsprechenden Foren und auf der Seite von Wordpress finden Sie dazu weiterführende Hinweise. …

usw. usw.

Naja, komische Sache, mit dem Ticket, daß mir nicht gehört. Vielleicht wurde pauschal an alle Kunden, die Wordpress nutzen, sowas verschickt. Keine Ahnung.

Noch zwei Interessenten für Strato

Nachdem sich Strato-Eigentümer Freenet bereits vom DSL-Geschäft getrennt hat, möchte man auch die Webhosting-Sparte los werden. Nur noch zwei Bieter sind im Rennen, die Interesse an Strato haben, die Deutsche Telekom und United Internet. United Internet hat bereits mit 1&1 einen direkten Strato-Konkurrenten im Hostingbereich am Markt.

Auch wenn ich mich hier bei Schnurpsel technisch und inhaltlich mehr und mehr von Strato entferne, habe ich immer noch die leise Hoffnung, daß sich vielleicht mit einem Besitzerwechsel bezüglich des Strato-Shared-Webhostings performancemäßig alles zum Guten wendet. Zumindest für größere PHP-Projekte wie Wordpress oder Joomla kann man im Moment von Strato nur abraten.

Update durch Downgrade 2.0

Auch wenn ich zumindest Wordpress-technisch gesehen mit meiner Schnurpsel-Seite Strato den Rücken gekehrt habe, habe ich nicht gleich das ganze Webhosting-Paket (PowerWeb Advanced) aufgegeben. Die Seite wird halt nur per DNS umgeleitet, weil ich die PHP-Performance im Moment bei Strato für nicht akzeptabel halte.

Das hält mich aber nicht davon ab, mal eben ein Update des Paketes vorzunehmen. Wer weiß, vielleicht wird auch bei Strato das PHP mal schneller und ich habe aus SEO-Kreisen gehört, daß es nicht verkehrt ist, Seiten bei verschiedenen Anbietern zu haben, um z.B. Linknetzwerke aufzubauen.

Wie schon beim letzten mal, kann man das Update nicht mit ein paar Klicks im Kundenmenü bewerkstelligen, weil man dort nur in höherwertige und damit teurere Hostingpakete wechseln kann. So bleibt nur der Weg über ein “Downgrade” per FAX, um quasi das Paket zu behalten und nur auf den aktuellen Stand zu bringen. Was bringt das nun konkret? Hier mal ein paar Paket-Leistungsdaten im Vergleich:

Für 9 Cent weniger im Monat und nur noch einem halben Jahr Mindestvertragslaufzeit gibt es einiges an Mehrleistung. Schneller ist damit aber leider nichts geworden.

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.

410 Gone – der SEO-technische Supergau

Lange Zeit habe ich ja die Strato-Fahne hochgehalten. Als es früher noch viele Schwierigkeiten mit wenig PHP-Speicher und Safemode, nicht vorhandenem mod_rewrite, falscher Artikelreihenfolge oder ominösen Endlosweiterleitungen gab (zum Teil auch noch gibt), habe ich stets nach Lösungsmöglichkeiten gesucht, diese meist gefunden und auch anderen, leidgeplagten Strato-Nutzern zur Verfügung gestellt.

Selbst über das fehlerhafte Datenbank-Backup konnte ich noch hinwegsehen, hat mich zwar geärgert, aber letztendlich war ich an der Sache ja selbst nicht ganz unschuldig. Schon länger stört mich allerdings die schlechte Gesamtperformance von Wordpress auf meinem Strato-Sharedwebhosting-Paket. Nun hab ich zwar herausgefunden, daß es wohl nicht an einer langsamen Datenbank liegt, wie meist angenommen wird, aber wirklich helfen tut diese Erkenntnis auch nicht.

Hier kommt zunächst ein kleiner Exkurs in die HTTP-Statuscodes. Jeder Aufruf einer Webseite (Request) wird vom Server mindestens mit einem Statuscode beantwortet (Respond), Wenn z.B. alles in Ordnung ist, kommt ein Status 200 OK zurück. Bei Fehlern gibt es mehrere Möglichkeiten, normale Fehler werden mit einem 4xx-Code beantwortet, zwei davon will ich kurz erläutern.

404 Not found

Der wohl am häufigsten auftretende Fehlercode dürfte 404 Not Found sein:

404 Not Found
The requested URL /blafasel was not found on this server.

Das dürfte wohl in der oder anderer Form jeder schon mal gesehen haben. Dieser 404 ist ein sehr allgemeiner Fehlercode. Der Server hat zwar einen technisch gesehen einwandfreien Request erhalten, kann aber das Gewünschte aus nicht näher bekannten Gründen nicht finden. Möglicherweise hat der Nutzer nur eine falsche URL in der Adresszeile der Browsers eingetippt oder der Webmaster der Seite versehentlich eine Datei gelöscht.
Der Aufrufende darf aber gern später noch mal probieren, ob der Fehler vielleicht nicht mehr auftritt.

410 Gone

Ganz ähnlich, aber von der Bedeutung her anders ist der Fehler 410:

410 Gone
The requested resource /blafasel is no longer available on this server and there is no forwarding address. Please remove all references to this resource.

Auch hier ist der Request technisch OK. Das Gewünschte gab es zwar mal, es ist aber absichtlich entfernt worden. Spätere Anfragen sind zwecklos, das Gesuchte wird es hier nicht mer geben.
Diesen Fehlercode 410 sendet der Webserver nicht einfach so, das muß vom Webmaster schon explizit und bewußt so konfiguriert sein.

Es kann durchaus sinnvoll sein, den Code 410 zu übermitteln, z.B. dann, wenn man nicht möchte, das eine Seite oder ein Bild weiterhin in den Suchergebnissen der Suchmaschinen erscheint. Und man teilt dem interaktiven Nutzer einfach mit, daß er sich keine Hoffnungen machen braucht, die Seite irgendwann mal wieder zu Gesicht zu bekommen.

DNS-Umleitung bei Strato

Weil die Seite hier nun immer so langsam ist, dachte ich mir, sie einfach per DNS auf einen schnelleren Webserver aufzuschalten. Das geht im Strato Kundenmenü auch ganz einfach mit Einstellungen->Domainverwaltung->DNS-Verwaltung. Eine andere IP-Adresse für den A-Record eintragen, fertig. Der folgende Hinweis wird angezeigt:

Hinweis: Bitte beachten Sie, dass Änderungen an diesen Einstellungen auf Grund der dezentralen Struktur von DNS, erst spätestens 24 h nach Aktivierung vollständig aktiv sein werden.

Gut denke ich, das ist auch kein Problem, schließlich liegen auf dem alten und neuen Server identische Kopien des Blogs. Dann wird halt erstmal noch die Seite bei Strato aufgerufen, ist auch kein Beinbruch.

Aber denkste! Als ich nach fünf Minuten probieren will, ob die DNS-Server vielleicht schon aktualisiert sind, das geht eigentlich meist recht schnell, sehe ich nur das:

410 Gone
The requested resource / is no longer available on this server and there is no forwarding address. Please remove all references to this resource.

Schock! Was soll das denn bitte? Warum wird nicht allen noch bei Strato eingehenden Requests für schnurpsel einfach alles wie bisher angezeigt, ich habe da doch nichts gelöscht.
Nö, stattdessen wird den Nutzern und Suchmaschinen-Bots mitgeteilt:

“Ja, hier bei Schnurpsel gab es mal was, das ist aber alles auf nimmer Wiedersehen verschwunden, hat sich aufgelöst, ist ins Web-Nirwana entfleucht. Kommt am Besten gar nicht mehr wieder, hier ist eh nichts mehr zu holen.”

Super, nicht auszudenken, wenn die DNS-Server tatsächlich erst nach 24 Stunden aktualisiert worden wären. Glücklicherweise hat es nur eine halbe Stunde gedauert, aber ein Ding ist es schon, was Strato da einfach macht. Bei meiner Testseite hier ist das kein Drama, wer aber eine richtige, wichtige Webseite bei Strato hostet, kann schon Probleme bekommen.

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.