So optimierst du WordPress Traffic-Spitzen auf einem VPS oder einem dedizierten Server

Das Problem ist nicht der Datenverkehr an sich, sondern die Frage, ob deine Serverkonfiguration ihn bewältigen kann, ohne dass der Server ins Stocken gerät oder komplett ausfällt.

Dieser Leitfaden behandelt die serverseitige Konfiguration, die die Belastbarkeit deiner Website bei Zugriffsspitzen bestimmt. Frontend-Optimierungen (Bildkomprimierung, Minifizierung) helfen zwar, aber die Obergrenze für die Traffic-Verarbeitung wird durch deinen Server-Stack festgelegt. Genau darum geht es hier.

Warum WordPress unter hoher Auslastung WordPress (und wie man das Problem tatsächlich behebt)

WordPress Seiten dynamisch. Jede Besucheranfrage löst standardmäßig eine PHP-Ausführung aus, die die Datenbank abfragt, die Seite zusammenstellt und sie an den Browser sendet. Eine Website, die 1.000 gleichzeitige Anfragen erhält, bedeutet 1.000 gleichzeitig laufende PHP-Prozesse und 1.000 Datenbankabfragen, die alle zur gleichen Zeit stattfinden.

Die Lösung besteht darin, vorgefertigte Seiten aus dem Cache bereitzustellen, anstatt sie bei jeder Anfrage neu zu generieren. Eine ordnungsgemäß zwischengespeicherte WordPress , die aus dem Speicher bereitgestellt wird, beansprucht nur einen Bruchteil der CPU- und E/A-Ressourcen einer nicht zwischengespeicherten dynamischen Anfrage. Der Unterschied bei der Kapazität für gleichzeitige Anfragen ist nicht nur geringfügig, sondern liegt um eine Größenordnung höher.

Serverseitiges Seiten-Caching

Vollseitiger Cache mit NGINX Cache

Der FastCGI-Cache NGINXspeichert komplette HTML-Seiten auf dem Server und liefert sie direkt aus, wobei PHP und die Datenbank bei zwischengespeicherten Seiten komplett umgangen werden. Dies ist die effektivste Caching-Ebene für die Bewältigung von Zugriffsspitzen.

Für WordPress , die auf der Managed-VPS- oder Dedicated-Server-Infrastruktur InMotion Hostingmit NGINX Stack gehostet werden, kann der FastCGI-Cache auf Serverebene konfiguriert werden. Die in den Managed-VPS-Paketen von InMotion verfügbare UltraStack umfasst NGINX mit integriertem Caching, der dies ohne manuelle Konfiguration übernimmt.

Caching-Plugins WordPress

Für Websites, auf denen kein Caching NGINX konfiguriert ist, W3 Total Cache und WP Super Cache sind die wichtigsten Optionen. W3 Total Cache in Konfigurationen auf Serverebene W3 Total Cache , darunter Redis und Memcached. WP Super Cache generiert statische HTML-Dateien, die Apache oder NGINX direkt NGINX . Beide reduzieren die Häufigkeit der PHP-Ausführung erheblich.

Für bei InMotion gehostete Websites W3 Total Cache das empfohlene Plugin, da es optimal auf den Server-Stack von InMotion abgestimmt ist. Konfiguriere es je nach deinem Tarif so, dass entweder das festplattengestützte Caching oder das Redis-Objekt-Caching verwendet wird.

Redis-Objekt-Caching

Redis ist ein In-Memory-Datenspeicher, der die Ergebnisse WordPress zwischenspeichern kann und so die Anzahl der Datenbankabfragen bei jedem Seitenaufruf reduziert. Für Websites mit datenbankintensiven Inhalten (umfangreiche Produktkataloge, WooCommerce-Shops, Websites mit hoher Nutzeraktivität) sorgt Redis für eine deutliche Steigerung des Durchsatzes.

Redis auf einem Ubuntu-VPS installieren:

sudo apt install redis-server

sudo apt install redis-server

Konfiguriere die grundlegenden Redis-Einstellungen in /etc/redis/redis.conf:

maxmemory 256mbmaxmemory-policy allkeys-lru

maxmemory 256mbmaxmemory-policy allkeys-lru

Die „allkeys-lru“-Richtlinie entfernt die am wenigsten kürzlich verwendeten Schlüssel, wenn der Speicher voll ist – das ist das richtige Verhalten für einen Caching-Anwendungsfall.

Installiere das Redis Object Cache-Plugin in WordPress und konfiguriere anschließend die Datei wp-config.php:

define('WP_REDIS_HOST', '127.0.0.1');define('WP_REDIS_PORT', 6379);

define('WP_REDIS_HOST', '127.0.0.1');define('WP_REDIS_PORT', 6379);

Aktiviere den Objekt-Cache über das Dashboard des Redis Object Cache-Plugins. Vergewissere dich, dass er aktiv ist und die Verbindung hergestellt wurde, bevor du das Caching aktivierst.

Optimierung des PHP-FPM-Pools für Lastspitzen

PHP-FPM verwaltet einen Pool von PHP-Worker-Prozessen. Bei einem Traffic-Anstieg kann die Anzahl der gleichzeitigen PHP-Anfragen die Anzahl der verfügbaren Worker im Pool übersteigen, was dazu führt, dass neue Anfragen in die Warteschlange geraten oder ein Timeout auslösen. Die Optimierung des Pools im Vorfeld bekannter Traffic-Spitzen entscheidet darüber, ob eine Website den Anstieg bewältigt oder daran scheitert.

