PythonベースのWebアプリケーション用のWebサーバーの比較
序章
この記事では、Python、Webサーバー、そして最も重要なこととして、2つの間のビットとボブの3つの主要なことについて説明します。
冗談はさておき、このかなり長い記事は、迅速なガイダンスや回答を探している人にとっては悲惨に思えるかもしれません。 残念ながら、Pythonの世界のほとんどのものとは異なり、アプリケーションをデプロイする本番サーバースタックを選択する場合、それを行うための明白な方法は 1つではなく、できれば1つだけです。
しかし、これはあなたを怖がらせるべきではありません。 この記事を完了すると、さまざまなWebサーバーがどのように機能し、PythonベースのWebアプリケーションと通信するタスクを処理するかについて十分な知識が得られます。 ニーズと要件を測定すると、使用するサーバーを決定できます。
Python Web Server Gateway Interface v1.0(WSGI)
問題を理解する
今日、Python Webアプリケーションと交換可能に動作するように特別に設計(または適合)されたWebサーバー(またはサーバー用のモジュール)が増え続けています。 ただし、これが常に当てはまるとは限りません。 昔は、開発者はWebサーバーを簡単に切り替えることができず、各切り替えには依存関係と制限のためにコストがかかりました。 構築するフレームワークを決定する際に、アプリケーションを提供するために使用できるサーバーについても、常に積極的または意識的にではなく、決定することになります。 これは、広く受け入れられているインターフェイス仕様が存在しないためでした。アプリケーション(フレームワーク)とWebサーバーが同様に適応して通信に使用する共通の基盤であり、必要に応じてコードをゼロにしてコンポーネントの互換性を実現します。変化する。
標準の誕生
今世紀の初めに、Python拡張提案( PEP )333をコミュニティに提示することで、問題を最終的に解決するための努力がなされました。
This document specifies a proposed standard
interface between web servers and Python web
applications or frameworks, to promote web
application portability across a variety of
web servers.
PEPで説明されているように、この新しい標準は、[web]サーバーと[Python web]アプリケーション間(および間)での移植性を可能にすることを目的としていました(そしてそうなっています)。 この規格の強力な機能と以前のものと比較したその幅広い採用は、今日の道を切り開いています。あなたのために仕事をしてくれる多くの(おそらく多すぎる)Webサーバーが存在する世界です。
比較
PythonベースのWebアプリケーション用のWebサーバーのこの比較では、利用可能な選択肢のいくつかと、それらを際立たせるものについて説明します。 ここでの目的は、読者がより明確なビジョンを持ち、1つを見つけるためのアプリケーションのカスタムニーズに対してサーバーを一致させるための支援を提供することです。 膨大な数のオプション(毎日より多くポップアップします!)のために、私たちはさまざまな方法で「特別な」ものについて話します:人気、堅実さ、またはとは異なる(またはより良い)何かをすること残り。
注:読者の皆様には、実際の本番環境の条件を反映しない傾向のある偏った、欺瞞的なベンチマークに注意することをお勧めします。 残念ながら、これらの[記事]は、本番用のWebサーバーを選択することに関してはあまり意味がありません。これも、ボトルネックの原因となる可能性はほとんどありません。 したがって、実際の将来の災害シナリオを回避するために、投機的な数値を控えて、自分のニーズを測定して理解し、さまざまなオプションを試すことをお勧めします。
Webサーバー(アルファベット順)
CherryPyWSGIサーバー
それは何ですか?
CherryPyは実際にはWebフレームワークです。 それでも、それは完全に自己完結型のものです。つまり、追加のソフトウェアを必要とせずに、本番シナリオを含め、単独で実行できます。 これは、独自のWSGI、HTTP/1.1準拠のWebサーバーのおかげで実現されます。 CherryPyプロジェクトでは、これを「高速で本番環境に対応した、スレッドプールされた汎用HTTPサーバー」と説明しています。 WSGIサーバーであるため、CherryPyのアプリケーション開発フレームワークに縛られることなく、他のWSGIPythonアプリケーションを提供するためにも使用できます。
なぜそれを使用することを検討する必要がありますか?
- コンパクトでシンプルです。
- WSGIで実行されているすべてのPythonWebアプリケーションにサービスを提供できます。
- 静的ファイルを処理でき、ファイルとフォルダーのみを提供するために使用できます。
- スレッドプールされます。
- SSLのサポートが付属しています。
- 適応しやすく、使いやすい純粋なPythonの代替手段であり、堅牢で信頼性があります。
Gunicorn
それは何ですか?
GunicornはスタンドアロンのWebサーバーであり、操作が非常に簡単な方法でかなりの機能を提供します。 プレフォークモデルを使用します。つまり、中央のマスタープロセス(Gunicorn)は、開始されたワーカープロセス(さまざまなタイプ)の管理を担当し、要求を直接処理して処理します。 そして、これらすべてを構成して、ニーズや多様な本番シナリオに合わせて調整することができます。
なぜそれを使用することを検討する必要がありますか?
- WSGIをサポートし、Pythonアプリケーションとフレームワークを実行している任意のWSGIで使用できます。
- また、Paster(例:Pyramid)、Djangoの開発サーバー、web2pyなどのドロップイン代替品としても使用できます。
- さまざまなワーカータイプ/構成および自動ワーカープロセス管理の選択肢を提供します。
- 同期および非同期ワーカーによるHTTP/1.0およびHTTP/1.1(Keep-Alive)のサポート。
- SSLサポートが付属しています
- フックで拡張可能。
- 透過的で、明確なアーキテクチャを備えています。
- Pythonバージョン2.6、2.7、3、3.2、3.3をサポートします
トルネード(wsgi.WSGIContainer経由のHTTPサーバー)
それは何ですか?
Tornadoは、非同期操作を処理するために設計されたアプリケーション開発フレームワークおよびネットワーキングライブラリであり、サーバーが多くのオープン接続を維持できるようにします。 また、他のWSGI Pythonアプリケーション(およびフレームワーク)が実行に使用できるWSGIサーバーも付属しています。
なぜそれを使用することを検討する必要がありますか?
- トルネードフレームワークの上に構築している場合。 また
- アプリケーションには非同期機能が必要です。
このような状況では、プロジェクトにTornadoのWSGIサーバーを選択することもできますが、Tornado[非同期]ワーカーでGunicornを使用することもできます。
ツイストウェブ
それは何ですか?
Twisted Webは、Twistedネットワーキングライブラリに付属しているWebサーバーです。 Twisted 自体は「イベント駆動型ネットワークエンジン」ですが、 Twisted Web サーバーはWSGIで実行され、他のPythonWebアプリケーションに電力を供給できます。
なぜそれを使用することを検討する必要がありますか?
- 使いやすく、安定した成熟した製品です。
- WSGIPythonアプリケーションを実行します。
- Python Webサーバーフレームワークのように機能し、カスタムHTTPサービスの目的で言語を使用してプログラムできます。
- シンプルで高速なプロトタイピング機能を提供します
Python Scrips (.rpy)
HTTPリクエストで実行されます。 - プロキシおよびリバースプロキシ機能が付属しています。
- 仮想ホストをサポートします。
- これは、twisted.web.twcgi APIを介してPerl、PHPなどにサービスを提供することもできます。
uWSGI
それは何ですか?
非常にの紛らわしい命名規則にもかかわらず、 uWSGI 自体は、多くのコンポーネントを備えた広大なプロジェクトであり、 full [software] stack
為に building hosting services
. これらのコンポーネントの1つであるuWSGIサーバーは、PythonWSGIアプリケーションを実行します。 SCGIとほぼ同一の独自のuwsgiワイヤプロトコルを含む、さまざまなプロトコルを使用できます。 アプリケーションサーバーの前でスタンドアロンHTTPサーバーを使用するという(理解できる)要求を満たすために、NGINXおよびCherokee Webサーバーは、 uWSGI の(最高のパフォーマンス)uwsgiをサポートするようにモジュール化されています。 ]プロセスを直接制御するプロトコル。
なぜそれを使用することを検討する必要がありますか?
- uWSGIにはWSGIアダプターが付属しており、WSGIで実行されるPythonアプリケーションを完全にサポートします。
- libpythonとリンクします。 起動時にアプリケーションコードをロードし、Pythonインタープリターのように機能します。 着信リクエストを解析し、Python呼び出し可能オブジェクトを呼び出します。
- 人気のあるNGINXWebサーバー(Cherokee *およびlighttpdとともに)を直接サポートします。
- Cで書かれています。
- そのさまざまなコンポーネントは、アプリケーションの実行よりもはるかに多くのことを実行できます。これは、拡張に便利な場合があります。
- 現在(2013年後半現在)、積極的に開発されており、リリースサイクルが高速です。
- アプリケーションを実行するためのさまざまなエンジンがあります(非同期および同期)。
- これは、実行するメモリフットプリントが低くなることを意味します。
ウェイトレスWSGIサーバー
それは何ですか?
ウェイトレスは純粋なPythonWSGIサーバーです。 一見すると、他の多くの製品とそれほど変わらないように見えるかもしれません。 しかし、その開発哲学はそれを他のものから分離しています。 Python Webアプリケーション開発者向けのWebサーバーによって引き起こされる本番(および開発)の負担を軽減することを目的としています。 ウェイトレスは、プラットフォームによって引き起こされる問題を中和することによってこれを達成します(例: Unix対。 Windows)、インタプリタ(CPythonと。 PyPy)とPython(バージョン2と 3)違い。
なぜそれを使用することを検討する必要がありますか?
- これは非常に無駄のない、純粋なPythonソリューションです。
- HTTP/1.0およびHTTP/1.1(Keep-Alive)をサポートします。
- さまざまなプラットフォームをサポートすることで、本番環境にデプロイする準備が整います。
- CherryPyとは異なり、実際にはフレームワークに依存しません。
- WindowsとUnix、およびCPythonインタープリターとPyPy(Unixのみ)で実行されます。
- Pythonバージョン2および3をサポートします。
スタンドアロンサーバー用のモジュール
WSGIアダプターを使用したmod_python(Apache)(Embedding Python)
それは何ですか?
簡単に言えば、mod_pythonはサーバー自体にPythonを埋め込むApacheモジュールです。 さまざまな理由で推奨されていませんが(プロジェクトは古く、元の作成者による開発を継続するというごく最近の意図があるだけです)、ラッパーを介してApacheでWSGIアプリケーションを実行するために使用できます。
なぜそれを使用することを検討する必要がありますか?
特定の理由で、Pythonを使用してApacheをプログラミングおよび拡張することをお勧めします。
mod_wsgi(Apache)(Pythonの埋め込み)
それは何ですか?
WSGI準拠のモジュールであるmod_wsgiを使用すると、ApacheHTTPサーバーでPythonWSGIアプリケーションを実行できます。 これは2つの方法で実現されます。1つ目は、コードを埋め込み、子プロセス内で実行することにより、mod_pythonの動作と似ています。 もう1つの方法は、デーモンベースの操作モードを提供します。これにより、WSGIアプリケーションは、mod_wsgiによって自動的に管理される独自のプロセスを持ちます。
なぜそれを使用することを検討する必要がありますか?
- Apacheの既存の経験は、Pythonの実行に関しても、運用のための安定した本番環境を意味する可能性があります。 これだけで1日を節約でき、価値があります。
- Apacheに依存している場合、またはその安定した豊富な拡張モジュールを利用したい場合は、それが最適な方法です。
- さまざまなシステムユーザーの下でアプリケーションを実行して、セキュリティを強化できます。
- これは、実証済みの信頼できるソフトウェアです。
- ワールドワイドウェブにはトン実際の生産上の問題に遭遇したときに多くの時間を節約できる、それに関連する情報とQ&Aの情報。
- また、Apacheが提供する他のすべての機能が付属しています。