Hits & Traffic

Im ersten Screenshot seht ihr die Zahlen, die die Serverstatisik des Hosters ausspuckt.

Ich meine, dass ≈4,4Millionen Hits pro Monat für ein One Man Show ganz gut sind; Probleme hatte ich ja schon ausreichend und daher musste ich ja, da ich nicht den Provider wechseln wollte, auf einen eigenen Server wechseln. Dank Sergej von wpSEO wird dieser auch ohne eigenes Zutun finanziert und so sind die Unkosten gleich null für mich persönlich - alternativ hatte ich überlegt, dass Blog anders zu fahren, da mir der Kostenaufwand für ein Freizeitprojekt recht hoch erschien.

Besucherzahlen

Der folgenden Screenshot zeigt euch die Monatsstatistik, die seit dem Einsatz von Mint gesammelt wurden. ich habe mal beispielhaft die Werte des Monats März hinzugefügt.

Populäre Seiten

Woher kommen die Leute und was wollen Sie - einen kleinen Einblick schafft der Blick auf den folgenden Screenshot. Hier ist nicht zu sehen, dass das Feed meines Blogs immer die Nummer 1 ist, dort kommen im Schnitt ≈250.000 Anfragen und 130.000 Besucher rein. Bei meinem Blog sind ganz klar die Feedleser die Masse; der Feed war es auch, der mir damals die meisten Probleme generierte. Die 250.000 Anfragen auf dem Feed sorgen für eine Last von 14.423.036 kByte.

Hinter den Kulissen

Das Blog läuft mir WordPress und auch sonst nutze ich keine Zaubertricks - setze auf klassische Methoden, die ich verstehe und kontrollieren kann. Ich bin der Meinung, dass Cache toll ist - aber man sollte wissen was man tut. Nicht selten befolgen Sites die Tipps aus dem Netz, verstehen aber nicht, was sie da tun und laufen dann in einem Problemfall in weitere Probleme rein. Blindes cachen bringt Ärger. Gerade im Umfeld von PHP und mySQL gibt es viele sehr unterschiedliche Methoden und wichtig ist mir, dass ich die Methode verstehe und möglichst keine Wissenschaft betreibe.

Zum Einsatz kommen möglichst nur Erweiterungen in WordPress, die ich selber schreibe, oder die ich geprüft habe. Dazu nutze ich den Editor und eigene Plugins von mir zur Analyse. Mir ist wichtig, dass die Last nicht durch Plugins enorm erhöht wird. Ebenfalls schaue ich genau auf die Last im Backend von WordPress, denn bei der wenigen Zeit die ich habe, will ich nicht noch auf Inhalte warten. Insofern beginnt eine Optimierung also bei der Installation, beim Theme und den Plugins, vor allem bei den Content-Filtern und ich nutze bewusst keine Widgets! Hier ist exakte, wissende und kontrollierte Arbeitsweise wichtig. Vieles an "Standard-caches" steuere ich via .htaccess; einen Einblick davon kann man sich in der Beispieldatei vom WP Basis Theme im SVN machen.

Am Rande: die größten Probleme machte mir in der Vergangenheit den Code, den ich in den Beiträgen darstelle, zu filtern. Der wurde via Filter maskiert und via Geshi formatiert - das war das aus ab einer gewissen Zugriffszahl. Aktuell arbeite ich mit einer eigenen Lösung und hinterlasse nur maskierten Code im Content, es läuft kein Filter mehr. Ich kenne kein Plugin für WordPress, was ich daher empfehlen kann, jeder Filter kann auf lange Sicht zu Problemen führen und das Blog ist abhängig vom Plugin, denn bei Deaktivierung wird der Code dann nicht selten interpretiert.

Im weiteren kommt nach Spielereien mit dem eAccelerator der APC zum Einsatz. Hier habe ich keine handhabe, ich habe das Modul vom Hoster installieren lassen und kann nicht daran drehen. Aber innerhalb von WordPress habe ich eine Erweiterung laufen, die den Standard-Cache von WP mit dem APC nutzt und parallel läuft das Plugin W3 Total Cache - dies ist aus meiner Sicht aktuell eines der Plugins, die man sich ansehen sollte, wenn man dahingehend Bedarf hat! Auch hier gilt, kontrolliert nutzen - nicht blind einschalten. Das Plugin hat sehr viele Funktionen, so dass man sehr schön gezielt schalten kann.
Ich kenne die Meinungen zu dem Auslagern auf statische Seiten, zum Beispiel via Plugin Super Cache, verliere damit aber eine gewissen Freiheit und muss mich wesentlich mehr um das Cachen kümmern. Daher bevorzuge ich eher andere Themen. Ebenfalls kommt hier kein CDN zum Einsatz; in einem anderen Projekt mit viel Grafik war dies wirklich ein Schachzug und hat extreme Geschwindigkeit gebracht.

