この PHP ハンドラの比較は、mod_php、CGI、FastCGI、PHP-FPM、LSAPI が パフォーマンス ホスティングに影響を与える要素（CPU負荷からテールレイテンシまで）について具体的に説明します。WordPress、WooCommerce、トラフィックのピーク時にどのような選択をするべきかを具体的に説明します。 ローディング時間 削減すると同時に資源を節約します。.
中心点
- ピーエッチピーエフピーエム mod_php や FastCGI よりも効率的にスケーリングされます。.
- LSAPI LiteSpeed で最高のパフォーマンスを発揮します。.
- 断熱 ユーザーごとにセキュリティが強化されます。.
- オペキャッシュ と Redis はレイテンシーを削減します。.
- P95/P99 実際のユーザー体験を示しています。.
PHPハンドラの仕組み
PHP ハンドラは、Web サーバーをインタープリタに接続し、以下を制御します。 プロセス, 、メモリ、および各リクエストの I/O を消費します。CGI はリクエストごとに新しいプロセスを開始し、設定を再ロードするため、オーバーヘッドが発生し、 レイテンシー 増加します。FastCGI、PHP-FPM、LSAPI などの最新バージョンは、ワーカーを永続的に待機させ、起動時間、コンテキストの切り替え、CPU サイクルを節約します。OPcache はメモリ内に残るため、バイトコードを毎回コンパイルする必要がなく、動的なページの応答が高速化されます。同時に、プロセス管理により、同時に実行できるリクエストの数、優先順位の設定、負荷のピークを緩和する方法が決定されます。.
一般的なハンドラーの直接比較
ハンドラーの選択によって、 スケーリング, 、セキュリティモデル、およびアプリケーションの RAM 要件。mod_php は PHP を Apache プロセスに組み込み、応答時間を短縮しますが、パフォーマンスが低下するという欠点があります。 断熱 アカウント間。CGI はユーザーを明確に分離しますが、リクエストごとに膨大な CPU 時間を消費します。FastCGI はオーバーヘッドを削減しますが、適切に調整された PHP-FPM よりも効率は低くなります。LSAPI は LiteSpeed を使用している場合にさらに効果を発揮し、特に同時接続数が多い場合のテールレイテンシを安定させます。.
| ハンドラー | パフォーマンス | セキュリティ | RAM 要件 | スケーラビリティ | 運営シナリオ |
|---|---|---|---|---|---|
| mod_php | 高い | 低い | 低い | ミディアム | 小規模サイト、まれなピーク |
| CGI | 低い | 高い | 高い | 低い | 静的コンテンツ、テスト |
| FastCGI | ミディアム | ミディアム | ミディアム | ミディアム | 暫定的な解決策 |
| ピーエッチピーエフピーエム | 非常に高い | 高い | 低い | 高い | 共有ホスティング、CMS |
| LSAPI | 最高 | ミディアム | 非常に低い | 非常に高い | 高トラフィック、Eコマース |
PHP-FPM の実践チェック：プロセス、プール、チューニング
PHP-FPM は、キューからリクエストを取得するワーカープールで動作します。 負荷ピーク エレガントに緩和する。私はウェブサイトごとに独自のプールを設定し、設定、制限、ユーザーコンテキストが分離されたまま、 セキュリティ 上昇します。実際には、pm = dynamic や ondemand などの適応的な設定が有効です。これは、アクティブなプロセスの数が需要に合わせて調整されるためです。重要なのは、pm.max_children とタイムリミットを適切に設定し、キューが拡大しすぎず、RAM の予備容量が残るようにすることです。まずは、パラメータを体系的に確認することをお勧めします。微調整の詳細については、こちらで説明します。 PHP-FPM プロセス管理.
LSAPI と LiteSpeed：高い同時接続数での最高値
LSAPI は PHP プロセスをメモリ内に保持し、コンテキストの切り替えを削減することで、動的コンテンツを HTTP/3 そしてQUICはさらにスムーズに配信されます。フル負荷でも、P95/P99レイテンシーは多くの代替製品よりも安定しており、これは ユーザー・エクスペリエンス 目に見えて改善されました。ショップページやコンテンツページでは、特に OPcache とサーバーキャッシュが連携している場合に、1 秒あたりのリクエスト数が定期的に増加し、TTFB が短縮されています。このメリットは、平均値だけでなく、同時セッション、キャッシュミスが発生したセッション、「コールド」な PHP ワーカーでも確認できます。アーキテクチャの違いを理解したい方は、概要をご覧ください。 LiteSpeed 対 Nginx そして、スタックについて決定します。.
WordPress と WooCommerce：測定値を正しく分類する
WordPress では、FPM または LSAPI 上で PHP 8.2 を使用すると、高いパフォーマンスを実現しています。 req/s-値であるのに対し、WooCommerce はセッション、カートロジック、およびより多くのデータベースアクセスにより、1 秒あたりのリクエスト数がやや少なくなっています。このテストは、現実的な条件下でのみ意味のある結果となります。 トラフィック キャッシュヒットとキャッシュミスが混在しています。クリティカル CSS、オブジェクトキャッシュ、および持続的な接続により、ボトルネックが発生する限界点が押し上げられます。頻繁に変更されるコンテンツには短い TTL、言語、ユーザーステータス、デバイスタイプには差別化されたキャッシュキーが特に有効です。これにより、パーソナライズされたコンテンツを配信しながら、ページの高速性を維持することができます。.
セキュリティと分離：プール、ユーザーコンテキスト、制限
マルチユーザーホスティングには、別々の プール アカウントごとに、権限、パス、制限が明確に分離されるようにします。mod_php は共通のコンテキストを共有するため、 リスク プロジェクトに不備がある場合に増加します。FPM または LSAPI をユーザーごとの設定で使用すると、プロセスが各ユーザーの下で実行されるため、この攻撃対象領域が大幅に減少します。さらに、他のサイトに影響を与えることなく、プロジェクトレベルでさまざまな php.ini オプションを設定することができます。プールごとの max_execution_time や memory_limit などのリソース制限により、異常値によってサーバーの速度が低下することを防ぎます。.
リソース消費とRAMの計画
各 PHP ワーカーは、コード、拡張機能、および オペキャッシュ-サイズが大きく異なるメモリがあるため、推測ではなく実際の使用量を測定しています。ps、top、systemd-cgtop などのツールは、アクティブなワーカーが実際に使用している RAM の量と、その使用時間を表示します。 スワッピング その後、pm.max_children を保守的に設定し、データベース、ウェブサーバー、キャッシュサービスにヘッドルームを残して、ピーク時の P95 レイテンシーを監視します。予備容量が残っている場合は、子プロセス数を段階的に増やして再度確認します。これにより、サーバーに過負荷をかけることなく、総容量を管理しながら増やすことができます。.
測定方法：TTFBからP99まで
私は平均値だけでなく、とりわけ P95– そして P99 レイテンシは、負荷がかかった状態での実際の体験を表しているから。スタックは、同じスループットで動作していても、P99 ではパフォーマンスが低下しているように見えることがある。 キュー 成長する。そのため、私はコールドキャッシュとウォームキャッシュをテストし、読み取りと書き込みの要求を混ぜ合わせ、現実的な同時実行値を使用しています。OPcache のウォームアップなしでは、多くのシステムは数回のウォームアップ呼び出し後に大幅に高速化するため、結果を慎重に解釈しています。代表的なテスト実行を経て初めて、ハンドラ、キャッシュ戦略、プロセス制限を決定します。.
ハンドラーの選択に関する決定ガイド
ログイン数が少ない小規模なサイトには、mod_php または経済的な FPM-セキュリティ面に対応している場合は、セットアップ。同時性が向上したら、私は ピーエッチピーエフピーエム プロジェクトごとに個別のプールを使用し、OPcache を一貫して有効にします。動的なショップやセッション数が多い場合は、P95 および P99 を低く抑えるために、LSAPI を使用した LiteSpeed を優先します。価格やアーキテクチャの理由から Apache/Nginx を継続して使用する場合は、適切に調整された FPM を使用すると非常に良好です。いずれの場合も、空のシステムでのベンチマークよりも、現実的な条件下での測定の方が重要です。.
実践的な設定：キャッシュ、セッション、時間制限
私は、OPcache を多めに設定しています。 メモリ-バイトコードが押し出されることが少ないように割り当てを行い、可能であればセッションを レディス, ファイルロックを回避するためです。これにより、同時ログインやパーソナライズされたページでの待ち時間が短縮されます。外部サービスについては、障害によってリクエスト全体がブロックされないよう、明確なタイムアウトとサーキットブレーカーを定義しています。アプリケーションレベルでは、キャッシュのTTLを最新性を維持するのに十分な短さに保ちながら、高いヒット率を確保できる長さに設定しています。ワーカーの制限に頻繁にぶつかる方は、こちらをご覧ください。 PHPワーカーの適切なバランス調整.
費用対効果の比較と運用
を評価する。 コスト レイテンシ、スループット、信頼性における測定可能な利点とのトレードオフ。FastCGI から PHP-FPM への移行は、PHP のマイナーバージョン番号の変更よりも大きな効果をもたらすことが多い。 プロセス-管理とキャッシュが継続的に機能します。LSAPI は、LiteSpeed をすでに使用しており、同時に多くの訪問者がアクセスする場合に特に有効です。スタックを変更する場合は、ログとメトリクスを注意深く監視し、ロールバックパスを準備しておく必要があります。数日間にわたって A/B 運用を計画的に実施することで、最も信頼性の高い結果を得ることができます。.
Webサーバーの連携：Apache MPM、Nginx、およびキープアライブ
実際には、PHP ハンドラだけでなく、Web サーバーのモードも決定要因となります。mod_php は Apache で prefork-MPM は、最新のイベントモデルの使用をブロックします。HTTP/2、より長いキープアライブフェーズ、および何千もの接続を効率的に処理したい場合は、Apache を使用してください。 イベント + PHP-FPM または Nginx/LiteSpeed をフロントエンドとして使用。その結果、必要な PHP ワーカーの数は、TCP 接続の数ではなく、実際に 同時に 進行中の PHP リクエスト。HTTP/2/3 マルチプレキシングは、Web サーバーのヘッダーのオーバーヘッドを削減しますが、容量不足の PHP プールには影響を与えません。.
Nginx は通常、FastCGI 経由で FPM にリクエストを転送します。私は短い read_timeout- そして send_timeoutプロキシで値を設定しないと、PHP は動作しているにもかかわらず、アップストリームがハングアップすると 502/504 エラーが発生します。Apache 環境では、長いアイドル接続がスレッドプールを拘束しないように、Keep-Alive を制限しています。LiteSpeed はその多くを抽象化していますが、LSAPI を使用することでその利点を最大限に発揮します。.
OPcache、JIT、プリロード：本当に役立つもの
OPcache は必須です。実際には、私は次のようにサイズ設定しています。 opcache.memory_consumption （コードベースに応じて、192～512 MB など）の容量を確保し、 opcache.max_accelerated_files, 、立ち退きが発生しないようにします。デプロイ頻度の少ないビルドについては、 validate_timestamps または、より高い値を設定してください。 再評価, システムコールを節約するため。. プリロード フレームワークを高速化できますが、一貫したオートロード構造で特に効果を発揮します。 ジャストインタイム PHP の使用は、従来の Web ワークロードではほとんどメリットがなく、RAM を消費することさえあります。私は、実際の条件でのベンチマークでそれが確認された場合にのみ、PHP を有効にします。.
キュー管理とバックプレッシャー
ほとんどのボトルネックはCPUではなく、 待ち行列. ワーカーが処理できる以上のリクエストが到着すると、キューが長くなり、P95/P99レイテンシが急上昇します。私は、 pm.max_children 典型的なピークを吸収するのに十分な大きさでありながら、RAMの予備容量を確保できるほど十分に小さい。. pm.max_requests メモリリークが長期実行プロセスを生成しないように、適度な値（例えば 500～2000）を設定します。 listen.backlog Webサーバーのバックログに適合している必要があります。そうしないと、負荷がかかるとカーネルが接続を切断してしまいます。到着率（1秒あたりのリクエスト数）と平均サービス時間を測定すれば、簡単な容量計算で、どの程度の同時実行数からレイテンシが急上昇するかを判断することができます。.
タイムアウト、アップロード、および長期実行
長いアップロードやAPIコールはワーカーをブロックします。私は明確な境界線を設定します。 最大実行時間 そして リクエスト終了タイムアウト FPM では、欠陥のあるリクエストが永遠に実行され続けることを防止します。プロキシレベルでは、同期化を行います。 proxy_read_timeout/fastcgi_read_timeout FPMの制限を使って、時期尚早な504が発生しないようにします。大きなアップロードはストリーミングし、制限します。 ポスト・マックス・サイズ そして upload_max_filesize 厳格に専用のエンドポイントを計画し、残りのトラフィックに影響が出ないようにします。cron のような長時間実行されるタスクについては、作業を キュー または、フロントエンドワーカーを数分間ブロックする代わりに、CLI ジョブを使用します。.
セッションとロッキングの詳細
PHPセッションはデフォルトで 遮断する. 同じユーザーによる 2 回目のリクエストは、1 回目のリクエストがセッションを解放するまで待機します。Ajax コールが並行して実行されている場合、これは WooCommerce にとって致命的です。私はセッションの書き込みアクセスを早期に終了します。 session_write_close(), 変更が不要になった時点で。Redis をセッションバックエンドとして使用すると、I/O レイテンシは低下しますが、ロックルールは依然として重要です。ロードバランサーの背後では、水平スケーリングが確実に機能するように、スティッキーセッション（シンプル、スケーラビリティは低い）とオブジェクトキャッシュを使用したステートレスパターンを意図的に選択しています。.
モニタリングとトラブルシューティング
テレメトリなしでは、チューニングは手探り状態になります。FPM ステータスとプールごとのスローログを有効にして、ボトルネックを確認し、目立つクエリを特定します。.
; プールごとに pm.status_path = /status ping.path = /ping ping.response = pong request_slowlog_timeout = 3s slowlog = /var/log/php-fpm/www-slow.log pm.max_requests = 1000
502/504 エラーが発生した場合、まず以下を確認します。FPM キューは満杯ですか？CPU スティールやスワップは発生していますか？Web サーバーのタイムアウトは FPM の制限に適合していますか？以下を確認してください。 smaps pro Worker は実際の RSS 使用率を表示し、 netstat/ss バックログのオーバーフローを発見します。OPcache については、ヒット率と再検証の数を監視して、エヴィクションを回避しています。.
コンテナ、ソケット、リソース制限
コンテナでは、私は主に TCP WebサーバーとFPMの間でUnixソケットの代わりに、ネームスペースの境界を回避し、負荷分散を容易にするために使用されます。一貫性が重要です。 cgroup-制限：コンテナの RAM が 1～2 GB しかない場合、pm.max_children はそれに応じて小さく設定する必要があります。そうしないと、OOM キラーが作動します。 CPU クォータは応答時間に大きく影響します。私はヘッドルームを計画し、制限内で P95 レイテンシを確認しています。NUMA およびコアアフィニティの問題は、負荷が非常に高い場合に重要になりますが、LiteSpeed セットアップでは、LSAPI がその多くを内部で最適化しています。.
マルチPHPバージョンと拡張機能
多くのホストは、複数の PHP バージョンを並行して実行しています。私はバージョンごとにプールを分離し、 拡張機能 スリム。追加モジュールはワーカーごとのRAMを増やすから、起動時間が長くなることがあるよ。使わない拡張機能はどんどん削除してる。そうすることで、pm.max_childrenを少し増やすよりも効果があることが多いんだ。アップグレードするときは、OPcacheのウォームアップ時間を短く設定して、デプロイ後にすべてのユーザーが同時にコールドスタートを経験しないようにしてるよ。.
RAMダイエットと現実的な容量計画
一律の値ではなく、ライブトラフィックでワーカーあたりの平均および上限のRAM要件を算出します。そこから、次の式を導き出します。（利用可能なRAM – システム/DB/キャッシュ） / ワーカーあたりのRAM = 最大 適切な pm.max_children。さらに、バースト、カーネルキャッシュ、予期せぬスパイクに備えて、15～25 % の予備を確保しています。アプリケーションが散発的にメモリを膨張させる場合は、制限値を下げたり、pm.max_requests を短縮してプロセスのリサイクル頻度を高めたりします。.
テスト戦略：再現可能な負荷と実際のパターン
私は、コールドキャッシュとウォームキャッシュを混合し、GET/POST を組み合わせ、同時実行数を段階的に増加させるテストプロファイルを使用しています。重要：OPcache をアクティブにし、現実的なシンクタイムを設定して初めて、システムが使用状況において安定しているかどうかを確認できます。 数分間にわたるランプアップにより、起動時の人為的なピークを防止します。評価は、平均 RTT や純粋な req/s だけでなく、TTFB および P95/P99 に焦点を当てています。.
実践におけるエラーパターン
- ピーク時に504が多数発生：FPMキューが満杯、バックログが小さすぎる、プロキシのタイムアウトがFPMよりも短い。.
- デプロイ時のスタッター：OPcache の置換、ウォームアップの欠如、opcache.memory_consumption が小さすぎる。.
- 平均値は良好、P99は不良：長時間の処理（I/O、外部API）が多すぎる、サーキットブレーキングが欠落。.
- CPU使用率が高い、req/sが低い：セッションロック、またはキャッシュされていないデータベースクエリがシリアル制限を引き起こしている。.
運用上の安全性およびロールバック
ハンドラやプールパラメータの変更は、すべて 特徴的なフラグ または段階的に停止します。 エラーログ、スローログ、P95、エラー率を監視し、メトリクスが急変した場合に明確な復旧手順を定義します。同一バージョンで異なるパラメータを持つ 2 つ目のプールにより、ダウンタイムなしで迅速な A/B 切り替えが可能になります。全負荷時には、新しいワーカーを無制限に起動する代わりに、同時実行数（バックプレッシャー）を自動的に短時間削減することが有効です。.
簡単にまとめると
同時ユーザー数の多い動的なサイトには、以下を推奨します。 LSAPI LiteSpeed 上で、PHP-FPM は Apache または Nginx 上で最高のパフォーマンスを発揮します。 オールラウンダー mod_php は、厳密な分離を必要としない非常に単純なプロジェクト向けの特別なケースです。重要なのは、OPcache を温めた状態での現実的なテスト、適切なプール制限、そしてクリーンなキャッシュです。レイテンシを確実に低減するには、P95/P99 を測定し、平均値よりもテール問題に優先的に対応します。これにより、アプリケーションの応答速度が大幅に向上し、ピークトラフィックに対応する余力が生まれます。.
