Python Webアプリケーションの起動方法の有効性の比較

最近、Web開発の分野で、Pythonプログラミング言語が人気を集め始めています。 ただし、Pythonの大規模な普及は、この言語でアプリケーションを効率的に起動する問題によって妨げられています。 これまでのところ、ほとんどの場合、これは専用サーバーまたは仮想サーバーの運命です。 モジュラー言語は、基本的なphp機能のモノリシックとは異なり、各要求で少なくともランタイムライブラリをロードし、少なくともユーザーが要求する数十個以上のモジュールをロードします。 したがって、PythonおよびPerlのmod_phpのような古典的なアプローチはあまり適切ではなく、アプリケーションをメモリに常に保持するのは高価でした。 しかし、時が経つにつれて、テクノロジーはより強力で安価になりました。そして、かなり長い間、大量ホスティングの一部としてアプリケーションで常に実行されているプロセスについて安全に話すことができます。

それは何ですか

Pythonでアプリケーションを実行する方法に関するさまざまな提案がネットワーク上に時々表示されます。 たとえば、最近Ginoをホストすると、 mod_pythonが一意に修正され、それを使用したホスティングが提供されます 。 彼に続いて、特定のLocumホスティングがmod_pythonのセキュリティを完全に拒否し（元のセキュリティの本質がnirvanaに向かう唯一のIT問題であるようです）、 fastcgiに対するmodwsgiの勝利テストを実施しました 。 私の検索から判断すると、コミュニティはmod_pythonとFastCGIの間で引き裂かれています。 さらに、FastCGIは通常Djangoに付属しているもの-flupを意味します。 Pythonアプリケーションの人気のあるホスティングであるため 、私たちはこの神聖な戦争を逃れずに貢献することにしました。



どんなテクノロジーでも、実装コーシャ、パフォーマンス、使いやすさ、汎用性を最適に相関させるべきだと私は心から信じています。 これに基づいて、提示されたソリューションのそれぞれについて説明します。 私は選択の問題に主観的にアプローチし、誰もが理解できる普遍的なプロセスマネージャーとしてApache Webサーバーに焦点を当てました。 www.wsgi.org/wsgi/Serversからflup （ trac.saddi.com/flup ）、python-fastcgi（ pypi.python.org/pypi/python-fastcgi ）、およびmod_wsgi（ www.modwsgi.org ）を選択しました。 同時に、彼はmod_python（ www.modpython.org ）を採用しました。これは、一般的なホスティング業者の間でpythonを起動する最も一般的な方法です。

体に近い

私はすべてのオプションに理想的な条件を作成しようとしました。特定の数のリクエストの後に再起動することはなく、すべてが通常の単純な方法で行われました。 実際には、Apache-> Publisher-> Applicationパスの効率と生産性のテストがあります。 これらのテストの多くは何らかの理由でインタープリターのパフォーマンスもテストしますが、同じインタープリターを比較する理由を説明し、異なるインタープリターの場合、どの機能の実装をテストし、テストする必要があるのか​​を説明するのは難しいことがわかりました。 特に、すべての技術テストはパフォーマンスの比較評価のみを提供するという事実に注意を喚起したいと思います。 したがって、特別なチューニングやパフォーマンスの向上は行われませんでした。 phpに関する不必要な暴言を避けるために、mod_phpもテストに含まれています。



すべての悪魔化されたプロセスについて、条件が選択されました-それぞれ5スレッドの2つの事前開始プロセス。 フラップのある特別な場合を除きます。 すべてのアプリケーションは、ユーティリティab 100,000（10万）リクエスト、10同時にリクエスト、さらに10,000（10,000）リクエストの追加mod_pythonテストによってテストされます。 5、30、100の事前開始プロセス（MPM Prefork）を使用して、傾向を特定するために、Apacheで順次テストが行​​われました。

実験的

デュアルプロセッサXeon E5335 2.00GHz、RAM 4Gb、SCSI-3インターフェイスを備えたSCSIハードドライブ。 FreeBSD 7.2-RELEASE amd64、Apache 2.2.11、php 5.2.10、python 2.5.4、mod_wsgi 3.0、mod_python 3.3.1、mod_fastcgi 2.4.6、python-fastcgi 1.1およびfcgi devkit 2.4.0、flup 1.0.2をインストール。 すべてのテストはサーバー上でローカルに実行され、負荷が1を超えることはありませんでした。