Um es kurz zu machen: einige Einblicke in die Zahlen habe ich gebracht, gern zeige ich mehr, wenn man mag. Den technischen Aspekt möchte ich ungern klar darstellen, da aus meiner Sicht das Thema nicht schwarz & weiß ist, sondern bedacht eingesetzt werden sollte und immer in Abhängigkeit der Anforderungen steht. Schreibe Reviews für Kunden, dann schaue ich mir jedes Detail an, gebe Empfehlungen und immer wieder gibt es Unterschiede. Nicht jeder hat unbegrenzte Möglichkeiten, nutzt Server Load Balancing für eine Verteilung der Last. Es gilt, mit bedacht und kontrolliert an der Performance drehen.

Ein letzter Hinweis: wer mehr über die Optimierung bei sehr hohem Traffic wissen möchte, der sollte sich den Vortrag von Florian Holzhauer ansehen. Er administriert das Lawblog und dies hat ≈8Millionen Hits im Monat - ich bin also recht klein in der Blogwelt.

© Frank Bültge, All rights reserved / Alle Rechte vorbehalten. (ID: 6e8b33de4342c4f2ca76b245199aeee8)

Danke für das Abonnieren meines Feed! Inhalt gefällt? Danke sagen · Kommentieren

Für Listenfreaks, besonders gedacht für Neueinsteiger, steht alternativ noch die Checkliste bereit, in englischer Sprache.

© Frank Bültge, All rights reserved / Alle Rechte vorbehalten. (ID: 6e8b33de4342c4f2ca76b245199aeee8)

Danke für das Abonnieren meines Feed! Inhalt gefällt? Danke sagen · Kommentieren

Nun aber zum eigentlichen Problem: wie findet man die Schwachstelle im Blog?

Einerseits kann mittels weniger Tools die Performance analysieren, dazu dient mir beispielsweise das Add on Firebug im Browser Firefox. Damit sind schnell große Scripte gefunden und Schwachstellen im Code. Dazu auch der Hinweis auf den Artikel „Ladezeiten bei WordPress-Templates optimieren“. Sinnvoll ist ebenfalls, die „vielen“ Scripte, die einige Plugins mitbringen, nicht per wp_head, sondern in wp_footer anzusteuern. Damit bleibt der Aufbau nicht an den Scripten hängen, die eventuell nur Mehrwert bieten. Ab in den Footer mit derartigen Scripten.

Allerdings ist die Analyse via Deaktivieren/ Aktivieren aller Plugins nach und nach mühsam. Da wäre es doch sinnvoll, man sucht die einzelnen Queries ab und schaut auf welche Funktion sie verweisen.

WordPress bietet von Hause aus die Möglichkeit, dass man sich die Gesamtzahl der Queries ausgeben lassen kann, ebenso die benötigte Zeit. Mit folgendem Syntax, vorzugsweise in den Footer der Seite gelegt, ist dies schnell geschehen.

<?php echo $wpdb->num_queries; ?>q, <?php timer_stop(1); ?>s

Aber die Variable $wpdb bietet mehr, dazu schaut man in die /wp-includes/wp-db.php.

if (!defined('SAVEQUERIES'))
	define('SAVEQUERIES', false);

class wpdb {

	var $show_errors = true;
	var $num_queries = 0;
	var $last_query;
	var $col_info;
	var $queries;
	var $prefix = '';

