Sonstiges

WP Super Cache

24. Sep 2008

das WordPress-Plugin ist ein netter Retter in Not, wenn es wie durch ein Wunder dazu kommen sollte, dass Dein Blog unter Besucherströmen ächzt und stöhnt. Denn, es generiert aus den Artikeln statische HTML-Dateien und entlastet damit das Nadelöhr MySQL-Datenbank ebenso wie die CPU, die sonst bei jedem Aufruf erneut mittels PHP dynamisch generierte Webseiten ausliefern muss. Vor der Einsatz sollte man das Tool testen, denn es gibt Ausnahmen, bei denen es zu keinem Caching kommt. Die sollte man kennen.

Wie ist es bei mir? Soweit ich das ungefähr abschätzen kann, fängt es bei mir ab rund 100 konkurrierenden Usern an, eng zu werden. Das hatte ich letztens erst wieder beobachten können, nachdem -weiß nicht warum- Massen von User über Philipps Blog rübergeschwappt kamen. In nicht einmal zehn Minuten kamen rund 2.000 Besucher vorbei. Gott sei Dank war das wieder schnell over. Aber in diesem kurzen Zeitraum konnte ich mein Blog nicht mehr aufrufen.

Was hilft noch? Man wechselt kurzzeitig auf ein superschlankes Template, das so wenig wie nur möglich an Informationen anzeigt bzw verarbeiten muss. Dazu gehören Grafiken ebenso wie Zusatzinfos und Skripte (recent comments, tags, comments, previous/next articles, Javascript im Header…). Im Hintergrund sollte man zudem alle Frontend-Plugins außer evtl. Akismet abschalten, die getriggert werden, sobald ein Besucher das Blog besucht.

Wenn Ihr mehr über WordPress erfahren möchtet, nutzt die Gelegenheit und besucht das Wordcamp 2009 in Jena! Das übrigens im Jena Tower stattfindet, eine klasse Location, die ich zum Barcamp Jena kennenlernen konnte.

Unsere Empfehlungen für dich

Über den Autor

Robert Basic

Robert Basic ist Namensgeber und Gründer von BASIC thinking und hat die Seite 2009 abgegeben. Von 2004 bis 2009 hat er über 12.000 Artikel hier veröffentlicht.

Zu allen Artikeln