フラップ

FastCGIインターフェースを備えたWSGIサーバーです。 これは、djangoアプリケーションdocs.djangoproject.com/en/dev/howto/deployment/fastcgiを起動するためのメインで唯一の通常の方法です 。 テストには、次のプログラムを使用しました。

#!/usr/local/bin/python <br/> <br/> def my_wsgi_application (environ, start_response):<br/> status = '200 OK' <br/> output = 'Hello World!' <br/> response_headers = [( 'Content-type' , 'text/plain' )]<br/> start_response(status, response_headers)<br/> return [output]<br/> <br/>application = my_wsgi_application <br/> from flup.server.fcgi import WSGIServer<br/>wsgi_opts = { 'maxSpare' : 5 , 'minSpare' : 5 , 'maxThreads' : 5 }<br/>WSGIServer(application,**wsgi_opts).run() <br/>

この方法でアプリケーションを起動することには、いくつかの困難があります：サーバーを再起動せずにアプリケーションを再起動できない、再起動またはサードパーティの改善なしでアプリケーションコードをリロードできない、アプリケーションでfastcgiハンドラーとそのパラメーターを個別に宣言する必要がある これは、python-fastcgiにも当てはまります。 結果からわかるように、flupは5つの事前起動されたApacheプロセスを使用したテストで既に飽和状態になっています。 彼はまた、flupがすぐに処理できないものはすべて投げると指摘しました。 テストでクエリエラーの最大40％を受け取りました。 このテストは悲しみと悲しみを引き起こします。私の統計によると、プログラマーはプログラムがどのように機能するかをめったに見ないため、多くの人が今アメリカを開いています。 驚いたことに、実行中のスレッドを厳密に制限せずにflupの動作を調べることにし、不要なパラメーターを削除して次のプログラムを作成しました。

#!/usr/local/bin/python <br/> <br/> def my_wsgi_application (environ, start_response):<br/> status = '200 OK' <br/> output = 'Hello World!' <br/> response_headers = [( 'Content-type' , 'text/plain' )]<br/> start_response(status, response_headers)<br/> return [output]<br/> <br/>application = my_wsgi_application <br/> from flup.server.fcgi import WSGIServer<br/>WSGIServer(application).run() <br/>

結果が期待されていました。 損失は​​ありません。flupは必要に応じてスレッドを作成します（psの出力を監視します）が、予想どおり、パフォーマンスはほぼ半分になります。

それで、今日のDjangoを起動する最も人気のある方法である、私の激しい挨拶をします...

modwsgi

Apache用のモジュールとして設計されたWSGIサーバーです。 メインアプリケーションはデーモンモードです。 つまり Webサーバーが、作成された常駐プログラムとその管理の間の仲介者にすぎない場合。 Djangoを起動するための主な推奨方法ですdocs.djangoproject.com/en/dev/howto/deployment/modwsgi Apacheで使用するため、Apachevのあらゆる種類の.htaccessなどの「ささいなこと」を使用でき、システム管理者にとってはそれほど怖いものではありません。 同じ事実は、nginxについて聞いて、Apacheが悪であると考えている開発者を大いに怖がらせます。 テストに使用したプログラムは次のようになります。

def my_wsgi_application (environ, start_response):<br/> status = '200 OK' <br/> output = 'Hello World!' <br/> response_headers = [( 'Content-type' , 'text/plain' )]<br/> start_response(status, response_headers)<br/> return [output]<br/> <br/>application = my_wsgi_application <br/>

テスト結果は、Apacheハンドラーの増加に伴うパフォーマンスの向上を示しています。 彩度の欠如。 そして、明らかにフラップよりも生産的です。



