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.
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:
- Die zip-Datei downloaden und entpacken
- Kopiere die Datei in dein Plugin-Verzeichnis (
/wp-content/plugins/)
- 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
Das Plugin ist praktisch
Nur leider bekomme ich eine Error-message:
Invalid argument supplied for foreach() in *** L 17
Greetz Phil
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!
@ Phil
Lies nochmal die Installationsanleitung, vor allem Punkt 3!
@Frank
Sehr nice, danke!
Das ist ja wieder einmal ein Highlight aus der Softwareschmiede Bültge
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
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.
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
@ Phil
Mir ist das gleiche passiert!
wie immer sehr geiles Plugin. Werde es nachher mal testen.
Damit die Arbeit damit einfach und schnell an dem jeweiligen BlogHört sich irgendwie komisch an
@Nils: Danke! - klingt und ist komisch, gefixt.
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.
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".
vielen lieben dank für deine antwort
Bei mir kommt die gleiche Fehlermeldung wie bei phil.
Ich habe savequeries auf "true" gesetzt und bin als admin angemeldet.
Trotzdem.
Irgendeine Idee?
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?
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.
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
Da steht aber E-5, also 0,00009 !?
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
oh, ok, die habe ich dann übersehen ^^
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
Hallo,
funktioniert das plugin auch unter wp 2.5.1 ?
lg
thomas
@thomas: ja, sollte ohne Probleme laufen.
Abend;
unter WP 2.6 läuft es leider nicht, könntest du da bitte mal nachschauen?
Gruß
@ocean90: Ich habe es auch unter 2.7 beta laufen, ohne Probleme. Hast du die Konstante definiert?
hallo vielen dank für die performancetipps. wie kann ich denn eine wordpress installation noch monitoren? bzw. das serververhalten? wie kann ich eine high-traffic-wordpressinstallation optimieren? wie kann ich denn punkt für punkt bestimmte sachen ausschließen? kann ich z.B. mir die /index.php vornehmen (also jede seite einzeln) und nach allen kriterien hin durchprüfen?
gruß
juniman
@juniman: Dazu gibt es hier keine Infos bisher und ich habe sie gerade erarbeitet für das kommende Buch von mir. Serverhalten kann man eigentlich nur sauber über einen eigenen Server oder entsprechenden Mietserver tracken. Bei Hightraffic helfen viele kleine Details, Super Cache als Plugin macht einen recht guten Fortschritt.
Ich habe es ganz genauso gemacht wie beschrieben und bekomme diese Fehlermeldung:
Warning: Cannot modify header information - headers already sent by (output started at garten/wp-config.php:23) in garten/wp-includes/pluggable.php on line 770Wo war ich noch blond?
beim secure-wordpress-plugin das gleiche....
@Nimue: eventuell ein Fehler in deiner Install. Bitte prüfe mal dein wp-config.php, denn der Fehler kommt durch die Mehrsprachigkeit in WordPress. Alternativ würde ich nochmal den Ordner wp-includes neu einspielen, nicht überschreiben.
Hab ich gemacht, jetzt komme ich nicht mal mehr in mein blog
(
das sind die meldungen, die ich jetzt bekomme....
Warning: Cannot modify header information - headers already sent by (output started at /www/htdocs/w00686b6/garten/wp-config.php:22) in /www/htdocs/w00686b6/garten/wp-login.php on line 267Warning: Cannot modify header information - headers already sent by (output started at /www/htdocs/w00686b6/garten/wp-config.php:22) in /www/htdocs/w00686b6/garten/wp-login.php on line 279
Warning: Cannot modify header information - headers already sent by (output started at /www/htdocs/w00686b6/garten/wp-config.php:22) in /www/htdocs/w00686b6/garten/wp-includes/pluggable.php on line 595
Warning: Cannot modify header information - headers already sent by (output started at /www/htdocs/w00686b6/garten/wp-config.php:22) in /www/htdocs/w00686b6/garten/wp-includes/pluggable.php on line 596
Warning: Cannot modify header information - headers already sent by (output started at /www/htdocs/w00686b6/garten/wp-config.php:22) in /www/htdocs/w00686b6/garten/wp-includes/pluggable.php on line 597
Warning: Cannot modify header information - headers already sent by (output started at /www/htdocs/w00686b6/garten/wp-config.php:22) in /www/htdocs/w00686b6/garten/wp-includes/pluggable.php on line 770
@Nimue: Da scheint aber ein Problem vorzuliegen; ich kann so nicht viel helfen. Kannst du mir deine wp-config.php senden. Welche WordPress Version ? Tritt das Problem auch auf wenn alle Plugins deaktiv sind dun wenn ja auch wenn du das Standard-Theme nutzt, wobei das wohl keinen Einfluss hat.
ich habe 2.6.1 und bis ich versucht habe, diese plugin laufern zu lassen,w ar alles in ordnung
ich würde gern die config schicken, ich finde nur keine mailaddi von dir.
@Nimue: siehe Impressum bzw. wenn du die Kommentare per Mail abonniert hast, dann bekommst du sie automatisch.
Thanks to this article I reduced the number of SQL queries on my index page from 45 down to 16! Great job!
hi
läuft dieser Plugin auch unter WordPress 2.7 ?
Ich habe WordPress 2.7 installiert und benutze default theme, WordPress erzeugt ca 22 queries was für mich zuviel ist. Modx kommt mit 4-7 queries aus wieso ist sowas nicht unter WordPress möglich?
Ich habe in Sidebar fast alles ausgeklammert aber kann die 22 queries nicht reduzieren
was mache ich denn falsch?
@junyk: läuft unter 2.7; die Queries wirst du aber nicht sonderlich senken können. Die Version 2.7 hat da schon Verbesserungen im Bauch, trotzdem ist ein Wert um 25 sehr realistisch.
Moin moin,
die 0.1er Version funktionierte bei mir nicht. Jetzt die Version 0.2 funktioniert besser, aber auch nicht wirklich vollständig.
Total query time: $total_query_time for 25 queries.
$total_query_time wird nicht aufgelöst?
Nur mal so als Hinweis ...
@mg: hm, habe ich noch nie erlebt. Kann mir aktuell auch keinen Reim machen. Hast du es mal mit einem anderen Theme versucht?
@Frank:
... __('Total query time: $total_query_time for') ...
=>
... __("Total query time: $total_query_time for") ...
@mg: danke, habe den Bug gefixt.
... mir ist noch eine Kleinigkeit aufgefallen ...
$wpdb->num_queries bei mir im Template = 29 Abfragen
Das Plugin zeigt nur 25?
Ich glaube die Ausgabe - der Hook - ist zu früh.
@ms: aber im Frontend kann ich nicht später einhooken, eventuell kommt nach deinem Hook im Theme noch einiges an Code.
@Frank: Ausgabe kann auch noch später modifiziert werden, aber auch wenn ich das Plugin anpasse sind die Anzahl der Queries immer noch verschieden
... crazy?
Bin gerade durch Zufall über Dein PlugIn gestolpert und finde es interessant zu sehen was diverse PlugIns oder auch WordPress so treibt. Kleiner Vorschlag: ich hab mal spasseshalber das PlugIn erweitert, dass es alle SELECT's nochmal mit "EXPLAIN " davor an die DB schickt und die Ergebnisse an die Queries anhängt damit man sieht, wenn jemand vollkommenen Murks gebaut hat
Das wäre vielleicht noch eine interessante Erweiterung für eine spätere Version.
Ansonsten ein wirklich tolles PlugIn!
Wäre schön, wenn du den Code sendest, dann kann ich einfach erweitern, testen, frei geben - das schöne an GPL. So muss ich mich erst damit beschäftigen, egal wie klein die Änderung ist.
@Frank: Hab mir noch mal kurz das Delta zwischen
$wpdb->num_queries;und$wpdb->queriesangesehen.mysql query log zeigt in meiner lokalen Umgebung die folgenden zusätzlichen Queries an.
SET NAMES 'utf8'SELECT option_value FROM wp_options WHERE option_name = 'siteurl'
SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'
SELECT option_value FROM wp_options WHERE option_name = 'aiosp_donate' LIMIT 1
Bin an einer neuen Version dran, lade die heute noch hoch. Aber ich kann die Unterschiede nicht feststellen, es sei denn, ich habe nach dem Hook
wp_footerim Theme noch aufrufe.Try this one: http://wordpress.org/extend/plugins/sqlmon/
It is more feature-rich
Sollten die Statements chronologisch im Log protokolliert werden, ist das Delta vor den durch das Plugin angezeigten Abfragen.
@mg: erkläre mal, habe ich nicht verstanden.
@Frank: Naja, die nicht angezeigten Abfragen sind vor dem Hook
wp_footer. Die werden aus was für einen Grund auch immer nicht im Objekt gehalten?@Frank: Ich habs ...
if ( !defined('SAVEQUERIES') )define('SAVEQUERIES', true);
... wird durch das Plugin erst nach einigen Queries gesetzt.
Die ersten vier werden aufgelistet, wenn der Wert früher (
wp-config.php) gesetzt wird.Alles wird gut!
@mg: ah, dass ist endlich eine Lösung, eventuell sollte ich dann darauf hinweisen.
Eine coole Sache! Danke dafür. Ich schau es mir mal genauer an
@mg: habe nochmal geschraubt, auch weil es unter 2.6 - 2.7 keine saubere Einbindung des SS-Pfades gab, seit 2.8 ist die Funktion besser. Habe nun aber einen kleinen Hinweis drin, wenn es verschiedene Werte gibt.
Hm. Bei mir schmeisst das Plugin, wenn ich es aktivere eine leere Seite aus.
Habe die neueste WP-Version drauf. Any hints?
@Patrick: eventuell ist dein CSS so, dass es die Ausgabe des Plugins formatiert und du es nur nicht lesen kannst; schaue mal, ob es Inhalt im Bereich gibt.
@Frank
Nee. Liegt sicher nicht an CSS weil im Quelltext überhaupt nix steht. Er rendert also überhaupt kein HTML raus.
@Patrick: hm, du bist aber angemeldet, als Admin? der Hook wp_footer() ist auch im Theme?
Yep, der Hook ist drin. Als Admin bin ich drin. Es passiert aber auch wenn man nicht eingeloggt ist!
@Patrick: schwer zu sagen; könnte ich als Admin zugreifen und mir das Problem ansehen?
Thanks for the plugin.
I had a quick question though about the difference between num_query and query.
As you cans see from the results below, there is an almost 10 second difference, but only one more query, so this is the query I am having problems with.
I have set define('SAVEQUERIES', true); in my wp-config.php file.
Total query time: 2.82855s for 2694 queries.
Total num_query time: 12.539 for 2695 num_queries.
» Different values in num_query and query? - please set the constant define('SAVEQUERIES', true);in your wp-config.php
Page generated in 11.99797s, 76.42% PHP, 23.58% MySQL
@clement: maybe you have set on the last line and WP hooks a little bis earlier.
Bekomm es leider nicht zum Laufen. Verwende WP 2.9.2. und erhalte einfach nur eine leere Seite. Auch im Quellcode ist nichts drin - der Body ist leer. Selbiges Verhalten konnte ich feststellen, wenn ich einfach nur SAVEQUERIES in die wp-db.php eingefügt habe. Irgendwelche Ideen?
@Axl: vermutlich fehlt der Hook wp_footer im Theme?
@Frank
der Hook ist drin. Komisch ist ja, dass gar kein Code mehr ausgegeben wird, sondern nur eine leere Seite...
@Axl: kann man das sehen. Ist das in Backend und Frontend so? Eventuell wird der query angefasst.
When I run Debug Queries the time shown on the individual queries is not correct. The total time for all queries on my page is .209 seconds but there are several queries that show 8 and 9 seconds which is way more than the total time. Why are the queries showing the wrong execution time? I'd also like to know where the english version of this site is.
@Jeff: The time-entries come from WordPress, not from the plugin, but i will see for this problem. I dont see in all my projects, hundreds of installs. Sorry, my blog is only in german language, but all stuff and informations about the plugin is on the plugin-page on wp.org; is this not enough? Thanks for your comment with this notice.
Changelog update for 1.0.1 please
@leo: sorry, i forgott to upload - now is in the svn
Danke Frank
Hallo Frank,
Ich habe extreme Probleme mit der Datenbank. Dadurch hat mich der Hoster vom Server runter genommen und vorübergehend auf anderen Server verschoben, damit ich die Ursachen finden kann. Nun habe ich das Plugin installiert und bekomme sehr viele ähnliche Abfragen die so aussehen:
Beispiel 1:
* Time: 0.118685007095
* Query: SELECT SQL_CALC_FOUND_ROWS kas_wp_posts.* FROM kas_wp_posts INNER JOIN kas_wp_term_relationships ON (kas_wp_posts.ID = kas_wp_term_relationships.object_id) WHERE 1=1 AND ( kas_wp_term_relationships.term_taxonomy_id IN (896) ) AND kas_wp_posts.post_type = 'post' AND (kas_wp_posts.post_status = 'publish' OR kas_wp_posts.post_status = 'private') GROUP BY kas_wp_posts.ID ORDER BY kas_wp_posts.post_date DESC LIMIT 0, 4
* Call from: require, require_once, include, WP_Query->WP_Query, WP_Query->query, WP_Query->get_posts
Beispiel 2:
* Time: 0.0798668861389
* Query: SELECT SQL_CALC_FOUND_ROWS kas_wp_posts.* FROM kas_wp_posts INNER JOIN kas_wp_term_relationships ON (kas_wp_posts.ID = kas_wp_term_relationships.object_id) WHERE 1=1 AND ( kas_wp_term_relationships.term_taxonomy_id IN (870) ) AND kas_wp_posts.post_type = 'post' AND (kas_wp_posts.post_status = 'publish' OR kas_wp_posts.post_status = 'private') GROUP BY kas_wp_posts.ID ORDER BY kas_wp_posts.post_date DESC LIMIT 0, 1
* Call from: require, require_once, include, WP_Query->WP_Query, WP_Query->query, WP_Query->get_posts
Beispiel 3:
* Time: 0.100769996643
* Query: SELECT SQL_CALC_FOUND_ROWS kas_wp_posts.* FROM kas_wp_posts INNER JOIN kas_wp_term_relationships ON (kas_wp_posts.ID = kas_wp_term_relationships.object_id) WHERE 1=1 AND ( kas_wp_term_relationships.term_taxonomy_id IN (7) ) AND kas_wp_posts.post_type = 'post' AND (kas_wp_posts.post_status = 'publish' OR kas_wp_posts.post_status = 'private') GROUP BY kas_wp_posts.ID ORDER BY kas_wp_posts.post_date DESC LIMIT 0, 1
* Call from: require, require_once, include, WP_Query->WP_Query, WP_Query->query, WP_Query->get_posts
... und noch viele solche Einträge. Das sind aber die Monster.
Hier die komplette Daten:
* Total query time: 1,46683s for 162 queries.
* Total num_query time: 3,013 for 163 num_queries.
* » Different values in num_query and query? - please set the constant define('SAVEQUERIES', true);in your wp-config.php
* Page generated in 2,00000s, 26,66% PHP, 73,34% MySQL
Mein Problem besteht darin, dass sobald ich neuen Artikel oder Seite veröffentliche, die Domain 10 oder 20 Minuten nicht mehr erreichbar ist, Backend wie Frontend.
Kannst du zu den Meldungen was sagen? Wo ich was entfernen/löschen/ändern sollte?
@Artur: ja, du hast extrem viele Abfragen der DB. Die Queries von 162 sind sehr hoch, kann sein - sollte aber nicht. Wir reden an sich im Rahmen von 30-50q. Aber dies 26,66% PHP, 73,34% MySQL ist ärgerlich. Schalte mal alle Plugins ab und prüfe dann. Mit meinem Plugin kannst du sehen, woher die Queries kommen. Bei der Menge und wenig Kenntnis in PHP/SQL wird das aber schwerer, als wenn du alles abschaltest, dann prüfen. Geht dies, dann schalte langsam zu und verringere am Ende die Queries.
Danke Frank für die Tipps! Habe jetzt mal alle Plugins außer
Google XML Sitemaps
Math Comment Spam Protection
WP-Table Reloaded
wpSEO
WP Super Cache
abgeschaltet.
Das Ergebiis:
* Total query time: 0,72092s for 149 queries.
* Total num_query time: 1,946 for 150 num_queries.
* » Different values in num_query and query? - please set the constant define('SAVEQUERIES', true);in your wp-config.php
* Page generated in 1,00000s, 27,91% PHP, 72,09% MySQL
Sieht immer noch zu viel aus aber bekomme zur Zeit keine Ausfälle. Das ist erst mal die Hauptsache.
@Artur: definitiv zu viel; eventuell ist einfach das Theme dahingehend schlecht erstellt. Auch da würde ich alternativ mal TwentyTen und keine Plugins testen.
Sorry für die späte Antwort. Habe das Theme umgestellt und in den PLugins aufgeräumt. Dann hat es auch funktioniert. Könnte dir aber nicht sagen, was schuld war (war ein größerer Umbau/Anpassung).
Vielen Dank Frank, war echt sehr hilfreich. Daumen hoch!
Einfach nur danke.
Bin gerade dabei meine Entwicklungsumgebung auf XAMPP zu tunen. Das tut bitter Not, da es lokal langsamer läuft als auf meinem Server. Da macht das Entwickeln keinen Spaß.
Gruß
Jürgen
Mir ist erst durch durch ein externes Performance Monitoring aufgefallen, wie langsam mein Blog war. Zwar hatte ich mit einem Flickr-Plugin den großen Übeltäter schnell gefunden, aber dank deiner Tipps konnte ich noch ein wenig tiefer debuggen, danke.
I just wanted to say thanks for creating this excellent plugin
Oh, and if I can submit a feature request; it would be great if you could also add the regular WP Debug information to the bottom of the page in the nice layout you have made.
@Johan: what is the regular information of WP Debug; do you mean the infos form the WP Debug Plugin, if the Debug-Mode is active?
Hi Frank,
First off, great plugin! Truly amazing and thank you for taking the time to make this.
Alright now here's the thing. I know someone already asked what the difference between "Total query time" and "Total num_query time", but I did not understand the answer.
Here's the results I'm getting when I load a page.
Total query time: 0.01885s for 64 queries.
Total num_query time: 2.911 for 68 num_queries.
As you can see it's a big difference between the two and I would like to know the difference between them. How do I see what's giving me the extra 2 seconds. Thank you in advance.
@Ricardo: i write a new version; inlcuded in the Plugin Debug Objects - you can current use, the current dev is 2.0.0. The time ist different, i think i have an error on round for seconds.
Hi. Love this plugin. But I want to test it with my caching tool, W3 Total Cache, and when it is enabled, I do not see any debug queries at all. Any ideas on why? Thanks.
@PH: please us the newer version Debug Objects; but if dont work also this plugin; maybe you must clear the cache of W3 Total Cache