37 Kommentare

  • Mir hat WP Super Cache leider zu viele Probleme bereitet, vor allem mit dynamischen Inhalten, aber wenns nur darum geht den Artikel schnell einer großen Besuchermenge zugänglich zu machen ohne das die Kiste abraucht, dann taugt das teil auch was.

    So eine Option, wie es ober mir Andreas anspricht, dass es erst aktiv wird wenn es eng wird, das wäre was.

  • *nachdenk*

    Also hauptsächlich mit anderen Plugins:

    – Landing Sites
    – Umfragen in der Sidebar
    – FeedStats

    Mehr fällt mir auf die schnelle nicht ein, es war aber alles nur Kleinkram, der aber im normalen Betrieb nervt.

  • Im Prinzip ja,es würde aber auch reichen die Plugins im Falle des Falles einfach abzuschalten, das Theme führt diese bei sauberer Implementierung auch nur dann aus, wenn sie aktivirt sind.

    Quasi: Super Cache geht an und alles unnütze geht aus.

  • Also wenn du echt noch mehr brauchst dann solltest du lieber auf Mephisto umsteigen. Das setzt von vornherein auf page caching und damit ist dann nur der Webserver und die Serveranbindung an sich das Limit (wir reden da von ein paar tausend requests pro Sekunde).

    Und wenn ich bei deinem Blog in den stats seh dass 33 requests nötig waren dann wunderts mich eh ned…

  • @ROB Caching Plugins habe ich auch mal verwendet, aber wie ein Leser schon schrieb, machen die meist mehr Probleme. Vorallem werden verschieden Statistiken nicht mehr korrekt angezeigt. Einige Blogbetreiber sollte vorher mal die Request und die Verzögerung beim Laden externer Daten beobachten. Bei deinem Blog HIER lädt allein Twittercounter ca. 7s bis zum Seitenaufbau!

  • if ($loadstuff = @file_get_contents(‚/proc/loadavg‘)) {
    $loadavg = explode(‚ ‚, $loadstuff);
    $load = $loadavg[1];
    } else {
    $stats = @exec(‚uptime‘);
    preg_match(‚/averages?: ([0-9.]+),[s]+([0-9.]+),[s]+([0-9.]+)/‘,$stats,$regs);
    $load = $regs[1];
    }
    if ($load > 10) {
    deaktiviereLastIntensivePlugins();
    zeigeSchlankesTemplate();
    exit();
    } else {
    ganzNormalerSeitenaufbau();
    }

  • >Pack das doch in ein Plugin, würde sicherlich Interesse wecken.

    Dürfte bei den wenigsten Bloggern gehen. Auch Shared-Hostigangeboten wird der Zugrif auf /proc/loadavg und das ausführen von exec(’uptime’) unterbunden sein.

  • @Marco, externe Dateien spielen keine Rolle beim Lastproblem, gerade bei Images, Width/Height rein und passt. Solange es den Seitenaufbau nicht stört, macht das alles nix.

  • @Michael: ne hab nicht dich gemeint. Und die 33 requests sind SQL-queries auf die Datenbank (sorry, war schon spät). Etwas was extrem eklig wird ist der Flaschenhals Datenbank.

    Übrigens, eine Technik die den meisten PHP hackern völlig unbekannt ist: fragment caching. Sehr praktisch wenn man z.B. die einzelnen Teile der Sidebar cachen will. Oder die einzelnen Artikel in den Übersichtsseiten. Da kann sich schnell ein Dutzend SQL-Queries sparen.

    Ich kann nur empfehlen sich mal in ruby on rails und dessen caching einzuarbeiten. Dann wird einem klar was überhaupt alles möglich ist.

  • Mit APC koenntest du bestimmt nochmal etwas rausholen; allerdings sehen deine [!–18 queries. 0.489 seconds. –]
    Stats im Source so schlecht nicht aus…

    Wuerde mich aber schon interessieren, wie sich ein Blog mit deiner Last auf diesem Server hochskalieren laesst:-)

    Wer ist denn eigentlich Technikchef bei dir? Oder macht der Chef hier alles alleine?

  • Hallo Robert,

    wenn du über die .htaccess deinen Sytlesheets und Grafiken eine Expire-Datum angibst, würde dein Server schon deutlich weniger belastet.

    Außerdem hast du wirklich eine Menge externe Quellen. Allein die Lookups zu den nachfolgenden Domains kosten viel Zeit:

    * http://www.basicthinking.de
    * lifestream.fm
    * http://www.trnd.com
    * http://www.statcounter.com
    * http://www.google-analytics.com
    * http://www.gravatar.com
    * feeds.feedburner.com
    * twittercounter.com
    * buttons.googlesyndication.com
    * http://www.xing.com
    * stats.blogoscoop.net
    * i135.photobucket.com
    * view.atdmt.com
    * wrmwb.7val.com

    Vielleicht gibt es auch eine Möglichkeit, deine Requests zu reduzieren:

    * This page has 6 external JavaScript files.
    * This page has 5 external StyleSheets.
    * This page has 7 CSS background images.

    Für mehr Infos empfehle ich dir das YSlow-Plugin für Firefox.

    Liebe Grüße

    Bertram

  • Schön wäre ein Plugin, dass die Zugriffe auf die Artikel erfasst und bei mehr als X Zugriffen innerhalb eines einstellbaren Zeitraums auf einen Artikel diesen als statische Seite ausgibt.

    Dafür könnte man vorher ein HTML-Template erstellen (so in der Art „Hot Topic“) und das Plugin setzt halt einfach nur den Inhalt des Artikels in das Template ein und liefert dieses dann aus.

    Dann braucht man nicht extra noch ein abgespecktes Theme, und der User sieht sofort, dass es hier um ein Thema geht, dass gerade „in“ ist im Netz.

    Funktioniert natürlich nicht, wenn die Hauptlast auf der Startseite liegt.

  • @Marco, externe Dateien spielen keine Rolle beim Lastproblem!
    Aber beim Aufbau

    @Bertram Simon: wenn du über die .htaccess deinen Sytlesheets und Grafiken eine Expire-Datum angibst, würde dein Server schon deutlich weniger belastet.

    Allein die Lookups zu den nachfolgenden Domains

    Na sag ich doch!

  • @Michael: Also smilies kann man ja wohl bitte cachen, fehlt sowieso komplett, ein content_html in der posts-table.

    @Pierre: extrawürst sind das schlimmste überhaupt. Man muss schon so konsequent sein und jeden GET request cachen.

    Die JS und CSS Dateien einfach in eine (also zwo) kopieren, darf ich sagen wie bequem das bei rails funktioniert?

  • @Thomas: Ja, aber meist ist das doch gar nicht nötig. Der Besucheransturm betrifft doch in der Regel nur einen Artikel. Alles andere kann doch dann „wie immer“ bleiben.

    Klar, wenn man alles in den Cache packt holt man noch mehr Perfomance raus, aber manche dynamischen Inhalte lassen das ja nicht zu.

    Für Blogs ohne solche dynamischen Inhalte jedoch ist das Cachen jedes Requests wie Du es vorschlägst sicherlich der beste Weg.

  • @Pierre: Entweder gescheit oder gar ned. Ist auch viel einfacher wenn man das Problem global angeht.

    Für sehr dynamische Sachen gibt’s ja die Möglichkeit des fragment caching, kennt halt blos kaum einer…

  • @Thomas: Kann man den Fragment Caching so ohne weiteres in WordPress, was ja die meitsten Blogger nutzen, integrieren?

    Bei ASP.NET und Ruby on Rails ist so etwas ja wohl üblich, aber wie implementier ich so etwas möglichst einfach bei WordPress?

  • @alle cache götter:

    Eigentlich eignet sich ein Blog sehr gut um das System direkt auf Caching aufzubauen, oder? Überwiegend Lesezugriffe. Warum also nicht ALLE Seiten in einer Table cachen und nur bei Veränderung rebuilden lassen?
    Dann hätte man pro Seitenaufruf eine Query.

  • Flash Gamez down…

    Heute, im Laufe des Nachmittages hat der Hoster von Flash Gamez die Subdomain mal schnell auf 0700 ge-chmod-det
    Angeblich zu viel Last für den Server(7.948.124 Hits in diesem Monat, Stand heute). Sieht so aus, als ob ich mich auch mit dem Thema cach…

  • wie heißt dein Hoster, blog.der-link.de?
    Der kann richtig Ärger bekommen, wenn er sich solche Rechte nicht irgendwo in den AGB eingeräumt hat.
    Bei H.E. haben sie inzwischen hoffentlich umgestellt, sodass statt Reduzierung der Leistung, lieber vorübergehend mehr Bandbreite zur Verfügung steht. Zumindest berichtete die Chip letztens über sowas.

  • @ Stephe
    Hättest Du die Kommentare(besonders die von Robert)gelesen, wären dir ein paar Sachen aufgefallen.
    1. Robert hat einen Root-Server – leider etwas schwach auf der Brust
    2. Ich bin Blogger und helfe Rob nur bei dem techn. Kram an der Kiste
    3. Der Trackback genau über Dir kommt von meinem Blog, der Artikel bezieht sich jedoch auf ein weiteres Blog von mir, welches gestern leider von einem anderem Hoster mal kurzer Hand abgestellt wurde

    😉

  • @ SteBu
    Ich denke er meint genau dich, also das dein Hoster richtig Ärger bekommen kann weil er den Stecker bei Flash Gamez gezogen hat.