ネットワークフレームワークのいくつかのベンチマークテスト

こんにちはHabr！ 数か月前、ネットワークフレームワークのパフォーマンスをテストして、それらの間のギャップがどれほど大きいかを理解したかったのです。 PythonをGeventで使用する場合、またはEventMachineでRubyを使用する場合にNode.jsを使用する必要がありますか。







これらの資料はフレームワークを選択するためのガイドではなく、議論の余地があるかもしれないという事実に注意を喚起したいと思います。 私はこの研究の結果を公表するつもりはまったくありませんでしたが、彼らが私の目に留まったとき、私はこれが誰かに役立つかもしれないと考えました。 今、私はグラフでシャワーを浴び始めます。

1.テキスト/ Httperf / VPS 1 CPU、512Mb RAM

最も安価なVPS DigitalOcean（1コア、512Mb RAM、20Gb SSD）で行った最初のテスト。 パフォーマンステストには、 httperfユーティリティが使用されました 。 必要な負荷を生成するために、同じ構成のVPSが5個含まれていました。 すべてのクライアントで同時にテストを実行するために、 自動ベンチユーティリティを次のパラメーターとともに使用しました 。



autobench_admin --single_host --host1 example.com --port1 8080 --uri1 / --low_rate 50 --high_rate 600 --rate_step 10 --num_call 10 --num_conn 6000 --timeout 5 --clients XX.XX.XX.XX:4600,XX.XX.XX.XX:4600,XX.XX.XX.XX:4600,XX.XX.XX.XX:4600,XX.XX.XX.XX:4600 --file bench.tsv







このテストは、1秒あたり50接続（1接続で10リクエスト）から始まり、1秒あたり10接続で600接続に達します。各テストは合計6000接続を確立し、5秒以内に処理されなかったすべてのリクエストはエラーと見なされます。



すべてのHTTPサーバーは同じことを行います。つまり、リクエストごとに文字列「I am a愚かなHTTPサーバーです！」を返します。 結果は次のとおりでした（ X軸に沿って-1秒あたりのリクエスト数 ）：

CPU負荷

RAM消費（512Mbの％）

返信数

応答時間（ミリ秒）

エラー数

CPU使用率が100％に達すると、RAMの消費量が増加し始め、応答数が減少し、各要求の応答時間が長くなり、エラーが表示され始めます。 上記で書いたように、5秒以内に応答を受信しなかった各要求はエラーと見なされます。これはまさにここで起こることです。これは「応答時間」グラフで追跡できます。



結果 （括弧内はエラーなしで処理されたリクエストの数）：

1. ゲベント（ 4700 ）
2. Express.js（ 3600 ）
3. イベントレット（ 3200 ）
4. 竜巻（ 2200 ）

私は自分の仕事に完全に満足しているわけではないので、数時間後、VPSでのパフォーマンスのテストは最良の選択ではないと判断しました。 フレームワーク間では、パフォーマンスの違いは理解可能であり、いくつかの結論を引き出すことができますが、実際のプロセッサの同じコアでサービスできるクライアントの数はわかりません。 未知のリソースを誰かと共有することと、すべてのリソースが既知で自由に使える場合はまったく別のことです。

2.Text / Httperf / Intel Core i7-4770 Quad-Core Haswell、32 GB DDR3 RAM

次のテストでは、Intel Core i7-4770クアッドコアHaswellプロセッサーと32 GB DDR3 RAMを備えたHetzner（EX40）から専用サーバーをレンタルしました。



今回は、必要な負荷を作成する10 VPSを作成し、次のパラメーターを使用してオートベンチを起動しました。



autobench_admin --single_host --host1 example.com --port1 8080 --uri1 / --low_rate 50 --high_rate 1500 --rate_step 50 --num_call 10 --num_conn 15000 --timeout 5 --clients XX.XX.XX.XX:4600,XX.XX.XX.XX:4600,XX.XX.XX.XX:4600,XX.XX.XX.XX:4600,XX.XX.XX.XX:4600 ... --file bench.tsv







このテストは、1秒あたり50接続（1接続で10リクエスト）で実行を開始し、1秒あたり50接続のステップで1500に達します。各テストは合計15,000接続を確立し、5秒以内に処理されなかったすべてのリクエストはエラーと見なされます。



サーバーのソースコードは、最初のテストと同じです。 1つのコアのみを使用するサーバーのコピーが1つ起動されました。 このテストでは、 Twisted 13.2およびEventmachine 1.0.3フレームワークを追加しました。 テスト結果からメモリ消費量を削除しました。これは、最新の基準ではその差が無視できるほど小さいためです。 私は猫を尾で引っ張りません、結果はここにあります：

CPU負荷

返信数

応答時間（ミリ秒）

エラー数

ここで、以前のように、彼らはCPUにぶつかりました。 ここでの生産性は、平均してVPS DigitalOcean（1コア、512Mb）の3倍であり、割り当てられたリソースの量について適切な結論を導き出すことができます。



結果 （括弧内はエラーなしで処理されたリクエストの数）：

1. Eventmachine（ 以下の詳細 ）
2. ゲベント（ 12500 ）
3. Express.js（ 11500 ）
4. イベントレット（ 9000 ）
5. ツイスト（ 7000 ）
6. 竜巻（ 6500 ）

イベントマシン

Eventmachineはそのパフォーマンスに驚き、競合他社とはかけ離れていました。そのため、特に彼のために負荷を1秒あたり25,000リクエストに増やす必要がありました。 グラフの結果：

CPU負荷

返信数

応答時間（ミリ秒）

エラー数

