Django 用の最もクリーンで最速のサーバー セットアップ [終了]
https://stackoverflow.com/questions/26025
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
Django を利用した中規模のサイトをデプロイしようとしています。専用の Ubuntu サーバーがあります。
どのサーバーソフトウェアを使用するか非常に迷っています。そこで私はこう思いました。stackoverflow に問い合わせてみてはいかがでしょうか。
私が探しているものは次のとおりです:
- セットアップが簡単
- リソースを高速かつ簡単に使用できます
- メディアファイルを提供できる
- 同じサーバー上で複数の Django サイトを提供可能
- 私は、PHP やリソースを消費する、役に立たないものはインストールしたくないと思っています。
Apache、nginx、lighty 上の mod_wsgi と mod_python について聞いたことがあります。これらの長所と短所は何ですか?また、誰かを見逃していませんか?
@バリー:どういうわけか、Apache は私にとって肥大化しているように感じます。代替案についてはどうでしょうか？
@BrianLy:わかりました。mod_wsgi をもう少し調べてみます。しかし、lighty で静的ファイルを提供する場合、なぜ Apache が必要なのでしょうか?また、django アプリ自体を lighty で提供することもできました。それはとにかく悪いことですか？バカなことしてごめんなさい:-)
アップデート:lighty と nginx はどうですか? これらが最適な選択である場合のユースケースは何ですか?
解決
より詳細な答えを探していたので、この問題を自分で詳しく調査することにしました。何か誤解がある場合はお知らせください。
一般的に推奨されるのは、メディアの処理に別の Web サーバーを使用することです。別個とは、Django を実行していない Web サーバーを意味します。このサーバーには、たとえば次のようなものがあります。
- Lighttpd (ライティ)
- Nginx (エンジンX)
- または他の軽量サーバー
その後、Django については、別の道を進むことができます。次のいずれかを行うことができます。
Django を提供する アパッチ そして：
mod_python
これは安定しており、推奨され、十分に文書化された方法です。短所:多くのメモリを使用します。
mod_wsgi
私の理解では、mod_wsgi はより新しい代替手段です。より速く、リソースを節約できるようです。
mod_fastcgi
FastCGI を使用すると、Django の提供を別のプロセスに委任することになります。mod_python にはすべてのリクエストに Python インタープリターが含まれるため、大量のメモリを使用します。これはその問題を回避する方法です。また、セキュリティ上の懸念もあります。
行うことは、Django FastCGI サーバーを別のプロセスで起動し、必要に応じてこのプロセスを呼び出すように書き換えによって Apache を構成することです。
または、次のこともできます。
ジャンゴに仕える Apacheを使わずに ただし、FastCGI をネイティブにサポートする別のサーバーを使用します。
(ドキュメントには、Apache 固有のニーズがない場合にこれを行うことができると記載されています。理由はおそらくメモリを節約するためだと思います。)
- ライトTPD
これはYoutubeを実行するサーバーです。高速で使いやすいようですが、メモリリークに関する報告を見たことがあります。
- nginx
このサーバーが lighttpd よりもさらに高速であると主張するベンチマークを見たことがあります。ただし、ほとんどはロシア語で文書化されています。
もう 1 つ、Python の制限により、サーバーはスレッドではなくフォーク モードで実行する必要があります。
これが私の現在の研究ですが、もっと意見や経験が欲しいです。
他のヒント
使っています チェロキー.
によると 彼らのベンチマーク (多少の話は必要ですが)、Lighttpd と nginx の両方よりも負荷をうまく処理します...しかし、それが私がそれを使用する理由ではありません。
あなたが入力する場合は、それを使用します cherokee-admin, 、(ワンタイム パスワードを使用して) ログインできる新しいサーバーが起動し、美しく仕上げられた Webmin を通じてサーバー全体を設定します。それはキラー機能です。それはすでに私を救ってくれました 多く 時間の。そして、サーバーのリソースを大幅に節約できます。
django に関しては、スレッド化された SCGI プロセスとして実行しています。うまくいきます。チェロキーも走り続けることができます。繰り返しますが、非常に素晴らしい機能です。
現在の Ubuntu リポジトリのバージョンは非常に古いため、使用することをお勧めします 彼らのPPA. 。幸運を。
@Barryが言ったように、ドキュメントでは使用されています mod_python. 。私は Ubuntu をサーバーとして使用したことはありませんが、Solaris 上の mod_wsgi には良い経験がありました。のドキュメントを見つけることができます mod_wsgi と Django で mod_wsgi サイト。
要件を簡単に確認します。
- セットアップが簡単 Apache 2.2 はビルドとインストールがかなり簡単であることがわかりました。
- リソースを高速かつ簡単に使用できます これは使用状況とトラフィックに依存すると思います。* Apache を使用してすべてのファイルをサーバーする必要はないかもしれません。 ライトTPD (軽い) 静的ファイルをサーバーに送信します。
- メディア ファイルを提供できる 画像やフラッシュファイルのことを言っているのでしょうか？Apache ならこれができます。
- 同じサーバー上の複数のサイト Apache 上でホストされている仮想サーバー。
- 他の拡張機能をインストールしないでください Apache 設定内で不要なものをコメントアウトします。
django プロジェクトをデプロイするために公式に推奨されている方法は、Apache で mod_python を使用することです。これについては、 ドキュメント。 これの主な利点は、これが最も文書化され、最もサポートされ、最も一般的な展開方法であることです。欠点は、おそらく最速ではないということです。
使用しています nginx (0.6.32 シドから取った） と mod_wsgi. 。これは非常にうまく機能しますが、代替品より優れているかどうかは試したことがないのでわかりません。Nginxには memcached サポートが組み込まれており、Django キャッシュ ミドルウェアと相互運用できる可能性があります (実際には使用しませんが、代わりに python-memcache を使用して手動でキャッシュを埋め、変更が行われたときにキャッシュを無効にします)。そのため、キャッシュ ヒットは Django (私の開発) を完全にバイパスします。マシンは 1 秒あたり約 3000 リクエストを処理できます)。
注意:nginx」 mod_wsgi 名前付きの場所を非常に嫌います (名前付きの場所を渡そうとします) SCRIPT_NAME）、明らかな「error_page 404 = @django' 多くの不明瞭なエラーが発生します。これを修正するには mod_wsgi ソースにパッチを適用する必要がありました。
私もすべてのオプションを理解するのに苦労しています。で このブログ投稿 mod_python と比較した mod_wsgi の利点をいくつか説明しました。
小規模な VPS 上にトラフィックの少ないサイトが複数あると、RAM の消費が最大の懸念事項となり、そこでは mod_python は悪い選択肢のように思えます。lighttpd と FastCGI を使用して、単純な Django サイトの最小メモリ使用量を、仮想 58MiB および常駐 6.5MiB まで下げることができました (再起動して、RAM を多く使用しない単一のリクエストを処理した後)。
Debian Etch で Python 2.4 から 2.5 にアップグレードすると、Python プロセスの最小メモリ フットプリントが数パーセント増加したことに気付きました。一方で、2.5 のメモリ管理の向上は、長時間実行されるプロセスに対してより大きな逆効果をもたらす可能性があります。
単純にする： Django は Apache と mod_wsgi (または mod_python) を推奨します. 。メディア ファイルの提供がサービスの大きな部分を占める場合は、Amazon S3 または Rackspace CloudFiles を検討してください。
私の意見では、最良/最速のスタックは varnish-nginx-uwsgi-django です。そして私はそれをうまく使っています。
lighthttpd を使用している場合は、Django を提供するために FastCGI を使用することもできます。mod_wsgi との速度の比較はわかりませんが、メモリが正しく機能していれば、mod_python では得られない、mod_wsgi で得られる利点がいくつか得られます。主な特徴は、各アプリケーションに独自のプロセスを与えることができることです (これは、さまざまなアプリケーションのメモリを分離したり、マルチコア コンピューターを活用したりするのに非常に役立ちます。
編集：nginix に関する更新に関して付け加えておきますが、メモリが再び正しく機能する場合、nginix は「greenlets」を使用して同時実行を処理します。つまり、1 つのアプリがサーバーの時間をすべて使い果たさないように、もう少し注意する必要があるかもしれません。
すべての Django デプロイメントに nginx と FastCGI を使用します。これは主に、通常は Slicehost でデプロイしており、すべてのメモリを Apache に寄付したくないためです。これが私たちの「ユースケース」になると思います。
ドキュメントがほとんどロシア語であるというコメントについては、ほとんどの情報を見つけました。 英語のウィキ 非常に便利で正確です。このサイトには Django のサンプル構成もあり、そこから独自の nginx 構成を調整できます。
これを行うには多くの方法やアプローチがあります。そのため、DjangoAdvent.com のデプロイメント プロセスに関連する記事を注意深く読むことをお勧めします。Eric Florenzano - FastCGI を使用した Django のデプロイ: http://djangoadvent.com/1.2/deploying-django-site-using-fastcgi/ こちらもお読みください:Mike Malone -Scaling django stochastictechnologiesブログ：完璧なDjangoセットアップMikkel Hoeghブログ：35 % 応答時間の改善-スイッチング-uwsgi-nginx
よろしく
Cherokee の使用に関して警告があります。Django に変更を加えると、Cherokee は古いプロセスを終了して新しいプロセスを開始するのではなく、古いプロセスを維持します。
Apache については、この記事を強くお勧めします。
http://www.djangofoo.com/17/django-mod_wsgi-deploy-exampl
セットアップが簡単で、変更後の終了やリセットも簡単です。
ターミナルを入力するだけです
sudo /etc/init.d/apache2 restart
そして変化は即座に現れます。
