PHP-FPM PHPは、より良好なプロセス管理を提供する有効メモリを制御することができ、プロセスが円滑にPHPの設定をオーバーロードすることができます。だから我々は、PHP-FPMマルチプロセスモデルについて話すとき、PHPerとしてあなたはどのくらい知っていますか？
まず、一緒にいくつかの質問で見てみましょう：
①：いくつかがあるそのプロセスを開始するためのPHP-FPMの方法、違いは何ですか？
②：PHP-FPM、それを確認する方法、メインプロセスは、サブプロセスに要求を受信するか、サブプロセス要求を受信し、別々に処理されていますか？
③：PHP-FPMモードでは、なぜ、少数の人々は、接続プールを実行することをPHPのコード？
④：PHP-FPMモードのパフォーマンスがどのように最適化するには、どのような違いを反映していますか？
⑤：PHP-FPMモードでのYACとCLIモードなぜ私は共有メモリできないことはできませんか？
プロセスを起動する方法1.
PHP-FPMは、マルチプロセス・モデル、マスターワーカー管理プロセスによって処理です。プロセスの数、具体的な構成は、PHP-fpm.confを介して行うことができます。PHP-FPMプロセスは動的モードと静的モードに分けることができます。
①：スタティック（静的）
直接、PHP-FPMプロセスの指定された数を開く増減はない。プロセスの固定数を開始し、高いメモリを取ります。ただし、ユーザーがシステムリソースのLinuxオペレーティングシステムプロセスの治療の揮発性、低コストを要求したとき。
②：ダイナミック（動的）
、初めにPHP-FPMプロセスの特定の数を開く要求が大きくなると、動的増加PHP-FPMはプロセスの数を制限するために、自由な時間が自動的に解除されたときに下限アイドルプロセスの数。
MAX、MIN、アイドル子ども構成、動的な調整プロセスの数に基づいて、ダイナミックモード。ダイナミックモードは変動によるなど、破壊、作成するために、多数のプロセスで動作しますときに、ユーザーの要求がより揮発性、またはインスタント要求負荷の増加にLinuxを増加させました。簡単に言えば、PHP-FPMプロセス大小要求の数、プロセスがより多くの、より少ない要求します。利点は、ときに、要求の少ない、少数の、小さなメモリフットプリントを処理することです。
③：デマンド（オンデマンド）
このモードでは、マスターのPHP-FPMフォークが子を処理しません、純粋なオンデマンドで開始することです。
それは単にオンラインビジネスの特定の順序に適応できないため、このモードでは、多くの場合、ほとんど使用されません。コネクタショートPHP-FPMので、そう接続を確立する各要求、接続確立工程は、必然的に図3のプロセスをトリガします。だから、大流量システムでマスター・プロセスは、大量のデプロイメント環境に適していないシステムのCPUリソースによって占められ、忙しくなります。
説明するためにネットワークの写真を借り：
注2ポイントを、「接続」と、すぐに「データ」。プロセスを接続し、再び来るフォーク、子プロセスの継承も、その後、子プロセスのユーザーは、この目的を要求し、親コンテキストを達成することができます。
（動的および静的プロセスモデルに関連するパラメータは、公式のPHPのマニュアルを参照してください。）
私たちの関心は、私たち自身のビジネスのために、あなたはPHP-FPMモードが動的または静的で選ぶべきです。
典型的には、比較的大きなメモリサーバに対して、効率を改善する静的ワードに設定されます。効果は、ケースを開くには、スタティックメモリに十分な大きさの下で良くなるので、頻繁な切り替えのphp-FPMプロセスなので、タイムラグがあるでしょう。数は、メモリ/ 30Mに基づいて得ることができます。例えば、サーバ2GBのメモリは、50に設定することができ、4GBのメモリ100等が設けられていてもよいです。機械による高は、静的、動的に選択された低配布マシン（県メモリ）を選択し、マシンは高いダイナミック装備されている私たちはタイムリーな瞬間的な高並行処理に対応できない、メモリやCPUリソースをフルに活用することができません。
2.どのように認証要求処理と
PHP-FPMプロセス管理、プロセス管理nginxのは、幾分類似しています。リクエストを扱うには、子の後にメインプロセスによって転送された要求を受け入れますが、「先制」子プロセスは、ユーザーの要求を受け入れません。後、基本的にPHP-FPM nginxのマルチプロセスとマルチプロセスは、目的に同じポートを監視し、複数のプロセスを達成するために、プロセスの主要港、フォークの子プロセスと聞いています。
Linuxシステムでは、すべてのIO操作を処理し、オペレーティングシステムが対処する必要があります。言い換えれば、システムは、すべてのIO操作を知っています。このプロセスは、私たちはしばしば言うことである「システムコールを。」私たちは、システムコールからこの問題を解決するために開始することができます。Viewシステムコールは、straceのを使用することができます。
比較的簡単に確認するために、どのように、我々は、2つの方法を取ることができます。
- ルックログPHP-FPMプロセス。このニーズは、適切なPHP-FPMログ形式を設定します。
- IOデータは、カーネルモードプロセスを介してユーザモードに移行しますので、我々はシステムコールをトレースする-pコマンドをstraceのことができます。PHP-FPM IDと子プロセスIDの主要なプロセスを追跡し、その後、nginxの訪問、nginxのは、高速CGIプロトコルによってPHP-FPMプロセスに行く、でプロセス呼び出しシステムを参照してくださいするために送信。
3.なぜPHP-FPM接続プールの下でコードをしませんか？
まず、PHP-FPMモードでは、要求のライフサイクルは一度だけ運命。換言すれば、リソースのZendの仮想マシンFPMの割り当てを実行するためのFPM要求、解析PHPスクリプトからの要求は、プロセスの最後の最後まで、PHP-FPMは、この要求のすべてのリソースを回復します。
あなたはネットワーク、ファイルディスクリプタがクローズされてどれだけ近いかを気にし、そうでない場合がありますので、開発者は、資源のリサイクルを気にする必要はありませんできるようにするこのような方法の1つ。第二に、メモリオーバーフローを軽減するためです。
このモードでは、接続プールを実現した場合、またリクエストの終わりを意味し、接続プールは無駄な努力を行うには、姿を消しました。
"無味" PConnect（永続リンク）。永続的リンクは、リンクが解除されていないです。しかし、問題はPHP-FPMは、マルチプロセス・モデルであり、永続的なリンクがプロセスに存在する、あります。これは、300のFPMプロセス、1回限りの初期化300個の永続的なリンクを持つマシンの場合。マシンの拡張のために要求する事業活動の向こう見ずに直面した場合、直接再生データベース接続事業の数を引き起こす可能性があるため。
4.パフォーマンスを最適化する方法
まず第一に、私たちはなぜ可能性、パフォーマンスの低下につながったかについて考える必要があります。アプリケーションパフォーマンスの場合は、我々は二つの側面から分析する傾向があり、一つは、IO性能であるコンピューティングパフォーマンスです。
IOの局面では、接続プールを作成することは困難でPHP-FPMモデルでは、非常に高い同時サービスで処理する欠点のネットワークが存在しますので。私はここで言っていることを注意CLIモードでPHP-FPMモードであるか、独自の接続プールを行うことができます。しかし、これは、単一の接続プールCLIプロセスモードに限定されており、このモードは、（例えばHTTPリクエストなど）プロセスネットワーク要求に使用することはできません。PHPのデフォルトのシングルプロセスモード、FPMので、CLIはCLIは、接続プールを作ることができ、容易に（ハートビートを同時に行うことはできません）キープアライブリンクしていない場合でも、デフォルトのシングルプロセスです。
簡単な理論計算のパフォーマンスが良好であればPHPは、Cで書かれているが、パフォーマンスを計算することに。しかし、問題は、PHPが要求を処理することで、毎回のPHPスクリプトを解析し、PHPコードはZendの仮想マシンの実行オペコード、プロセスの終わりに、オペコードに翻訳され、リソースを解放します。このプロセスを通じてPHPを計算パフォーマンスの低下の最大の原因の一つです。
どのように最適化するには：
- パフォーマンスの計算、延長ZendのOPcache、バイトコードキャッシュを使用する場合。
- ** ** IO性能は、ファイルキャッシュの使用はmemcachedのか、キャッシュのネットワークへの圧力を軽減するために、キャッシュ層のYACの緩和圧力を使用し、同じ要求では、多重リンクは常に新しいを使用していない。合理的な設計コンポーネントライブラリをログに記録する、最適化されたロガーはIOの圧力を減らすために、ファイル操作の数を減らします。
資格の設計ロガーコンポーネントについて、我々はいくつかの点に注意を払う必要があります：
①各要求を、一つだけのログの書き込みではなく、毎回誰かがあなたの関数を呼び出すには、同様のますfile_put_contents操作を実行する必要があります。
②同様のエラーの様々な互換性。でも、PHPの致命的なエラー言い換えれば、あなたは、よく知られているエラーの前に記録ログインできるようにする必要があります。実装は、PHPクラスのデストラクタによって行うことができます。また、最終的な伐採事業を完了するために、PHP要求コールバックフックの最後にフックを登録するには、より良いregister_shutdown_functionを使用することができます。
5. YACなぜ、メモリとCLIモードを共有することはできません
私たちは知っている、プライムマクロ実行中のPHP拡張モジュールの開発はPHP_MINIT_FUNCTIONです。共有メモリからYAC拡張ニーズを共有使用する各プロセスに対して、PHP-FPMプロセスが開始初期化されます。したがって、必要性の重要な嘘は、各プロセスの同じIDが知っているように共有しました。
YACは、初期化プロセスを拡張：
私たちは具体的な実現のcreate_segmentsを参照してください。
いくつかのコメントをした上で、最も重要なは、共有メモリシステムのID、shared_segment_nameを開く必要があり、この値は、プロセスIDが含まれています。PHP-FPMは、メインプロセスIDです。同じ共有メモリ識別子のIDを持っている、それはすべてのプロセスが謎の嘘を伝えることができますPHP-FPMモードの間です。我々はPHPスクリプトによって拡張共有メモリ使用量のYACを読みたい場合や、実行します。
CLIモードでは、PHP-FPMモードでの共有メモリのデータセットを取得することは不可能ですので。以来、PHP-FPMモードIDの下でPHPスクリプトCLIモード、プロセスID、プロセスの実装は完全に異なっています。
今後の記事、我々はプロセス間通信と共有メモリベースの通信について話をする機会を探します。結論として、共有メモリ通信に複数のプロセスは、我々はユニークなIDを調整するために開始する必要があります。複数のプロセス間でIDを知っている必要があります。PHP-FPMが子供アウトマルチプロセス、メインプロセスのフォークです（Linuxのスタックメモリプロセスのフォークがすべてやり直す全体のプロセスをforkしますので）、子供はユニークなIDが何であるかを知っているだろう。しかし、この実行a.php PHPは、実際には、完全に独立したプロセスであり、そしてPHP-FPMは、このプロセスを任意の関係を持っていなかった、それはユニークなIDはいにあったものをPHP-FPMプロセスを知ることができません。
