管理

PHPハンドラの比較：ホスティングにおけるCGI、FPM、LSAPI

PHPハンドラーの比較 CGI、PHP-FPM、LSAPI がどのように PHP スクリプトの実行を制御し、ホスティングにおけるレイテンシ、分離、RAM 要件を特徴付けるかを明確に示します。その違いを実用的な方法で説明し、ワークロードに応じて分類し、日々の運用における選択と設定に関する推奨事項を示します。.

中心点

パフォーマンスLSAPIはテールレイテンシーでリードしているが、PHP-FPMは非常に一定の応答時間を実現している。.
セキュリティCGIは厳密に分離し、PHP-FPMはプールで分離し、LSAPIはユーザーごとにカプセル化する。.
リソースLSAPIはRAMを節約し、PHP-FPMは効率的であり続け、CGIはオーバーヘッドを発生させる。.
互換性PHP-FPMはApache/Nginxに適合し、LSAPIはLiteSpeedで輝く。.
練習CMSやショップでは、主にPHP-FPMを使っている。多くのトラフィックは、LSAPIが役に立つことが多い。.

ホスティングにおける最新のPHPハンドラーの比較 - データセンターにおけるCGI、FPM、LSAPI

PHPハンドラの基本

PHPハンドラーは、ウェブサーバーと PHPインタプリタ. .CGIは各リクエストに対して新しいプロセスを開始するので、アカウント間の非常にきれいな分離を実現する。リクエストのたびに拡張モジュールや設定を再読み込みするため、この分離には時間がかかります。PHP-FPM はワーカーを永続化し、リクエストをプールに分散させます。LSAPI は LiteSpeed と深く統合されており、非常に軽量で長寿命のプロセスを 高効率.

Mod_phpはPHPを直接ウェブサーバーに統合するが、分離が弱い。私はモダンなハンドラの方を好みます。なぜならエラーの発生源を最小化し、負荷がかかってもプラットフォームをより安定に保つことができるからです。もし1つのシステムで多くのユーザーをホストするのであれば、分離された ユーザーコンテキスト. .これこそ、FPMプールとLSAPIが威力を発揮する場面である。CGI は、非常に小規模なサイトや特殊なテストシナリオでは、安全ではあるが遅いオプションであることに変わりはない。.

比較表：強みと適用シナリオ

以下の表は、コア機能を要約し、典型的なワークロードに割り当てたものである。私はこの表を、次のような場合の迅速な判断材料として使っている。 ホスティングphp-CMS、ショップ、APIとのセットアップ。実際のパフォーマンスは、キャッシュ、ストレージ、ネットワークプロファイルにも依存することに注意してください。とはいえ、この概要は最初の選択のための確かな出発点となる。その後、特定の負荷プロファイルやネットワークプロファイルに基づいて構成を微調整します。 測定値.

ハンドラー	パフォーマンス	セキュリティ	RAM消費量	スケーラビリティ	こんな人に向いている
CGI	低い	非常に高い	高い	低い	テスト、静的ページ、めったにアクセスされないページ
ピーエッチピーエフピーエム	非常に高い	高い	低い	高い	共有ホスティング、CMS、API
LSAPI	最高	中～高（ユーザー1人当たり）	非常に低い	非常に高い	高トラフィック、電子商取引、並行処理

CGIの得点分離, が、プロセスの起動コストに悩まされる。PHP-FPM は Apache や Nginx を使用したシステムにおいて、レイテンシ、スループット、分離の面で最高の比率を提供する。LSAPI は、LiteSpeed スタック上で高い競合性を保ちつつ、非常に低いテールレイテンシを実現する。LiteSpeedサーバーを使用しない場合は、FPMが最も幅広いサポートを提供します。非常に小規模なサイトでは、私はシンプルなセットアップにこだわる。 FPM またはLSAPIである。.

負荷時のパフォーマンス：レイテンシーとスループット

競争が激化する中、P95/P99のレイテンシーと 安定性 スループットのLSAPI が最も高い負荷を保持し、驚くほど安定した応答時間を実現しています。PHP-FPM はそのすぐ後に続き、動的なプロセス番号の設定など、プールのチューニングに非常によく反応します。CGI は、短いリクエストがたくさん来るとすぐに速度が低下します。より詳細な測定については性能比較, これは典型的なCMSとショップのワークロードをカバーしている。.