modwsgiのいくつかの機能に注目したいと思います。 まず、再起動する前に処理するリクエストの数を独自に設定します。 これにより、メモリリークに効果的に対処できます。 他の方法と同様に、例ではこの設定を行いませんでした。これはパフォーマンスがわずかに低下することが明らかだからです。 第二に、他の方法とは異なり、ユニークなアイドル時間設定があり、その後は過負荷になります。 これにより、デプロイされたアプリケーションや、不要なときにメモリがリークしたアプリケーションをメモリに保持しないようにすることができます。 第三に、アプリケーションファイルの更新時に自動的にリロードされます。 つまり プログラムを変更するときは、必ず新しいバージョンが表示されると確信しています。 上記の方法のいずれも、特別な変更をせずにこれを行うことはできません。 もう1つの重要な機能は、アプリケーションの起動方法をアプリケーションの責任範囲から思い出せないことです。 例に注意してください-プログラムには実際にはWSGIインターフェースしかなく、それだけです。

python-fastcgi

〜ビンゴです！ -WSGI_server、FastCGIインターフェース付き。 実際、標準C ++ FastCGIのラッパー。 プログラムは次のようになります。

#!/usr/local/bin/python <br/> import fastcgi<br/> def my_wsgi_application (environ, start_response):<br/> status = '200 OK' <br/> output = 'Hello World!' <br/> response_headers = [( 'Content-type' , 'text/plain' )]<br/> start_response(status, response_headers)<br/> return [output]<br/> <br/>application = my_wsgi_application <br/>s = fastcgi.ThreadedWSGIServer( my_wsgi_application , workers= 5 )<br/>s.serve_forever() <br/>

テスト結果は一目瞭然です。 サーバーハンドラーの成長に伴い、生産性が向上します。 明らかにpython-fastcgiはテストのリーダーです（こんにちは、Locum）。 一般に、Apacheを介してFastCGIの台頭を基本的に破った後、このモジュールは最小限の質問と苦情を引き起こしました。 当然、この起動方法のすべての欠点があります-設定の複雑さ、アプリケーションへのサーバーの依存性、定期的な再起動ツールの欠如（プログラムの更新など）など。

mod_python

mod_phpのようなApacheサーバーモジュールです。 いくつかのフックがあり、WSGIインターフェースはありません。 主な問題はセキュリティと見なされます。これは、変更せずにサーバーに代わって実行されるためです。 確かに、mod_phpを含む組み込みモジュールにも同じ欠点があります。 テスト用に次のプログラムを作成しました。

#!/usr/local/bin/python <br/> <br/> def index (req):<br/> return "Hello World!\n" <br/>

突然、結果は控えめになりました。 テストの過程で、もう1つの機能が明らかになりました。 10,000クエリのテスト結果は次のとおりです。



プロセッサの数が増えると、生産性が低下することがわかります。 これは、サーバーの起動時にapacheがアプリケーションを「吸う」のではなく、リクエストがハンドラの1つにヒットしたときにのみ吸うためです。 したがって、ハンドラーを作成すればするほど、「初めて」のリクエストが増えました。 2-3のアクティブなアプリケーションでは、輻輳が非常に頻繁に発生することは明らかです。 サーバー全体しか構成できない場合にアプリケーションを起動する方法を選択するかどうかはユーザー次第です。 また、mod_pythonにはコード更新の問題があります。 彼には適切な設定がありますが、サーバー全体を再起動せずに変更するときに、アプリケーションコードを効果的に更新することはできませんでした。 一部のホスティングサイトでは、diffprivモジュールを使用してコードを更新するという目に見える問題なく動作します。 しかし、2番目の問題が発生します。アプリケーションはすべてのリクエストに対してサーバーによってダウンロードされるため、テストを外挿してもパフォーマンスが大幅に低下します。 そして、別の深刻な問題は、もちろん、「出版社」の選択と彼らと協力することです。 mod_pythonは、インジケーターの合計による評価の最も基盤であることが判明しました。

mod_php

比較のために、テストとphpを実行することにしました。 プログラムは非常に明白に見えます：

<?php echo ( "Hello, World!" ); ?> <br/>

結果は明白ですが、想像力は打たれません。 不必要なコミュニケーションとモノリシックなphp自体が存在しない場合、2以上の係数が予想されました。



要約は非常にシンプルで明白です。 テクノロジーが単純であればあるほど、生産性が向上します。 パフォーマンスのノミネートにおける評価のリーダーは間違いなくpython-fastcgiであり、利便性のノミネートのリーダーはmodwsgiです。 さらに、modwsgiは明らかに今日では特性の合計に対する最適なソリューションですが、最も生産的でもバグの多いものでもありません。