nginx の背後にある Gunicorn をリバース プロキシとして使用して、Django ベースの Web サービスを実行しています。
私の Web サービスは、MATLAB の外部インスタンスを使用して計算を実行する Django ビューを提供します。MATLAB の起動には数秒かかるため、非常に単純な MATLAB 計算のみが発生する要求であっても、応答するのにこの時間を必要とします。
さらに、私のコードでは MATLAB サンドボックス化が行われているため、Web サーバー プロセスに対して同時に実行される MATLAB インスタンスは 1 つだけであることが重要です。(したがって、現在、分岐前の Web サーバーを実装するが、マルチスレッドを使用しない Gunicorn 同期ワーカー モデルを使用しています。)
ユーザー エクスペリエンスを向上させるために、いくつか (たとえば 3 ～ 5 個) の "準備ができている" MATLAB インスタンスを実行し続け、要求が受信されたときにそれらを使用することで、MATLAB 起動の待ち時間をなくしたいと考えています。要求が処理された後、MATLAB プロセスは終了し、新しいリクエストがすぐに開始され、別のリクエストに備えることができます。
私はこれを行うための2つの方法を評価してきました:
Gunicorn 同期ワーカー モデルを引き続き使用し、Web サーバー プロセスごとに 1 つの MATLAB インスタンスを保持します。
これに関する問題は、着信要求が Web サーバーのワーカー プロセスにラウンド ロビン方式で分散されないことです。したがって、計算集約型のすべての要求が同じプロセスにヒットし、その単一の MATLAB インスタンスを必要な速度で再起動できないため、ユーザーは依然として待機する必要がある場合があります。
MATLAB の計算をバックエンド サーバーに外注します。バックエンド サーバーは実際の作業を行い、RPC を介して Web サーバー プロセスによって照会されます。
私の考えでは、多数の RPC サーバー プロセスが実行されており、それぞれが実行中の MATLAB プロセスをホストしています。要求が処理された後、MATLAB プロセスが再起動されます。RPC サーバー プロセスはラウンド ロビンでクエリされるため、ユーザーは MATLAB の開始を待つ必要はありません (全体的に要求が多すぎる場合を除きますが、それは避けられません)。
最初のアプローチで説明した問題のため、RPC サーバー (アプローチ 2) が私の問題に対するより良い解決策になると思います。
Python 用の RPC ソリューション (特に Pyro と RPyC) をいくつか調べましたが、RPC サーバーにフォーク前のサーバー モデルを使用する実装を見つけることができません。サンドボックスがあるため、マルチスレッド化は不可能であり、接続が受け入れられた後にのみサーバーが分岐する場合は、その後も MATLAB を起動する必要があり、アイデア全体が妨げられることを覚えておいてください。
私の問題に対するより良い解決策を知っている人はいますか? それとも、RPC サーバーが実際に最適なソリューションでしょうか? しかし、その場合、事前にフォークする RPC サーバー (= いくつかのプロセスをフォークし、それらすべてを同じソケットの accept() でスピンさせる) か、少なくとも事前に簡単に変更できる (モンキーパッチ?) RPC フレームワークが必要になります。 -フォーク。
前もって感謝します。