FreeBSDのHTTPサーバー（C / C ++）のベンチマーク

7つのC / C ++ライブラリを使用して構築されたHTTPサーバーコアのパフォーマンスと、（教育目的で）この分野の他の既製ソリューション（nginxおよびnode.js）のパフォーマンスを比較しました。

HTTPサーバーは、複雑で興味深いメカニズムです。 コンパイラーを作成しなかったプログラマーは悪いという意見があります。「コンパイラー」を「HTTPサーバー」に置き換えます。これはパーサーであり、ネットワークで動作し、マルチスレッドと非同期で動作します。

すべての可能なパラメーター（静的、動的、さまざまな暗号化モジュール、プロキシなどを返す）のテストは、1か月以上の骨の折れる作業のタスクであるため、タスクは簡素化されます。コアのパフォーマンスを比較します。 HTTPサーバーのコア（ネットワークアプリケーションなど）は、ソケットイベントマネージャーとそれらを処理するための主要なメカニズム（スレッド、プロセスなどのプールとして実装）です。 これには、HTTPパケットパーサーと応答ジェネレーターも含まれます。 一見すると、すべてが非同期イベント（select、epollなど）、それらのメタラッパー（libev、boost.asioなど）およびOSカーネルを処理するための特定のシステムメカニズムの機能をテストすることになりますが、特定の実装ターンキーソリューションとしては、パフォーマンスに大きな違いがあります。

HTTPサーバーのバージョンをlibevに実装しました 。 もちろん、悪名高いrfc2616の要件の小さなサブセットのサポートが実装されています （少なくとも1つのHTTPサーバーがそれを完全に実装しているとは考えられません）。このテストの参加者の要件を満たすために必要な最小限のみ、

1. 8000番目のポートでリクエストをリッスンします。
2. チェック方法（GET）;
3. リクエストのパス（/回答）を確認してください。
4. 答えには以下を含める必要があります。
   

                HTTP / 1.1 200 OK
               サーバー：ベンチ
               接続：キープアライブ
               コンテンツタイプ：テキスト/プレーン
               コンテンツの長さ：2
                42
           

   
   
5. 他の方法\パス-エラーコード404（ページが見つかりません）で応答が返されます。

ご覧のとおり、拡張子なし、ディスク上のファイルアクセス、ゲートウェイインターフェイスなど。 -すべてが最大限に簡素化されます。
_{サーバーがキープアライブ接続をサポートしていない場合（ちなみに、cpp-netlibのみがこれによって区別されました）、それぞれテストが実行されました。 モード。}

背景

最初は、1日あたり何億ものヒットの負荷を持つHTTPサーバーを実装することがタスクでした。 リクエストの90％を生成する顧客の数は比較的少なく、残りの10％を生成する顧客の数は多いと想定されていました。 応答を収集して結果をクライアントに返すために、各要求をさらに他の複数のサーバーに送信する必要があります。 プロジェクトの全体的な成功は、応答の速度と品質に依存していました。 したがって、最初に利用可能な既製のソリューションを使用することは、まったく不可能でした。 次の質問に対する回答を得る必要がありました。

1. 自転車を再発明したり、既存のソリューションを使用したりする価値はありますか？
2. node.jsは負荷の高いプロジェクトに適していますか？ もしそうなら、C ++コードの茂みを捨て、30行ですべてをJSに書き換えます。

たとえば、HTTPキープアライブはパフォーマンスに影響しますか？ （1年後、答えはここに表明されました -それは影響を及ぼし、非常に重要です）。

もちろん、最初に私の自転車が発明され、次にnode.jsが登場し（2年前にそのことを知りました）、知りたいと思いました：既存のソリューションはあなたのものよりもどれだけ効率的で、無駄な時間でしたか？ 実際、この投稿が登場しました。

準備する

鉄

• プロセッサー：CPU：AMD FX（tm）-8120 Eight-Core Processor
• ネットワーク：localhost（理由-TODOを参照）

ソフトウェア

• OS：FreeBSD 9.1-RELEASE-p7

チューニング
通常、ネットワークアプリケーションの負荷テストでは、次の標準設定セットを変更するのが一般的です。


しかし、私のテストでは、パフォーマンスの向上にはつながりませんでしたし、場合によっては大幅な速度低下につながりました。そのため、最終テストではシステムの設定（つまり、すべてのデフォルト設定、GENERICカーネル）に変更は加えられませんでした。

会員

図書館

名	バージョン	イベント	キープアライブサポート	メカニズム
cpp-netlib	0.10.1	Boost.asio	いや	マルチスレッド
手作り	11/11/30	リベフ	はい	マルチプロセス（プロセスごとに1つのスレッド）、非同期
libevent	2.0.21	libevent	はい	シングルスレッド*、非同期
マングース	5.0	選択する	はい	シングルスレッド、非同期、リストあり（詳細）
たまねぎ	0.5	リベフ	はい	マルチスレッド
Pionネットワークライブラリ	0.5.4	Boost.asio	はい	マルチスレッド
POCO C ++ライブラリ	1.4.3	選択する	はい	マルチスレッド（着信接続用の個別のスレッド）、キュー付き（詳細）

既製のソリューション

名	バージョン	イベント	キープアライブサポート	メカニズム
Node.js	10/10/17	libuv	はい	クラスタモジュール（マルチプロセッシング）
nginx	1.4.4	epoll、select、kqueue	はい	マルチプロセッシング

_{*「マルチプロセス-1プロセス1スレッド」スキームに従ってやり直されたテストの場合}

