Mein ursprüngliches Ziel mit diesem Schurpsel-Blog hier ist schnell benannt. Ich konnte das ewige Rumgenörgel im Wordpress-Deutschland-Forum bezüglich Wordpress und Starto nicht mehr hören (lesen). Also habe ich ein Hostingpaket bei Strato bestellt um selbst zu sehen, was an den ganzen Kritiken dran ist.

Probleme und Lösungen

Ja, die meisten Kritikpunkte am Stratohosting des Sommers 2007 waren durchaus berechtigt. Das für die Permalinks notwendige mod_rewrite war nicht verfügbar, der PHP-Speicher mit 8MB recht knapp bemessen, durch eine fehlerhafte Server-Konfiguration wurden Endlosschleifen produziert und die gesamte Performance der Webseiten war nicht gerade berauschend.

Im Großen und Ganzen habe ich mein Ziel erreicht. Durch Plugins, Konfigurationseinstellungen und Hacks habe ich Wordpress auch beim Strato-Webhosting zufriedenstellen zum Laufen bekommen, auch mit Permalinks und ohne Endlosschleife. Eigentlich wäre das der Zeitpunkt gewesen, die Blogaktivitäten hier bei schnurpsel.de einzustellen.

Aber wie das so ist, es tauchen neue Probleme auf und auch so ganz allgemein ist ein Zweitblog zum Testen und Probieren ganz praktisch.

Kurzfristige Nahziele

Wenn SEO-Wettbewerbe laufen, wie aktuell das iPhone4Spiel, dann möchte ich mit meinem Schnurpsel-Test-und-Probierblog natürlich so weit wie möglich nach vorne kommen, am besten auf Platz 1. Allerdings investiere ich nicht wirklich viel in solche Aktionen. Ich registriere keine Keyword-Domain, befülle nicht 100 Blogs mit automatischen Texten und kippe auch nicht täglich “Pressemeldungen” in News-Portalen ab. Insofern habe ich da auch kaum eine Chance, aber es gibt doch immer wieder Interessantes zu beobachten. Ich freue mich auch immer über nofollow-Links als Dankeschön oder Quellenangabe.

Außerdem will ich immer der Erste mit einer Meldung sein, wenn es wichtige Neuerungen bei Google und dort speziell bei der Bildersuche gibt. Manchmal schaffe ich das sogar, wie beim geheimen imagesite-Paramter. :-)

Langfristige Fernziele

Ich will auch in Zukunft den leidgeplagten Wordpress-bei-Strato (1&1, Host-Europe, All-Inkl) Nutzern mit Rat und Tat zur Seite stehen. Dazu muß ich natürlich mit den relevanten Suchbegriffen bei Google gefunden werden. Als kann das Fernziel nur lauten. Platz 1 bei Google. :-)

Erst begrüßt mich die Loginseite des Strato-Webhostig mit dieser Meldung.
Na gut denke ich, kann ich ja mal schnell mein Profilbild bei Twitter ändern. Ich finde ja eigentlich die Schwarz-Rot-Gelben-M&Ms schöner als die Pusteblume. Aber denkste:

Bei Strato kann ich mich mittlerweile wieder einloggen, die Wartungsarbeiten bei Twitter dauern aber noch an.

Nachtrag 11:15 Uhr:
Zu früh gefreut, Strato geht immer noch nicht:

“… bedauerlicherweise sind für Ihr Kundenkonto Zahlungsschwierigkeiten aufgetreten. Aus diesem Grund sehen wir uns leider gezwungen, einige Dienste einzuschränken.
Möglicherweise haben wir nicht Ihre aktuellen Daten und konnten daher die Lastschrift nicht durchführen. Bitte überprüfen Sie unter Kundenbetreuung – Ihre Kundendaten Ihre Bankverbindung, Ihre Anschrift und Ihre E-Mail-Adresse …”

Nur habe ich keine Daten geändert, das Konto ist auch nicht leer und die Abbuchung hat in den letzten Jahren immer problemlos geklappt. Allerdings konnte ich auch auf die Schnelle keine Einschränkungen bei den Diensten feststellen, wie im Text angemerkt wird. Meine Webseite ist normal erreichbar. Wäre aber auch ein Unding, wenn gleich beim ersten Zahlungsproblem elementare Funktionen eingeschränkt wären.

