WordPress-Skalierung für 10.000 Nutzer pro Stunde

Jeder Website-Betreiber träumt davon, “viral” zu gehen. Aber für einen Serveradministrator wird dieser Moment oft zum Albtraum. Die Seite lädt 30 Sekunden lang, und dann sehen die Nutzer nur noch “Error 500” oder “503 Service Unavailable”.

In diesem Artikel zeige ich Ihnen, wie Sie WordPress auf hohen Traffic vorbereiten.

#1. Die Mathematik der Katastrophe: PHP Worker Limit

Die meisten WordPress-Abstürze entstehen nicht durch fehlenden RAM, sondern durch Erschöpfung des PHP Worker Limits.

#Was ist ein PHP Worker?

Stellen Sie sich einen PHP Worker als Kassierer in einem Geschäft vor.

• Wenn Sie 10 Kassierer haben (10 Worker).
• Jeder Kunde (Besucher) braucht 1 Sekunde zur Bedienung.
• Sie können maximal 10 Kunden pro Sekunde bedienen.

Wenn der 11. Kunde kommt, muss er warten. Wenn die Schlange voll ist -> Fehler 503.

#2. Level 1: Full Page Cache (FPC) – PHP umgehen

Das schnellste PHP ist das, das gar nicht ausgeführt wird.

Wenn Ihre Seite statisch ist (z. B. ein Blogartikel), sollte PHP sie nicht jedes Mal neu generieren. Sie sollten eine fertige HTML-Datei ausliefern.

#Lösungen:

1. Plugins: WP Rocket, W3 Total Cache.
2. Server-Side Cache (Pro):
   • Varnish: Ein Proxy-Server, der die ganze Seite im RAM hält.
   • Nginx FastCGI Cache: In Nginx integriert.
   • Cloudflare: Seiten ausliefern, bevor sie Ihr Hosting erreichen.

#3. Level 2: Object Cache (Redis) – Datenbank entlasten

Was ist mit WooCommerce-Shops? Dort muss PHP arbeiten.

Redis (Object Cache) speichert die Ergebnisse von Datenbankabfragen im RAM. Statt MySQL (langsame Festplatte) zu fragen, fragt PHP Redis (schneller RAM).

• Ohne Redis: 150 SQL-Abfragen pro Aufruf.
• Mit Redis: 5 SQL-Abfragen pro Aufruf.

#4. Fallstudie: Analyse eines Ausfalls

Projek: Nachrichtenportal am Black Friday. Server stürzte in 3 Minuten ab.

#Was lief falsch?

1. Killer-Ajax: Ein “Besucherzähler”-Plugin sendete bei jedem Besuch einen AJAX-Request (admin-ajax.php), der nicht gecacht wurde.
2. Keine Datenbank-Indexe: ORDER BY RAND() tötete MySQL.

#Die Lösung

1. Ajax deaktiviert (Google Analytics genutzt).
2. Redis implementiert.
3. Varnish konfiguriert.

#5. Wie überwachen?

1. Query Monitor: Plugin für SQL-Analyse.
2. New Relic: Professionelles APM-Monitoring.
3. Logs: tail -f im SSH.

#Zusammenfassung

1. Hosting: Cloud VPS mit konfigurierbaren PHP Workern.
2. Cache: Varnish oder Nginx FastCGI.
3. Datenbank: Redis.
4. Bereinigung: Kein Admin-Ajax im Frontend.