私は一貫して、FPMかLSAPIと組み合わせている。 オペキャッシュ, これにより、バイトコードが常に新しく生成されることがなくなります。加えて、リバースプロキシキャッシュは、繰り返されるコンテンツに対する PHP のヒット数を減らします。ジョブキューは、フロントエンドリクエストを高速に保つために、計算集約的なタスクには価値があります。散発的なピークを阻止したい場合は、 FPM ワーカーを追加して短時間のバーストスケーリングを使います。これにより、テールレイテンシを制限内に保ち 応答時間 一貫している。

共有ホスティングにおけるセキュリティと分離

マルチユーザー環境で重要なこと断熱少なくともスピードと同じくらい。CGI はリクエストごとのプロセスによって非常にきれいな分離を実現しますが、オーバーヘッドが多くなります。PHP-FPM はプール単位で分離し、メモリ、実行時間、プロセス数を厳しく制限します。LSAPI もプロセスをアカウントに割り当てますが、詳細には LiteSpeed スタックに関連付けられます。リスクを分類したければ、以下の記事を読むのが一番だ。 FPMでリスクをプールするそして明確な制限を設ける。.

私はそれぞれのアカウントに別のアカウントを設定した。 プール を、独自のUID/GIDと制限付き権限で設定する。これにより、可能性のある攻撃の範囲を制限し、欠陥のあるスクリプトが外部データを見ることを防ぎます。これにはメモリ、ワーカーあたりの最大リクエスト数、タイムアウトの制限が含まれます。定期的なアップデートと安全なファイルパーミッションが、このコンセプトを完成させます。私は、ネットワーク上でオープンに利用できる管理スクリプトを最小限にするか、次のような方法でスクリプトを保護しています。認証.

リソース消費とRAM管理

RAMは多くの場合 コスト とサーバーあたりの密度である。LSAPIは、プロセスあたりのフットプリントが非常に小さく、コンテキストスイッチも経済的である。PHP-FPM も、動的にプールを作成し、適切に制限をかければ、効率的なままである。CGI は拡張モジュールの頻繁なリロードによりメモリを浪費するので、動的なプロジェクトにはほとんど適していません。多くのアカウントをホストしている場合、FPM や LSAPI を使用すると、ノードあたりのリザーブ数が大幅に増加します。 総費用 計画的である。

私は定期的にピークRAMを測定し、一日を通してその分布を観察しています。ピークは、ワーカー数が少なすぎるか、キャッシュ戦略が不適切であることを示しています。私は、プールのサイジングを細かくしたり、OPcacheのチューニングの対象を絞ったりして、需要を減らしています。これによりスワップリスクを減らし、予測できないレイテンシの異常値を防ぎます。過密状態のホストでは、個々の サイト 全体的なパフォーマンスが低下する前に、自ノード上で。.

Apache、Nginx、LiteSpeedとの互換性

ウェブ・サーバーの選択は、次の段階での決断の指針となる。 ハンドラー. .PHP-FPMはNginxの裏でうまく動作し、プロキシ経由でApacheにきれいに接続することができます。Apache 環境では、 mpm_event や keep-alive のチューニング、安定したプロキシ設定を推奨します。LSAPIはLiteSpeedでその能力をフルに発揮し、.htaccessファイルを効率的に読み取ります。すでにLiteSpeedを使っている人は、LSAPIで最後の性能を引き出すことがよくあります。 パフォーマンス アウト。

静的コンテンツには、ウェブサーバーのキャッシュから直接NginxかLiteSpeedを使っている。PHPは、動的であり続ける必要があるものだけを処理する。このように分離することで、ハンドラーの負荷を減らし、CPU時間を節約することができる。副次的な効果として、TTFBの一貫性は、繰り返しページがリクエストされることで向上する。つまり、フロントエンドは、たとえ バックエンド はプレッシャーにさらされている。.

PHP FPM プールのベストプラクティス

私は保守派から始める プールのレイアウト サイトごとに、実際のピークを測定する。それからpm、pm.max_children、pm.start_servers、pm.max_requestsを調整する。小さすぎるプールはリクエストを待たせ、大きすぎるプールはRAMを消費し、コンテキスト・スイッチを発生させる。WordPress、WooCommerce、TYPO3の場合、私は通常ダイナミックかオンデマンドを選び、制限を厳しくする。pm.max_childrenの詳細は私のガイドを参照してください。 pm.max_children と要約した。

