5 つの主要な PHP 動作モード-PHPチュートリアル-php.cn

PHP の 5 つの一般的な動作モードは、CGI (Common Gateway Interface)、FastCGI (Resident CGI/Long-Live CGI)、 CLI (Command Line) Interface)、Web モジュールモード (モード) です。 Apache などの Web サーバーが動作する)、 ISAPI (Internet Server Application Program Interface)、この記事が皆様のお役に立てれば幸いです。

注: PHP5.3 以降、PHP には ISAPI モードがなくなり、インストール後に php5isapi.dll ファイルは存在しません。 IIS6 で上位バージョンの PHP を使用するには、FastCGI 拡張機能をインストールし、IIS6 が FastCGI をサポートできるようにする必要があります。

1.1、CGIモード

CGIはCommon Gateway Interface（共通ゲートウェイインターフェース）です。平たく言えば、CGIはWeb上のWebページと実行プログラムをつなぐ橋のようなものです。サーバーにアクセスすると、HTML で受け取った命令をサーバーの実行プログラムに渡し、サーバーの実行プログラムの結果を HTML ページに返します。 CGI は優れたクロスプラットフォームパフォーマンスを備えており、ほぼすべてのオペレーティングシステムに実装できます。 CGI はすでに古いモデルであり、近年ではほとんど使用されていません。

ユーザーリクエストがあるたびに、最初に CGI サブプロセスが作成され、次にリクエストが処理され、処理後にサブプロセスが終了します。これが Fork-And-Execute モードです。ユーザーリクエストの数が非常に多い場合、メモリやCPU時間などのシステムリソースが大量に占有され、パフォーマンスが低下します。したがって、CGI を使用するサーバーには、接続要求と同じ数の CGI サブプロセスが存在することになり、サブプロセスの繰り返しロードが CGI パフォーマンスを低下させる主な原因となります。

PHP をサーバー側ソフトウェア (Apache など) に埋め込んでモジュールとしてインストールしたくない場合は、CGI モードでインストールすることを選択できます。または、PHP とさまざまな CGI ラッパーを使用して、コード用に安全な chroot および setuid 環境を作成します。このようにして、各クライアントは PHP ファイルを要求し、Web サーバーは php.exe (Win では php.exe、Linux では php) を呼び出してファイルを解釈し、解釈結果を次の形式でクライアントに返します。ウェブページ。このインストール方法では通常、PHP 実行可能ファイルが Web サーバーの cgi-bin ディレクトリにインストールされます。 CERT 勧告 CA-96.11 では、cgi-bin ディレクトリにインタプリタを配置しないことが推奨されています。この方法の利点は、Web サーバーを特定のプログラムの処理から分離し、構造が明確で制御性が高いことですが、同時に、アクセス需要が高い場合、CGI プロセスの Fork が巨大なサーバーになってしまうことが欠点です。負荷がかかるのは、何百もの同時リクエストによりサーバーが何百ものプロセスをフォークすることを想像してみれば理解できるでしょう。これが、CGI が常にパフォーマンスが低く、リソース消費量が多いことで悪名が高い理由です。

1.2、FastCGIモード

FastCGIはCGIのアップグレード版のようなもので、有効化されている限り常に実行できます。時間をかけてフォークを 1 回実行します (これは CGI で最も批判されているフォークして実行するモードです)。

FastCGI は、HTTP サーバーと動的スクリプト言語間の通信のためのスケーラブルな高速インターフェイスです。 Apache、Nginx、lighttpd などのほとんどの一般的な HTTP サーバーは FastCGI をサポートしています。同時に、FastCGI は PHP などの多くのスクリプト言語でもサポートされています。

FastCGI インターフェイスモードは C/S 構造を採用しており、HTTP サーバーとスクリプト解析サーバーを分離し、スクリプト解析サーバー上で 1 つ以上のスクリプト解析デーモンを起動できます。 HTTP サーバーが動的プログラムに遭遇するたびに、そのプログラムは実行のために FastCGI プロセスに直接配信され、その結果がブラウザーに返されます。この方法により、HTTP サーバーは静的リクエストを排他的に処理したり、動的スクリプトサーバーの結果をクライアントに返すことができるため、アプリケーションシステム全体のパフォーマンスが大幅に向上します。