Bearbeite die PHP-FPM-Pool-Konfiguration (normalerweise /etc/php/8.2/fpm/pool.d/www.conf):

pm = dynamicpm.max_children = 50pm.start_servers = 10pm.min_spare_servers = 10pm.max_spare_servers = 30

pm = dynamicpm.max_children = 50pm.start_servers = 10pm.min_spare_servers = 10pm.max_spare_servers = 30

pm.max_children legt die maximale Anzahl an PHP-Worker-Prozessen fest. Jeder Worker verbraucht Speicherplatz. Eine grobe Berechnung: Auf einem Server mit 4 GB RAM ergibt die Zuweisung von 1,5 GB an PHP-Worker bei etwa 50 MB pro Prozess 30 Worker. Passe diesen Wert entsprechend dem tatsächlichen PHP-Speicherverbrauch deines Servers an.

Bei bekannten Traffic-Ereignissen (Produkteinführungen, Werbekampagnen) solltest du `pm.max_children` vorübergehend erhöhen, die Speicherauslastung während des Ereignisses überwachen und den Wert danach wieder reduzieren.

MySQL-Konfiguration für WordPress mit hoher Parallelität

Die WordPress-Datenbank ist nach PHP der zweithäufigste Engpass bei hoher Auslastung. Zwei Einstellungen haben den größten Einfluss.

„max_connections“ legt fest, wie viele gleichzeitige Datenbankverbindungen MySQL zulässt. Der Standardwert liegt normalerweise bei 151. Bei hohem WordPress kann dieser Wert schnell ausgeschöpft sein, was zu Fehlern wie „Zu viele Verbindungen“ führt. Erhöhe ihn in der Datei /etc/mysql/mysql.conf.d/mysqld.cnf:

max_connections = 500

max_connections = 500

innodb_buffer_pool_size legt fest, wie viele Daten MySQL im Arbeitsspeicher hält. Abfragen, die aus dem Pufferpool bedient werden, erfordern keine Lesevorgänge von der Festplatte, was unter Last den entscheidenden Unterschied in der Leistung ausmacht. Stelle diesen Wert auf 70 % des verfügbaren Arbeitsspeichers auf einem dedizierten Datenbankserver ein, oder auf 25 bis 30 % auf einem gemeinsam genutzten Anwendungsserver:

innodb_buffer_pool_size = 1G   # für einen Anwendungsserver mit 4 GB

innodb_buffer_pool_size = 1G   # for a 4GB application server

CDN-Integration für die Auslagerung statischer Inhalte

Selbst eine gut zwischengespeicherte WordPress generiert erheblichen Datenverkehr für statische Inhalte (Bilder, CSS, JavaScript) zum Ursprungsserver. Ein CDN verlagert die Bereitstellung statischer Dateien auf Edge-Knoten, die sich geografisch in der Nähe der Besucher befinden, wodurch die Auslastung des Ursprungsservers verringert und gleichzeitig die wahrgenommene Leistung verbessert wird.

Bei WordPress umfasst die CDN-Integration in der Regel entweder die Konfiguration Cloudflare deiner Domain oder die Verwendung eines WordPress . Die kostenlose Stufe Cloudflarebietet grundlegende CDN-Funktionen und DDoS-Schutz. Für Produktionsseiten, die echten Datenverkehr verarbeiten, sollten die Caching-Regeln Cloudflareso konfiguriert werden, dass statische Inhalte intensiv zwischengespeichert werden und der Cache für WordPress umgangen wird.

InMotion unterstützt die CDN-Integration bei allen VPS- und Dedicated-Server-Tarifen. Entscheidend ist, dass du dein CDN so konfigurierst, dass es das Cache-Invalidierungsverhalten WordPressberücksichtigt – insbesondere bei Websites mit WooCommerce oder Mitgliederfunktionen, bei denen sitzungsspezifische Seiten nicht zwischengespeichert werden dürfen.

Datenbankbereinigung vor Veranstaltungen

WordPress im Laufe der Zeit Beitragsrevisionen, temporäre Einstellungen und Spam-Kommentare in der Datenbank WordPress . Vor einem Ereignis mit hohem Traffic verringert eine Datenbankbereinigung die Tabellengröße und verbessert die Abfrageleistung.

• Beitragsrevisionen löschen: Nutze das WP-Optimize-Plugin oder führe den Vorgang direkt in MySQL aus.
• Abgelaufene Zwischenspeicher löschen: Auch das übernimmt WP-Optimize.
• Leere die Warteschlange für Spam-Kommentare.
• Führe nach der Bereinigung den Befehl „OPTIMIZE TABLE“ für die Tabellen „wp_posts“ und „wp_options“ aus.

Das ist Wartung, keine Notfalloptimierung. Baue es in einen vierteljährlichen Zeitplan ein, anstatt es nur als Vorbereitung auf ein bestimmtes Ereignis zu betrachten.

Verwandte Themen: „Tune Up Your VPS for WordPress behandelt WordPress optimierten WordPress von InMotion ausführlich.WordPress : Einzelne Website vs. mehrere Websites