CGI
CGI の正式名は「Common Gateway Interface」です。これは、HTTP サーバーが自分のマシンまたは他のマシン上のプログラムと「通信」するために使用するツールです。プログラムはネットワーク サーバー上で実行する必要があります。
CGI は、言語に標準入力、出力、および環境変数がある限り、どの言語でも作成できます。 php、perl、tclなど。
FastCGI
FastCGI は長寿命 CGI のようなもので、アクティブ化されている限り、毎回フォークする手間がかかりません (これは最も一般的な CGI です)。批判されている fork-and-execute パターン)。また、分散コンピューティングもサポートしています。つまり、FastCGI プログラムを Web サイト サーバー以外のホストで実行し、他の Web サイト サーバーからのリクエストを受け入れることができます。
FastCGI は、言語に依存しないスケーラブルなアーキテクチャの CGI オープン拡張機能であり、その主な動作は CGI インタープリター プロセスをメモリ内に保持し、より高いパフォーマンスを実現することです。ご存知のとおり、CGI インタープリタの繰り返しロードが CGI パフォーマンス低下の主な原因です。CGI インタープリタがメモリ内に残り、FastCGI プロセス マネージャーのスケジューリングを受け入れる場合、良好なパフォーマンス、スケーラビリティ、フェイルオーバー機能などが提供されます。
FastCGI の機能
FastCGI は言語に依存しません。
FastCGI は、コア Web サーバーから独立して実行されるインプロセス アプリケーションであり、API よりも安全な環境を提供します。 API はアプリケーションのコードをコア Web サーバーにリンクします。つまり、アプリケーションが間違った API を使用すると、他のアプリケーションやコア サーバーが破損する可能性があります。 悪意のある API アプリケーション コードは、別のアプリケーションやコア サーバーのキーを盗む可能性もあります。
FastCGI テクノロジーは現在、C/C++、Java、Perl、Tcl、Python、SmallTalk、Ruby などの言語をサポートしています。関連モジュールは、Apache、ISS、Lighttpd などの一般的なサーバーでも利用できます。
FastCGI は Web サーバーの内部アーキテクチャに依存しないため、サーバー テクノロジーが変わっても、FastCGI は安定したままになります。
FastCGI の仕組み
Web サーバーの起動時に、FastCGI プロセス マネージャー (IIS ISAPI または Apache モジュール) がロードされます
FastCGI プロセス マネージャーは、それ自体を初期化し、複数の CGI インタープリター プロセス (複数の php-cgi が表示されます) を開始します。そしてWebサーバーからの接続を待ちます。
クライアント リクエストが Web サーバーに到達すると、FastCGI プロセス マネージャーが CGI インタープリターを選択して接続します。 Web サーバーは、CGI 環境変数と標準入力を FastCGI サブプロセス php-cgi に送信します。
FastCGI サブプロセスは処理が完了すると、同じ接続から Web サーバーに標準出力とエラー情報を返します。 FastCGI 子プロセスが接続を閉じると、リクエストが処理されます。次に、FastCGI 子プロセスは、(Web サーバーで実行されている) FastCGI プロセス マネージャーからの次の接続を待機して処理します。 CGI モードでは、php-cgi はこの時点で終了します。
上記の場合、CGI が通常どれほど遅いか想像できるでしょう。 PHP へのすべての Web リクエストでは、php.ini を再解析し、すべての拡張機能を再ロードし、すべてのデータ構造を再初期化する必要があります。 FastCGI では、これらすべてがプロセスの開始時に 1 回だけ行われます。さらに、永続的なデータベース接続が機能するという利点もあります。
FastCGI の欠点
マルチプロセスであるため、CGI マルチスレッドよりも多くのサーバー メモリを消費します。PHP-CGI インタープリタは、この数値を 50 または 100 倍します。大量のメモリ。
Nginx 0.8.46+PHP 5.2.14 (FastCGI) サーバーには 30,000 の同時接続があり、開始された 10 個の Nginx プロセスは 150M のメモリ (15M*10=150M) を消費し、開始された 64 個の php-cgi プロセスは 1280M のメモリ (20M) を消費します。 *64=1280M)、システム自体が消費するメモリを加えた合計メモリ消費量は 2GB 未満です。サーバーのメモリが小さい場合は、25 個の php-cgi プロセスしか開くことができないため、php-cgi によって消費される合計メモリはわずか 500M になります。
上記のデータは、Apache (バージョン 6) よりも 10 倍優れた Web サーバーを構築するための Nginx 0.8.x + PHP 5.2.13 (FastCGI) から抜粋したものです
PHP-CGI
PHP-CGI はPHP 独自の FastCGI マネージャー。
PHP-CGI の欠点:
php-cgi は、php.ini 設定を変更した後、新しい php-ini を有効にするために php-cgi を再起動する必要があり、スムーズな再起動は不可能です。
php-cgi プロセスを直接強制終了すると、php は実行できなくなります。 (PHP-FPM と Spawn-FCGI にはこの問題はありません。デーモン プロセスは新しい子プロセスをスムーズに再生成します。)
PHP-FPM
PHP-FPM は PHP FastCGI マネージャーであり、PHP にのみ使用されます。 http://php-fpm.org/download からダウンロードできます。
PHP-FPM は実際には PHP ソース コードのパッチであり、FastCGI プロセス管理を PHP パッケージに統合することを目的としています。 PHP ソース コードにパッチを適用する必要があり、PHP をコンパイルしてインストールした後に使用できるようになります。
最新のPHP 5.3.2ソースツリーにPHP-FPMを直接統合するブランチがダウンロードできるようになりました。次のバージョンではPHPのメインブランチに統合される予定だそうです。 Spawn-FCGI と比較すると、PHP-FPM は CPU とメモリの制御が優れており、前者はクラッシュしやすく、crontab で監視する必要がありますが、PHP-FPM にはそのような問題はありません。
PHP5.3.3 には php-fpm が統合されており、サードパーティのパッケージではなくなりました。 PHP-FPM は、メモリとプロセスを効果的に制御し、PHP 設定をスムーズにリロードできる、より優れた PHP プロセス管理方法を提供します。そのため、spawn-fcgi よりも多くの利点があるため、PHP に正式に組み込まれています。 PHP-FPM は、./configure で –enable-fpm パラメーターを渡すことでオンにできます。
Spawn-FCGI
Spawn-FCGI は、Lighttpd の一部である一般的な FastCGI 管理サーバーですが、いくつかの欠点があります。 PHP-FPM の登場により、いくつかの問題は多少軽減されましたが、PHP-FPM には再コンパイルが必要になるという欠点があり、既に実行されている一部の環境ではかなりのリスクが生じる可能性があります (参照)。PHP 5.3.3 PHP で直接使用できます。 -FPM。
Spawn-FCGI は別個のプロジェクトになり、より安定し、多くの Web サイトの構成に利便性をもたらします。多くのサイトでは、動的 Web ページを解決するために nginx と組み合わせています。
最新の lighttpd にはこの部分 (http://www.lighttpd.net/search?q=Spawn-FCGI) は含まれていませんが、以前のバージョンには含まれています。これは、lighttpd-1.4.15 バージョン (http://www.lighttpd.net/download/lighttpd-1.4.15.tar.gz) に含まれています。Spawn-FCGI の現在のダウンロード アドレスは http://redmine です。 lighttpd .net/projects/spawn-fcgi、最新バージョンは http://www.lighttpd.net/download/spawn-fcgi-1.6.3.tar.gz です。
注: 最新の Spawn-FCGI については、lighttpd.net Web サイトで「Spawn-FCGI」を検索して、最新バージョンのリリース アドレスを見つけることができます。
PHP-FPMとspawn-CGIの比較
PHP-FPMは非常に使いやすく、設定はPHP-FPM.iniファイルにあり、php/sbin/PHPから起動と再起動が可能です。 -FPM が進行中です。さらに便利なのは、php.ini を変更した後、PHP-FPM のリロードを直接使用して、プロセスを停止せずに php.ini の変更とロードを完了できることです。 PHP のパフォーマンスを向上させます。 PHP-FPM によって制御されるプロセスの CPU リサイクル速度は比較的遅く、メモリは均等に割り当てられます。
Spawn-FCGI によって制御されるプロセスの CPU が急速に低下し、メモリ割り当てが不均一になります。未割り当てのように見えるプロセスが多数ありますが、占有率が高いプロセスもあります。プロセス タスクの不均等な分散が原因である可能性があります。これは全体的な応答速度の低下にもつながります。 PHP-FPM の適切な分散は、全体的な応答とタスクの平均につながります。