	// Our tables
	var $posts;
	var $users;
	var $categories;
	var $post2cat;
	var $comments;
	var $links;
	var $options;
	var $postmeta;
	var $usermeta;
	var $terms;
	var $term_taxonomy;
	var $term_relationships;
	var $tables = array('users', 'usermeta', 'posts', 'categories', 'post2cat', 'comments', 'links', 'link2cat', 'options', 'postmeta', 'terms', 'term_taxonomy', 'term_relationships');
	var $charset;
	var $collate;

Dabei fällt die Konstante SAVEQUERIES auf, die im Standard nicht in der wp-config.php definiert ist. Setzt man diese Konstante auf TRUE, dann sind weitere Möglichkeiten offen.
Aber auch darauf will ich nicht im Detail eingehen, denn es würde zu weit führen, wer Interesse hat, der findet in der besagten Datei eine ganze Reihe von Infos.

Mein Ziel war es nun aber, dass man nicht die Gesamtzahl der Queries im Blog als Ergebnis bekommt, sondern die einzelnen Abfragen inklusive ihrer auszuführenden Syntax, denn so kann ich das Problem explizit im Code finden.

Damit die Arbeit einfach und schnell an dem jeweiligen Blog von der Hand geht, habe ich die Funktion in ein Plugin ausgelagert und aktiviere es nur, wenn ich auch eine Analyse durchführen möchte. Außerdem wird die Analyse nur gestartet und das Ergebnis ausgeben, wenn man als Administrator eingeloggt ist.

Das Ergebnis kann das beispielsweise folgendermaßen aussehen.

16. Time: 0.000431060791016
      Query: SELECT object_id, term_taxonomy_id FROM fb122_term_relationships INNER JOIN fb122_posts ON object_id = ID WHERE term_taxonomy_id IN (6,5,1) AND post_type = 'post' AND post_status = 'publish'
      Call from: wp-includes\taxonomy.php(2093): wpdb->get_results()

17. Time: 0.00243401527405
      Query: SELECT t.*, tt.* FROM fb122_terms AS t INNER JOIN fb122_term_taxonomy AS tt ON t.term_id = tt.term_id WHERE tt.taxonomy IN ('link_category') AND tt.count > 0 ORDER BY t.name ASC
      Call from: wp-includes\taxonomy.php(777): wpdb->get_results()

18. Time: 0.00080418586731
      Query: SELECT * , IF (DATE_ADD(link_updated, INTERVAL 120 MINUTE) >= NOW(), 1,0) as recently_updated FROM fb122_links INNER JOIN fb122_term_relationships AS tr ON (fb122_links.link_id = tr.object_id) INNER JOIN fb122_term_taxonomy as tt ON tt.term_taxonomy_id = tr.term_taxonomy_id WHERE 1=1 AND link_visible = 'Y' AND ( tt.term_id = 2 ) AND taxonomy = 'link_category' ORDER BY link_name ASC
      Call from: wp-includes\bookmark.php(255): wpdb->get_results()

