WordPress Performance analysieren (Plugin)

Die Zeiten ändern sich.

Dieser Beitrag scheint älter als 16 Jahre zu sein – eine lange Zeit im Internet. Der Inhalt ist vielleicht veraltet.

Die Performance von WordPress kann schnell und einfach mittels einiger Plugins verschlechtert werden. Dazu muss man kein Experte sein, mehr Funktionalität sorgt für mehr Last. Allerdings sorgt gerade die Einfachheit und offene Arbeitsweise von WordPress, die WordPress unter anderem so populär gemacht haben und ich sehr schätze, zu einem Problem – das Plugin muss nicht unbedingt von Profi-Entwicklern erstellt sein und die Optimierung des Syntax würde viel im Bereich Performance verbessern.

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.
Screenshot Ergebnis WordPress Plugin Debug Queries


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

Von Frank Bültge

bueltge.de [by:ltge.de] wird von Frank Bültge geführt, administriert und gestaltet. Alle Inhalte sind persönlich von mir ausgewählt und erstellt, nach bestem Gewissen und Können, was die Möglichkeit von Fehlern nicht ausschließt.

97 Kommentare

  1. Das Plugin ist praktisch 🙂

    Nur leider bekomme ich eine Error-message:

    Invalid argument supplied for foreach() in *** L 17

    Greetz Phil

  2. wow – grosses kino mal wieder, funktioniert einwandfrei und hilft wirklich sehr. das ganze wird auch gleich an einige kunden empfohlen die sich über schlechte performance beschweren, aber nicht einsehen das viele informationen auch viele datenbankabfragen bedeutet.

    danke für die arbeit!

  3. 2 Autoren – ein Gedanke: Verwende SAVEQUERIES auch zur Optimierung und wollte es ebenfalls nach meinem Nachtschichtblock in ein Plugin packen, allerdings mit einem anderen Ansatz: Das Plugin schreibt nach Aktivierung einmalig die gesammelten Queries und Zeiten in eine Datenbanktabelle die dann im Adminmenü abgerufen werden kann, wobei die Queries zusätzlich noch mit einer EXPLAIN-Query verlinkt sein sollten. So könnte man dann einfach und gezielt nach Performanceproblemen forschen.
    Naja, vielleicht schreibe ich es ja trotzdem noch…
    Grüsse

  4. Plug-In installiert und Auswertung im Quelltext angeschaut.
    Zunächst musst ich mir die Augen reiben, ist ja doch sehr kryptisch.
    Resultat: Total query time: 0.17107510566711
    vermutlich ist das kein besonders guter Wert?
    Da die Werte für wp_term_relationships und wp_term_taxonomy am höchsten waren habe ich mal nachgeforscht was sich dahinter verbirgt:
    WP-Datenbank-Erklärungen

    also irgendwas mit Kategorien-zuordnen.
    Habe dann das Plug-In Advanced-Category-Excluder deaktiviert und konnte somit den Wert senken.
    Resultat: Total query time: 0.073061466217041
    Das sieht schon besser aus,
    aber leider mag ich auf dieses Plug-In nicht verzichten.

  5. Autsch…
    Entschuldige ! Das passiert wenn man eifrig ans Werk gehen will weil einem das eigene System nervt und zum Stier macht *gg*

    Danke für den blitz Tip

    Greetz & gute Nacht, vile Glück
    Phil

  6. wie immer sehr geiles Plugin. Werde es nachher mal testen.

    Damit die Arbeit damit einfach und schnell an dem jeweiligen Blog

    Hört sich irgendwie komisch an :P

  7. ich bin selbst kein großer php und datenbank-typ. was sind denn gute werte? in deinem obige screenshot ist die Total query time 0.0315816402435 – bei meiner website spuckt das plugin Total query time: 0.021893262863159 aus. ist das jetzt gut? schlecht? gibt es im netzt einen artikel zu dem thema?

    ansonsten respekt für eine wunderbare webseite.

  8. Auch ich bin kein Experte für dieses Thema, aber entscheidend ist der Vergleich der ausgespuckten Werte. Im Vergleich zeigt sich, was dauert und wie lange. Damit kann man einigen Extremen auf den Grund gehen. Eventuell kann man sie nicht beseitigen, aber man kann entscheiden, ob man sie unbedingt benötigt, weil sie beispielsweise von einem Plugin kommen oder nicht.
    Ansonsten hilft eventuell der Artikle „Using the New MySQL Query Profiler„.

  9. Bei mir kommt die gleiche Fehlermeldung wie bei phil.
    Ich habe savequeries auf „true“ gesetzt und bin als admin angemeldet.
    Trotzdem.
    Irgendeine Idee?

  10. Hallo!
    Dieses Plugin hat mir gut dabei geholfen, die Performance aus Sicht des Users deutlich zu erhöhen..
    Aber jetzt mein verbleibendes Wehwehchen: Die Ladezeiten im Adminbereich von WP sind abgrundtief schlecht.. wenn ich nur Spam löschen will, warte ich schon mal 1-2 Minütchen auf eine Reaktion – auch alle anderen Aktionen (aktivieren/deaktivieren v Plugins, Einfügen von Bannercode ins WPAds, …) enden in ellenlangem Warten…
    Weiß jemand Rat?

  11. Eventuell ©Feed im Einsatz, dann schau die Kommentare zum Plugin an, dort ist die Lösung dazu.
    Ansonsten schau mal, ob du ein Plugin im Einsatz hast, welches Daten von Außen holt, das ist dann das Problem. ©Feed macht das und wenn der Service nicht verfügbar ist, dann hackt es.

  12. Ui, ngg gallery haut ganz schön:


    9.3936920166016E-5 SELECT filename FROM wp_ngg_pictures WHERE pid = '71'

    0.00024104118347168 SELECT path FROM wp_ngg_gallery WHERE gid = '4'

    9.7036361694336E-5 SELECT galleryid FROM wp_ngg_pictures WHERE pid = '71'

    9.1075897216797E-5 SELECT filename FROM wp_ngg_pictures WHERE pid = '71'

    9.3936920166016E-5 SELECT path FROM wp_ngg_gallery WHERE gid = '4'

    Total query time: 0.043978929519653

  13. Vielen Dank für den Hinweis! das ganze Adminpaneel rennt wieder…
    und @Nils: ebenso habe ich mich auch erschreckt – bis ich die „E-5“ entdeckt habe 😉

  14. Gut dass es sowas gibt. Ich bin dabei etwas neues mit WP zu realisieren und da muss unbedingt auf die performance achten. manchmal ist es doch besser plugin selber zu schreiben, wenn fertige plugins zu viel performance beanspruchen, obwohl man nur vlt. die hälfte der funktionen benötigt.

    gruß
    damian

Kommentare sind geschlossen.