sensibilisiert durch die jüngsten Performanceprobleme mit dem WordPress Blog, wenn es mal etwas turbulenter wurde (wir reden von lediglich 5-10.000 Seitenaufrufen) habe ich zwarWP Cache installiert, aber möchte der Sache doch auf den Grund gehen.
Ich habe mir hierzu die Anzahl der Queries angesehen, die nötig sind, um aus der Datenbank Daten (Artikeltexte etc…) auszulesen, um damit die Startseite oder eine beliebige Unterseite anzuzeigen. Diese Queries können in WordPress über diese Funktion angezeigt werden: < ?php echo $wpdb->num_queries; ?> database queries in < ?php timer_stop(1); ?> seconds
(Textdatei fürs Code-Schnippsel kopieren). Einfach in der Footer.php einbauen. Und dann nach Laden der Webseite den Quellcode aufrufen. Dabei kommt zB sowas heraus: –27 queries. 2.057 seconds. —
Ich hatte ja stets die Plugins in Verdacht, die hier laufen. Habe also zwecks Test WP Cache ausgeschaltet, um die Ergebnisse gleich zu sehen.
Schauen wir uns einmal die Startseite und die Plugins an, die bei mir dafür Sorge tragen, in der Sidebar die letzten Kommentare anzuzeigen. Dazu gibt es ja einige Lösungsvarianten. Ich stelle drei vor: Get Recent Comments (Einzelkommentare und Trackbacks), Smart Unread Comments (zeigt per Cookie die ungelesenen Kommentare an) und Customizable Post Listing (zeigt die zuletzt kommentierten Artikel an). Alle drei wirken also etwas anders, greifen aber alle auf die Datenbank zu. Und dazu kommt noch Ultimate Tag Warrior (UTW), eines der beliebtesten WordPress Plugins im Bereich Tagging. Die Tags werden am Artikelende angezeigt.
Neue Stellenangebote
Social Media Manager (m/w/d) NordwestLotto Schleswig-Holstein GmbH & Co. KG in Kiel |
||
Social – Media Redakteur / Manager / Journalist (m/w/d) Niedersächsischer Fußballverband e.V. in Barsinghausen bei Hannover |
||
Social Media Manager (m/w/d) ViscoTec Pumpen- u. Dosiertechnik GmbH in Töging am Inn |
Die Startseite besteht bei mir aus 25 Artikeln. Die Gesamtzahl der Queries auf Startseite (index.php) mit wahlweise eingeschaltetem Plugin:
0. keine Plugins auf Startseite: 27 Queries
1. Ultimate Tage Warrior: 38 Queries
2. UTW + Customizable Post Listing: 49 Q
3. UTW + CPL + Smart Unread Comments: 162 Q
4. UTW + Smart Unread Comments: 152 Q
5. UTW + Get Recent Comments (10 Kommentare + 5 Trackbacks): 52 Q
Ergo:
UTW erzeugt ca. 11 Queries
CPL ca. 11 Queries
Get Recent ca. 14 Queries
Smart Unread ca. 114 Queries !!!
Der Killer scheint Smart Unread Comments zu sein.
Raus damit? Jein. Smart Unread packe ich in eine Ansicht, die separat aufzurufen sein wird, auf alle Fälle kommt dieses praktische Monster von der Startseite und den Artikel-Einzelansichten runter. Denn die meisten User surfen auf die Startseite und auf die Einzelartikel.
Übertragen auf 10.000 Seitenaufrufe (PI) je Tag
= Queries/Tag = Queries/Std (18h Basis) = Queries/Sekunde
Basis: Startseite mit 25 Artikeln
UTW = 38xPIs = 0.38 Mio Q = 21.000 Q/h = 5.8 Q/s
UTW + CPL + Smart Unread = 162xPIs = 1.62 Mio Q = 90.000 Q/h = 25 Q/s
UTW + Get Recent = 52xPIs = 0.52 Mio Q = 29.000 Q/h = 8 Q/s
UTW + Customizable = 49xPIs = 0.49 Mio Q = 27.000 Q/h = 7,5 Q/s
Am Crashtag hatte ich in der Spitze 1.000 Seitenaufrufe zw. 13:00 und 14:00 Uhr. Angenommen, alle wären auf der Startseite gelandet, hätte ich zu dem damaligen Pluginpackage 162 Queries je Seitenaufruf gehabt. Das waren also in der einen Stunde 162.000 Datenbankabfragen bzw. 2.700 pro Minute bzw. 45 pro Sekunde. Hätte ich statt dem Package UTW+Smart Unread+CPL nur UTW+Get Recent verwendet, wäre die DB-Belastung um ca. 2/3 niedriger ausgefallen. Also statt 45 wären es nur 15 Abrufe pro Sekunde gewesen. Mit WP Cache wäre es erst recht kein Thema mehr gewesen.
Dann schauen wir uns gleich mal die Einzelansicht (Kommentarview) an, wie es zum Zeitpunkt des Crash aussah:
– UTW spielte als Tagginganzeiger mit
– Smart Unread Comments für die ungelesenen Kommentare
– Customizable Post Listing zur Anzeige der 10 letzten Artikel
– dann der Counter Sayfa Sayac (wie oft wurde Artikel insgesamt gelesen und wie oft heute, damit ist es also ein Plugin, das auch für Write-Vorgänge in der DB sorgt)
– Subscribe to Comments (mailt Kommentator an, wenn jüngere Kommentar erstellt wird)
– Und natürlich Spam Karma 2, das einen Kommentareintrag auf Spamspuren durchschnüffelt
– die Plugins Edit Comments und Official Comments sind mehr oder minder irrelevant, da simple IF Abfragen, keine DB Afragen
In dieser Konstellation erzeugt ein Seitenaufruf:
– 145 Queries bei 0 Kommentaren
– und 258 Queries bei >0 Kommentaren, wow.. qualified for highscore
Testen wir mal einzeln, wenn >0 Kommentare vorliegen (da meine Kommentarquote >1 ist)
Sayfa Sayac = 3 Queries
Spam Karma = beim reinen Aufruf 0 Queries, solange nicht kommentiert wird
Customizable PL = 11 Queries
Smart Unread Comments: 230 Queries!!
Schalte ich CPL und Smart Unread aus, komme ich lediglich auf 20 Queries dann. Was wohl WP Normalmaß ohne Plugin-Schnickschnack darstellt.
Fassen wir zusammen, Zeiptunkt Crash:
1. Startseite BasicThinking Blog erzeugte je Aufruf ~160 Queries
2. Einzelansicht je Aufruf = ~260 Queries
3. Im Schnitt, da ca. 2/3 in Einzelartikelansicht gehen = ~230 Queries je Seitenaufruf
Dazu kommen die Blogs 321 und Living in WoW. Die ja ebenfalls auf dem gleichen Server laufen. 321 erzeugt ~50 Queries und WoW ~70 Queries. Zwischen 13-14:00 Uhr:
– 1.000 PIs BT-Blog = 230.000 Q/h = 64 Q/s
– 250 PIs 321Blog = 12.500 Q/h = 3,5 Q/s
– 250 PIs WoW-Blog = 17.500 Q/h = 5 Q/s
=
summa summarum 260.000 Q/13:00-14:00 und ~72 Queries/s.
Also:
– Plugins auf Queries genauer checken, nicht nur einschalten und freuen
– alternative Plugins miteinander vergleichen, nicht nur auf Funktionalität achten
– WP Cache einsetzen und ruhig schlafen
Update
„DonKult“ schreibt im Kommentar auf 521MB.net:
Naja, ein bisschen hängts schon an der Blogsoftware (hier z.B. WordPress oder pMaschine) immerhin ist die für ihre Datenbankengine zuständig. Aber meineserachtens sind auch 27 Queries zu viel. Ich als Programmierer hab gelernt, dass man bei Datenbankabfragen so wenige wie möglich stellen soll, dafür die Wenigen dann aber recht „kompliziert“?, also mit JOIN, GROUP usw. Aber viele kennen sich damit leider nicht genug aus, um sie anstendig verwenden zu können. Und da mangelt es wohl bei den Plugins, den wenn ich bei Robert lese, dass ein Plugin mehr als 100 Abfragen schluckt, dann ist dass aber allerdeutlichst viel zu viel. Ich hab keine Ahnung wie WP aufgebaut ist und wieviele MySQL-Tabellen das hat, aber ich denke mit 100. Abfragen kann man sicher 10 mal komplett die Datenbank auslesen“¦ Weiterer Nachteil bei den Plugins wird sein, dass einige Plugins die selben Abfragen stellen, da sie nichts voneinander wissen. Das einige Plugins einfach auch nur schlecht programmiert sind ist leider so (wohl der größte Faktor) und das wird sich dank gnadenloser Selbstüberschätzung seitens der Möchtegernprogrammier wohl auch nie ändern, wenn man so manche Foren ansieht…… mhh.
Update 15.01.06, Lösungen:
siehe Blogtuning 1, Maßnahmen zur Verbesserung der Performance und Blogtuning 2, userabhängige Seitenaufbau und Performancekompromisse