私はプールごとにmemory_limitやmax_execution_timeなどの制限を設定している。max_input_varsとupload_max_filesizeは、プロジェクトに応じて、感覚的に確保されている。これにより、プール可変ホストは安定している。.

キャッシュとOPcacheの実際

私にとっては、OPcacheはすべての PHPのインストール. .私はそれを有効にして、サイズをチェックし、ヒット率を監視する。多くのデプロイメントでは、file_cache_onlyを設定し、revalidate_freqを調整することで、デプロイメントが素早く反映されるようにしている。また、PHPのヒット率を下げるために、CMSのリバースプロキシ・キャッシュやページ・キャッシュ・プラグインも使っている。実際にPHPに到達するリクエストが少なければ少ないほど、スケールが向上する。 すべて.

サーバーサイドのセッションを集中的に使用する人は、Redisが有効な場合が多い。私はTTLを調整し、メモリ制限を厳密に管理しています。フルページキャッシュについては、価格や在庫の変更後にショップが正しく配信できるように、キャッシュキーと無効化戦略を検討しています。明確なキャッシュ計画は、CPU、RAM、時間を節約します。OPcache、プロキシキャッシュと アプリケーションキャッシュ 最終的には、知覚されるスピードが決まる。.

決定マトリックス：どのハンドラーがどのプロジェクトに適しているか？

トラフィックの少ない小規模サイトは、以下の方法で安全に運営できる。 ピーエッチピーエフピーエム と保守的な制限があります。純粋なテスト環境や特別なコンプライアンス要件では、速度は低下するものの、CGI が有用になります。トラフィックの多いショップや競争力の高い API では、LiteSpeed の LSAPI が役立つことがよくあります。最大限の互換性と柔軟性が必要な場合は、FPMに頼ることができます。WordPressやWooCommerceでphpをホスティングする場合、私は汎用性の高いFPMを好みます。 オールラウンダー の前に。

私はベンチマークだけに基づいて決定を下すことはありません。その代わりに、静的ヒット、動的ページ、APIコールの実際の組み合わせを測定する。平均スクリプト時間とキャッシュヒットの割合も選択に影響する。また、頻繁なデプロイやビルドプロセスなど、管理者の習慣も考慮に入れる。最良の解決策は、実際の環境下で機能するものであることに変わりはない。条件安定していて速い。.

コスト、ライセンス、運営 - 何が利益を生むのか？

純粋なコスト観について FPM 追加ライセンスを必要としないため、魅力的です。LSAPIは、密度が高くレイテンシが低いため、サイトあたりの運用コストを削減できますが、ユーロでLiteSpeedライセンスが必要です。多くの有料顧客にとっては、これはしばしばペイしますが、趣味のプロジェクトでは通常ありません。CGIは、非効率的なリソースの利用と長い応答時間によって間接的なコストを引き起こします。そのため、私は全体的な運用を計算し、意味のあるところは節約しています。品質危険はない。.

計画を立てる能力は依然として重要である。オーバーブッキングが多すぎるホストは、短期的にはコストを削減できるが、その代償としてダウンタイムやユーザーの不満が発生する。最新の観測可能なツールは、早い段階でボトルネックを認識するのに役立ちます。定期的にキャパシティを追加することで、レイテンシーは安定し、サポートの負担も軽減される。結局のところ、リソースを節約し、遅延を最小化するソリューションが必要なのだ。 アップタイム 高い。.

マルチPHPバージョン、ロールアウト、ダウンタイムゼロ

普段の生活では、私はよく複数の車を操作する。 PHPバージョン を並列に使うことができる。FPMでは、バージョンごとに別々のプールと別々のソケットを使うことで、これをきれいに実現できる。これにより、システム全体を混乱させることなく、段階的にサイトを移行することができる。私はローリングアップデートを計画している。まずステージングを行い、次に小規模の本番グループ、そして残りを移行する。. 優雅なリロード (FPM:リスタートの代わりにリロード) ハードティアリングを回避し、コネクションを開いたままにします。LSAPIでは、LiteSpeedスタックのアナログメカニズムを使ってワーカーを予熱し、コールドスタートの影響を最小限に抑えます。.

