PHPワーカー、データベース、キャッシュが機能しない場合、ページ呼び出しは数秒で終了します。 ワードプレスのタイムアウト. .なぜリクエストがスタックするのか、その原因を突き止め、特定の設定とアップグレードを使用することで、負荷時のタイムアウトを永久になくす方法をお見せします。 パフォーマント.
中心点
- 原因過負荷のPHPワーカー、遅いデータベース、キャッシュの欠落
- 診断サーバーログ、負荷テスト、プラグインチェック、クエリー分析
- 直ちにPHPの制限を増やす、WP-Cronを変更する、.htaccessを修復する
- 最適化キャッシュ、オブジェクトキャッシュ、画像とアセットのチューニング、CDN
- スケーリングより強力なホスティング、より多くのPHPワーカー、接続制限の調整
高負荷がタイムアウトを誘発する理由
同時問い合わせの増加は、まず空きスペースを食いつぶしてしまう。 CPU, するとI/Oとデータベースロックがブロックされ、レスポンスタイムが上昇する。新しいリクエストがキューに滞留している間に PHP のワーカーが満杯になり、504 エラーや 502 エラーになるのをよく見かけます。 タイムアウト. .共有ホスティングは、他のプロジェクトとリソースを共有し、ピークが加算されるため、これを悪化させる。さらに危険なのは、最適化されていないwp_optionsのデータベースクエリや、数秒かかるリビジョンの投稿です。ページキャッシュの欠落も相まって、最終的にサイトに残された時間予算はありません。.
502対504：エラー画像の正しい解釈
私は撮影の前に症状を区別する。 502 悪いゲートウェイ は、PHP バックエンドプロセスがクラッシュしたか到達不能であることを示します (FPM を再起動し、制限をチェックします)。A 504 ゲートウェイタイムアウト は、上流 (PHP-FPM) の応答が遅すぎることを知らせます。 read_timeout-の値をプロキシに返さなければならない。このふたつのエラーが交互に発生する場合、注目すべきはキューの長さと接続の制限です。 プロキシはまだ新しい接続を受け付けることができますが、 FPM はジョブを受け付けなくなったり、接続が一杯になったために接続を拒否したりします。.
原因を見つける数分で診断
私はエラーログとアクセスログから始める。 リクエスト と長いランタイムをすぐに確認します。その後、CPU、RAM、I/O、アクティブなPHPプロセスをチェックし、ワーカーが限界に達していないか、遅いクエリが優勢になっていないかを確認する。アプリレベルでは、長いアクションとフックを表示し、不具合のあるクエリを特定するためにデバッグログをオンにします。 プラグイン で切り分けます。その後、すべてのエクステンションを非アクティブにし、トリガーが決まるまで個別にアクティブにする。最後に、ロードをシミュレートして、いつ失敗し始めるか、キャッシュとオブジェクトキャッシュが効果を発揮するかどうかを確認する。.
即効性のある対策
私はまず、ランタイムとメモリを増やし、次のようにする。 プロセス タイムアウトで死なないようにする。 set_time_limit(300)；; そして define('WP_MEMORY_LIMIT','512M')；;. .許可されている場合は、.htaccess で次のように設定します。 php_value max_execution_time 300 そして php_value メモリリミット 512M もっと見る バッファ. .その後、WP-Cronを停止します。 define('DISABLE_WP_CRON', true)； そして、ページのリクエストがcronの実行をトリガーしないように実際のシステムcronをセットアップしました。もしファイルが壊れていたら、パーマリンクダイアログに新しい.htaccessを生成させます。最後に、すべてのキャッシュを空にし、シークレットウィンドウでTTFBが崩壊していないか、安定しているかをチェックする。.
ウェブサーバーとプロキシのタイムアウトを特別に設定する
WebサーバーとPHP-FPMのチェーンが十分なタイムウィンドウを持ち、アイドルブロックが生成されないことを確認しています。NGINXの場合は fastcgi_read_timeout, fastcgi_connect_timeout そして send_timeout 適度に上向き（例えば60～120秒）、一方 keepalive_timeout は、スロットを占有しないように、かなり短いままである。リバースプロキシ（ロードバランサー）の背後には proxy_read_timeout そして プロキシ接続タイムアウト どちらもFPMとアプリの予算に合わせる必要がある。Apacheでは、以下のように制限している。 KeepAliveTimeout (2-5秒)と増加する。 最大リクエストワーカー数 RAMのリザーブが追加プロセスに十分な場合に限る。ルールとしては、タイムアウトは十分に大きくすべきであるが、ゾンビ接続が発生しないように、接続時間と接続数を制御すべきである。.
PHP-FPM、プロセス、制限を正しく設定する
タイムアウトは、実行されているPHPワーカーの数が少なすぎるか、ブロックされている時間が長すぎるためによく起こります。 ピーエッチピーエフピーエム pm=dynamic/ondemandと賢明な限界値を介して。大まかな pm.max_childrenPHPで使用可能なRAMを平均的なプロセスサイズで割って、サーバーが呼吸できるように20-30%の予備を確保してください。. pm.max_requests メモリリークを防ぎ pm.process_idle_timeout これにより、負荷が変動した場合のアイドル・コストを削減できる。私は、インタープリターが常に再コンパイルしないように、またTTFBが大幅に縮小するように、Opcacheを厳密に有効にしている。より深く掘り下げたい場合は、実用的な PHP-FPMの設定, これは、NGINX/Apacheにテーマを拡大縮小したり適応させたりする前に、ベースとして使用するものです。.
Apache/NGINX/LiteSpeed: ワーカーモデルとキープアライブ
トラフィックのプロファイルに合わせてワーカーモデルを選びます。 mpm_event よりもスケールが大きい。 prefork で、FPM と調和します。NGINXの利点はいくつかあります。 ワーカープロセス (オート）と高 ワーカーコネクション, を使用することで、多数の同時クライアントに対応することができます。LiteSpeed/LSAPIはPHPを効率的にバインドするが、PHP側でMax-Connsをカスタマイズする必要がある。. キープアライブ 短いタイムアウトと限られた時間しか使わない。 keepalive_requests アイドル状態のクライアントがスロットをブロックするのを避けるためだ。HTTP/2やHTTP/3では、複数のアセットが1つのコネクションで実行され、オーバーヘッドが削減されるため、これが功を奏する。.
データベースの合理化とスピードアップ
最も一般的なブレーキは データベース肥大化したリビジョン、古いトランジェント、wp_optionsの過剰なオートロード負荷。私は定期的に整理整頓し、リビジョンを減らし、期限切れのトランジェントを削除して autoload='yes' WordPressが起動時に何百キロバイトも読み込まないように、全体的に小さくしています。DBツールを使ってテーブルを最適化し、以下のような問題がないかチェックしています。 インデックス を頻繁に使用するWHERE条件に使用する。大きなメディアデータの場合は、JOINが爆発しないようにオフロードや効率的なメタデータクエリーに頼る。必要に応じて 最大許容パケット数 また、オブジェクト・キャッシュ（Redis/Memcached）を使用することで、リード・アクセスの負荷が著しく軽減される。.
MySQL/InnoDBのパラメータと遅いクエリ分析
を起動させる。 遅いクエリログ 一時的な（小さな long_query_time-値、例えば0.2-0.5秒)を使用して外れ値を可視化する。InnoDBの場合、私は innodb_buffer_pool_size (DB-RAMの50-70%)を使用し、ホットデータをメモリに保存する。. innodb_log_file_size そして innodb_flush_log_at_trx_commit 一貫性の要件に応じて調整している。SSD/NVMetmpdir 大きなソートを加速させる。 最大接続数 PHPワーカーの数とコネクションプーリングのバランスをとり、DBがスラッシュしないようにします。重要: 自動コミットトラップや長いトランザクションは、ロックを長引かせページチェイン全体を遅くするので避けましょう。.
キャッシュとCDN：アプリの負荷を軽減する
ページキャッシュは、PHPやデータベースに触れることなくHTMLを配信します。これは、トラフィックのピーク時に最大の利点です。 レバー. .TTLの長いフルページキャッシュを設定し、ログインユーザーとゲストを区別し、「stale-while-revalidate」を有効にして、再構築中もページが高速に保たれるようにしている。オブジェクトキャッシュは、繰り返される クエリ, 一方、CDNは静的アセットをユーザーの近くに配信し、Originの負荷を大幅に軽減します。私は画像をWebPに変換し、遅延ローディングを有効にし、HTTP/2またはHTTP/3と組み合わせることで、多くのファイルが並行して流れるようにしています。このガイドは フルページキャッシュ, これは、ピーク時に私が常に優先するものだ。.
キャッシュ戦略：キー、バリアント、スタンピード対策
私は、パス、ホスト、関連するクッキー（できるだけ少ない）、およびデバイスタイプという、早期かつ安定したキャッシュキーを定義しています。パーソナライズするクッキー（例：買い物かご、通貨）を意図的に次のように設定しています。 可変 あるいは断片化されたキャッシュで迂回する。それに対して キャッシュスタンピード ウェブサーバーでのマイクロキャッシュ（1～10秒）、キャンペーン前の重要なルートの予熱など、„stale-while-revalidate “をサポートしています。クリーンな 無効化キャッシュ全体をフラッシュするのではなく、コンテンツが公開されたときに特別に削除します。こうすることで、全負荷時でも高いヒット率を維持し、レスポンスタイムを一定に保つことができます。.
ホスティングの比較と賢明なアップグレード
ある時点で、パッケージの限界に達する。 リソース 微調整の代わりに。本当に忙しくなったら、共有環境から離れ、専用のCPU/RAMを備えたマネージド・オファリングか、NGINX/LiteSpeedとNVMeストレージを備えたVPSに移行します。高速IOPS、十分なPHPワーカー、最新のPHP 8+と オプキャッシュ. .繰り返し発生するピークに対しては、オートスケーリングが、手動による介入なしにワーカーとデータベースをスケールするのに役立ちます。以下の概要は、一般的なオプションとその用途を示しています。.
| 場所 | プロバイダー/タイプ | コアの厚さ | こんな人におすすめ |
|---|---|---|---|
| 1 | webhoster.de (マネージド) | オートスケーリング、NVMe SSD、高CPU/RAM、マネージドWP | 高トラフィック、スケーリング |
| 2 | マネージドWPホスティング | 統合されたキャッシュ、最適化されたPHPワーカー | 中荷重 |
| 3 | NGINX/LiteSpeed搭載VPS | 高IOPS、専用リソース | 洗練されたサイト |
スケーリング、接続制限、PHP ワーカー
Webサーバー、PHP-FPM、データベースのいずれかが狭すぎると、並列性は破綻する。 限界 セット。バランス pm.max_children 実際のプロセスサイズ、ウェブサーバーのキープアライブの調整、MySQLのコネクションプールのチェック。ちなみに、ワーカーが多すぎるとRAMを使い果たし、I/Oを詰まらせる可能性がある。負荷が高い状態で500エラーや504エラーが発生した場合は、接続制限、タイムアウト、キューの長さを一緒にチェックします。典型的なリミットのトラップについては、以下の記事でコンパクトに説明されている。 接続制限, そのため、原因を分析するのに数分の時間を節約できることが多い。.
WooCommerceとダイナミック・エリアの効率的なキャッシュ
Eコマースはキャッシュ戦略に挑戦している：カテゴリーページ、商品ページ、CMSコンテンツは完全にキャッシュするが、ショッピングバスケット、チェックアウト、„マイ・アカウント “は特にキャッシュから除外している。. カートの破片 およびパーソナライズされたバナーは、JavaScriptを介して小さな動的な部分をリロードまたは断片化することによって生成されます。通貨、国、セッションなどのクッキーは 可変, やむを得ない場合、そうでない場合はヒット率を下げてしまう。計画されたアクション（例えばセールス）をウォームアップし、コールドキャッシュがスタート時にヒートアップしないようにする。クエリーをバンドルし、結果をキャッシュし、ポーリングをスロットリングすることで、管理者のAjaxとRESTエンドポイントを制限している。.
負荷テスト、モニタリング、アラート
私はフィーリングに頼らず、効果を証明する。 計測. .キャンペーンの前に、私は訪問者の波をシミュレートし、徐々に同時実行数を増やし、TTFBとエラー率が増加し始める負荷をチェックします。APMツールは、最も遅いトランザクション、クエリー、外部コールを示してくれます。CPU、RAM、5xxレート、レスポンスタイムに関するアラートは、早い段階で私に警告を発してくれる。 失敗 反応する。その後、キャッシュを有効にしてテストを繰り返し、全負荷時に最適化が機能することを確認する。.
セキュアな外部サービスとHTTPリクエスト
多くのタイムアウトは、テーマやプラグインでHTTPコールをブロックしていることが原因です。私は wp_remote_get()/wp_remote_post() (接続／読み込みのタイムアウト）、フォールバックを組み込み、高価な同期をバックグラウンド・ジョブに移す。DNSの解決とSSLのハンドシェイクを別々にチェックする。リゾルバや証明書のチェーンに欠陥があると、処理速度が著しく低下する。外部APIの障害がサイトに影響しないように、定期的な結果をローカルにキャッシュしている。原則：外部I/Oはリクエストのランタイムを支配してはならない。.
セキュリティ、ボットトラフィック、WAFルール
私は無駄なトラフィックからアプリケーションを守ります：ログイン、XML-RPC、検索エンドポイントのレート制限、スクレイパーと悪質なボットに対する厳格なルール、攻撃的なクローラーに対するスロットル。429/503と 再試行後 は、実ユーザーのために容量を確保するのに役立ちます。アップストリームWAFはレイヤー7のピークを選別し、既知の攻撃ベクトルがPHP/DBに影響を与える前にブロックする。メディアについては、賢明なキャッシュ（ETag/Last-Modified）を有効にして、繰り返し呼び出されてもサーバーコストがほとんど発生しないようにしています。.
システム制限とOSチューニング
負荷がかかった状態で突然接続が拒否された場合、私はOSのパラメーターを調べる： fs.file-max およびウェブサーバ/DB用のオープンディスクリプタ、, net.core.somaxconn そして net.ipv4.ip_local_port_range 多数の同時ソケットに対応。小さすぎる バックログ または攻撃的 tcp_fin_timeout がボトルネックになります。私は、クラッシュしたログをディスク上の高速データキャリアに移動させたり、I/Oがアプリを遅くしないようにしっかりと回転させたりしている。.
オブジェクト・キャッシュ：Redis/Memcachedを正しく使う
私は永続性とフロー・ガイドラインのような機能のためにRedisを選んだ。. maxmemory ホットキーがずれないようにし、適切な退去ポリシー（allkeys-lruなど）を設定する。igbinaryのようなシリアライザーはRAMを節約し、揮発性トランジェントの短いTTLはチャーンを減らす。重要：オブジェクト・キャッシュ・レイヤはDBを救済しなければならない。ヒット率が低いままであれば、キーの分散を分析し、ヒット率が上がるまでコード・パスを均等化する。.
よくあるエラーの原因を素早く排除
多くのタイムアウトはいくつかのトリガーによって引き起こされる。 クロン, ハートビートと検索。WP-Cronをシステムクーロンに切り替え、Heartbeat APIを大幅にスロットルし、高価なバックエンドリストをサーバーサイドキャッシングに置き換えます。問題のあるプラグインは削除するか、より軽い代替プラグインに置き換える。 API コンタクト.htaccessでは、重複したリダイレクトループを削除し、プロセスを重複させる不正なPHPハンドラを修正しています。ボットやスクレイパーを速度制限やアップストリームCDNで減速させ、実際のユーザーを待たせないようにしています。.
迅速な実施のためのまとめ
私は差し迫った問題を解決する タイムアウト 原因を測定し、制限を上げ、キャッシュを有効にし、データベースを合理化し、ホスティングを増やす。明確なワーカーとキャッシュの戦略は、リクエストがリソースを奪い合わないようにするために非常に重要です。きれいなフルページキャッシュ、オブジェクトキャッシュ、WebPアセットがあれば、サーバーの負荷は即座に軽減されます。それでも不十分な場合は、CPU/RAMを増やし、NVMeストレージを高速化し、PHP FPMパラメータを適切に設定することで、必要な負荷が軽減されます。 リザーブ. .負荷テストとモニタリングは、実際のトラフィック下でのパフォーマンスを保証するため、繰り返し測定することでループを閉じる。.
