Das Putzlowitsch Test- und SEO-Blog

Geschwindigkeit ist keine Hexerei

Googlebot Ladezeit

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 akzeptabel. Gut, WordPress ist keine ganz kleine Webapplikation und erfordert schon einiges an Ressourcen vom Webserver, aber trotzdem ist es auch auf mittleren Shared-Webhostingpaketen vernü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.

Keine Kommentare »

BornToBeASeo – ein Plugintest

borntobeaseo

Eigentlich will ich für diese Anfrage nur testen, ob das 123 Moderate Comment Notification-Plugin auch unter WordPress 2.8.x funktioniert. Da mir kein sinnvolles Thema eingefallen ist, muß nun wieder einmal borntobeaseo für den Test herhalten.

123 Moderate Comment Notification

Mit diesem Plugin kann man festlegen, wer alles eine E-Mail erhält, falls ein Kommentar z.B. zu borntobeaseo freigeschaltet werden muß. Normalerweise bekommt nur der Admin eine solche E-Mail. In Multiautorenblogs kann es aber sinnvoll sein, das auch die Autoren selbst Kommentare (sofern sie berechtigt sind) zu ihren eigenen Beiträgen moderieren, damit der Admin entlastet wird.

borntobeaseo – bitte jetzt kommentieren :-)

Damit ich nun sehe, ob tatsächlich auch Babsi eine E-Mail bekommt, muß hier jetzt bitte jemand einen Kommentar zu borntobeaseo hinterlassen. Danke!

Keine Kommentare »

Update auf WordPress 2.8.1

Seit gestern kurz vor Mitternacht gibt es das Update für WordPress 2.8.1 (DE-Edition) und ich habe todesmutig diesmal ein automatisches Update gefahren. Falls was schief gegangen wäre, kein Drama, es ist ja nur mein WordPress bei Strato Testblog (siehe oben :-).

Es hat aber alles gut funktioniert und so bin ich hier wieder auf dem aktuellen Stand. Zumindest ein Versprechen wurde schon mal offensichlich eingelöst. Der Speicherverbrauch im Dashboard (Admin-Startseite) ist nicht unerheblich zurückgegangen. Bei mir sind es nun 17,4 statt noch 20,9 mit Version 2.8. Das ist fast genau der Wert, den ich auch mit meinem 123 Tools-Plugin und der Option

[x] Die Anzeige von WordPress-Blog und -News sowie der eingehenden Links abschalten

schon vorher erzielt habe. Da wurde wohl beim Laden der Feeds für diese News angesetzt.

Nun überlege ich, ob ich auch meine anderen Blogs auf Version 2.8.1 nachziehe. Ich werde mal noch ein paar Tage warten, ob vielleicht kurfristig neue Probleme auftauchen. Wenn nicht, werde ich wohl auch mit den anderen Blogs auch auf 2.8.1 umsteigen, da läuft derzeit noch WordPress 2.7.1.

Einen Vorteil gibt es hier übrigens bei Strato bezüglich des automatischen Updates. Da PHP hier als CGI läuft, wird es im Kontext des jeweiligen Users gestartet und so gibt es keine Probleme mit den Schreibrechten oder irgendwelchen Updatekonfigurationen per FTP.

Weitere Artikel mit Bezug zu diesem:
11 Kommentare »

Shortlink ist schon eingebaut

Kurz ist besser

Kürzlich schrieb ich über das Risiko mit URL-Verkürzern wie TinyURL und Konsorten. Groß in Mode gekommen sind diese besonders auch mit Twitter, denn da stehen für einen geistigen Erguß gerade mal 140 Zeichen zur Verfügung. Wenn man nun gerne dem interessierten Leser zum Text auch noch einen interessanten, themenrelavanten Link mitgeben will, kann es knapp werden. Hier kommen dann die Linkdienste ins Spiel, denn die vielleicht über 100 Zeichen lange URL schrumpft auf angenehme 25 Zeichen.

Für WordPress-Blogs (und möglicherweise andere) geht es auch einfacher, denn bei WordPress sind kurze URLs und damit kurze Links (Shortlinks) bereits eingebaut. Am Beispiel der längsten URL hier bei Putzlowitsch sieht das so aus:

http://www.putzlowitsch.de/2007/08/23/urlaub-eberswalde-wehrkreiskommando-familiengarten-schiffshebewerk-kloster-chorin-o-bus/

wird zu

http://putzlowitsch.de/?p=362

Der obere Link ist 126 Zeichen lang, da blieben bei Twitter gerade mal noch 14 Zeichen für den Text übrig. Der WP-Shortlink hat nur 29 Zeichen, es bleiben also mehr als 100 Zeichen für den 140-Zeichen-Twitter-Text.

So funktionierts

Bei WordPress (WP) wird jeder Artikel unter einer eindeutigen ID abgespeichert und ist über diese ID auch ansprechbar. Das ist der Standard bei einer WP-Neuinstallation und erst durch das Konfigurieren der sogenannten Permalinks kommt die lange URL zustande, die üblicherwweise aus den Wörtern des Titels besteht.

Wo bekommt man nun aber die ID eines Artikels her? Manchmal steht sie mit in der langen URL drin, wie z.B. bei akkordwechsel (am Anfang) oder schnurpsel (am Ende). Oder man guckt in den Quelltext der Seite und findet z.B. bei mir hier

<div class="entry" id="artikel-1368">

oder beim tagSEOBlog

<div class="post" id="post-1524">

Falls so ein div-Dingens niht zu finden ist, lohnt es sich im Seitenquelltext weiter unten nachzuschauen. Dort steht, so vorhanden, das Formular für Kommentare. Normalerweise wird hier die ID des Artikels in einem unsichtbaren Feld vermerkt

<input type="hidden" name="comment_post_ID" value="1368" />

damit WordPress weiß, zu welchem Artikel der Kommentar gehören soll. Am schnellsten wird man fündig, wenn man im Quelltext der Seite nach comment_post_ID sucht.

Wenn nun WordPress so einen Link der Form /?p=123 übergeben bekommt und feststellt, daß aber Permalinks konfiguriert sind, dann wird einfach auf die lange URL weitergeleitet. Etwas anderes macht ein URL-Verkürzungsdienst auch nicht. Zudem kann man auch das www weglassen, denn seit Version 2.3 erzeugt WordPress auch in dem Fall eine Weiterleitung auf die konfigurierte Adresse mit (oder ohne) www.

Was bringts?

Neben dem Vorteil, nicht den Fehlern, Problemen, Sicherheitslücken und Ausfällen externer Dienste ausgeliefert zu sein, sieht man dem Link sofort an, auf welche Website er verweist. Und selbst wenn der Betreiber des WordPress-Blogs mal die Permalinkstruktur für seine Artikel ändert, behalten die Links ihre Gültigkeit und funktionieren weiterhin.

Keine 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.

58 Kommentare »