失格

名	理由
nxweb	Linuxのみ
g-wan	Linuxのみ（および一般的に... ）
libmicrohttpd	一定の負荷がかかる
利回り	コンパイルエラー
えー	コンパイルエラー
libhttpd	同期、HTTP / 1.0、ヘッダーの変更は許可されません
リベブ	コンパイルエラー、クラッシュ

クライアントとして、lighttpd- weighttpdの開発者からのアプリケーションを使用しました。 元々は、より柔軟なツールとしてhttperfを使用する予定でしたが、常にクラッシュします。 さらに、weighttpdはlibevに基づいています。これは、selectを使用したhttperfよりもFreeBSDにとってはるかに優れています。 メインテストスクリプト（リソース消費の計算などを伴うweighttpdのラッパー）として、FreeBSD用に再作成されたgwan-ovsky ab.cを検討しましたが、その後Python（アプリケーションのbench.py​​）でゼロから書き直されました。

クライアントとサーバーは同じ物理マシンで実行されていました。
次の値が変数値として使用されました。

• サーバースレッドの数（1、2、および3）
• 同時に開いている顧客リクエストの数（10、100、200、400、800）

各構成では、20〜30回の反復が実行され、反復あたり200万のリクエストが行われました。

結果

記事の最初のバージョンでは、 VBartと外出中のユーザーによるコメントに示されているように、テスト方法で重大な違反が行われました。 そのため、特に、プロセッサコアによるタスクの厳密な分離は使用されず、サーバー\クライアントスレッドの合計数が許容基準を超えました。 また、測定結果に影響するオプション（AMD Turbo Core）は無効化されておらず、測定エラーは示されていません。 記事の現在のバージョンでは、 ここで説明するアプローチを使用しています 。

シングルスレッドモードで実行されているサーバーの場合、次の結果が得られました（サーバー/クライアントストリームの組み合わせの最大中央値が取得されました）。

場所	名	クライアント 流れ	パーセント 時間		お問い合わせ
			カスタム	システム。	成功（秒）	失敗（％）
1	nginx	400	10	10	101210	0
2	マングース	200	12	15	53255	0
3	libevent	200	16	33	39882	0
4	手作り	100	20	32	38550	0
5	たまねぎ	10	22	33	29230	0
6	ポコ	10	25	50	20943	0
7	パイ中間子	10	24	83	16526	0
8	node.js	10	23	173	9374	0
9	cpp-netlib	10	100	183	5362	0

スケーラビリティ：

理論的には、コアがもっとあれば、生産性の直線的な増加が観察されます。 残念ながら、理論を検証することはできません-十分な核がありません。

率直に言って、nginxは私を驚かせました-結局のところ、本質的には既製の多機能モジュール式ソリューションであり、結果は高度に専門化されたライブラリよりも桁違いに優れています。 尊敬。

mongooseはまだ湿っていて、バージョン5.0は実行されておらず、ブランチはアクティブな開発段階にあります。

cpp-netlibは最悪の結果を示しました。 HTTPキープアライブ接続をサポートしなかったのはこれだけでなく、ブーストのどこかでクラッシュしただけでなく、すべての反復を連続して実行することが問題でした。 間違いなく、解決策は粗雑であり、ドキュメントは古くなっています。 法的最後の場所。

node.jsはすでにここでscられているので、私はそれほどカテゴリー的ではありませんが、V8はまだ見続けています。 ペイロードがなくてもリソースを非常に熱心に消費し、テスト参加者の生産性の10〜20％を提供するこの高負荷ソリューションとは何ですか？

HTTPキープアライブのオン/オフ： ポストで差がx2回に達した場合、私のテストでは差はx10まででした。

ミニスタットによる精度：95.0％の信頼度で差は証明されていません。

藤堂

• 「異なるマシン上のクライアントとサーバー」モードでのベンチマーク。 あなたは注意する必要があります-すべてがネットワーク腺に陥り、ネットワークカードのモデルだけでなく、スイッチ、ルーターなどにも出くわす可能性があります。 -実マシン間のインフラストラクチャ全体。 手始めに、直接接続を試すことができます。
• クライアントHTTP APIのテスト（サーバーおよびプロキシとして編成）。 問題は、すべてのライブラリがHTTPクライアントを実装するためのAPIを提供しているわけではないことです。 一方、人気のあるライブラリ（libcurlなど）には、クライアント側のAPIセットのみが用意されています。
• 他のHTTPクライアントの使用。 httperfは上記の理由で使用されていません。ab-多くのレビューは時代遅れであり、実際の負荷を保持していません。 多くの人が推奨しています。 いくつかのソリューションをいくつか紹介しますが、そのうちのいくつかを比較する必要があります。
• Linux環境での同様のベンチマーク。 これは興味深いトピックになります（少なくとも、ホリバーの議論の新しい波）。
• 多数のコアを搭載した上位のIntel Xeonでテストを実行します。

参照資料

httperf、siege、apacheベンチマーク、pronkのストレステスト -サーバーの負荷テスト用のHTTPクライアント。
Httperfを使用したパフォーマンステスト -ベンチマークのヒントとコツ 。
ApacheBenchとHTTPerf -G-WANのベンチマークプロセスの説明。
ワープは別の高負荷の苦情HTTPサーバー、Haskellです。

アプリ

アプリケーションでは、すべてのテストの反復のソースと結果、およびHTTPサーバーのアセンブリとインストールに関する詳細情報を確認できます。