WSGIサーバーのパフォーマンス分析：パート2

この記事は、Kevin Goldbergの記事「Python WSGIサーバーのパフォーマンス分析：パート2」の翻訳です。

はじめに

このシリーズの第1回では、 WSGIの作者によると、 WSGIと6つの最も人気のあるサーバーに会いました。 このパートでは、これらのサーバーのパフォーマンスを分析した結果が表示されます。 この目的のために、特別なテストサンドボックスが作成されました。

出場者

時間の制約のため、調査は6つのWSGIサーバーに限定されていました。 このプロジェクトの起動手順はすべてGitHubでホストされています 。 おそらく時間の経過とともに、プロジェクトは拡大し、他のWSGIサーバーのパフォーマンス分析が提示されるでしょう。 ただし、今のところ、6つのサーバーについて説明します。

1. Bjoernは自身を「超高速WSGIサーバー」と表現し、「最速、最小、最軽量のWSGIサーバー」であることを誇っています。 デフォルトのライブラリ設定のほとんどを使用する小さなアプリケーションを作成しました。
2. CherryPyは非常に人気のある安定したフレームワークおよびWSGIサーバーです。 この小さなスクリプトは 、 CherryPyを介してサンプルアプリケーションを提供するために使用されました。
3. Gunicornは、RubyのUnicornサーバー（名前の由来）に触発されました。 彼はそれが「簡単に実装され、使いやすく、かなり速い」と控えめに主張しています。 BjoernやCherryPyとは異なり、 Gunicornはスタンドアロンサーバーです。 このコマンドを使用して作成しました。 WORKER_COUNTパラメーターは、使用可能なプロセッサーコアの数の2倍に1を加えた値に設定されました。 これはGunicornドキュメントの推奨事項に基づいて行われました。
4. Meinheldは、軽量であると主張する高性能のWSGI互換のWebサーバーです。 サーバーサイトに示されている例に基づいて、 アプリケーションを作成しました。
5. mod_wsgiは mod_pythonと同じ作成者によって作成されました。 mod_pythonと同様に、Apacheでのみ使用可能です。 ただし、可能な限り最小のApacheインスタンスを作成する「mod_wsgi express」というツールが含まれています。 このコマンドで mod_wsgi expressを構成して使用しました。 Gunicornに一致するように 、プロセッサコアの2倍のワーカーを作成するようにmod_wsgiを調整しました。
6. uWSGIはフル機能のアプリケーションサーバーです。 原則として、 uWSGIはプロキシサーバー（例：Nginx） とインターフェイスします。 ただし、各サーバーのパフォーマンスをより適切に評価するために、ベアサーバーのみを使用して、使用可能なプロセッサコアごとに2つのワーカーを作成しようとしました 。

ベンチマーク

テストを可能な限り客観的にするために、 Dockerコンテナを作成して、テスト対象のサーバーをシステムの他の部分から分離しました。 また、Dockerコンテナを使用することで、すべての起動が最初から確実に開始されます。

サーバー：

• Dockerコンテナで隔離されます。
• 割り当てられた2つのプロセッサコア。
• コンテナのRAMは512 MBに制限されていました。

テスト：

• 最新のHTTPベンチマークツールであるwrkがテストを実行しました。
• サーバーはランダムな順序でテストされ、同時接続数は100〜10,000の範囲で増加しました。
• wrkは、Dockerが使用しない2つのCPUコアに制限されていました。
• 各テストは30秒続き、4回繰り返されました。

メトリック：

• 永続的なリクエスト、エラー、および遅延の平均数はwrkによって提供されました 。
• Dockerに組み込まれた監視により、CPUとRAMの使用レベルが示されました。
• 最高値と最低値は破棄され、残りの値は平均化されました。
• 好奇心のために、スクリプト全体をGitHubに送信しました。

結果

すべての初期パフォーマンス指標はプロジェクトリポジトリに含まれており、サマリーCSVファイルも提供されていました。 また、視覚化のために、グラフィックスはGoogle-doc環境で作成されました。

RPS対同時接続数

このグラフは、同時リクエストの平均数を示しています。 数値が大きいほど優れています。

• Bjoern：明確な勝者。
• CherryPy：純粋なPythonで書かれているにもかかわらず、彼は最高のパフォーマンスを発揮しました。
• Meinheld：コンテナリソースが乏しいことを考えると、すばらしいです。
• mod_wsgi：最速ではありませんが、パフォーマンスは一貫して適切でした。
• Gunicorn：より低い負荷で良好なパフォーマンスを発揮しますが、多数の接続でトレースできます。
• uWSGI：フラストレーションがあり、結果は良くありません。

勝者：ビョルン

ビョルン

