Gunicorn: 同じgunicornインスタンスを介して多くのWSGIアプリを提供する方法。

作成日 2010年03月29日  ·  7コメント  ·  ソース: benoitc/gunicorn

同じgunicornインスタンスを介して多数のアプリケーションを実行し、それらが同じpythonインタープリターを使用するようにする方法があるとしたら、それは良い考えだと思いますか。
少なくとも私にとっては、これは非常に便利です。同じマシンで実行される小さなアプリケーション(負荷が非常に低い)が多数あるため、RAMを大量に節約できるからです。

Add Example

最も参考になるコメント

私はこれがコアに属していないことをjbergstroemに同意する必要があります。 しかし、私は先に進んで、ルートでこれを達成する方法を概説する例を追加しました:

http://github.com/benoitc/gunicorn/blob/master/examples/multiapp.py

全てのコメント7件

この種の動作は、エンドユーザーが最もよく解決できると思います。 従来のウェブサーバーと比較して、gunicornが「複数のサイト」で機能する方法には明確な違いがあります。
werkzeugなどの単純なPythonライブラリを使用して、2つのアプリが異なるルートで応答するようにすることをお勧めします。

私はこれがコアに属していないことをjbergstroemに同意する必要があります。 しかし、私は先に進んで、ルートでこれを達成する方法を概説する例を追加しました:

http://github.com/benoitc/gunicorn/blob/master/examples/multiapp.py

アプリごとに特定のマウントポイントを用意する代わりに、名前で仮想ホストを使用した例を作成することは可能でしょうか?

はい、それは完全に可能です。 environ ['HTTP_HOST']のアプリへの簡単なマッピングを書くことができます。

これはgunicornに組み込むことができると思いますが、どう思いますか?

これは、contribのもののように、gunicornのオプションの部分である可能性があります。

個別の構成を持つスタンドアロンのマルチプレクサアプリケーションとして最適だと思います。 Django / Pasteの専門分野もそこに行く必要があります。 このような:

$ gunicorn wsgi_multi django:project1 myblog.wsgi:wsgi_app anotherapp.foo

ここで、gunicornは1つのアプリケーションwsgi_multiのみを実行し、他の引数は特別なAPIを介して渡されます。 またはconfigまたは他の方法で。

私はこのチケットで提案されているようなものを書くことに多くの時間を費やしました。 まず、HTTP_HOSTに基づいてvirtualenvを切り替えるコードを試してみました。 純粋なPythonではvirtualenvsを実際に非アクティブ化できないことが判明したので、それは無駄でした。

それから私は考えました:多分それが単一のvirtualenvであるという要件を持つことができるので、私はHTTP_HOSTに基づいて異なるWSGIアプリに切り替えるコードを書きましたが、djangoは2つのdjangoアプリを並べて実行できないことを発見しましたどこにでもある本当に驚くべき数のグローバル変数。

つまり、基本的に、私が言っているのは、上記で提案したほど簡単ではなく、実現可能でもないということです。

おそらく、アプリに応じてワーカーが異なるvirtualenvで実行され、中央のgunicornマスターが、より多くのワーカーを必要とするアプリがそれらを確実に取得できるようにする、ある種の負荷分散を行う方が現実的ですか? おそらく書くのは簡単でも楽しいものでもありません:(

このようなことを可能にするために、djangoをクリーンアップしてほしいです...

このページは役に立ちましたか?
0 / 5 - 0 評価