空間画像データのタイル サーバーと同様に、Django ベースの Web アプリケーションでオンザフライで生成された多くの画像を表示したいと考えています (画像のマージ、色の変更など)。1 つのクライアントが短時間で多数 (>100) のイメージを簡単に要求できるため、Web サーバー (Apache + mod_wsgi) を簡単にダウンさせることができます。
したがって、私は別の方法を探しています。既に Celery を使用しているため、この画像処理を非同期で行い、生成されたデータをクライアントにプッシュすることをお勧めします。それを始めるために、WSGIサーバーをgeventに切り替え、Apacheをプロキシとして使用しました。ただし、まだプッシュ機能を動作させることができておらず、とにかくこれが正しい方向であるかどうかはよくわかりません。それに基づいて、私は3つの質問があります：
これ (Celery、gevent、Socket.IO) は、多くのクライアントが Web サーバーをダウンさせることなくアプリケーションを使用できるようにする賢明な方法だと思いますか? 代替案はありますか？
画像処理をCeleryに任せて、終わったら画像データをブラウザにプッシュさせたら、Apache経由で接続されませんよね？
クライアントへの何らかのプッシュが使用されている場合、1 つの接続を使用するか、イメージごとに 1 つの接続を使用する方がよいでしょうか (完了したら閉じます)。
バックグラウンド：
私が取り組んでいる Django アプリケーションでは、ユーザーは非常に大きな画像を表示できます。これは、前に大きな画像を並べて表示し、現在関連するタイルのみをグリッドでユーザーに表示することによって行われます。私が理解していることから、これはマッピングおよび空間画像データ (OpenStreetMap など) の分野でデータを提供する標準的な方法です。しかし、マッピング データとは異なり、Z にはユーザーがスクロールできる多くのスライス (生物学的画像) もあります。
タイルが静的に提供される場合、これはすべて正常に機能します。これらのタイルをオンザフライで生成するオプションを追加しました。さまざまな画像がマージされ、色が修正されます。これは機能しますが、1 つの画像が生成されるのに約 0.1 秒かかるため、Web サーバーの負荷が高くなります。現在、Apache と mod_wsgi (WSGIRestrictedEmbedded On) を使用しており、サーバーを簡単にダウンさせることができます。画像スタックを参照するだけで、Web サーバーがハングアップします。すでに MaxClients などを調整しようとして、KeepAlive をオフにしました。また、mod_wsgi のさまざまなスレッド/プロセスの組み合わせも試しました。ただし、複数のユーザーが使用できるようにするのに十分なものはありませんでした。したがって、Comet/WebSocket の方法がここで役立つと考えました。