層ごとに最適化する — 各層が次の層に到達する前に負荷を吸収します。 目標は、ほとんどのリクエストをキャッシュから提供し、PHPとデータベースの処理を最小限に保つことです。
1. PHP-FPMとOPcache
RAMに合わせてプールをサイズ変更し、を有効にしてPHPが毎回ではなく1回だけコンパイルされるようにします:
; 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)
max_childrenが高すぎるとスワップしてクラッシュし、低すぎるとリクエストがキューイングされ(負荷下で502エラー)ます。
このレイヤリングにより、ホームページのヒットはエッジまたはページキャッシュから返され、PHPまたはDBに到達しません。
スロークエリログを有効にして問題のあるクエリを見つけ、カスタムクエリ用にインデックスを追加し、オートロードオプション(autoload = yesを持つwp_options)を監査します(オートロードデータは毎回のリクエストで読み込まれるため、膨張したオートロードデータはすべてを遅くします)。最後に、プラグインの肥大化を削減します: 各プラグインはクエリとPHP処理を追加するため、未使用のものは削除します。
WordPressリクエストはデフォルトではPHPとDB集約型であるため、チューニングなしではトラフィック下で停止します。レイヤ化されたキャッシング(OPcache → オブジェクトキャッシュ → ページキャッシュ → CDN)に加えて、適切なサイズのPHP-FPMと軽いデータベースにより、単一サーバーは桁違いに多くのトラフィックを処理でき、スパイク中でも稼働を維持します。