ゼロダウンタイムのデプロイメントのために、私はシンボリックリンクを使ったアトミックリリース戦略と OPcacheの検証. .切り替え後は、すべてを破棄せずに選択的にキャッシュをクリアする。こうすることで、テールレイテンシが安定し、新しいデプロイがすぐにウォームな状態になる。重要: ファイルのパーミッションとオーナーは正しくなければなりません。そうしないとFPMやLSAPIワーカーが新しいリリースをブロックしてしまいます。.

ソケット対TCP：結果を伴うアーキテクチャ上の決定

ハンドラーは Unixソケット またはTCP経由。ソケットはオーバーヘッドを節約し、通常、ホスト上のレイテンシーを最小限に抑えることができる。TCPは、ウェブサーバーとハンドラーが別々に動作する場合や、プールを複数のノードに分散させたい場合に有効だ。 スケール が欲しい。TCPでは、負荷のピーク時に502/504エラーが発生しないように、タイムアウト、キープアライブ、バックログをきれいに定義します。Apacheのセットアップでは、アクティブなプロキシワーカーの数に注意を払い、Nginxではオープンなコネクションの制限に注意を払います。LSAPIでは、LiteSpeedが多くのことを内部で処理しますが、それでも負荷が高いときは定期的にバックログとキューをチェックします。.

私は FPM ステータスのキューの長さ、ワーカーの利用率、CPU 飽和度を監視しています。低い利用率で高いキューは、多くの場合フロントエンドのボトルネック（例えば Nginx のワーカーが少なすぎる）や I/Oブレーキ そこにいる。ボトルネックがわかって初めて、子プロセスを増やしたり、ネットワークパラメーターを調整したりする。.

モニタリング、メトリクス、トラブルシューティング

観測のために頼りにしているのは ホリスティック・モニタリングウェブサーバーのログ、FPM のステータス、システムメトリクス（CPU、RAM、I/O）、アプリケーションログ、合成チェック。特に貴重なのは FPMスローログ, 異常値を検出する。私はP95/P99レイテンシをCPUスパイク、OPcacheヒット率、実行中のプロセス数、データベースレイテンシと相関させる。P99レイテンシが増加したら、まずプロキシとハンドラの間のキューとタイムアウトをチェックする。.

1）HTTPエラーコードとその時間、2）プロキシ／ウェブサーバのエラー、3）ハンドラのキューとワーカーの状態、4）アプリケーションのログ、5）バックエンドのシステム（DB、キャッシュ、ファイルシステム）。502/504 のよくある原因は、厳しすぎるタイムアウト、アップストリームのブロック、あるいは 疲労困憊 プールの容量。簡単な対策：現実的なタイムアウト、明確な制限、そして以下のような警告。曩に疲労困憊の。.

ファイルシステム、リアルパス、OPcacheの詳細

ファイルアクセスは、多くの人が思っている以上にレイテンシに大きな影響を与える。私は高速な ストレージパス コードとテンプレート用。ネットワーク・ファイル・システム（NFSなど）では、realpathとOPcacheパラメータが重要である。十分に大きなrealpath_cache_sizeと適切なttlは、恒久的なパス解決を防ぐ。OPcacheでは、memory_consumption、interned_strings_buffer、および ハッシュテーブル validate_timestampsとrevalidate_freqをデプロイのワークフローに合わせて設定し、変更がすぐに反映されるようにしたが、1秒ごとにチェックが入ることはなかった。.

大規模なコードベースには、次のような価値がある。 プリロード を中央のクラスや関数に使用します。これにより、FPMやLSAPIワーカーのホットパスでのCPU時間を節約できる。私がJITをテストするのは、実際にCPUのボトルネックがある場合だけだ（数値ロジックが多い）。クリーンなOPcacheコンフィギュレーションと高速なI/Oパスの方が重要です。.

データベースとキャッシュの接続：待ち時間の回避

パフォーマンスの問題の多くは、ハンドラーに起因するものではなく データベース とキャッシュを監視しています。私はクエリーのランタイム、コネクションプール、ロックを監視しています。持続的接続は助けになるが バインド RAMをワーカーに割り当てます。そのため、pm.max_childrenをデータベースの接続制限に合わせて調整し、タイムアウトを制御しています。Redis/Memcachedへのアクセスでは、低いネットワークレイテンシとタイムアウトも重要です。N+1クエリを認識し削減するために、アプリケーションでトレースを使用しています - これによりハンドラとバックエンドの負荷を同時に減らすことができます。.