彼は30,000件のリクエストを処理できるのではないかと疑っていますが、先に進む必要があったため、これを確認できませんでした。 一般に、この時点で、プロジェクトにPythonを使用することは既にわかっていたため、比較のために他の言語のフレームワークが必要でした。

3.ファイル/ Siege / Intel Core i7-4770クアッドコアHaswell、32 GB DDR3 RAM

上に書いたように、私は自分の仕事に完全に満足しているわけではないので、達成感を持って就寝し、「もっとテストが必要だ！」という考えで目が覚めました。 各リクエストに1行のテキストを与えることは確かに良いことですが、これがWebサーバーの唯一の機能ではないため、ファイルを配布します。



このテストでは、10 VPSを使用して必要な負荷を作成しました。 実験的に、1 VPS DigitalOceanでは、平均で100 Mbpsのチャネルが割り当てられていることがわかりました。 1Gbpsチャネルのサーバーがあり、完全にロードする必要がありました。 配布用のファイルは、サイズが異なる10,000個のオンラインストアからの画像でした。 負荷を作成するために、私は次のパラメーターでsiegeユーティリティを使用しました。



siege -i -f fileslist.txt -c 55 -b -t1M







ファイルのリストはfilelist.txtに保存され、55の接続が確立され、それらを介して1分以内にリクエストをサーバーに送り始めます。 ファイルは、fileslist.txtリストからランダムに選択されます。 このテストは同時に10台のマシンで実行されることを考慮する価値があります。つまり、 550ではなく550の同時接続をインストールするということです。 さらに、このオプションを5から55に5単位で絶えず変更して、サーバーの負荷を増やし、50から550の同時接続を確立しました。



ここに得られるものがあります（ X軸に沿って-同時接続の数 ）：

完了したリクエストの数

1秒あたりの処理済みリクエストの数

CPU負荷（％）

RAM消費（32Gbの％）

通信チャネルの負荷（メガバイト/秒）

平均要求応答時間（秒単位）

このテストでは、比較のためにnginx Webサーバーと同様にRAM消費量を追加しました。 ここでボトルネックは通信チャネルであり、1コアでこのチャネル全体を1 Gbpsでロードするには十分です。



結果 （括弧内はエラーなしで処理されたリクエストの数）：

1. ニグン（ 100175 ）
2. イベントレット（ 97925 ）
3. ゲベント（ 96918 ）
4. Express.js（ 96162 ）
5. ツイスト（ 85733 ）
6. 竜巻（ 83241 ）

4. GridFS / Siege / Intel Core i7-4770クアッドコアHaswell、32 GB DDR3 RAM

これで記事の終わりかもしれませんが、プロジェクトでMongoDB GridFSを使用したかったので、その使用によってパフォーマンスがどのように変化するかを確認することにしました。 このテストは3番目のテストに似ていますが、10,000個のすべての画像をMongoDBにアップロードし、データベースからファイルを配布するようにWebサーバーを書き換えました。 それで何が得られますか：

完了したリクエストの数

1秒あたりの処理済みリクエストの数

CPU負荷（％）

RAM消費（32Gbの％）

通信チャネルの負荷（メガバイト/秒）

平均要求応答時間（秒単位）

エラー数

テスト中、Geventにはエラーのある回答があったため、「エラーの数」というグラフを追加しました。 一般に、GridFSを使用できますが、データベース自体がCPUにかなりの負荷をかけることを考慮する価値があります。また、ファイルシステムのすべてが非常に単純な場合、7つの空きコアを自由に使用できました。



結果 （括弧内はエラーなしで処理されたリクエストの数）：

1. Express.js（ 88714 ）
2. ゲベント（ 86182 ）

結論

• MacBook Pro Retinaは、1回の充電で9時間動作します。
• Node.jsは、ネットワークアプリケーションを開発するための唯一のツールではありません。
• Geventのパフォーマンスは非常に優れています。
• 記事の作成には、書くよりも時間がかかります。
• パフォーマンステストは、時間がかかる複雑なプロセスです。

真剣に、それはすべてあなたのプロジェクトが動作する条件に依存します。 膨大な数のテストを実行できますが、サービスが作成されると、すべてが完全に異なる可能性が高くなります。 たとえば、写真の数を10,000から1,000,000に増やすと、通信チャネルではなくハードドライブのパフォーマンスが既にボトルネックになります。

素材

独自のテストを実施したり、さらに詳しく調査したりする場合は、このリストが役立ちます。

報告書

個々のチャートと数字を含む完全なレポートは、次のリンクからダウンロードできます。

1. テキスト/ Httperf / VPS 1 CPU、512Mb RAM
2. テキスト/ Httperf / Intel Core i7-4770クアッドコアHaswell、32 GB DDR3 RAM
3. ファイル/ Siege / Intel Core i7-4770 Quad-Core Haswell、32 GB DDR3 RAM
4. GridFS / Siege / Intel Core i7-4770クアッドコアHaswell、32 GB DDR3 RAM

道具

私のテストでは、以下を使用しました。

• httperf
• オートベンチ
• 包囲

フレームワーク

関連するテスト：

• Gevent （ テキスト 、 ファイル 、 GridFSサーバーコード ）
• Express.js （ テキスト 、 ファイル 、 GridFSサーバーコード ）
• Eventlet （ テキスト 、 ファイルサーバーコード）
• 竜巻 （ テキスト 、 ファイルサーバーコード）
• Eventmachine （ テキストサーバーコード）
• ツイスト （ テキスト 、 ファイルサーバーコード）

ご清聴ありがとうございました。



Twitterで私をフォローしてください。私はスタートアップでの仕事、私の間違いと正しい決断、Python、そしてWeb開発に関連するすべてについて話しています。



PS 会社で開発者を探しています 。詳細は私のプロフィールにあります 。