[原則]

1) Web サーバーの起動時に FastCGI プロセスマネージャー (IIS ISAPI または Apache モジュール) をロードします。

2) FastCGI プロセスマネージャーは自身を初期化し、複数の CGI インタープリタープロセス (複数の php が表示されます) を開始します。 cgi.exe または php-cig) を実行し、Web サーバーからの接続を待ちます。

3) クライアント要求が Web サーバーに到達すると、FastCGI プロセスマネージャーが CGI インタープリターを選択して接続します。 Web サーバーは CGI 環境変数と標準入力を FastCGI サブプロセス php-cgi に送信します

4) FastCGI サブプロセスが処理を完了すると、同じ接続から標準出力とエラー情報を Web サーバーに返します。。 FastCGI 子プロセスが接続を閉じると、リクエストが処理されます。次に、FastCGI 子プロセスは、FastCGI プロセスマネージャー (WebServer で実行されている) からの次の接続を待機して処理します。通常の CGI モードでは、php-cgi.exe はここで終了します。

CGI モードでは、CGI が通常どれほど遅いか想像できるでしょう。 PHP へのすべての Web リクエストでは、php.ini を再解析し、すべての DLL 拡張機能を再ロードし、すべてのデータ構造を再初期化する必要があります。 FastCGI では、これらすべてがプロセスの開始時に 1 回だけ行われます。さらに、永続的なデータベース接続が機能するという利点もあります。

注: PHP の FastCGI プロセスマネージャーは PHP-FPM (PHP-FastCGI Process Manager) です

[利点]

1) 安定性の観点から、FastCGI はプロセスが停止した場合に独立したプロセスプールで CGI を実行します。システムはそれを簡単に破棄し、ロジックを実行するための新しいプロセスを再割り当てできます。2) セキュリティの観点から、FastCGI は分散コンピューティングをサポートします。 FastCGI はホストサーバーから完全に独立しています。FastCGI がどのようにダウンしても、サーバーはダウンしません。

3) パフォーマンスの観点から、FastCGI は動的ロジックの処理をサーバーから分離します。 IO 処理は引き続きホストサーバーに任せられるため、通常の動的 Web ページでは、論理的な処理はごく一部であり、大量の静的画像などを処理することができます。。

【デメリット】

メリットを話した後は、デメリットについても話しましょう。実際に使用したところ、FastCGI モードは実稼働環境のサーバーに適しています。ただし、開発マシンには適していません。 Zend Studio を使用してプログラムをデバッグすると、FastCGI は PHP プロセスがタイムアウトしたと判断し、ページ上で 500 エラーを返すためです。これは非常に面倒だったので、開発マシンで ISAPI モードに戻しました。一部のサーバーの新しいバージョンのサポートは良好ではないため、分散負荷分散を必要としないモジュール式インストールの方が良い選択です。 FastCGI とサーバー間の現在の通信は十分にスマートではなく、FastCGI プロセスの実行に時間がかかりすぎると、プロセスが強制終了され、停止したプロセスとして再起動されます。これにより、FastCGI が実行できなくなります。オンラインデバッグを可能にします。マルチプロセスであるため、PHP-CGI インタプリタはプロセスごとに 7 ～ 25 メガバイトのメモリを消費します。この数値を 50 または 100 倍にすると、大量のメモリが消費されます。

1.3 CLIモード

PHP-CLIはPHP Command Line Interfaceの略称で、その名のとおりコマンドライン上で動作するPHPのためのインターフェースであり、上で動作するPHP環境とは異なります。 Web サーバー (PHP-CGI、ISAPI など)。つまり、PHP はフロントエンドの Web ページを作成できるだけでなく、バックエンドプログラムの作成にも使用できます。 PHP CLI シェルスクリプトは PHP のすべての利点に適用され、サーバー側スクリプトまたはシステム、さらには GUI アプリケーションの作成を Windows および Linux でサポートします。