競争の激しい状況下では、しばしば理にかなっている、, 執筆プロセス（キュー、非同期ジョブ）とキャッシュの読み取りアクセスを切り離す。これにより、フロントエンドのリクエストを短く保ち、応答時間のばらつきを抑えることができる。.

コンテナ、chroot、OSの側面

でFPMやLSAPIを使用している人なら、誰でもそうだろう。 コンテナ バージョンと制限で柔軟性が増す。適切な上限、効率的なプロセススケジューラ、適切なCPU/メモリクォータが重要です。厳しすぎるクォータは、P99のレイテンシーにスタッタリングを引き起こします。古典的なセットアップでは、chroot/jailやネームスペースによるユーザー分離が、ファイルアクセスを厳密に分離するのに役立ちます。コールドスタート時間（ロールアウトの後など）を短くするためにイメージは無駄のないものにし、トラフィックが切り替わる前にプールを予熱しておきます。.

ログのローテーションと背圧-ストラテジーは必須です。フルディスクやログ書き込みのブロックはレスポンスタイムに直接影響します。また、ノード間のメモリアクセスによってワーカーが遅くならないように、多くのコアを持つホスト上で、スワップネス、HugePages（適切な場合）、NUMA戦略を調整します。.

稼働中のLSAPIとFPMユニット

LSAPI の利点は、安定した長持ちするプロセスと効率的なリクエストディスパッチです。私はメモリリークの影響を抑えるためにワーカーあたりのリクエストの最大数を調整し、ライブ運用での再起動を監視しています。FPM では オンデマンド 不規則なトラフィックのあるサイト向け、, ダイナミック pm.max_requestsは、散発的なリークや断片化が起こらないように定義しています。 request_slowlog_timeoutは、実際のハングアップを早期に認識するのに十分な間隔に設定していますが、複雑な管理操作が常にアラームを鳴らすほど近くは設定していません。.

どちらの世界でも、私は シグナル伝達経路 ワーカーがきれいに再起動しない場合のリロードとエスカレーションパスを定義します。これにより、日中のデプロイがプラットフォームの中断を引き起こすことを防ぎます。.

チェックリスト選択と調整の実際

ターゲットの定義：最大 互換性 (FPM)対最小テール・レイテンシー(LSAPI)対非常にハードなセパレーション(CGI)。.
サーバーの役割を明確にする：タイムアウトやバックログを適切に設定する。.
アカウント/サイトごとのプール：独自のUID/GID、メモリ、リクエスト、時間の厳しい制限、スローログの有効化。.
OPcache：十分なサイズ、高いヒット率、配備に適した再検証戦略。.
ストレージ：コード/キャッシュ用の高速パス、ディメンション・リアルパス・キャッシュ、NFSの特別な機能の観察。.
DB/Cache: pm.max_childrenと一致する接続とタイムアウト。.
キャッシュ・レイヤー：リバース・プロキシ、ページ・キャッシュ、アプリケーション・キャッシュを組み合わせる。.
観測可能性：P95/P99、キューの長さ、ワーカーの状態、OPcacheのヒット率、I/O、バックエンドのレイテンシが一目でわかる。.
ロールアウト：優雅リロード、ウォームアップ、アトミックデプロイメント、選択的キャッシュ無効化。.
キャパシティプランニング：リザーブのバースト、オーバーブッキングの禁止、LSAPIライセンスのコスト／利益の現実的な評価。.

簡単にまとめると、私の分類

混合ホスティング環境 ピーエッチピーエフピーエム は、パフォーマンス、分離、互換性の最適なバランスを実現します。LiteSpeedスタックでは、LSAPIはテールレイテンシとRAM消費量の点で測定可能な利点をもたらします。CGI はニッチなケースでは厳密な分離に適していますが、動的なプロジェクトでは遅れをとります。私は、プール制限を明確にし、OPcacheを有効化し、Webサーバーをクリーンな状態にしたFPMにまず頼っています。多くの競合が予想される場合は、LSAPI を LiteSpeed でテストしてから判断してください。 費用対効果-決断だ。.