技術情報

PHPワーカーを理解する：PHPワーカーとは何か、いつボトルネックになるか

php労働者 は PHP コードを実行する独立したプロセスで、ウェブサイトからのすべての動的リクエストを処理します。多くのキャッシュされていないリクエストが同時にサーバーに到達すると、既存のワーカーがすべてのスロットを占有し、待ち行列が形成され、ボトルネックが長いレスポンスタイムにつながります、 TTFB-ヒントとエラー。

中心点

以下の重要なメッセージをコンパクトにまとめました。 パフォーマンス と容量。

定義PHP Workers はリクエストをシリアルに処理します。
ボトルネックワーカーが少なすぎるとキューができ、TTFBが増加し、タイムアウトが間近に迫ってくる。
リソースワーカーにはCPUコアが必要で、その比率が正しくない場合、コンテキスト・スイッチングが発生する。
キャッシングキャッシュからのヒット数が多ければ多いほど、トラフィックのピーク時のワーカーの負荷は軽減される。
スケーリングページのプロフィール、プラグイン、インタラクションに合わせてワーカーの数を調整します。

ホスティングにおけるPHP Workerとは？

分かっている PHPワーカー を、それぞれの動的リクエストに個別に対応するデジタル・ウェイターとして使用する。ワーカーはPHPスクリプトを読み、データベースクエリをトリガーし、それらを使ってブラウザ用のHTMLを構築します。タスクが実行されている場合、ワーカーは完了するまでバインドされたままです、 パラレル は動作しません。WordPressでは、ワーカーはcronジョブ、メール送信、セキュリティチェックなどの定期的なタスクも実行します。ワーカーの数と質がウェブサイトの速度に影響するのはこのためです。 ウェブサイト 質量がある。

労働者のボトルネックはいつ、なぜ発生するのか？

よりも多くのキャッシュされていないリクエストが同時に到着すると、すぐにボトルネックが発生する。 労働者 が利用可能である。各追加リクエストはキューに入れられ、空きスロットを待つことになる。このため、最初のバイトにかかる時間が長くなり、ロード時間が長くなり、チェックアウト処理がキャンセルされる可能性があります。ショップやメンバーエリアでは、パーソナライズされたコンテンツは、キャッシュが多くの答えを提供できないため、状況を悪化させ、チェックアウトプロセスを遅くする可能性があります。負荷を直接ワーカーに送る。このような状況では、賢明なキャッシュ、最適化されたプラグイン、そして首尾一貫したワーカーとCPUの比率が最大の効果を発揮します。

症状を認識するメトリクスとログを正しく読む

まず最初に見るのは TTFBというのも、値が大きくなるにつれてキューが増えるからである。504 Gateway Timeoutのようなエラーは、リクエストがあまりにも長い間ブロックされたままであり、激しくキャンセルされた場合に発生します。ホスティングパネルでは、ブロックされたリクエストの典型的な例である、高いプロセス数と同時に低いネットワーク利用率によってキューを認識します。 労働者 です。アクセスログには、ショッピングバスケット、チェックアウト、個人ダッシュボードなど、キャッシュされていないパスへの多数の同時リクエストが表示されます。バックエンドのレスポンスタイムが同時に増加する場合、重い管理アクションは通常、個々のワーカーを必要.

重要な違い：ウェブサーバーとPHP-FPMの違い

私はウェブサーバーワーカー（NGINX/Apacheなど）を明確に区別している。 PHP-FPM ワーカー.Keep-AliveとHTTP/2のおかげで、ウェブサーバーは多くのコネクションを多重化し、静的アセットを極めて並列に提供することができる。しかし、本当のボトルネックはPHP-FPMで発生し、各子プロセスは正確に1つのリクエストを処理します。ブラウザが何十ものリクエストを並行して開いたとしても、PHPプロセスの数によって動的パスの同時処理が制限されます。多くの静的ファイルを含むページが高速に表示される一方で、個々の動的なエンドポイント (チェックアウト、ログイン、REST API) が依然として詰まっているのは、この違いによるものです。