Aber da ich schon mal vor Jahren bei 1&1 bis zur dritten Mahnung mit Androhung von Inkasso bzw. Rechtsanwalt gekommen war, wollte ich die Sache nicht auf sich beruhen lassen, auch wenn das Problem offensichtlich nicht bei mir liegt. Ein kurzer Anruf beim Strato-Kundenservice bestätigt dann auch meine Vermutung, daß es sich um ein technisches Problem in der Buchhaltung handelt.

Bei 1&1 war es damals auch ein firmeninternes Problem. Ich hatte 2001 meine neue Bankverbindung ordnungsgemäß im Kundenmenü eingetragen und die Abbuchung der monatliche Beträge funktionierte auch ohne Probleme vom neuen Konto. Etwa ein Jahr später habe ich dann das Webhosting-Paket gewechselt und mir für 6 Euro Versandkosten die dazugehörige Software zuschicken lassen. Allerdings versuchte 1&1 nun, warum auch immer, diesen Betrag von meinem alten Konto abzubuchen, was natürlich fehl schlug.

Nach einigen Telefonaten und weiteren Mahnungen habe ich dann die 6 Euro selbst überwiesen, da die das mit der Abbuchung nicht auf die Reihe bekommen haben. Vermutlich steht in meinem Versandkonto oder wo auch immer jetzt noch meine alte Bankverbindung drin. Naja, diese Softwarezugaben braucht man auch nicht wirklich, da kann ich auch drauf verzichten.

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.

Seit heute scheint das weiter unten geschilderte Problem mit der Remote-Adresse nicht mehr zu bestehen. Die Einträge in der .htaccess-Datei oder sonstige Eingriffe sind daher möglicherweise nicht mehr erforderlich.
Bei mir ist das Problem verschwunden, aber offensichtlich noch nicht generell.

Seit Anfang Dezember 2009 bin ich mit meiner Schnurpsel-Seite wieder zurück zu Strato umgezogen. Ganz weg war ich ja nicht, ich hatte nur den Hostnamen bei einem anderen Anbieter aufgeschaltet. Aber seit es nun SpeedPlus bei Strato gibt, bin ich nun doch wieder zurückgekehrt.

Die Geschwindigkeit ist wirklich gut. Antwortzeiten von ungefähr 0,5 Sekunden gegenüber 3 bis 4 Sekunden vorher sind für ein PHP-Schwergewicht wie Wordpress eine merkliche Verbesserung. Zudem wurde auch gleich das ohne-www-Problem beseitigt, in der Umgebungsvariable HTTP_HOST steht nun der tatsächlich im HTTP-Request angegebene host drin.

Die Remote-IP-Adresse (REMOTE_ADDR)

Neben allerlei anderen interessanten Informationen wird bei jedem Webseitenaufruf auch die IP-Adresse des Aufrufers in einer Umgebungsvariablen vermerkt. Auf diese kann z.B. mit Skriptsprachen wie PHP oder Perl als Variable “REMOTE_ADDR” zugegriffen werden. Diese Remote-Adresse ist z.B. für statistische Auswertungen interessant oder kann beim Aussperren unerwünschter Zugriffe (Spam-Bots) helfen.

Allerdings zählt diese IP-Adresse ja nach Auffassung und Auslegung der Gesetze zu den personenbezogenen Daten und dürften dann eigentlich nicht gespeichert werden. Bei Strato werden die IP-Adressen in den den Kunden zur Verfügung gestellten Serverlogdateien in anonymisierter Form gespeichert. Auch die im Kundenmenü anzeigbare Webseiten-Statistik greift auf diese Daten zurück.
So können die Zugriffe zwar unterschieden aber nicht einem konkreten Anschluß zugeordnet werden

Mehr Geschwindigkeit mit SpeedPlus

Wenn ich die Grafik zu SpeedPlus bei Strato richtig deute, werden die Zugriffe nicht mehr direkt auf die Webserver geroutet, sondern von einem Loadbalancing-Cluster lastabhängig verteilt.
Diese Verteilung funktioniert vermutlich ähnlich wie bei einem nicht-transparenten Proxy, denn für den Webserver sieht es so aus, als würde der Strato-interne Server die Seite anfordern. Genau deshalb steht in der Remoteadresse nicht mehr die IP-Adresse des Aufrufers drin, sondern eine 81.169.145.xxx drin.