 * Total query time: 0.02111s for 18 queries.
 * Page generated in 0.36373s, 94.20% PHP, 5.80% MySQL

Für den Laien ist damit die Arbeit sicher nicht unbedingt angenehm, aber so finde ich die eigentlichen Probleme in der Datenbankabfrage und kann die jeweilige Abfrage in den Dateien suchen und eventuell verbessern bzw. deaktivieren. Das Plugin bedient noch einige mehr Informationen als das obige Tutorial, so dass es verständlicher wird und mehr Informationen liefert.

Debug Queries (Plugin)

Nach dem Aktivieren des Plugins werden die einzelnen Abfragen in den Footer der Seite geschrieben, als HTML-Kommentar, so dass man den Quelltext analysieren muss, um an die Werte zu kommen. Die Werte werden nur analysiert und ausgegeben, wenn man als Administrator im Blog eingeloggt ist.

Anforderungen:

Das Plugin benötigt WordPress Version 1.5 und wurde getestet bis Version 2.9-rare.

Installation:

1. Die zip-Datei downloaden und entpacken
2. Kopiere die Datei in dein Plugin-Verzeichnis (/wp-content/plugins/)
3. Aktiviere das Plugin im Admin-Bereich deines Blogs

Download:

Ist die Arbeit nicht 1 Euro wert?
Jede Spende wird dankbar angenommen und ermöglicht das weitere Arbeiten an freier Software.
Möchtest du mehr oder anders spenden, so besuche meine Wunschliste.

Download als zip-Datei:
downloads.wordpress.org/plugin/debug-queries.zip - 2 kByte

Historie

• 0.1 - Idee und Umsetzung
• 0.2 - Erweiterung der Ausgabe (30/03/2009)
• 0.3 - Bugfix (31/03/2009)
• 0.4 - WP2.8 tauglich-neue Rechte, gekapselte Klasse, Ausgabe im Frontend, viel Code neu (18./04/2009)
• 0.4.1 - Bug für 2.7 korrigiert, CSS-Pfad; Hinweis ergänzt, wenn es verschiedene Ergebnisse der Queries gibt
• 0.5 - Erweiterung diverser Werte, PHP und mySQL Umfang und Hinweise (04/05/2009)
• * - für weitere Änderungen bitte Changelog besuchen

© Frank Bültge, All rights reserved / Alle Rechte vorbehalten. (ID: 6e8b33de4342c4f2ca76b245199aeee8)

Danke für das Abonnieren meines Feed! Inhalt gefällt? Danke sagen · Kommentieren

CSSTidy erlaubt es, das Sytelsheet zu optimieren und formatieren. So soll unter anderen die Ladezeit des CSS-Files optimiert werden. Noch immer wird dieser Aspekt bei vielen Entwicklern nicht beachtet. In Zeiten von Trennung von Layout und Inhalt sind aber die Stylesheet-Dateien nicht immer klein und beanspruchen die Ladezeit doch erheblich. Bisher haben mich diverse CSS-Optimierungswerkzeuge nicht überzeugt, was vor allem daran lag, dass der Code im Anschluss für mich nicht mehr so verständlich und nachvollziehbar war.
Mit CSSTidy ist steht nun aber ein Werkzeug zur Verfügung, welches vor allem durch die Mitteilungen des Optimierungsvorgangs besticht. Damit behält man die Kontrolle und die Strukturierung kann erhalten bleiben.

Das Tool verfügt über eine ganze Reihe von Optionen und unterstützt CSS Level 2. Außerdem steht das Online-Tool in vier Sprachen zur Verfügung, darunter auch deutsch. CSSTidy ist ein Parser und Optimierer aus dem OpenSource-Umfeld.

© Frank Bültge, All rights reserved / Alle Rechte vorbehalten. (ID: 6e8b33de4342c4f2ca76b245199aeee8)

Danke für das Abonnieren meines Feed! Inhalt gefällt? Danke sagen · Kommentieren

© Frank Bültge, All rights reserved / Alle Rechte vorbehalten. (ID: 6e8b33de4342c4f2ca76b245199aeee8)

Danke für das Abonnieren meines Feed! Inhalt gefällt? Danke sagen · Kommentieren

In recht ausführlicher weise listet er die Ergebnisse und verschiedenen Resultate. Viele kleine Details werden dabei berücksichtigt - schaut mal über den Artikel. Klarer Sieger ist Icey's - CSS Compressor.
Sollte man sich merken und ab und zu auch mal den CSS-Code damit optimieren, zumindest werde ich es mal testen.

Update: Ich habe es getestet und war eigentlich mit dem Ergebnis immer unzufrieden und bleibe somit bei meiner händischen Alternative und erstelle die CSS-Files lieber nach meiner gedanklichen Übersicht.

Beim Testen kam mir aber noch ein weiterer Service dieser Art unter, der in dem obigen verlinkten Beitrag keine Beachtung fand - cleancss. Hier arbeitet man mit CSSTidy und hat eine ganze Reihe von Möglichkeiten. Außerdem ist die Oberfläche mehrsprachig, darunter auch deutsch.

© Frank Bültge, All rights reserved / Alle Rechte vorbehalten. (ID: 6e8b33de4342c4f2ca76b245199aeee8)

Danke für das Abonnieren meines Feed! Inhalt gefällt? Danke sagen · Kommentieren

• Tag nutzen (Wolken, Seiten) - machbar mit Ultimate Tag Warrior oder WP Jerome's Keywords (Bsp: Meine Statistikseite
• Ähnliche Beiträge zum Artikel - geht mit Related Posts (Tipps dazu im Artikel: „Ähnliche Artikel (Plugin)“) oder Related Posts for Jerome’s Keywords Plugin (Bsp.: unter meinem Artikel zu finden)
• Top 10 der Beiträge - Auch dafür gibt's ein Plugin:„Sayfa Sayaç (de) - Counter für Beiträge gelesen (Plugin)“
• Frühere und ältere Einträge - im WP-default-Theme vorgesehen (Bsp.: über meinem Artikel zu finden)
• Pflege die Blogroll - über die Links von WP zu pflegen
• Tags von diversen Service in den Beitrag integrieren, z.B. Technorati

Im weiteren sollte das Blog auch im Title-Tag und den URLs optimiert werden.

• Der Blogname gehört ans Ende des Titels - Tutorial WordPress Titel ändern, außerdem kann man mit dm Plugin „SEO Title Tag“ arbeiten
• Tags sollten auf eine Tag-Seite verlinken - kann WordPress standardmäßig, darstellen kann man das auch in einer Tagwolke mit den oben genannten Tag-Plugins
• Zusätzliche Keywords sollten nur auf deiner Website zu sehen sein

Außerdem gehören ‚Unmengen’ Tags auf die Seite:

• Kategorie Name, der verlinkt ist auf die Kategorie-Seite
• Beitragstitel enthält den Permalink zum Artikel
• Verwende interne und externe Links, schreiibe dabei einen aussagekräftigen text und nicht „hier“ oder „dort“
• Tags, Keywords führen zu Tag-Seiten
• Verwende interne Anker, um bestimmte Bereiche anzusprechen - z.B. zum Header zu kommen (siehe die Quicknavi rechts oben)

Besonders bei Gruppen-Blogs, bei der mehrere Autoren schrieben, sollten sich die Autoren beschreiben, vorstellen. Ebenfalls sollte der Tag des Autors auf diese Vorstellungsseite führen.

Weitere SEO-Tipps für WordPress gibt es im Beitrag „Methoden der Suchmaschinen-Optimierung (SEO) unter WordPress“.

© Frank Bültge, All rights reserved / Alle Rechte vorbehalten. (ID: 6e8b33de4342c4f2ca76b245199aeee8)

Danke für das Abonnieren meines Feed! Inhalt gefällt? Danke sagen · Kommentieren