最適なワーカー数：コンピューティングコア、RAM、アプリのプロファイル

適切なワーカー数は、動的ページの割合、プラグインの状況、利用可能な CPUコア オフ。永続的なコンテキストの切り替えはレイテンシを増加させるので、私はCPUコアよりかなり多くのワーカーを計画することはない。小規模なブログでは通常2〜4ワーカーで十分だが、アクティブなショップやLMSではかなり多くのワーカーが必要になる。CPUリザーブなしでワーカーを増やしても何のメリットもない。加速.だから、さらにアップグレードする前に、負荷をかけてテストし、TTFBを測定し、キューが消えるかをチェックするんだ。

シナリオ	キャッシュなし	労働者	CPUコア	効果	アクション
キャッシュ付きブログ	非常に低い	2-4	2-4	迅速な配達	キャッシュを維持する、プラグインスリムに保つ
ヒント付きWooCommerce	ミディアムハイ	6-12	4-8	短い待ち時間	チェックアウトを緩和する、労働者増加
会員/LMS	高い	8-16	8-16	タイムアウトの減少	キャッシュのパーソナライズ、 CPU 締め付ける
APIを多用するアプリ	高い	8-20	8-20	さらにTTFB	クエリを最適化する、限界セット

寸法測定の経験則

最初の感覚として、私は単純な近似値で計算する： 必要なワーカー ≈ キャッシュされていない同時リクエスト.この同時性は、リクエスト頻度に平均処理時間を掛けることで計算されます。例: 10リクエスト/秒、処理時間300msの場合、PHPの同時リクエスト数は約3となります。セキュリティリザーブや短いピークを考慮する場合は、この値を2倍にします。重要: この数値は CPUコア CPU時間のないワーカーはただの待機ワーカーです。

収納予算を正しく計算する

各 PHP-FPM プロセスは RAM を消費します。 PHPバージョンアクティブ オプキャッシュ とロードされたプラグイン。負荷時のフットプリント（ps/top）を測定し、それに pm.max_childrenウェブサーバー、データベース、キャッシュサービスを追加する。こうしてスワッピングとOOMキラーを防いでいる。原則として、私は20～30%の空きRAMバッファを確保している。プロセスあたりの消費量が著しく増加した場合、私はこれを プラグイン・ダイエット拡張の数が少ないか、プールごとの memory_limit 設定がより制限されている。

救済層としてのキャッシュ

から学ぶことが多い。 キャッシュ の方が、ワーカーが消費するエネルギーが少なくて済む。ページキャッシュ、オブジェクトキャッシュ、エッジキャッシュはPHPの実行を劇的に減らします。ショッピングカートやパーソナライズされたブロックのような動的な部分はESIやAjaxでカプセル化し、残りはキャッシュされたままにします。さらに深く知りたい場合はサーバーサイド・キャッシング NGINXとApacheについて、ワーカーに負担をかけないための有用な戦略を紹介する。これは、TTFBを顕著に減らし 応答時間 負荷が低い。

私はまた、次のことも考慮に入れている。 キャッシュの無効化 とウォームアップ戦略：デプロイメントや大きな製品変更の後は、重要なページやAPIルートをウォームアップします。ショップでは、カテゴリーページ、ベストセラー、スタートページ、チェックアウトプリロードをロードし、コールドスタートのピークを緩和します。オブジェクトキャッシュについては、不必要にホットセットを破棄しないよう、クリーンキー戦略に注意を払っています。

典型的な過ちと高価な罠

多くの人は、当初は、このような問題が生じていないのではないかと考えていた。 RAM 実際のボトルネックはワーカーのキューなのだが。そのため、私はキャッシュされたページが高速に保たれ、ダイナミックパスだけが手に負えなくなるかどうかをチェックしている。もうひとつの誤解は、「ワーカーを増やせばすべて解決する」というもので、コアを増やさなければ、コンテキストスイッチが多くなり、レイテンシが悪化する。同様に、悪質なプラグインはワーカーを過度に長い時間バインドし、レイテンシを増大させます。 パフォーマンス が悪化する。そのため、アドオンを減らし、データベースクエリを最適化し、リソースを一体的に拡張している。

