Optimieren Sie Schicht für Schicht — jede Schicht absorbiert die Last, bevor sie die nächste erreicht. Das Ziel besteht darin, die meisten Anfragen aus einem Cache zu bedienen und PHP und die Datenbank so wenig wie möglich arbeiten zu lassen.
Größen Sie den -Pool auf Ihren RAM aus, und aktivieren Sie , damit PHP einmal kompiliert wird, nicht bei jeder Anfrage:
; php-fpm pool: cap workers so you don't exhaust RAM
; pm.max_children = (available RAM for PHP) / (avg process size, ~50MB)
pm = dynamic
pm.max_children = 40 ; hard ceiling on concurrent PHP workers
pm.start_servers = 10
pm.min_spare_servers = 8
pm.max_spare_servers = 16
pm.max_requests = 500 ; recycle workers to avoid memory leaks
; OPcache: cache compiled bytecode in memory
opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 0 ; skip file-stat checks in prod (flush on deploy)
Wenn max_children zu hoch ist, tauschen Sie aus und stürzen ab; zu niedrig und Anfragen werden in die Warteschlange eingereiht (502er unter Last).
Diese Schichtung bedeutet, dass ein Seiteneintrag vom Edge oder Page-Cache zurückkehren kann, ohne PHP oder die DB überhaupt zu berühren.
Aktivieren Sie das slow query log, um Verursacher zu finden, fügen Sie indexes für benutzerdefinierte Abfragen hinzu, und überprüfen Sie autoloaded options (wp_options mit autoload = yes werden bei jeder Anfrage geladen — aufgeblähte autoload-Daten verlangsamen alles). Reduzieren Sie abschließend die Plugin-Bloat: Jedes Plugin fügt Abfragen und PHP-Arbeit hinzu, daher entfernen Sie ungenutzte.
Eine WordPress-Anfrage ist standardmäßig PHP- und DB-intensiv und stürzt unter Datenverkehr ohne Tuning ab. Geschichtetes Caching (OPcache → Object Cache → Page Cache → CDN) plus richtig dimensioniertes PHP-FPM und eine schlanke Datenbank ermöglichen es einem einzelnen Server, um Größenordnungen mehr Datenverkehr zu verarbeiten — und halten ihn während Spitzen in Betrieb.