WordPress & Webwork

WordPress und der Speicherverbrauch

Ich habe schon von mehreren Kollegen und Lesern gehört … eigentlich gelesen 🙂 in denen man sich über den PHP-Speicherverbrauch von WordPress 2.8.x beschwert hat. Irgendwie konnte ich das nicht ganz nachvollziehen, weil bei mir so weit alles in grünem Bereich lag. Der Speicherverbrauch lag bei meinem Weblog trotz mittlerweile 28 Plugins und der deutschen Sprachdatei bei lediglich 22,69 MByte und damit bei einer Auslastung von 35%.

Der Speicherverbrauch von WordPress

Der Speicherverbrauch von WordPress

Ich habe das Thema eigentlich schon vergessen, bis ich Gestern auf ein paar Lesezeichen gestoßen bin, welche ich vor mehreren Wochen in den Ordner "Noch zu lesen" abgelegt habe. 🙂 So viel zum Thema Informations-Management.

Der erste Link führt zum Beitrag von Dieter Welzel. Dort werden zwei Gründe aufgeführt warum eine WordPress-Installation verhältnismäßig viel Speicher in Anspruch nehmen kann. Zum einen wird auf Servern mit 64-Bit Systemen in manchen Fällen fast der doppelte Speicherverbrauch vermeldet.

Interessant in diesem Zusammenhang ist auch der Beitrag bei WordPress-Deutschland.org.

Eine weitere Ursache ist auch die nicht ganz optimale Verarbeitung der deutschen Sprachdatei (de_DE.mo) durch die Datei /wp-includes/pomo/mo.php. Je nach Installation kann man hier zwischen mehreren hundert KByte bis ein paar MByte an beanspruchten PHP-Speicher frei schaufeln, wenn man die optimierte mo.php von Heiko Rabe benutzt.

Speicherverbrauch von WordPress nach Austausch der Datei

Speicherverbrauch von WordPress nach Austausch der Datei

Durch den Austausch der mo.php konnte ich gut 830 KByte bzw. 1%-Punkt an PHP-Speicherbedarf einsparen. Das ist nicht die Welt, aber in den Kommentaren bei Heiko sieht man, dass bei manchen Leuten der Speicherbedarf um mehrere MByte runter gegangen ist. Je höher der ursprüngliche Speicherverbrauch um so höher das Einsparpotential.

Eine weitere Maßnahme, die bei der Reduzierung des PHP-Speicherbedarfs helfen soll (ich habe es noch nicht getestet) ist der Einsatz von Caching-Plugins. Was an sich logisch ist, weil diese aus den einzelnen Artikeln statische HTML-Dokumente machen und dadurch, bei der Auslieferung der entsprechenden Artikel, PHP nicht beansprucht wird.

