Das Putzlowitsch Test- und SEO-Blog

STRATO Wartungsarbeiten ausgefallen?

Strato Wartungsarbeiten Nov 2010

Eigentlich hätten heute früh zwischen 4 und 7 Uhr bei Strato Wartungsarbeiten stattfinden sollen. Diese wurden bereits vor etwa einer Woche angekündigt. Dabei wären sowohl die Websites als auch die E-Mail-Dienste nicht verfügbar gewesen. Allerdings konnte ich für diesen Zeitraum keine Ausfälle beobachten.

Ich hatte mir extra den Wecker auf kurz vor Vier gestellt und dann regelmäßig geprüft, ob meine schnurpsel.de-Seite hier irgendwelche Ausfallerscheinungen zeigt. :-)

Nein, hatte ich nicht. Ich bin heute ganz normal gegen 6.30 Uhr aufgestanden, habe gefrühstückt und ein wenig Zeitung gelesen (mehrer Seiten Wikileaks-Diplomatie-Dokumente). Zumindest war die Seite gegen 8 Uhr normal verfügbar.

Wie der Zufall es will, ist derzeit der archive.org-Bot auf Schnurpsel zugange. So brauchte ich nur einen Blick in die Serverlogdatei werfen um zu sehen, daß es praktisch keine Ausfälle gab. Im regelmäßigen fast Minutentakt finden sich dort im fraglichen Zeitraum Logeinträge vom archive.org_bot, die allesamt mit „200 OK“ quittiert wurden. Also können wartungsbedingte Ausfälle bestenfalls im unteren Minutenbereich aufgetreten sein.

Entweder hat Strato nun doch keine planmäßigen Wartungsarbeiten durchgeführt oder es lief alles so gut und schnell, daß davon nicht zu merken war.

Keine Kommentare »

STRATO Wartungsarbeiten am 30.11. von 4 bis 7 Uhr

Strato Wartungsarbeiten Nov 2010

Grad eben hat mich Strato wieder mal mit einer großen, roten Warnmeldung erschreckt. Scheint so, als würde man dort Großes vorhaben. Neben der Nichterreichbarkeit der Webpräsenzen ist in dieser Zeit auch kein Empfang oder Versand von E-Mails möglich. Vermutlich wird auch der Login im Kundenmenü nicht funktionieren.

Gut, der Ausfall für drei Stunden am frühen Morgen ist für mich nicht wirklich schlimm, schließlich ist das hier sowieso nur eine Test-Website („Das Putzlowitsch Testblog für alles mögliche“). Wer aber seine richtige Webpräsenz bei Strato hostet, für den könnte es schon ärgerlich sein. Insbesondere auch denn, wenn man viele Besucher aus anderen Teilen der Erde hat, wo es dann halt nicht früh morgens, sondern mitten am Tag ist.

Vielleicht sind die 3 Stunden ja auch eher etwas großzügig angesetzt und in Wirklichkeit dauert der Ausfall nicht so lange. Wie auch immer, wer also meine Schnurpsel-Seite hier am nächstens Dienstag früh zwischen 4 und 7 Uhr aufrufen will muß damit rechnen, daß nicht zu sehen ist.

Weitere Artikel mit Bezug zu diesem:
Ein Kommentar »

Mit Bing die Server-Mitbewohner finden

Vor ein paar Tagen hatte ich schon etwas zu Bing geschrieben. Das will ich jetzt nicht zum aktuellen Thema des Webmaster-Friday „bing – Wichtig oder überflüssig?“ wieder aufwärmen. Dabei bin ich aber auf die Liste der Bing-Suchparameter gestoßen und eine Sache ist mir in der Liste besonders aufgefallen, die Suche nach einer IP-Adresse.

Bing IP-Suche

Bing schreibt dazu:

Sucht nach Websites, die von einer bestimmten IP-Adresse (Eine spezifische Adresse für einen Computer im Internet.) gehostet werden. Bei der IP-Adresse muss es sich um eine punktierte Vierergruppenadresse handeln. Geben Sie das Schlüsselwort ip:, gefolgt von der IP-Adresse der Website, ein.

Als Ergebnis erhält man nicht nur Treffer zu Domains, sondern auch zu konkreten Unterseiten, wobei zum Anfang zunächst hauptsächlich die Domains angezeigt werden. Eine IP-Suche gibt es bei den anderen großen Suchmaschinen wie Google oder Yahoo meines Wissens nicht.

Es existieren zwar spezielle Dienste, die auch die Hosts zu einer IP-Adresse auflisten. Oft muß man sich dort aber Anmelden, um nicht nur die ersten paar Treffer zu Gesicht zu bekommen.

Zum praktische Nutzen kann ich nicht viel sagen, finde es aber mal ganz interessant zu wissen, mit wem man sich einen Server teilt. Wobei „Server teilen“ technisch nicht ganz korrekt ist, man müßte eher sagen, mit wem man sich eine IP-Adresse teilt. Mit dem Server ist das aber anschaulicher, da kann man sich ein konkretes Gerät oder eben ein Haus mit Mitbewohnern vorstellen. :-)

Weitere Artikel mit Bezug zu diesem:
Keine Kommentare »

WordPress mit Permalinks – den Webserver entlasten

