WordPress vor dem Ausreizen des RAM-Speicher bewahren

Seit einigen Wochen finden sich in meiner php.err täglich Einträge wie den folgenden:

...
[12-Jan-2015 14:19:24 UTC] PHP Fatal error: Out of memory (allocated 9699328) (tried to allocate 78720 bytes) in /blog/wp-includes/script-loader.php on line 528
[12-Jan-2015 14:19:24 UTC] PHP Fatal error: Out of memory (allocated 8126464) (tried to allocate 49152 bytes) in /blog/wp-includes/comment-template.php on line 2163
[12-Jan-2015 14:19:24 UTC] PHP Fatal error: Out of memory (allocated 1572864) (tried to allocate 3072 bytes) in /blog/wp-includes/functions.php on line 3514
[12-Jan-2015 14:19:24 UTC] PHP Fatal error: Out of memory (allocated 6291456) (tried to allocate 3072 bytes) in /blog/wp-includes/post.php on line 670
[12-Jan-2015 19:59:36 UTC] PHP Fatal error: Out of memory (allocated 19660800) (tried to allocate 8 bytes) in /blog/wp-includes/pomo/mo.php on line 237
[12-Jan-2015 19:59:36 UTC] PHP Fatal error: Out of memory (allocated 23592960) (tried to allocate 32 bytes) in /blog/wp-includes/pomo/mo.php on line 243
[12-Jan-2015 19:59:36 UTC] PHP Fatal error: Out of memory (allocated 16252928) (tried to allocate 49152 bytes) in /blog/wp-content/plugins/stop-spammer-registrations-plugin/stop-spammer-registrations.php on line 163
[12-Jan-2015 19:59:36 UTC] PHP Fatal error: Out of memory (allocated 22544384) (tried to allocate 32 bytes) in /blog/wp-includes/pomo/mo.php on line 237
[12-Jan-2015 19:59:36 UTC] PHP Fatal error: Out of memory (allocated 18350080) (tried to allocate 1920 bytes) in /blog/wp-includes/default-widgets.php on line 914
[12-Jan-2015 19:59:36 UTC] PHP Fatal error: Out of memory (allocated 22806528) (tried to allocate 94 bytes) in /blog/wp-includes/pomo/mo.php on line 250
[12-Jan-2015 19:59:36 UTC] PHP Fatal error: Out of memory (allocated 22282240) (tried to allocate 32 bytes) in /blog/wp-includes/pomo/mo.php on line 243
[12-Jan-2015 19:59:36 UTC] PHP Fatal error: Out of memory (allocated 20709376) (tried to allocate 12288 bytes) in /blog/wp-content/plugins/wptouch/themes/foundation/modules/sharing/sharing.php on line 126
[12-Jan-2015 19:59:36 UTC] PHP Fatal error: Out of memory (allocated 20971520) (tried to allocate 12288 bytes) in /blog/wp-content/plugins/wptouch/themes/foundation/modules/social-links/social-links.php on line 54
[12-Jan-2015 19:59:36 UTC] PHP Fatal error: Out of memory (allocated 21495808) (tried to allocate 12449 bytes) in /blog/wp-includes/pomo/streams.php on line 113
...

Egal, ob ein WordPress-Update, eine Aktualisierung eines Plugins oder Überbuchungen meines Hosting-Servers durch Cyon der Auslöser war — ich wollte mein Log vor solchen Einträgen bewahren.

Nachfolgend eine Anleitung, wie ich vorgegangen bin:

TPC! Memory Usage

Als erstes installierte ich das Plugin TPC! Memory Usage, welches die Speicherauslastung bei jedem Aufruf eines WordPress-Artikels aufzeichnet und im Administrations-Dashboard anzeigt.

Ca. 120 vom Plugin innerhalb weniger Minuten automatisch generierte und versendete E-Mails später hatte ich dann auch herausgefunden, dass ich in der Administrationsoberfläche im schwarzen, vertikalen Menubalken unter Memory Usage > Einstellungen > Notify if memory usage exceeds: den Schwellenwert von 32MB auf 64MB erhöhen musste, um von der Mailflut verschont zu werden.

Der Schwellenwert ist übrigens auch in der Datei tpcmem-core.php hardkodiert, falls jemand den Wert vor dem Upload der Dateien in die WordPress-Installation anpassen möchte:

...
add_option('tpc_memory_usage_email_high_usage', 32);
...

P3 (Plugin Performance Profiler)

Nachdem ich mit dem Plugin und den automatisch versendeten E-Mails die hohe Speicherauslastung durch meine WordPress-Installation bestätigt hatte, stiess ich mit einer Google-Suche auf folgenden Artikel:

How to monitor and reduce WordPress memory usage by plugins

Ich entschied mich, das in diesem Artikel erwähnte Plugin P3 (Plugin Performance Profiler) zu installieren und auszuführen. Beim ersten Durchlauf wurde ich wieder mit TPC!-Notifikations-E-Mails eingedeckt, die Speicherauslastung lag regelmässig über 80 MB.

Die erste Auswertung sah folgendermassen aus:

WordPress Plugin Profile Report
===========================================
Report date: Dienstag, 13. Januar 2015
Theme name:
Pages browsed: 31
Avg. load time: 2.1364 sec
Number of plugins: 13
Plugin impact: 79.58% of load time
Avg. plugin time: 1.7001 sec
Avg. core time: 0.5284 sec
Avg. theme time: 0.0218 sec
Avg. mem usage: 86.89 MB
Avg. ticks: 88,114
Avg. db queries : 70.94
Margin of error : -0.1139 sec

Plugin list:
===========================================
P3 (Plugin Performance Profiler) - 0.0073 sec - 0.43%
Akismet - 0.0147 sec - 0.86%
Better WordPress Minify - 0.0540 sec - 3.18%
Google Sitemap Generator - 0.0035 sec - 0.21%
Jetpack von WordPress.com - 0.8103 sec - 47.67%
Limit Login Attempts - 0.0257 sec - 1.51%
Simple Lightbox - 0.4993 sec - 29.37%
Stop Spammer Registrations Plugin - 0.0092 sec - 0.54%
SubToMe - 0.0065 sec - 0.38%
Tpc Memory Usage - 0.0311 sec - 1.83%
WP Permalauts - 0.0327 sec - 1.92%
Wp Super Cache - 0.0138 sec - 0.81%
WPtouch Mobile Plugin - 0.1919 sec - 11.29%

Deaktivierung von Jetpack

Eine Google-Suche zeigte, dass ich offenbar nicht der einzige WordPress-Benutzer bin, dessen Jetpack-Plugin mehr als die Hälfte der Ladezeit eines Blog-Artikels ausmacht.

Deshalb entschied ich mich kurzerhand dazu, Jetpack zu deaktivieren. Der nächste Benchmark mit P3 lieferte folgende Zahlen:

WordPress Plugin Profile Report
===========================================
Report date: Dienstag, 13. Januar 2015
Theme name:
Pages browsed: 17
Avg. load time: 1.2534 sec
Number of plugins: 12
Plugin impact: 60.86% of load time
Avg. plugin time: 0.7629 sec
Avg. core time: 0.4815 sec
Avg. theme time: 0.0994 sec
Avg. mem usage: 76.41 MB
Avg. ticks: 91,763
Avg. db queries : 56.94
Margin of error : -0.0904 sec

Plugin list:
===========================================
P3 (Plugin Performance Profiler) - 0.0014 sec - 0.19%
Akismet - 0.0098 sec - 1.28%
Better WordPress Minify - 0.0315 sec - 4.13%
Google Sitemap Generator - 0.0071 sec - 0.94%
Limit Login Attempts - 0.0108 sec - 1.42%
Simple Lightbox - 0.5075 sec - 66.53%
Stop Spammer Registrations Plugin - 0.0040 sec - 0.52%
SubToMe - 0.0146 sec - 1.92%
Tpc Memory Usage - 0.0284 sec - 3.72%
WP Permalauts - 0.0231 sec - 3.03%
Wp Super Cache - 0.0087 sec - 1.14%
WPtouch Mobile Plugin - 0.1159 sec - 15.20%

Deaktivierung von Simple Lightbox

Das Plugin Simple Lightbox dient dazu, verlinkte Bilder im Grossformat als Overlay über der aktuellen Seite anzuzeigen. Doch war die Funktionalität es wert, über eine halbe Sekunde auf das Plugin zu warten? Ganz klar: Nein.

Ich deaktivierte auch dieses Plugin und führte die Messungen ein drittes Mal durch:

WordPress Plugin Profile Report
===========================================
Report date: Dienstag, 13. Januar 2015
Theme name:
Pages browsed: 17
Avg. load time: 0.8826 sec
Number of plugins: 11
Plugin impact: 39.13% of load time
Avg. plugin time: 0.3454 sec
Avg. core time: 0.4266 sec
Avg. theme time: 0.1072 sec
Avg. mem usage: 28.44 MB
Avg. ticks: 5,251
Avg. db queries : 55.35
Margin of error : 0.0034 sec

Plugin list:
===========================================
P3 (Plugin Performance Profiler) - 0.0082 sec - 2.36%
Akismet - 0.0118 sec - 3.42%
Better WordPress Minify - 0.0467 sec - 13.53%
Google Sitemap Generator - 0.0064 sec - 1.87%
Limit Login Attempts - 0.0258 sec - 7.46%
Stop Spammer Registrations Plugin - 0.0064 sec - 1.86%
SubToMe - 0.0215 sec - 6.24%
Tpc Memory Usage - 0.0347 sec - 10.05%
WP Permalauts - 0.0271 sec - 7.84%
Wp Super Cache - 0.0110 sec - 3.19%
WPtouch Mobile Plugin - 0.1457 sec - 42.20%

Bravo! Die Zeiten für das Laden der Plugins lag nun durchgehend im Hundertstel-Sekundenbereich, im Fall von WPTouch Mobile im Zehntelssekundenbereich.

Positiver Nebeneffekt: Auch die RAM-Auslastung brach markant ein:

Ursprungszustand | 86.89 MB
Ohne Jetpack | 70.94 MB
Ohne Jetpack, ohne Simple Lighbox | 28.44 MB

Um die doch wirklich nützliche Lightbox-Funktionalität nicht zu verlieren, installierte ich stattdessen folgendes Plugin:

CSS3 Lightbox

Es handelt sich um eine rein CSS-basierte Lösung; der Einfluss auf die PHP-Renderzeiten von WordPress-Seiten ist vernachlässigbar.