[利点]

1) 複数のプロセスを使用すると、子プロセスが終了した後、カーネルがリソースをリサイクルする責任があります。

2) 複数のプロセスを使用すると、子プロセスの異常終了によってプロセス全体のスレッドが停止することはありません。終了すると、親プロセスは再構築する機会を得ることができます。プロセス

タスクの分散のみを担当する常駐メインプロセスであり、ロジックはより明確です

;

3) スケジュールされたタスクを実装でき、Linux 上で PHP を使用してシェルスクリプトを作成できます。

Linux では、PHP がどの拡張機能をインストールしているかを調べるために「php -m」をよく使用します。これは PHP コマンドラインの実行モードであり、興味のある学生は「php -h」を入力して実行モードを詳しく調べることができます。

1.4 モジュールモード

モジュールモードは、mod_php5 モジュールの形式で統合されています。現時点で、mod_php5 モジュールの機能は、Apache によって渡された PHP ファイルリクエストを受信し、これらのリクエストを処理して、処理結果を Apache に送信します。 Apache が起動する前に設定ファイルで PHP モジュール

(mod_php5) を設定すると、PHP モジュールは apache2 の ap_hook_post_config フックを登録し、Apache が PHP ファイルに対するリクエストの受け入れを開始したときにこのモジュールを起動します。

この起動時のロード方法に加えて、Apache のモジュールは実行時に動的にロードすることができます。つまり、ソースコードを再コンパイルしたり、サーバーをまったく停止したりすることなく、サーバーの機能を拡張できます。必要なのは、シグナル HUP または AP_SIG_GRACEFUL をサーバーに送信して、モジュールをリロードするようにサーバーに通知することだけです。ただし、動的にロードする前に、モジュールをダイナミックリンクライブラリにコンパイルする必要があります。このときのダイナミックロードとは、ダイナミックリンクライブラリをロードすることです。 Apache のダイナミックリンクライブラリの処理は mod_so モジュールによって完了するため、mod_so モジュールは動的にロードできず、Apache のコアに静的にコンパイルすることしかできません。これは、Apache とともに起動されることを意味します。

Apache はどのようにモジュールをロードしますか?例として、前述の mod_php5 モジュールを見てみましょう。まず、Apache の設定ファイル httpd.conf に次の行を追加する必要があります。

LoadModule php5_module modules/mod_php5.so

ここでは、LoadModule コマンドを使用します。名前は、モジュールの名前です。ソースコード内のモジュールに実装されます。 2 番目のオプションは、モジュールが配置されているパスです。サーバーの実行中にモジュールをロードする必要がある場合は、シグナル HUP または AP_SIG_GRACEFUL をサーバーに送信できます。シグナルが受信されると、Apache はサーバーを再起動せずにモジュールを再ロードします。

この動作モードは、Windows 環境で Apache サーバーを使用するときによく使用されるモードであり、モジュール化 (DLL) では、Web サーバーと一緒に PHP が起動して実行されます。 (Apache を CGI ベースに拡張し、PHP の動作効率を向上させたものです)。

1.5 ISAPI モード

ISAPI (Internet Server Application Program Interface) は、Microsoft が提供するインターネットサービス用の API インターフェイスのセットであり、ISAPI DLL はユーザーの要求によってアクティブ化された後、メモリ内に常駐して、 user 別のリクエストについては、1 つの DLL 内に複数のユーザーリクエスト処理関数を設定することもできます。また、ISAPI DLL アプリケーションと WWW サーバーが同じプロセス内にあるため、CGI に比べて効率が大幅に高くなります。 (Microsoft の独占権により、Windows 環境でのみ実行できます)

Apache モジュールとして、PHP はシステムの起動後に複数のプロセスのコピーを事前に生成し、メモリ内に常駐させます。子プロセスは処理に使用されるため、子プロセスの生成による遅延は発生しません。これらのサーバーコピーは、HTTP 要求の処理後すぐには終了せず、次の要求を待ってコンピューター内に留まります。クライアントのブラウザ要求に対する応答が速くなり、パフォーマンスが向上します。