絶え間ないリクエストの数で、 ビョルンは明確な勝者です。 しかし、その数字が競合他社の数字よりはるかに高いことを考えると、私たちは少し懐疑的です。 Bjoernが本当に驚くほど速いかどうかはわかりません。 最初にサーバーをアルファベット順にテストしましたが、 Bjoernが不当な優位性を得たと考えました。 ただし、サーバーをランダムな順序でサーバーを起動して再テストした後でも、結果は変わりません。

uWSGI

uWSGIの弱い結果に失望しました。 彼が先頭に立つことを期待していました。 テスト中に、 uWSGIログが画面に出力されることに気付き、最初にサーバーが行った追加作業でパフォーマンスの不足を説明しました。 ただし、「-- disable-logging 」オプションを追加した後でも、 uWSGIは依然として最も遅いサーバーです。



uWSGIマニュアルで述べたように、通常はNginxなどのプロキシサーバーとインターフェイスします。 しかし、これがこのような大きな違いを説明できるかどうかはわかりません。

遅延

遅延は、要求とその応答の間の経過時間です。 数値が小さいほど優れています。

• CherryPy：負荷を適切に処理しました。
• Bjoern：一般的に待ち時間は短いですが、同時接続が少ない方がうまく機能します。
• Gunicorn：一貫性があります。
• mod_wsgi：多数の同時接続がある場合でも平均パフォーマンス。
• Meinheld：全体的に、許容可能なパフォーマンス。
• uWSGI：uWSGIは再び最後の場所になりました。

勝者：CherryPy

RAM使用量

このメトリックは、各サーバーのメモリ要件と「明度」を示します。 数値が小さいほど優れています。

• Bjoern：非常に軽いです。 10,000 MBの同時リクエストを処理するために9 MBのRAMしか使用しません。
• Meinheld： Bjoernと同じです。
• Gunicorn：わずかなメモリ消費で高負荷に巧みに対処します。
• CherryPy：最初は少量のRAMが必要でしたが、負荷が増加するにつれて使用量が急速に増加しました。
• mod_wsgi：低いレベルでは、メモリ内で最も激しいものの1つでしたが、かなり一貫したままでした。
• uWSGI：明らかに、私たちがテストしているバージョンには、消費されるメモリの量に問題があります。

受賞者：Bjoern and Meinheld

エラー数

エラーは、サーバーがクラッシュしたとき、中断したとき、または要求がタイムアウトしたときに発生します。 低いほど良い。







サーバーごとに、リクエスト数とエラー数の合計比の比率を計算しました。

• CherryPy：接続数が多い場合でも、エラー率は約0です。
• Bjoern：エラーが発生しましたが、これは処理されたリクエストの数によって相殺されました。
• mod_wsgi：許容エラー率6％で良好に機能します。
• Gunicorn：9％のエラー率で動作します。
• uWSGI：処理されたリクエストの数が少ないことを考えると、34％のエラー率で終わりました。
• Meinheld：最も負荷の高いテスト中に10,000を超えるエラーを投げ、より高い負荷で落ちました。

勝者：CherryPy

CPU使用率

サーバーが正常に動作している場合、CPU使用率が高くても悪くもない。 ただし、これはサーバーに関するいくつかの興味深い情報を提供します。 2つのCPUコアが使用されたため、可能な最大使用率は200％です。

• Bjoern：100％CPUを一貫して使用していることから明らかなように、シングルスレッドサーバー。
• CherryPy：マルチスレッドですが、150パーセントでスタックしています。 これは、 Python GILが原因である可能性があります。
• Gunicorn：低いレベルでCPUリソースをフルに使用して、いくつかのプロセスを使用します。
• Meinheld：BjoernなどのCPUリソースを使用するシングルスレッドサーバー。
• mod_wsgi：すべての測定を通じてすべてのCPUコアを使用するマルチスレッドサーバー
• uWSGI：CPU使用率が非常に低い。 CPU消費は50％を超えません。 これは、uWSGIが正しく構成されていない証拠の1つです。

勝者：いいえ。これは、パフォーマンスの比較というよりも行動の観察に近いためです。

おわりに

まとめると！ 各サーバーの結果から引き出すことができる一般的なアイデアを次に示します。

• Bjoern：「超高速、超軽量のWSGIサーバー」として正当化します。
• CherryPy：高性能、低メモリ消費、低エラー率。 純粋なPythonにとって悪くはありません。
• Gunicorn：中負荷に適したサーバー。
• Meinheld：うまく機能し、最小限のリソースで済みます。 ただし、高負荷に苦労しています。
• mod_wsgi：Apacheに統合し、うまく機能します。
• uWSGI：非常に失望しました。 uWSGIを誤って設定したか、インストールしたバージョンに基本的なエラーがあります。