Komischerweise tritt der Effekt aber nicht bei allen Domains auf, nur die Hälfte meiner Domains (inkl. Subdomains) bei Strato ist davon betroffen.

Die richtige Remoteadresse ermitteln und setzen

Ich wäre ja nicht Schnurpsel, hätte ich nicht bereits eine Lösung für das Problem parat :-)
Die richtige IP-Adresse findet man im Request-Header-Feld X-Forwarded-For, daß heißt der Strato-Server trägt hier die Adresse ein, von der er die Anforderung erhalten hat.

In Skriptsprachen wie PHP oder Perl steht diese Variable als “HTTP_X_FORWARDED_FOR” zur Verfügung. Hier könnte man sich die Remote-Adresse also einfach möglichst am Anfang (bei WP z.B. in der wp-config.php) der Abarbeitung in die REMOTE_ADDR eintragen, z.B. so:

if( isset( $_SERVER['HTTP_X_FORWARDED_FOR'] ) ) {
  $ip_addr = @trim( @end( @explode( ",", $_SERVER['HTTP_X_FORWARDED_FOR'] ) ) );
  if( '' != $ip_addr )
    $_SERVER['REMOTE_ADDR'] =  $ip_addr;
}

Hier kommen zwei wichtige Aspekte zum Tragen, denn in “X-Forwarded-For” können mehrere durch Komma getrennte IP-Adressen stehen, sofern unterwegs mehrere Proxies durchlaufen wurden. Außerdem soll die Adresse nicht überschrieben werden, falls kein X-Forwarded-For-Feld existiert oder aus anderem Grund nicht ermittelt werden kann.

Für Perl könnte das etwa so aussehen:

if( $ENV{'HTTP_X_FORWARDED_FOR'} ne "" )
{
  my @ip_list = split(/,/, $ENV{'HTTP_X_FORWARDED_FOR'});
  $ENV{'REMOTE_ADDR'} = $ip_list[-1];
}

Nachteil ist hierbei natürlich, daß man alle Webapplikationen, die irgendwie die REMOTE_ADDR verwenden, entsprechend anpassen muß. Es geht aber auch noch einfacher und allgemeiner.

Umgebungsvariablen mit mod_setenvif setzen

Das Apache-Modul mod_rewrite kennen bestimmt viele Wordpress-Nutzer, manch einer kennt vielleicht sogar mod_alias, aber vermutlich nur wenige haben schon mal etwas vom Modul mod_setenvif gehört. Es kommt auch ganz bescheiden und unspektakulär mit nur vier Anweiungen daher.

Mit dem Modul mod_setenvif hat man die Möglichkeit, Umgebungsvariablen abhängig von Request-Feldern zu setzen. Genau das brauchen wir hier. Wir haben das Request-Feld X-Forwarded-For und wollen abhängig davon die Umgebungsvariable REMOTE_ADDR setzen. Das Problem läßt sich mit ein bißchen Regular-Expression in einer Zeile in der .htacces erschlagen:

SetEnvIf X-Forwarded-For "(.+,)? *(.+)$" REMOTE_ADDR=$2

Optimalerweise steht diese Zeile ganz am Anfang einer .htaccess im Wurzelverzeichnis des Webpaketes. Dann wirkt sei auch auf alle Domains oder Subdomains, die ihr sichtbares Wurzelverzeichnis in einem Unterverzeichnis des Webspace haben.

Das schöne an diesem kleinen Eingriff ist, daß er auch auf das Serverlogfile und die Webstatistik wirkt. Im Logfile stehen nun wieder zwar anonymisierte, aber unterscheidbare Zugriffe und die Webstatistik zeigt nicht mehr 10000 Zugriffe von nur 5 Adressen an.

Ende gut, alles gut?

Mit ein bißchen Handarbeit kann man wieder mal einen Strato-Konfigurationsfehler ausbügeln. Andereseits ist die SpeedPlus-Plattform noch recht neu, da können solche Fehler schon mal auftreten. Ich habe das Problem auch bereits vor 10 Tagen an den Strato-Support gemeldet, warte aber immer noch auf die Antwort zu meinem Ticket. Scheint etwas komplizierter zu sein. Bis zur Strato-Problemlösung kann mein kleiner “Trick” zumindest über die Zeit helfen.