Wie WordPress Permalinks verarbeitet

Durch Permalinks bekommen Artikel und Seiten lesbare URLs und auch Struktur. Alle Artikel in der Kategorie ‚Wordpess‘ können mit schnurpsel.de/themen/wordpress/ aufgerufen werden, das Monatsarchiv für Juli 2010 mit schnurpsel.de/date/2010/07/.

Auf dem Webserver existiert aber kein Verzeichnis /themen/wordpress/ oder /date/2010/07/. Damit die Seiten trotzdem aufgerufen werden können, erstellt WordPress eine einfache Regel für das Rewrite-Modul des Apache-Webservers:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

Diese drei Zeilen führen dazu, das alles, was nicht tatsächlich als Datei oder Verzeichnis auf dem Server existiert, einfach an die index.php von WordPress durchgereicht wird. WordPress kümmert sich nun darum, ob es z.B. eine Kategorie „WordPress“ gibt, stellt die Liste mit den passenden Artikeln zusammen und gibt sie aus.

Was es alles nicht gibt

Im Moment sind wohl mal wieder ein paar Bots oder Skriptkiddies unterwegs, die einfach versuchen, irgendwelche php-Skripte aufzurufen, um mögliche Sicherheitslücken ausnutzen zu können. Das sieht dann etwa so aus:

/scripts/setup.php
/pma/scripts/setup.php
/phpMyAdmin/scripts/setup.php
/phpmyadmin/scripts/setup.php
/myadmin/scripts/setup.php

Solche Dateien gibt es hier allerdings nicht. Auch andere Sachen können zu fehlerhaften Aufrufen führen, z.B. Standard-Icons wie favicon.ico oder apple-touch-icon.png, die manche Browser einfach aufrufen oder durch Nutzer aus der Bildersuche falsch kopierte BILd-URLs.

Durch die für die Permalinks notwendigen mod_rewrite-Regeln werden alle dies Aufrufe nun an WordPress weitergeleitet. WordPress wird geladen, stellt eine Datenbankverbingung her, klappert die internene Rewriteregeln ab um schließlich nur festzustellen, daß es mit dem Aufruf nichts anfangen kann. Dann gibt WordPress schließlich auch nur eine Fehlerseite aus, die möglicherweise auch noch aufwändig gestaltet ist und unnötig viel Daten als Antwort zurücküberträgt.

WordPress und den Webserver entlasten

Damit nun nicht WordPress wegen jeder Kleinigkeit behelligt werden, kann man eine spezielle Regel der WordPress-Regel vorschalten, die einfach gegebenfalls die Abarbeitung der Rewrite-Regeln beendet:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule \.[^\.]+$ - [L]
</IfModule>

Die Idee dabei ist, daß alle Permalink-URLs normalerweise keine Dateierweiterung wie .html, .jpg oder .php haben. Falls nun eine Datei nicht existiert (RewriteCond) und diese Datei mit einem Punkt und mindestens einem weiteren Zeichen endet, wird die Abarbeitung der Regeln an dieser Stelle beendet (RewriteRule). Diese Zeilen müssen vor den WordPress-Regeln stehen.

WordPress bekommt diese Aufrufe nicht mehr zu sehen, der Fehler wird einfach vom Webserver behandelt. Hier kommt dann auch eine konfigurierte und vorhanden benutzerdefinierte Fehlerseite zu Anwendung.

Ich weiß, es gibt auch Blogger, die aus welchen Gründen auch immer, die Permalinks mit einem abschließenden .html konfiguriert haben. Aber auch das ist kein Problem, es muß nur eine Zeile hinzugefügt werden, welche die Regel für die Endung .html (oder eine andere) ungültig macht:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI}	!\.html$
RewriteRule \.[^\.]+$ - [L]
</IfModule>

Optimierte Version

Mann kann die zusätzlichen Bedingungen auch direkt in die WordPress-Rules einfügen. Nachteil hierbei ist aber, daß sie bei Änderungen an den Permalinkeinstellungen verloren gehen, weil WordPress den Block zwischen # BEGIN WordPress und # END WordPress neu schreibt:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI}	!\.[^\.]+$
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Die Version mit Endung .html:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI}	!\.[^\.]+$ [OR]
RewriteCond %{REQUEST_URI}	\.html$
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Plugin-Version

Angeregt durch die Kommentare von Ralf habe ich nun eine Plugin-Version fertig gestellt.

Download: 123 Rewrite Error 0.10

Das Plugin schreibt die Regeln beim Aktivieren, Deaktivieren und bei Änderungen an der Permalinkstruktur wie bei der Optimierten Version beschrieben automtisch mit den WordPress-RewriteRules in die .htaccess. Dabei wird auch gleich berücksichtigt, ob in der Permalinkstruktur eine Erweiterung wie .html angegeben wurde.

Fazit

Wieviel Serverlast oder Traffic durch diese Maßnahme eingespart wird, kann ich nicht sagen. Das hängt sicher auch vom Nutzungsprofil und der Konfiguration der Website ab. Aber warum sollte man solch eine einfache Möglichkeiten auslassen, um WordPress und dem Webserver das Leben ein bißchen leichter zu machen.

8 Kommentare »

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.

53 Kommentare »