29 Reaktion(en)

  1. Dieter

    1. Danke für die Nennung und Verlinkung meines Blogbeitrags. 🙂
    2. Danke für den Hinweis auf reduzierten Speicherbedarf durch Caching-Plugins. Leuchtet ein, kannte ich aber noch nicht. Werde ich mal ausprobieren. 8)

  2. Pingback: Tweets zu diesem Artikel

  3. Jeriko

    Anzumerken ist noch, dass WP-Memory-Usage (also das Plugin in deinen Screenshots) nur den aktuell verbrauchten Speicher anzeigt, was ich de facto nutzlos finde. Viel wichtiger ist doch der Peak-Wert, also wieviel Speicher maximal pro Aufruf benötigt wird, ist der doch ausschlaggebend für Fehler a la "Memory exhausted, trying to allocate…". Solange eine Instanz in das Speicherlimit von PHP passt ist mir alles andere eigentlich recht egal.

  4. Perun

    @Jeriko,

    Viel wichtiger ist doch der Peak-Wert, also wieviel Speicher maximal pro Aufruf benötigt wird, ist der doch ausschlaggebend für Fehler a la "Memory exhausted, trying to allocate…".

    Da hast du Recht. Werde mal mit WP System Health testen.

  5. Dieter

    Ich weiß zwar nicht, ob WP System Health Peak-Werte anzeigt, aber da es im Administrationsbereich den Speicherverbrauch anzeigt und dort meistens das Speicherproblem auftritt, ist der dort angezeigte Wert wohl nahe am Peak dran.
    Im Übrigen kann ich WP System Health auch wegen der vielen weiteren Infos wie bspw. 32- oder 64-Bit System nur empfehlen.

  6. Julian

    Die Werte des Backends sind doch für den Betrieb der Seite relativ egal. Aber gehen wir man davon aus, dass der gleiche RAM auf für jeden Seitenaufruf benötigt wird. Das würde dann heißen, wenn 2 GB RAM nur für WordPress zur Verfügung stehen, wäre es nicht möglich mehr als etwa 100 Requests gleichzeitig zu verarbeiten. Okay, das mag jetzt viel erscheinen, doch für 2 GB RAM finde ich das dann doch etwas sehr wenig…

  7. Stefan

    Das Plugin TPC! Memory Usage zeigt eigentlich alles an was man braucht: Speicherverbrauch, Peak, History Peak und den zugewiesenen Speicher laut php.ini bzw wp-config.php

    Danke für den Tip mit der optimierten mo.php, hat mir 3MB Speicher gespart!

  8. Björn

    Hallo, interessanter Beitrag.
    Ich habe das Problem, dass ich seit Version 2.8 nicht mehr die Autoupdate Funktion nutzen kann. Allerdings habe ich auch ein MemoryLimit von 20 MB

    Ich werde mal testen, ob es mit der Sprachdatei geht ansonsten muss ich mal meinen Hoster fragen, ob der das etwas erhöhen kann!

    Gruß
    Björn

  9. Tom

    Das mit dem Speicher ist schon manchmal merkwürdig. Da spielen auch OS und PHP Version. Die gleiche WP-Installation braucht bei mir mal 15,5 und mal 20 MB. Aber die optimierte mo.php nutze ich auch. Mit Erfolg. 🙂

  10. Ben

    Was mich wundert, dass ich 50.13 % Auslastung im Dashboard habe, obwohl ich ne Menge Widgets deaktiviert habe.

    Möchte gerne mal wissen, wo dass alles her kommt, denn mein Backend ist mehr als langsam, was aber auch nen Grund vom schlechten, bzw. zu voll gemüllten CORE hat.

    LG

  11. Frank

    Es lohnt den Ordner cache (777) in wp-content anzulegen, wenn man Heikos Lösung einsetzt, dann werden die Mehsprachigkeits-Themen gecacht; zu erkennen, wenn im Ordner cache der Ordner mo entstanden ist.

  12. Pingback: Wordpress: modifizierte mo.php : powerbook_blog

  13. Pingback: Bange Zukunft von WordPress? | Dackworld

  14. Paul

    Ich muss sagen das ich keine Probleme mit der Geschwindigkeit habe. Allerdings bin ich auch erst seit Version 2.7 dabei und finde das es normal ist wenn man etwas vom Server abruft, dies nun mal etwas länger dauert.

    Haben die Entwickler sich bereits dazu geäußert? Ich meine sie hätten gesagt, das es auf keinen Fall weniger werden wird.

  15. Markus

    Vielen Dank für den Beitrag. Das hier ist wirklich immer eine tolle Anlaufstelle für Probleme, die mal auftreten und wieder in Vergessenheit geraten, aber von einem selbst nicht lösbar sind.
    <3

  16. Pingback: Bange Zukunft um WordPress? | Dackworld

  17. Pingback: Update auf WordPress 2.8.4 | TimmBlog

  18. Susi

    Danke für die Info. Ich hatte mit dem Speicherplatz nur einmal Probleme. Da hatte ich noch kein Anti-Spam Blugin. Unglaublich wieviel MB Spam Eintrage man da in ein paar Wochen zusammen hat.

  19. Luca

    Warum ist der optimierte Sprachparser denn noch nicht in WordPress integriert? Anstatt das System mal schneller zu machen, blähen sie es leider nur immer weiter auf… Gibts da denn Hoffnung?

    Danke für die Infos, bei mir hat der Einsatz der PHP ganze 3MB gebracht.

    Hast du noch andere Optimierungsmöglichkeiten?

  20. Pingback: PHP-Speicher frei schaufeln | Rappelsnut

  21. thomas

    Leider wird das Projekt mit der beta mo.php wegen dem reduzieren der Speicherfressenden deutschen Sprachdatei nicht vorangetrieben – oder auch sonstwo weiter bearbeitet…..sic!

    Diese beta mo.php läuft auch in WP3 allerdings kann dann im Adminbereich die Seite mit den installierten Plugins nicht aufgerufen werden:

    Es gibt da die Fehlermeldung:
    Fatal error: Call to a member function on a non-object (wegen translations.php on line 108)

    Deswegen habe ich in der translations.php die Zeilen 107 – 109
    = foreach( $other->entries as $entry ) {
    $this->entries[$entry->key()] = $entry;
    }

    ausgetauscht mit:
    $this->entries = array_merge($this->entries, $other->entries);

    siehe auch: http://core.trac.wordpress.org/ticket/11832

    Jedenfalls läuft so die beta mo.php wieder ohne Probleme außer das ein etwas älterer Code wieder eingefügt wurder der folgenden kleinen Fehler verursachen kann falls man es gebraucht:
    It creates problems with numeric keys. For example, _e(’2′) outputs 4 on a localized version, regardless of the value in a .mo file.

    Denke das wäre aber zu vernachlässigen…..

    Schön wäre allerdings eine Überarbeitung der beta mo.php

    grüsse
    thomas

  22. Hody - Diary Of A Fatman

    Hallo,
    Ich habe ständig das Problem mit dem Speicher. Ich habe nun irgendwo gelesen ich soll in der wp-config.php Die Zeile define (’WPLANG’, ‘de_DE’); mit der Zeile define (’WPLANG’, ”); ersetzen – seit ich das gemacht habe funktioniert es wieder. Was kann ich ansonsten noch tun? (Hoster 64bit System, akuell 64MB zugewiesen für mich).
    Zielt die Lösung mit der mo.php auf das Selbe ab und viel wichtiger gibt es seine überarbeitete mo.php für WordPress 3.1.1.

Die Kommentare in diesem Beitrag sind geschlossen.