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
|
Growth Marketing Manager:in – Social Media GOhiring GmbH in Homeoffice |
|
|
Social Media und Content-Marketing Spezialist (m/w/d) HELDELE GmbH in Salach |
|
|
Senior Communication Manager – Social Media (f/m/d) E.ON Energy Markets GmbH in Essen |
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
50 Queries in durchschnittlich einer Sekunde beim Aufruf der Startseite. Get Recent Comments erzeugt 14 Queries für 5 Kommentare, die anderen Plugins kann ich nicht einfach so abschalten, da die Site dann nicht mehr korrekt lädt.
Das das zuviel ist, zeigt mir der Vergleich mit deinem Blog. Allerdings kann ich nicht einschätzen, ob nun die 27, die bei dir ohne Plugins rauskommen, okay sind oder nicht. Bei meinem Blog und meinen Besucherzahlen mag das vielleicht nicht so sehr ins Gewicht fallen, es geht da wohl mehr um den persönlichen Frieden. Ich habe einfach das Gefühl, dass selbst 27 Queries irgendwo zuviel sind.
Dies ist einfach das große Problem von Systemen wie WordPress oder auch phpNuke, in welchem die Community die Produkte durch eigenen Code erweitern dürfen. Eine Vielzahl der Änderungen sind in der Kombination einfach tötlich.
@Thomas Reimer: Seltsame Auffassung von Open Source und dem was sie leisten soll. Schließlich kann jeder diese Software selbst optimieren oder einen Programmierer mit der Optimierung beauftragen. Wer mit solchen Ansprüchen kommt, der sollte besser auf propritäre Software umsteigen und dafür zahlen.
Kombination? Was für eine Kombination denn? Also so wie ich das sehe ist dieses Smart Unread Comments ALLEINE für über 100 Anfragen verantwortlich, keine Spur von Kombination.
Aber im Grunde haben beide Recht: Weil jeder ein Plugin schreiben kann entsteht auch eine Menge blödes Zeug. Aber jeder kann sich dann auch hinsetzen und es besser machen.
Bedanke mich sehr bei Dir für diesen aufschlussreichen Artikel und Deine Detailarbeit bei der Auffindung der Schwachstellen. Empfehlenswerte Vorgehensweise.
Zugleich zeigt sie doch deutlich Schwachstellen auf, die offenbar doch Blogsystem-übergreifend zu existieren scheinen.
Alle Kritiken an MT relativieren sich zumindest dadurch. Die Möglichkeit statische Seiten und dynamische Aufrufe kombinieren zu können scheint mir eine gute Mäöglichkeit, Last zu nehmen und Funktionalität zu behalten.
Plugin-Funktionen bringen zum Teil erst richtig interessante Farben in die Landschaft (siehe oben). Bleibt die Frage, wie lassen sich die Plugins systemschonender fahren?
BTW, warum kann man eigentlich die Anzahl der täglichen und kummulativen Leser nicht aus den Statistiken auslesen und muss diese NOCH EINMAL mitschreiben?
Wie bringe ich ein WordPress Weblog in Bedrängnis?
Wer bis heute annahm, dass nur MT-Weblogs und Perl dem Server zu schaffen machen kann, der wird dieser Tage eines Besseren belehrt. Interessante Berichte bringen Erkenntnisse insbesondere für WordPress-Fans. Wie bei Robert Basic im Weblog berichte…
[…] Update: Siehe WordPress Plugin-Perfomance weitere Artikel zu: WordPress […]
danke Robert für die gute Aufarbeitung. Jetzt ist mir auch klar, warum die eine Installation bei 23.000 PI’s kaum eine Verzögerung zeigt und die andere bei 10.000 wegbricht. Aber was ist mit Gerald? Der hatte doch auch Probleme und arbeitet ohne Smart Unread?! Vielleicht mag er ja mal was dazu sagen.
Thomas
PS: Komische OpenSource-Diskussion da oben 🙁
… ich habe oben die 4.000 nach dem ersten Speichern auf 10.000 geändert. Warum ist das jetzt nicht zu sehen? WP-Cache?
kann sein, WP Cache brauche ich momentan nicht, muss ich noch raushauen.
Test: Edit 1 + Edit 2 = ich sehe jede Einzeländerung, Du nicht?
Doch jetzt ja. Ich habe es zweimal editiert und jeweils standen wieder 4.000 da. Es war ein bißchen verwirrend. Hast Du mit Gerald gesprochen?
[…] siehe auch WordPress: Plugins = Performance-Killer? weitere Artikel zu: caching, mysql, SQL, WordPress, WP Plugin […]
wird wohl WP Cache Auswirkungen beim Editieren von Kommentaren sein, da ist ja einiges beim Entwickler im Kommentarverlauf gerade mit Cookies hochgepoppt.
Mit Gerald schon gesprochen? Nein, noch nicht, aber er liest das Blog regelmäßig, wird sich sicherlich zu Wort melden bzw, eigene Maßnahmen ergreifen, der Fuchs 🙂
Er könnte uns aber auch mal in seine Karten schauen lassen 🙂
Muß jetzt arbeiten – viel Erfolg bei den weiteren Nachforschungen und halt uns weiter so gut auf dem Laufenden 🙂
Hier ist der Übeltäter->
foreach ($recent_posts as $postid => $posttime) {
$sql = "SELECT comment_date FROM ".$GLOBALS['tablecomments']." WHERE comment_date > FROM_UNIXTIME(".$current_timeout.") AND comment_post_ID = ".$postid." AND comment_approved = '1' ORDER BY comment_date DESC LIMIT 1";
$rs = $db->get_results($sql);
if ($rs === false) {
die( $wpdb->ErrorMsg());
}
if ($rs[0]->comment_date) {
$recent_posts_new[$postid] = $posttime;
}
}
Also wenn ich mir das so Anschaue wird mir richtig schlecht…. eine Schleife die Sql Abfragen ausführt…
Wenn du Pech hast kann dir dein Plugin locker flockig 1000 Abfragen durchlaufen….. oder auch mehr….
[…] Wie machen es andere? Z.B. Simple Machines (kurz SMF, ein Webforum im Stil von BB) hat eine zentrale Plugin-Datenbank, im Admin-Bereich von SMF können Plugins aus dieser Datenbank heraus installiert werden. Die Plugins werden auf der SMF-Seite zentral geführt und vor Aufnahme (oberflächlich?) geprüft. Für jedes Plugin wird automatisch ein Forumsbeitrag im offiziellen Forum erzeugt. Dadurch werden die Plugins automatisch dort zentral diskutiert, und die SMF-Entwickler lesen stetig mit. Damit existiert zumindest eine indirekte QS. Meines Erachtens ist dies durchaus ein gangbarer Weg und wäre auch für WordPress sicherlich machbar und sinnvoll. Updated: Unter WordPress: Gesamt und Plugin-Performance analysiert Robert im Detail die Plugin-Performance. Interessant ist in dem Zusammenhang auch der Kommentar von Micha, was meie o.g. Befürchtungen bezügl. Queries in Schleifen bestätigt: Hier ist der Übeltäter-> […]
am gravierendsten in hinblick auf die performance ist seit v2.0 das URL-rewriting für schicke permalinks. da fallen die paar db-queries nicht mehr ins gewicht (ich schätze mal, intern wird PHP längst sowas wie ein connection-pooling betreiben, insofern spielt das kaum noch ne rolle, ob man 10 oder 100 queries absetzt, sofern dabei nicht megabyteweise resultsets erzeugt werden).
die URL-rewriteregeln, die WP2.0 in die .htaccess schreibt, sind ein wahrer apache-killer, denn a) wird dadurch JEDER request abgefangen, um zu schauen, ob es auf dem server zu dieser request-URI evtl. tatsächlich ein echtes file gibt, und zum anderen enthält der regelsatz sogar noch einen fehler, wie man in der bugliste verfolgen kann. wenn auf ein solches blog dann viele requests zukommen, so quasi aus heiterem himmel, muss man sich nicht wundern, wenn die chose dann zusammenbricht.
@Thomas: So komisch finde ich die Diskussion gar nicht. Da ich öfters Open Source Foren lese, wundere ich mich schon sehr über die Anspruchshaltung, die einige Nutzer an den Tag legen. Deshalb konnte ich mir einen Kommentar zu meinem Vorredner nicht verkneifen.
[…] Früher haben echte Männer an ihren Autos herumgeschraubt, heute tun diese Männer an ihren Blogs schrauben 🙂 Aaasloooo… habe nunmehr folgende Tuningmaßnahmen getroffen, nachdem ich mich gestern mit den Plugins befasst habe. […]
@countzero
Exzessive .htaccess? Ich habe gerade erst ein brandneues 2.0 installiert mit fancy-Urls und die htaccess ist gerade mal 5 Zeilen lang.
mod_rewrite ist sicherlich performance-bremsend.
Aber – @countzero – warum soll das erst seit WP 2.0 so sein? Ich wüsste jetzt nicht, dass sich da von 1.5 auf 2.0 was geändert hätte.
@kgblog: Jupp – genau das meinte ich. Bin also ganz Deiner Meinung 😉
Ist es Absicht, dass du die php-Befehle fürs Anzeigen der Queries und der beötigten Zeit falsch geschrieben hast? Ist ein Leerzeichen zuviel drin, damit funktioniert der Code nicht.
Gruß, Ralph
Ist Absicht, sonst würde WordPress meckern. Ich hab gerade mal bei mir geschaut: ~1200 Queries. Ich wär fast an einem Keks erstickt, das ist doch irgendwie zuviel. Das liegt aber definitiv an der Sidebar, in der Artikelansicht hab ich weitaus weniger. Dh. soviel wie du vorher auf der Mainpage hattest … ich sollte da vlt. auch mal was tieferlegen, allerdings mehr als nur 5cm.
1200 Datenbankabfragen????? Biste sicher???
@Ralph, WP scheint irgendwie stets dieses Leerzeichen reinzumachen, ätzend !!! Werd mal ne Textdatei ankleben, danke.
Pimp my WordPress
Robert Basic zeigt in seinem Basic Thinking Blog, wie man WordPress ressourcenschonender bzw. serverfreundlicher gestalten kann. […]
Robert, schau mal unten in der Leiste, da hab ich das temporär eingebaut und surf mal ein wenig herum und vergleiche.
erstaunlich viel … 1200 auf der Startseite und über 200 auf der Single View, die ohne Sidebar daherkommt.. wow… was hast Du denn für Plugins am Laufen?
Jede Menge, allerdings nicht viel, was mit der Sidebar zu tun hat. Kommentare und iTunesSpy (ganz unten) hab ich testweise mal rausgenommen, sonst ist da nichts, was nicht WP-Standard wäre. Hat aber beide mal nur ein ganz paar Queries weniger gebraucht. Dann hab ich die Anzahl der pro Seiten angezeigten Beiträge mal kurz auf einen gesenkt. Und siehe da: Nur noch ~ 230 Queries. Liegt also an der Anzahl der angezeigten Beiträge. Was ist da drin ? Eigentlich nur UTW Tags. Also testweise raus, ohne hab ich nur die Hälfte ~ 600. Aber immer noch verdammt viele … Sonst fällt mir eigentlich nix ein, was noch da Queries verursachen könnte. Wie ich das jetzt optimiere muss ich wannanders ausprobieren, jetzt ist ertmal Schule angesagt (war es eigentlich schon um 14:00 ….).
hm.,.. die Anzahl der angezeigten Artikel auf Startseite änderte in meinen Tests nix, was die DB Abfragen angeht. Es wird nur einmal angefragt anscheinend. Ob Du nun 100 oder 1 Artikel abbildest. Klar, es ändert sich die KByte Größe der Seite bei mehr Artikeln, aber das ist ne andere Story. UTW erzeugt 600 Queries?????? Wow… was haste denn für eine UTW gewählt, die das so aufdreht? Ich nutze UTW_ShowTagsForCurrentPost(„commalist“) in der single.php nicht mehr in der index.php.
Melde Dich mal, wenn Du wieder Zeit hast, Schule geht ja vor 😉
@fletcher (20) und michael (21):
ihr habt nicht verstanden, was ich geschrieben habe – gerade WEIL die neue .htaccess von wp2.0 nicht mehr mit einzelnen mustern arbeitet, sondern nur noch auf existenz eines files prüft und ansonsten stur durchreicht, geht die last nach oben. nun muss der server jede URL erst prüfen, obs ne datei zu dem pfad gibt, bevor an die wp-eigene rewrite-funktion durchgereicht wird (und diese dann, nochmals aua, statt in native code in vergleichsweise lahmarschigem php-code die erkennung übernehmen muss).
merke: ne scheinbar elgantere weil kleinere htaccess muss nicht gleichzeitig besser sein 😉 mein provider wird schon wissen, weshalb er mich wegen dieser htaccess-datei angeschissen hat, und so wenig ich mich auch sonst mit dem indianer auskennen mag, wie urlrewriting funktioniert, das weiss ich nun wirklich.
[…] Achtung: Jedes Plugin erzeugt eine weitere Last, so daß die Performance des WordPress Blogs mit steigendem Traffic immer schlechter wird. Wenn Du ein Plugin nutzen möchtest, teste es lieber, ob sich an der Geschwindigkeit des Seitenaufbaus etwas ändert. Manche Plugins greifen auf die Datenbank zu. Um zu kontrollieren, ob die DB Abfragen nicht übermäßig hoch sind, siehe diesen Artikel: WordPress: Gesamt und Plugin-Performance, Blogtuning und Blogtuning II.: Userabhängige Seitendarstellung […]
Ich habe auf meine Blog einen Artikel veröffentlich, der sich ebenfalls mit diesem Thema beschäftigt, und auch deine Artikel als Beispiele heranzieht. Wieso funktioniert der Trackback nicht? 🙁
[…] Klar hat er sich – so wie man ihn kennt – gleich daran gemacht und angefangen, seinen Blog zu optimieren! Hier findet man einige gute testergebnisse sowie Lösungswege. Robert Basic hat 2 weitere BlogtuningArtikel veröffentlicht: […]
Björn, die Antwort ist einfach; Setzt Du einen Link zu meiner Seite in Deinem Posting, klappt das Trackback. Ist der Link aber wie bei Dir so aufgebaut: Link-eigene URL?Link-meine URL sperrt sich natürlich Spam Karma und deklariert Deine Trackbackversuche als Spam. Habs jetzt manül freigeschaltet.
achso, das passiert wahrscheinlich durch das ClickCounterPlugin, oder so ähnlich 🙂
Naja, danke für das Freischalten, bzw es hat seltsamerweise auch nicht funktioniert, wenn ich deine URL direkt unten bei Trackback einfüge. Das sollte aber funktionieren, oder?
solange die echte URL irgendwo im aufzurufenden Artikel bei Dir auftaucht, ist das alles kein Problem. Sonst blockt Spam Karma. Hättest Du nix gesagt, hätte Spam Karma Deine Domain in die Blacklist geschoben. Schon doof zwar, aber wie soll man umgekehrt auch wissen, welche Blogs was für Tools im Einsatz haben?
Ja stimmt … Zum Glpck bin ich noch nicht in der Blacklist 🙂
Wahrscheinlich könnte man halt nur ne extra Whitelist programmierern 😉
dazu hat SK eigens ne Domain/IP Whitelist, also keine Mühen bitte :-))
Ok, sehr gut 😉
[…] Wie ich sehe, läuft eine Diskussion um die Performance von WordPress 2.0, was insbesondere die Systembelastung durch die Anzahl der Queries pro Seite betrifft. Ausführliche Informationen findet man z.B. hier und hier. […]
[…] Durch den Artikel von Robert inspiriert, habe mich auf die Suche nach Plugins begeben, die die Datenbankabfrage nach oben drücken. Robert gibt dazu ja schon eine Menge an Tipps und viele seiner Kommentare erläutern noch mehr Hintergründe. Nun, ich wollte aber auf die Darstellung meiner Startseite nicht unbedingt verzichten. Die Posts und Kommentare habe ich bisher mit dem Plugin „Customizable Comment Listings“ in die Seite geladen. Leider drückt das Plugin die Querie-Abfrage enorm hoch. In meinem Fall möchte ich die letzten 10 Beiträge und Kommentare auf der Startseite darstellen, deshalb habe ich mich dafür entschieden, das ganze mit dem RSS-NewsFeed zu ermöglichen. Mit der hier vorgestellten Lösug konnt ich mehr als 40 Anfragen, welche das Plugin duchführte, beseitigen. Auf anderen Blogs, wo ich WP als CMS einsetze, habe ich so ebenfalls einige Anfragen (ca. 20 Queries) unterbinden können. In den Fällen stelle ich nur die letzten Kommentar im Sidebar dar, bzw. auf einer extra Seite. […]
Wie man WordPress Weblogs tiefer legt & richtig tuned
»Geschwindigkeit ist (keine) Hexerei.« Sprach Robert und legte sich wie einige andere WordPress Blogger unter sein Weblog und fing an zu schrauben. Und so lernen wir, wie auch WordPress Weblog tiefer zu legen sind. Breits in Wie bringe ich …
Einige Daten zur Web-Performance mit mod_rewrite
Erklärung von Abkürzungen
Seitenanforderungen, Anzahl pro Sek.: sa
Testlaufzeit, in Sekunden: t
Prozessorlast, normal 2~4 : l (je höher desto schlechter)
mod_rewrite: F
Mustervergleich: FM
Dateivergleich: FD
sa t l F WP-Cache Plugin
-----------------------------------------
500 13 0.3 - - (rein statische Seiten)
500 13 117.x FD n (beinahe Crash)
500 13 40.x FM n
500 16 1.4 FD j
500 17 1.0 FM j
150 13 0.4 FM j
150 13 0.4 FD j
50 13 41.x FF n
50 12 39.x FM n
25 13 0.3 FD j
25 13 0.5 - j (rewrite Off)
25 22 38.2 FM n
Zusammenfassung: wichtiger als mod_rewrite auf Dateiebene oder auf Musterebene ist die Aktivierung eines Caches für Seiten, die häufig angefragt werden.
Selbst bei 500 Seiten pro Minute sind zwischen beiden rewrite-Methoden nur geringe Unterscheidungen zu finden.
alles gestetet auf AMD x64 3000+, Apache 2, Linux 2.6.8-24.20-default
Mustersuche:
RewriteCond %{REQUEST_URI} index.html$
Dateisuche:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
Die RewriteRule war bei beiden Conditions die gleiche.
ich hab wordpress 2.0.3 laufen und bin eigentlich sehr zufrieden nur die performance ist sehr schlecht und ich weiß nicht recht warum. übermäßig viel plugins hab ich nicht, wp-cache ist aktiviert, (das brachte zwar einiges an geschwindigkeit) aber für 15 queries 40 sekunden zu brauchen ist meiner meinung nach schon krass.
Und das bei maximal ca. 30 zugriffen pro tag!
hat wer nen tipp?
aja, der url: http://www.georghanisch.at
thx!
@Georg: Auch ich hab die Beobachtung gemacht, dass WordPress ab der 2.0er Version regelrecht einschläft. Vielleicht läuft bei Dir WP 1.52 auch besser?
http://www.gunnart.de/tipps-und-tricks/wordpress-use_verbose_rules-permalinks-und-performance/
Diese „verkürzte“ .htaccess funktioniert bei mir nicht, aber mit der „langen“ hatte ich manchmal 50 abfragen auf seiten, für die wordpress 1.52 mit 15 ausgekommen ist.
hey!
ja, also ich bin jetzt auf was draufgekommen und zwar hat bei mir shortstat enorm gebremst, speziell die ip2country abfragen. da ich aber für die flaggen im gästebuch ohnehin auf meinem server eine solche datenbank laufen habe, hab ich das shortstat einfach umgeschrieben dass es nicht auf den externen host den request schickt sondern lokal abfragt und das brachte etliche sekunden. ich würde sagen die performance is jetzt wirklich ok. und das auf nem shared host..
lg
Georg
danke für den guten Tipp! Wird hoffentlich dem einen oder anderen helfen.
[…] WordPress: Gesamt und Plugin-Performance […]
[…] – WordPress: Gesamt und Plugin-Performance – 48 (28) […]
hi robert,
ich habe einen blog für 2 freunde erstellt, ist ein persönlicher blog um ihre bilder darzustellen, daher auch recht selten besucht.
habe da gerade probeweise nach der anzahl der queries geschaut und das ergebnis wird dich umhauen:
hier die url des blogs falls du neugierig geworden bist: http://www.rum-reisen.de/
ich dachte erst, daß das shoutbox plugin dran schuld ist, aber nach deaktivierung der shoutbox, waren es nur einige wenige aufrufe weniger…
hoppla, das ergebnis wurde rausgefiltert:
1655 queries. 0.938 seconds.
[…] Update: Unter WordPress: Gesamt und Plugin-Performance analysiert Robert im Detail die Plugin-Performance. Interessant ist in dem Zusammenhang auch der Kommentar von Micha, was meine o.g. Befürchtungen bezügl. Queries in Schleifen bestätigt: Hier ist der Übeltäter-> […]
[…] Gesamt und Plugin-Performance, Blogtuning und Blogtuning II.: Userabhängige Seitendarstellung Trackback-URL Gelesen: 5605 heute:18 […]
[…] Mir fällt da gerade wieder ein Artikel auf Roberts Seiten ein….mal suchen……ah ja, hier: 1, 2. Nur gut, dass man sonst nichts zu tun hat Fliegen Sie mit LTU günstig zu über 70 Zielen weltweit! Weitere Artikel zu diesem Thema: – Keine passenden Artikel gefunden […]
[…] Langsam wird es Zeit für ein neues Stöckchen. Aber keins der langweiligen Sorte! Diesmal soll sich das Holzstück unter die Menschen mischen und mich mit keineswegs langweiligen Zahlen versorgen: Anzahl und Dauer der SQL-Queries auf Seiten des Blogs. Zahl, der Retter So manch einer hat sich schon über die langsame Startseite gewundert und geärgert. Goldwert und empfehlenswert ist dann Information über die Anzahl der ausgeführten Datenbank-Anfragen kombiniert mit summierter Ausführungszeit. Aber auch bei einem flüssig laufenden System machen diese Werte durchaus Sinn: Zum Beispiel weisen die Zahlen beim genauerem Hinsehen und permanenten Beobachten auf eine Reorganisation der Datenbank hin. […]