Und nun kommt auch schon die schlechte Nachricht. Von SpeedPlus profitieren derzeit nur Webhostingpakete der PowerPlus-Klasse. Mit BasicWeb und DynamiX guckt man geschwindigkeitsmäßig weiterhin in die Röhre.

Zwar werden in der Pressemitteilung nur die Neukunden erwähnt, aber teilweise werden wohl auch Bestandskunden mit den passenden Tarifen umgestellt. So erhielt ich vorhin einen Anruf vom technischen Support bezüglich meines Tickets 1034031, welches ich angeblich am 16.11. durch eine telefonisch Anfrage initiiert haben soll. Ich bin zwar manchmal etwa vergeßlich aber in dem Fall sehr sicher, daß ich da nicht angerufen hatte. Aber egal, zumindest wurden vom Support ein paar technische Fragen zur Umstellung geklärt und eine halbe Stunde später ging mit meiner Wordpress-Testinstallation richtig die Post ab.

Antwortzeiten von etwa einer halben Sekunde gegenüber 3 bis 4 Sekunden vorher sind schon eine angenehme und merkliche Verbesserung. Zudem wurde das ohne-www-Problem beseitigt, es wird also im HTTP_HOST der tatsächlich im Request angegebene host zurückgeliefert.

Im Moment gibt es eigentlich nur noch einen Grund, der mich davon abhält, mit meiner Schnurpsel-Seite wieder zu Strato zurück umzuziehen. Der hoffnungslos veraltete und damit fehlerhafte WebDatabaseManager in Gestalt von phpMyAdmin-Version 2.6.4-pl3 ist nun wirklich keine Glanzleistung für einen der großen Webhoster in Deutschland.

Vielleicht gibt es ja auch noch ein Update für den “WebDatabaseManager”, dann könnte man sogar Strato mit den PowerPlus-Webhostingpaketen für Wordpress empfehlen. Das kleinste PowerPlus-Paket, welches ich hier selbst habe, kostet übrigens derzeit 6,90 Euro und ist mit der aktuellen Aktion bis zum 31.12. für die ersten 6 Monate umsonst.

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.

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.

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.

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.

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.

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.

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.

So konnte ich hier erstmal testen, ob meine eigenen Plugins funktionieren. Ja, das tun sie. Wobei ich das eine oder andere an die neuen Möglichkeiten von Wordpress 2.5 anpassen werde oder schon angepaßt habe. Zudem ist mir grad ein nettes Feature aufgefallen, wenn man Tags (Stichwörter) eingeben will. Dann klappt nach Eingabe von mindestens zwei Zeichen eine Auswahlliste auf, aus der man dann einfach ein passendes, schon vorhandenes Stichwort auswählen kann. Fein Sache, das.

Seit kurzem unterstützt Strato das für Permalinks wichtige Modul mod_rewrite. Bisher mußte man sich da mit Tricks, wie einem vorangestellten index.php oder dem Fehler 404 Plugin behelfen. Jetzt funktioniert das einfach so, wie es von Wordpress selbst vorgesehen ist, über ein paar mod_rewrite-Regeln.
Wenn Strato jetzt noch die Datenbank-Performance verbessert, könnte man aus Wordpress-Sicht schon fast rundum zufrieden sein.

Nachtrag 09.04.2008: Seit heute findet man auch einen entsprechenden Artikel zu mod_rewrite in den Strato-FAQ.

Ab sofort können Sie Ihre Homepage als klimafreundlich kennzeichnen. Mit dem Umweltsiegel haben Sie die Möglichkeit, Ihr Umweltengagement auch im Netz zu zeigen und damit ein klares Statement für den Klimaschutz abzugeben.

Und dann kann man da auch gleich ein schönes Logo einbinden. Wenn man dem Link [Jetzt Logo einbinden ->] folgt, wird ein Imagelink zu einem fertigen Umweltlogo angezeigt. Als GIF-Bild in fester Größe und noch nicht mal der Hintergrund ist freigestellt und transparent. Wenn man es nicht zufällig grad auf eine weiße Fläche pappen will, sieht das schon mal besch… aus. Und mit der Größe paßt es möglicherweise auch nicht.
Aber die Rettung liegt nur ein paar Klicks entfernt, in Form einer EPS-Datei im Pressebereich bei Strato (ganz unten in der Liste). Damit kann man doch schon etwas mehr anfangen. So habe ich den Hintergrund transparent gemacht und alles auf meine gewünschte Breite von 150 Pixeln gebracht. Im PNG-24-Format bleiben auch die Rundungen schön rund, es sieht so einfach harmonischer aus. Und da nun das Kubrick-Blau nicht so recht dazu passen mag, habe ich den Rest der Seite auch noch begrünt. Jaaaa, der Frühling steht ja fast schon vor der Tür.