WordPress特有のホットスポット

admin-ajax.php そして wp-json私はリクエストを束ね、賢明なキャッシュを設定する。
ハートビートAPIバックエンドでは、不必要に同時リクエストが多くならないように頻度を制限している。
WooCommerce wc-ajaxショッピングカート、配送、クーポンのチェックはキャッシュされないことが多いので、外部APIの呼び出しを減らし、フックを最適化しています。
トランジェント そして オプションオートロードオプションの過負荷や、高価な一時的な再生成は、PHPのランタイムを延ばし、スロットのコミットメントを延ばします。

実践：3人から8人まで - 混雑なし

店舗が3店舗しかないと仮定すると 労働者 夕方にはチェックアウトの渋滞が発生する。まず、キャッシュにないパスを分析し、負荷時のTTFBを測定します。次に、ページとオブジェクトのキャッシュを有効にし、パーソナライズされたエリアのみをアウトソースするようにしました。その後、ワーカーを8人に増やし、同時に2人追加しました。 CPUコア 無料。次の負荷テストでは、キューは減少し、エラー率は大幅に低下する。

オプションとして、ウェブサーバー内の高価なエンドポイントに保守的な制限（チェックアウトの同時アップストリームが少ないなど）を設けてピークを平準化する一方、静的コンテンツやキャッシュされたコンテンツは無制限の速度で配信する。これにより、FPMプールから圧力が取り除かれ、FPMプールが安定します。 TTFB たとえ個々のユーザーのアクションが一時的に遅くなったとしても、全体的に。

モニタリングと負荷テスト：私が使っているツール

フォローする TTFBまた、輻輳を早期に検出するために、短い間隔で応答時間とエラーレートを測定する。合成負荷については、K6 や Loader のようなツールを使っている。アプリケーションログは、遅いクエリや外部 API 呼び出しを特定するのに役立ちます。PHP FPM のステータスページもチェックして、稼働中、待機中、空きスロットに注意しています。スロットが恒常的に満杯になったら、ワーカーを増やし CPU ステップ・バイ・ステップで、各ステップをテスト負荷でチェックする。

メトリクスを確実に解釈する

最大児童数ワーカーを増やすか、より高速なキャッシュが必要です。
リスナーキューウェブサーバーとアップストリームの設定をチェックする。
リクエスト_スローログ_タイムアウト と slowlog を参照してください：ワーカーがアタッチされている正確なリクエスト場所を特定します。
アップストリーム・レスポンス・タイム ウェブサーバのログに表示されます：PHPが応答している時間を示す。 リクエスト時間 とステータスコード(502/504)。

特定のアップグレード信号を正しく解釈する

もし TTFB キャッシュが有効であるにもかかわらずトラフィックが顕著に増加している場合、通常はワーカーの能力が不足しています。チェックアウトやログインなどのアクション中に504エラーが頻発する場合は、実際にトラフィックが詰まっています。同時注文の増加、突発的なキャンペーンや立ち上げは、トランザクションが円滑に進むようにワーカーを追加することを正当化します。503エラーステータスが発生した場合、次のガイドを参照する価値があります。 WordPressの503エラーというのも、誤ったプロセスや制限も同様の効果を生むからだ。そして、Workerを使うかどうかを決める、 CPU またはタイムアウト。

設定：PHP-FPMと賢明な制限

PHP-FPMでは、次のように判断します。 pm.max_children 同時プロセスの最大数、つまりワーカーの上限を指定します。pm.start_servers と pm.min/max_spare_servers を使って、キャパシティがどれだけ早く利用可能になるかを制御しています。pm.max_requests は X リクエスト後にプロセスを再起動することでメモリリークを防ぎます。request_terminate_timeout はワーカーが永遠にハングしてスロットをブロックしないように長いランナーを確保します。これらの設定はキューに直接影響を与えるので、変更するのは テスト.

