apache2.2のデーモンモードでmod_wsgiを使用してDjangoをデプロイしました。それで、Djangoがコンテンツを解約した後、最適化された栄光で提供するためにそこからapacheにすべてを渡しますか、それともDjangoはこの提供ステップでまだ何らかの形で課税されていますか?
2 に答える
FWIW、mod_wsgi 1.Xでは、Apacheが出力バッファリングを実行できるようにすることはデフォルトでオフでした。これは、WSGI仕様が、基盤となるWebサーバーによる出力バッファリングを効果的に禁止しているためです。これは、WSGI仕様では、反復可能/ジェネレーターから返される各文字列の後にデータをブラウザーにフラッシュバックする必要があるためです。
言い換えれば、出力バッファリングを有効にすることはオプションであり、何よりも実験的でした。これは、WSGIで禁止されており、特定のApacheバージョンで誤った動作を回避するための回避策を実装する必要がある場合にmod_wsgiコードが実際に複雑になったために削除されました。
WSGIインターフェイスは(http://www.python.org/dev/peps/pep-0333/)、WSGIアプリケーション(この場合はDjango)が呼び出され、コンテンツを返す必要があることを示しています。
Djangoがビュー関数を呼び出しました。ビュー関数がレンダリングされたテンプレートを返しました。Djangoはテンプレートのレンダリング結果を返しました。そして、あなたに代わって、start_response
callableを呼び出しました。
別のステップに逆戻りして、Apacheはmod_wsgiを呼び出しました。start_response
mod_wsgi(WSGIルールに従う)は環境を作成し、 Djangoが使用できる呼び出し可能オブジェクトとともにこれをDjangoに渡しました。
Djangoが呼び出したときstart_response
、mod_wsgiはその応答を収集し、それを使って何かをする義務がありました。それをApacheに渡して、ブラウザーにフィードダウンします。
Djangoはかなり急いで行われる可能性があることに注意してください。ただし、Apacheは、最初のページをブラウザに流し込んで立ち往生しています。次に、ブラウザは.JSライブラリ、.CSSファイル、およびそれらすべての画像の要求を開始します。理想的には、Apacheはこれらの後続の要求をすべて処理します。
あなたは「mod_wsgiは私のためにバッファリングしますか?」と尋ねているかもしれません。答えはバージョンによって異なります。2.0より前のmod_wsgiは、バッファを蓄積する可能性があります。mod_wsgi 2.0以降はバッファリングしません。アプリケーションがバッファリング可能であるか、バッファリング用のミドルウェアが含まれていることを前提としています。
http://code.google.com/p/modwsgi/wiki/ChangesInVersion0200
通常、Djangoテンプレートは1つのバッファーでレンダリングされ、mod_wsgiに1つで渡され、Apacheが出力フィルターを適用してブラウザーにトリクルダウンする準備が整います。