序章


Djangoサーバーに関しては、かなりの数の選択肢があります。 どの設定が適切かを判断するのは難しい場合があります。 それぞれの設定は異なりますが、それぞれに長所と短所があります。 この記事では、最も一般的なDjangoサーバーを調査し、それらに関連する長所と短所を指摘します。

1つ-Django開発サーバー


Django開発サーバーはDjangoにパッケージ化されており、次のコマンドで実行できます。

django-admin.py runserver

これにより、ポート8000でローカルホストを使用してデフォルトで実行されている軽量のWebサーバーが起動します。 追加パラメータとして次のようなものを渡すことで、これを変更できます。

django-admin.py runserver 10.0.0.150:8001

これにより、Webサーバーがポート8001でIP10.0.0.150を使用してDjangoアプリケーションを提供するようになります。 渡すことができる他のさまざまなオプションがありますが、上記が最も一般的です。

Django開発サーバーはまさにそれ、開発サーバーです。 公式のDjangoドキュメントここに記載されているように、これは実稼働環境向けではありません。 ただし、これは、Webサーバーにフルをインストール/構成するオーバーヘッドを追加することなく、開発環境でアプリケーションをテストする簡単な方法として使用することを目的としています。

Django開発サーバーは、軽量で使いやすいという点で優れています。 静的ファイルを特定の場所に収集することなく提供します。 また、ファイルを保存するたびに開発サーバーが再起動します。 Python用のほとんどすべてのWebサーバーは、起動時間の必要性をなくすためにアプリをキャッシュしますが、新しいコピーをキャッシュできるようにコードが変更された場合は再起動が必要になるため、これは便利です。

Django開発サーバーの明らかな欠点は、本番環境に対応しておらず、開発目的でのみ使用する必要があることです。 一度に大量のリクエストやロードを処理するようには作られていません。 これ以外に、Djangoをすばやく起動して実行する方法を探している人にとっては素晴らしいオプションです。

2-Mod_WSGI


Mod_wsgiは、Apache用の最も人気のあるPython WSGIアダプターモジュールであり、WebサーバーとしてApacheを使用している場合に強く推奨される方法です。

mod_wsgiをインストールすると、実装はかなり簡単になります。 次の行をApacheVirtualHostエントリに追加するだけです。

WSGIScriptAlias /yourapp /opt/yourenv/yourapp.wsgi

WSGIScriptAliasディレクティブに指定する最初の引数は、URLマウントポイントです。 したがって、このVirtualHostエントリがドメイン mydomain.com に対するものである場合、アプリケーションはhttp://mydomain.com/yourappに表示されます。

DjangoアプリがApacheにアクセスできるように構成されているディレクトリの外にある場合は、VirtualHostエントリにも以下を追加する必要があります。

<Directory /opt/yourenv>
Order allow,deny
Allow from all
</Directory>

ドメインのルートにWSGIアプリケーションをマウントする場合は、「/」を使用できますが、これには小さな注意点があります。 これを行うと、DocumentRootにある静的ファイルはApacheではなく、WSGIアプリケーションによって提供されます。 これを回避するには、次のように「Alias」ディレクティブを使用して静的ファイルをマップするだけです。

Alias /static/ /opt/yourenv/static/

WSGIScriptAliasディレクティブの場合と同様に、最初の引数はマウントポイントです。 2番目のオプションは、ファイルが存在する静的ディレクトリへのパスです。

mod_wsgiの利点は、Apacheとかなりシームレスに統合するように構築されていることです。 これは、ApacheをプライマリWebサーバーとして使用する人に最適です。

mod_wsgiの欠点は、Apacheでのみ機能することです。 したがって、NGINX、Lighttpd、Cherokeeなどの別のWebサーバーが必要な場合は、 その後、あなたは運が悪いです。 また、これから説明する他のオプションほど軽量ではありません。

3-uWSGI


uWSGIは、NGINX、Apache、Cherokeeなどの他のWebサーバーと通信するためにWSGIプロトコルを実装するサーバーです。 その最終的な目標は、Pythonコードの解釈を処理することですが、前の文で説明したようなWebサーバーは静的ファイルやその他の要求を処理します。 uWSGIはPython用に作成されているため、インストールは次のコマンドを実行するのと同じくらい簡単です。

sudo pip install uwsgi

Django用のuWSGIの実装はかなり簡単です。 Djangoプロジェクトサイトには、このテーマに関する優れたドキュメントがあり、ここにあります。

Djangoのドキュメントに示されているようにuWSGIをインストールして実行すると、メインのWebサーバーからuWSGIにプロキシするだけで済みます。 これを行う方法はWebサーバーによって異なりますが、通常は非常に簡単です。

uWSGIを使用する利点は、非常に軽量で、Webサーバーとは別に実行され(Webサーバープロセスに過負荷がかからないようにするため)、セットアップが比較的簡単なことです。

短所のいくつかは、Webサーバーとは別に別のサーバーをセットアップする必要があり、メインのWebサーバーからuWSGIにプロキシする必要があるというオーバーヘッドです。 ただし、構成で手を少し汚してもかまわない場合は、uWSGIが最適なオプションです。

4-Gunicorn

Gunicornは、uWSGIによく似たPythonWSGIHTTPサーバーです。 私は個人的にGunicornを使用していますが、それが必ずしも最高であるとは限りません。 セットアップが簡単で、Djangoとの統合が簡単なため、Gunicornを使用しています。 次のコマンドを使用して、uWSGIとほぼ同じようにインストールされます。

sudo pip install gunicorn

実装手順はここにあります。

uWSGIと同様に、メインWebサーバーからGunicornにプロキシする必要があります。 これは、uWSGIの場合よりもGunicornの場合の方が簡単ではありません。

Gunicornも非常に軽量です。 それがuWSGIよりも速いかどうかは、議論の余地があります。 これの多くは、GunicornまたはuWSGIの構成方法に関係しています。 どちらも非常に印象的なレベルのパフォーマンスに達する可能性がありますが、Gunicornは高負荷でより適切に機能するとの意見もあります。

Gunicornの欠点はuWSGIとほとんど同じですが、個人的にはGunicornはuWSGIよりも簡単に構成できることがわかりました。 それでも、Apacheでmod_wsgiを使用する場合ほど迅速または簡単に構成およびセットアップすることはできませんが、パフォーマンスレベルでは比較できません。

概要

Flup、FastCGI、mod_pythonなど、カバーしなかったオプションは他にもたくさんあります。

Flupはあまり広く使用されていないので、お勧めしません。 FastCGIは、Webサーバーやリソースを共有していないDigitalOceanのようなものよりも、共有ホスティング環境向けです。 Apache用のMod_pythonは機能しますが、ほとんどのドキュメントでは、mod_wsgiの方がはるかにうまく機能するため、推奨されるルートになります。

では、どちらの方法が勝者ですか? まあ、それは正直にあなたが何を求めているかに依存します。 Apacheと簡単なセットアップと統合が好きな場合は、必ずmod_wsgiを使用してください。 Apacheを使用しない場合は、uWSGIまたはGunicornのいずれかをお勧めします。 どちらにもメリットがあり、Djangoアプリケーションに最適です。 そしてもちろん、開発環境では、組み込みのDjango開発サーバーを使用しない理由はありません。