Über denn Sinn und Zweck eines solchen Logos läßt sich zwar streiten, was Strato damit sagen will, kann man hier nachlesen. Da ich aber sonst mit Buttons und Logos eher zurückhaltende bin und dies hier mehr eine Art Testseite ist, dachte ich, kann ich mir es mal leisten, so ein Teil auf die Seite zu nehmen.

Zunächst wird eine neue statische Seite erstellt, die z.B. “Kontakt” heißt. Hier wird der Text und Code für den Formmailer eingegeben. Die URL der Seite lautet dann beispielsweise

http://schnurpsel.de/kontakt/

Diese wird bei den Einstellungen für den DD-Formmailer als “Contact page” eingetragen.

Dann wird eine Kopie der Datei index.php aus dem Wordpress-Wurzelverzeichnis erstellt und bearbeitet.
Originale index.php:

<?php
/* Short and sweet */
define('WP_USE_THEMES', true);
require('./wp-blog-header.php');
?>

Bearbeitete index.php:

<?php
/* Short and sweet */
define('WP_USE_THEMES', true);
require('../wp-blog-header.php');
?>

Kleine Änderung, große Wirkung, es ist nur ein Punkt beim require hinzugekommen.
Nun wird per FTP im WP-Wurzelverzeichnis ein Unterverzeichnis /kontakt/ angelegt und die geänderte index.php dort hinein kopiert.

Das wars, jetzt kann man die Kontaktseite aufrufen und Daten absenden, sofern man sonst auch alles andere beim DD-Formmailer richtig konfiguriert hat.
Man kann das auch bei mir hier testen, unter Kontakt, wo sonst? :-)

Und zum Schluß noch ein wichtiger Hinweis: Falls man im WP-Wurzelverzeichnis eine php.ini hat, muß diese ebenfalls mit in das /kontakt/-Verzeichnis kopiert werden, denn im Unterschied zur .htaccess werden die dort gemachten Einstellungen nicht auf Unterverzeichnisse “vererbt”.

Besonders wichtig ist das Update aber für das kleinste PowerWeb-Paket, früher “XE”, jetzt “Basic”. Denn im Unterschied zum alten XE-Paket, welches ganz ohne PHP und Datenbank auskommen mußte, gibt es im neuen Einsteigerpaket “PowerWeb Basic” endlich eine Datenbank und auch PHP. So kann nun auch mit diesem Paket ein richtiges Wordpress genutzt werde :-)

So dachte ich mir, feine Sache, dann kann ich ja sicher mein altes “PowerWeb A” mit ein, zwei Klicks auf das neue “PowerWeb Advanced” updaten. Als flux im Kundenmenü die “Vertragsbetreuung” aufgerufen und “Paket upgraden” ausgewählt. Aber nichts da, ein Upgrade geht nur auf ein teureres Paket, das nächste wäre das “PowerWeb Pro” für 9,99€, aber das will ich nicht. Dann gibt es ja noch bei “Ihr Vertrag” den Menüpunkt “Paketwechsel (Downgrade)”, aber das wird es ja woöh nicht sein. Ich will ja nicht ein kleineres Paket, sondern nur ein bißchen mehr Leistung zum selben Preis. Naja, halt ein Update.

Ja wie nun, geht das etwa gar nicht? Auch im WP-Forum gab es bereits eine kleine Diskussion dazu. Und siehe da, es geht doch über ein “Downgrade”. Und auch nicht mit ein paar Klicks, sondern nur per Fax mit Unterschrift. Na egal, hab ich also das Fax hingeschickt, am nächsten Tag kam die Bestätigung und noch einen Tag später war die Umstellung erledigt.

Man sollte aber beachten, daß eventuell aus Sonderaktionen bestehende Vergünstigungen wegfallen und auch unbedingt vor der Umstellung alle Daten (nebst Datenbank) zu sichern sind (ein entsprechender Hinweis steht auch auf dem Fax-Formular). Und die Vertragslaufzeit beginnt dann für das neue Paket neu zu laufen.