少し前、私が現在働いている会社で、サーバーアプリケーションの動作を最適化することが決定されました。 最初は、nginx + apache + mod_fastcgiまたはmod_fcgidバンドルで使用されていました。 ただし、nginx自体がFastCGIアプリケーションで動作できることを考えると、Apacheを削除したかったのです。
この問題を解決する過程で、FCGI :: ProcManagerモジュールから後続モジュールを作成しました。 負荷に応じてワークプロセスの数を制御し、ワークプロセスの寿命を特定の数の要求に制限する機能を追加しました。
FCGI :: ProcManagerの作成者を含め、後者の可能性は既に実装されていますが、プロセスの数を柔軟に制御することはできませんでした。 そのため、上記のモジュールに機能を追加することにしました。
FCGI :: ProcManager :: Dynamicモジュールは、FastCGIプロセスを管理するための説明された高度な機能を実装します。 ワークプロセスの数を監視するために、メインプロセスは共有メモリのメッセージチャネルを介した相互作用を使用します。
次の詳細オプションがサポートされています。
max_nproc-ワークプロセスの最大数。
min_nproc-ワークプロセスの最小数。
delta_proc-プロセスの総数を変更する場合の「ステップ」。
delta_time-プロセス数の最後の変更後の経過時間。その後、低負荷でワークプロセス数が減少します。 そのような減少は、全期間中にプロセス数が減少した後、新しいプロセス数を超えて同時に占有されなかった場合にのみ発生します。 これは、負荷変動のある高負荷アプリケーションのプロセス数の時期尚早な削減を回避するために必要です。
max_requests -1つのワークフローの最大リクエスト数。 超過すると、ワークフローは正しく終了し（下記を参照）、プロセスマネージャーが代わりに新しいワークフローを作成します。
ワークフローのリクエスト数の制限の導入に関連して、たとえばデータベース接続を閉じるなど、FastCGIアプリケーションのワークサイクルを正しく完了できるようにしたいと考えています。 このために、追加の関数pm_loopが作成されました。 これを使用する場合、FastCGIアプリケーションのワークサイクルの終了は通常の方法で実行され、このサイクルの背後にあるすべてのコードが実行されます。 使用例はドキュメントにあります：
$ proc_manager-> pm_manage（）;
while（$ proc_manager-> pm_loop（）&&（my $ cgi = CGI :: Fast-> new（）））{
$ proc_manager-> pm_pre_dispatch（）;
＃...ここでリクエストを処理します...
$ proc_manager-> pm_post_dispatch（）;
};
＃...これがすべての最終ステップです...
このモジュールは、約2週間にわたって実稼働サーバーで既に機能しています。 もちろん、この用語は短いですが、かなり大きな負荷と障害がないことを考えると、彼が対処している間に言えることです。
モジュールはCPANで利用可能です。 コメント、アドバイス、改善を歓迎します。
Kavkaz habrayuzerに感謝の意を表したいと思います。なぜなら、このモジュールを作成することを私に促したのは、大部分が彼の記事だったからです。