PHP FastCGI プロセス マネージャーのアーキテクチャ PHP-FPM

マスター プロセスは複数のプールをサポートし、各プールは異なるポート上のマスター プロセスによって監視されます。
各ワーカー プロセスには組み込みの PHP インタープリターがあり、プロセスはバックグラウンドでの Prefork のサポートが動的に追加されます。
各ワーカー プロセスは、実行時のスクリプトのコンパイルと、生成されたオペコードのメモリへのキャッシュをサポートし、指定された数のリクエストに応答した後の自動再起動の構成をサポートします。マスタープロセスは、ハングしたワーカープロセスを再起動します。
各ワーカープロセスは、MySQL/Memcached/Redis への永続的な接続を維持して、繰り返しの接続確立を回避し、プログラムに対して透過的です。データベース永続接続の場合は、ワーカー プロセスの固定数を設定し、動的プリフォーク モードを使用しないでください。マスター プロセスは、epoll モデルを使用してリクエストを非同期に受信および配布し、リスニング ポートをリッスンし、epoll_wait を使用して待機します。
接続を取得し、対応するプール内のワーカー プロセスに分散します。ワーカー プロセスは、accpet リクエスト後に接続を処理するためにポーリングします。
ワーカー プロセスが十分でない場合、マスター プロセスはさらにプロセスをプリフォークします。
prefork が pm.max_children の上限に達すると、ワーカー プロセスは再びビジー状態になります
この時点で、マスター プロセスは接続キュー バックログでリクエストを一時停止します (デフォルト値は 511)。 1 つの PHP-FPM ワーカー プロセスは同時に 1 つのリクエストのみを処理できます。
MySQL の最大接続数 max_connections はデフォルトで 151 です。
PHP-FPM 作業プロセスの数が 151 を超えない限り。 MySQL への接続に問題はありません
また、通常の状況では、それほど多くの PHP-FPM 作業プロセスを開く必要はありません
たとえば、4 つの PHP-FPM プロセスは最大 4 つのコアを実行できます。
その場合、40 個の PHP-FPM プロセスを開いたとしても意味がありません
より多くのメモリを消費し、CPU コンテキストの切り替えによりパフォーマンスが低下するだけです。リクエストごとに接続の確立と解放を繰り返すオーバーヘッドを減らすために、永続的な接続を有効にすることができます
PHP-FPM プロセスは MySQL への長い接続を維持し、「接続プール」を分離します。 PHP-FPM は実際には非常に優れた分離です。PHP-FPM は特に 1 つの PHP リクエストに対応します。ページ内の静的リソースに対するリクエストはすべて Nginx によって処理されます。動的と静的の分離であり、Nginx が最も優れているのは、高い同時実行性の処理です。
PHP-FPM は、Apache のプリフォーク プロセス モデルに似たマルチプロセス FastCGI サービスです。
PHP リクエストの場合、これは処理専用です。モデルは非常に効率的で安定しています
Apache (libphp.so) とは異なり、1 つのページで画像、スタイルシート、JS スクリプト、PHP スクリプトなどを含む複数のリクエストを処理する必要があります。
php-fpm はPHP ソース コード トランクは 5.3 からあり、以前のバージョンには php-fpm はありませんでした
当時の spawn-fcgi は、php-cgi を呼び出す必要がある FastCGI プロセス マネージャーでした
さらに、Apache と同様です。 mod_fcgid と IIS の PHP マネージャーも php-cgi プロセスを呼び出す必要があります
しかし、php-fpm は php-cgi にまったく依存せず、完全に独立して実行され、php (cli) コマンドライン インタプリタに依存しません。
php-fpmはphpインタープリタが組み込まれたFastCGIサービスなので、起動時にphp.ini設定とphp-fpm.conf設定を単独で読み込むことができます
PHP-FPM の動作プロセスは CPU の 2 倍に設定する必要があります
結局のところ、Nginx、MySQL とシステムも CPU を消費します
PHP-の数を設定するのは非常に無理があります。サーバーのメモリに応じて FPM プロセスが実行されます。
MySQL、Memcached、Redis、Linux ディスク キャッシュ (バッファ/キャッシュ) サービスにメモリを割り当てる方が適切です。
過剰な PHP-FPM プロセスは CPU コンテキスト スイッチングのコストを増加させます。
ネットワーク I/O に時間がかかるコードを引き起こす可能性のある、PHP コードでは、curl または file_get_contents を使用しないようにしてください。
プロセスが長時間ブロックされるのを避けるために、CURLOPT_CONNECTTIMEOUT_MS タイムアウトの設定に注意してください。
長時間のタスクを非同期で実行したい場合は、 pclose(popen('/path/ to/task.php &', 'r')); 処理のためにプロセスを開くか、
を使用します。つまり、PHP-FPM ワーカー プロセスをブロックしないようにします。
php-fpm.conf で request_slowlog_timeout を 1 秒に設定し、1 秒以上かかるコードがあるかどうかを確認します。 コードを最適化すると、すべての PHP-FPM ワークプロセスの負荷を軽減できます。これは、CPU を最大負荷で実行できるようにする操作
です。 アップロードとダウンロードは、主にネットワーク I/O とディスク I/O で時間がかかるため、典型的な I/O 集中型の操作です。
PHP 認証を必要とするダウンロード操作は、Nginx の AIO スレッド プールに委任できます。
header("X-Accel-Redirect: $file_path");アップロード操作に関しては、たとえば、ポート 9001 をリッスンする、upload という名前の PHP-FPM プロセス プール (プール) を確立できます。
は、アップロード操作 (Nginx を通じて分散) の処理を​​特に担当し、アップロード操作を回避します。ポート 9000 をリッスンする計算をブロックします。高密度の www プロセス プール
現時点では、アップロード プロセス プールでさらにプロセスを開いても問題ありません:
[www]
listen = 127.0。 0.1:9000
pm = 静的
pm.max_children = 4
[アップロード]
listen = 127.0.0.1:9001
pm = 動的
pm.max_children = 8
pm.start_servers = 4
pm .min_spare_servers = 4
pm.max_spare_servers = 4
PHP-FPM によって提供されるプールの分離を使用して、コンピューティング集中型の操作と I/O 集中型の操作を分離します。 PHP アプリケーション全体に対するブロックの影響を軽減します

元々はオープンソースの中国のブログ eechen によって書かれた記事です。

上記では、PHP FastCGI プロセス マネージャー PHP-FPM のアーキテクチャをその側面も含めて紹介しましたが、PHP チュートリアルに興味のある友人に役立つことを願っています。