私は正しい選択をする午後-意識的にモードを変更する： ダイナミック 変動する負荷に対応する、 オンデマンド 小規模インスタンスでの散発的な負荷や静的 CPUとRAMが明らかに予約されているときに、常に高いピークが発生するためです。また オプキャッシュ を十分なメモリで動作させ、スクリプトを効率的に再検証することで、ワーカーがリクエストごとに必要とするCPUを少なくします。と リクエスト_スローログ_タイムアウト そして スローログ プールを拡大することなく、コードのホットスポットを見つける。FPMソケットが Unixソケット 或いは TCP ローカルではソケット、コンテナやホスト経由ではTCPがいい。

ショップ、メンバーシップ、LMSのチェックリスト

私が考えるショップのダイナミック ページ数 買い物カゴ、チェックアウト、「マイアカウント」などの外部からの問い合わせを減らします。メンバーエリアでは、すべてのプロフィールとダッシュボードのクエリをチェックして、余計なクエリがないかチェックします。LMSでは、コースリストのオブジェクトキャッシングに依存し、進捗インジケータを効率的にレンダリングします。すべての場合において、1アクションあたり数回の短いリクエストで済むようにし、ワーカーがすぐに自由になるようにします。この宿題が終わってから、ワーカーを拡張して CPU 並行する。

セッション、ロック、同時実行の罠

PHPのデフォルトでは、ユーザーセッションごとに連続的に動作するセッションロックに注意しています。高価なアクション(例: 支払いのコールバック)が同じセッションで実行されると、そのユーザーからのリクエストがブロックされます。 TTFB そして、ハングアップを認識する。私はセッションの使用を最小限に抑え、必要なものだけをセッションに保存し、高性能なハンドラ（インメモリなど）に切り替えています。WooCommerceでは、ショッピングバスケット内のセッションと一時的な嵐に注意しています。

乗数としてのデータベースと外部サービス

しばしば遅い SQLクエリ または外部APIのレート制限がワーカーに影響します。インデックスを最適化し、N+1クエリを減らし、クエリキャッシュ（オブジェクトキャッシュ）を設定し、タイムアウトとリトライロジックで外部コールを制限する。支払いサーバー、ディスパッチサーバー、ライセンスサーバーの動作が重くなった場合は、プール全体が待機しないように、意図的に並列処理を制限しています。これにより、他のユーザーアクションのための空きスロットができる。

労働者を視野に入れたプロバイダー選定とホスティング・チューニング

私は、以下のようなホスティングプランを好む。 PHPワーカー CPUコアを柔軟に並列拡張します。高性能プロバイダーは、クリーンなキャッシング・レベル、高速NVMeストレージ、明確なメトリクスをパネルに表示します。技術評価の導入として PHPホスティングガイド中央の基準やオプションを具体化するものです。私にとって重要なのは、トラフィックのピーク時にサポートが中断されることなく、リブートすることなくキャパシティを確保できることです。このようにして、私はTTFB、エラー率、そして スループット バランスが取れている

ピークに対する計画とボット負荷に対する保護

私は事前にエスカレーション・パスについて合意している。 CPU どのタイムアウトが一時的に増加することを許可されるかを監視するのは誰ですか？同時に、ダイナミックエンドポイントの適切なレート制限によって、ボットやスパムの負荷を最小限に抑えています。不必要なリクエストはすべて、本当の顧客のためのフリーワーカー枠になるのです。

持ち去る

PHPワーカー 各プロセスは一度に1つのリクエストしか処理しないので、動的なページが負荷にどれだけ素早く反応するかを決める。私は一貫したキャッシュで負荷を最小化し、ブロックするプラグインを片付け、ワーカーとCPUの比率を適正にします。ピーク時には注意深くワーカーを増やし、キューが消えて TTFB が下がるかどうかテストします。ログ、FPM ステータス、負荷テストは、私が正しくスケーリングしているか、タイムアウトを厳しくする必要があるかについての証拠を提供してくれます。これらのレバーをコントロールできれば、ボトルネックを回避し、トランザクションを保護し、処理時間を顕著に速くすることができる。 ユーザー・エクスペリエンス.