Battle of the Balancersは、WebSocketをサポートするバランサー/プロキシの負荷テストです。 これらのテクノロジーは、インフラストラクチャのスケーリングに不可欠です。
次のテクノロジーがテストされました。
-http
-proxy 、バージョン：0.10.0
-HAProxy、バージョン：1.5-dev18（開発リリース）
-制御テスト用の基本的な「エコーサーバー」。
腰痛に疑いがあり
ました 。 除外された理由は簡単です
-http-proxyに基づいて構築されています。 現時点では、彼らはプロジェクトのフォークを使用しています。このプロジェクトでは、パフォーマンスに関連するパッチはまったくありません。
テストのために、3つの異なる接続されていないサーバーが使用され
ました 。
1.プロキシ、512Mb、Ubuntuサーバー。 すべてのプロキシがこのサーバーにインストールされました。 画像：sdc：jpc：ubuntu-12.04：2.4.0
2. WebSocketエコーサーバーが回転していたNode.jsを備えた512MBの「スマートマシン」WebSocketサーバー。 サーバーはNode.jsで記述されており、クラスターモジュールを使用して複数のカーネルで実行されます。 画像：sdc：sdc：nodejs：1.4.0
3.トール、512MB、Node.js上のもう1つの「スマートマシン」。前の仕様と同様の仕様です。 このサーバーから必要な負荷を生成しました。 Thorは、当社が開発したWebSocket負荷生成ツールです。 このアプリケーションはオープンソースで配布されており、
http：//github.com/observing/thorで入手でき
ます 。
プロキシ設定
プロキシサーバーは、Ubuntu 12.04を備えた「クリーン」サーバーでした。 すべての依存関係を構成およびインストールするために、次の手順が実行されました。 最新バージョンで作業していることを確認するには、次を実行します。
apt-get upgrade
次の依存関係がシステムにインストールされました。
-githubリポジトリにアクセスするgit
-ソースからプロキシをコンパイルするために不可欠なビルド、ほとんどのプロキシはWebSocketまたはHTTPSのサポートを最近取得したばかりです
-HTTPSをサポートするにはlibssl-devが必要です
-スタッドにはlibev-devが必要です。これはすごいです
apt-get install git build-essential libssl-dev libev-dev
Node.js
Node.jsはhttp-proxyに必要です。 http-proxyはNode.jsの最新バージョンを使用しますが、これらのテストはすべての依存関係の互換性を確保するためにバージョン0.8.19で実行されました。 Node.jsはgithubで複製されています。
git clone git://github.com/joyent/node.git cd node git checkout v0.8.19 ./configure make make install
このプロジェクトの依存関係をインストールできるように、バイナリnpmがインストールされます。 このリポジトリとhttp-proxyのルートでnpm installを実行すると、すべての依存関係が自動的にインストールされます。
Nginx
Nginxはすでに普及しているサーバーです。 さまざまなサーバーバックエンドへのプロキシをサポートしていますが、WebSocketはサポートしていません。 少し前までは、Nginxブランチの開発に追加されました。 したがって、最新の開発バージョンをインストールし、ソースからコンパイルしました。
この記事のテストと執筆以来、nginx 1.4.0がリリースされており、WebSocketがサポートされています。 したがって、この記事を読んでいて本番環境に展開する予定がある場合は、バージョン1.4.0を使用することをお勧めします。 開発バージョンの代わりに。 wget http://nginx.org/download/nginx-1.3.15.tar.gz tar xzvf nginx-1.3.15.tar.gz cd nginx-1.3.15 ./configure --with-http_spdy_module --with-http_ssl_module \ --pid-path=/var/run/nginx.pid --conf-path=/etc/nginx/nginx.conf \ --sbin-path=/usr/local/sbin --http-log-path=/var/log/nginx/access.log \ --error-log-path=/var/log/nginx/error.log --without-http_rewrite_module
これらのオプションからわかるように、SSL、SPDYをオンにし、他のいくつかの設定を使用しました。 最終的に、この一般的な構成が出てきました。
Configuration summary + PCRE library is not used + using system OpenSSL library + md5: using OpenSSL library + sha1: using OpenSSL library + using system zlib library nginx path prefix: "/usr/local/nginx" nginx binary file: "/usr/local/sbin" nginx configuration prefix: "/etc/nginx" nginx configuration file: "/etc/nginx/nginx.conf" nginx pid file: "/var/run/nginx.pid" nginx error log file: "/var/log/nginx/error.log" nginx http access log file: "/var/log/nginx/access.log" nginx http client request body temporary files: "client_body_temp" nginx http proxy temporary files: "proxy_temp" nginx http fastcgi temporary files: "fastcgi_temp" nginx http uwsgi temporary files: "uwsgi_temp" nginx http scgi temporary files: "scgi_temp"
その後：
make make install
HAProxy
HAProxyは、以前はtcpモードでWebSocketをプロキシでき、現在はhttpモードでもプロキシできました。 HAProxyはHTTPS終了のサポートも受けました。 そのため、開発ブランチをインストールする必要があります。
wget http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev18.tar.gz tar xzvf haproxy-1.5-dev18.tar.gz cd haproxy-1.5-dev18 make TARGET=linux26 USE_OPENSSL=1 make install
スタッド
HAProxyにはSSL終了機能がありますが、スタッドは通常、HAProxyの前のSSL終了に使用されます。 そして、これも検証したいと思います。
git clone git://github.com/bumptech/stud.git cd stud make make install
すべてがインストールされたので、構成ファイルを構成する必要があります。 Nginxの場合、nginx.confをこのリポジトリのルートから/etc/nginx/nginx.confにコピーできます。 他のプロキシはその場で構成できます。
カーネル調整
すべてのプロキシをインストールした後、ソケットの調整が必要です。 この情報をインターネットから取得しました。
vim /etc/sysctl.conf
そして、次の値が設定されます。
ベンチマーク
2つの異なるテストが実行されます。
1. SSLなしでテストプロキシサーバーを読み込みます。 この場合、WebSocketプロキシのパフォーマンスのみをテストします。
2.テストプロキシサーバーにSSLをロードします。 安全でないWebSocketを使用しないでください。 ブラウザの接続が非常に悪いです。 ただし、ここではSSL終了プロセス中にプロキシサーバーに余分な負荷が追加されます。
2つのテストに加えて、異なる数の化合物を試します。
-2k
-5k
-10k
また、同じ結果を得るために：
-20k
-3万
各テストの前に、すべてのWebSocketサーバーがリセットされ、プロキシが再初期化されます。 Thorは、すべてのプロキシにX個の接続と100の同時接続をロードします。 確立された接続ごとに、1つのUTF-8メッセージが送受信されます。 メッセージを受信した後、接続は閉じられます。
打ち上げ
スタッド
stud --config stud.conf
HAProxy
haproxy -f ./haproxy.cfg
Nginx
nginx
HTTPプロキシ
FLAVOR=http node http-proxy.js
WebSocketServer
FLAVOR=http node index.js
結果
http-proxyはその名の通り、リクエストをプロキシし、十分高速に処理します。 しかし、以来 Node.jsに基づいており、多くのメモリを消費します。 最も単純なノードプロセスでも、12 MB以上のメモリが必要です。 1万件のクエリの場合、約70 MBのメモリが必要でした。 コントロールテストと比較して、HTTPプロキシは5秒以上かかりました。 Node.jsがSSLを介して失われているため、予想どおりHTTPSは最も遅い結果を示しました。 そして、これは、重い負荷の下で、メインイベントループを完全に停止するという事実は言うまでもありません。
メモリ使用量を大幅に削減するhttp-proxyの
プルリクエストがあります。 手動でパッチを適用した結果、食べた記憶が半分になりました。 それでも、パッチの後でも、Nginxと比較してより多くのメモリを使用します。これは、純粋なCで後者を記述することで簡単に説明できます。
私はNginxに大きな期待を持っていましたが、それは私を失敗させませんでした。 彼は10 MBを超えるメモリを使用せず、非常に迅速に解決しました。 Nginxを初めてテストしたとき、ひどいパフォーマンスを示しました。 NodeはNginxよりもSSLでさらに速い結果を示しましたが、何らかのエラーがあるはずだと感じました。Nginxの設定は間違っているはずです。 友人からのいくつかのヒントの後、設定の1行を実際に変更しました-暗号化設定が正しくありませんでした。 openssl s_client -connect serverを使用した少しの設定と確認：すべてが修正されました（現在、デフォルトでは本当に高速なRC4暗号化が使用されています）。
次に、HAProxyがありました。これは、NGINXと同じパフォーマンスを示しましたが、必要なメモリはより少なく（7 MB）でした。
最大の違いは、HTTPSでのテスト時でした。非常に遅く、Nginxに近いものでもありませんでした。 これが修正されることを願っています、なぜなら これまでのところ、開発ブランチのみをテストしました。 次に、Nginxと同じ間違いをし
ました 。暗号化が正しく構成されてい
ません 。これは
HackerNewsで正しく認識され
ました 。 HTTPSのテストに加えて、示されているパフォーマンスをテストするために、その前にスタッドを設置しました。
結論
http-proxyは非常に柔軟なプロキシであり、簡単に拡張および追加できます。 実稼働環境で使用する場合は、SSL終了のためにその前でスタッドを実行することをお勧めします。
nginxとhaproxyは非常に近い結果を示しましたが、そのうちの1つがより高速またはより良いと言うことは困難です。 しかし、管理の観点からそれらを見ると、スタッドおよびhaproxyよりも1つのnginxを使用して展開および操作する方が簡単です。
HTTP
| プロキシ | 接続 | 握手（中） | レイテンシー（中） | 合計 |
|---|
| HTTPプロキシ | 10k | 293ミリ秒 | 44ミリ秒 | 30168ミリ秒 |
| nginx | 10k | 252ミリ秒 | 16ミリ秒 | 28433ミリ秒 |
| ハプロキシ | 10k | 209ミリ秒 | 18ミリ秒 | 26974ミリ秒 |
| 制御 | 10k | 189ミリ秒 | 16ミリ秒 | 25310ミリ秒 |
勝者 ：NginxとHAProxyは非常に高速で、結果は近いです。
Https
| プロキシ | 接続 | 握手（中） | レイテンシー（中） | 合計 |
|---|
| HTTPプロキシ | 10k | 679ミリ秒 | 62ミリ秒 | 68670ミリ秒 |
| nginx | 10k | 470ミリ秒 | 30ミリ秒 | 50 180ミリ秒 |
| ハプロキシ | 10k | 464ミリ秒 | 25ミリ秒 | 50058ミリ秒 |
| haproxy +スタッド | 10k | 492ミリ秒 | 42ミリ秒 | 52403ミリ秒 |
| 制御 | 10k | 703ミリ秒 | 65ミリ秒 | 71500ミリ秒 |
勝者 ：NginxとHAProxyは非常に高速で、結果は近いです。
すべてのテスト結果は、
https ：
//github.com/observing/balancerbattle/tree/master/resultsで入手できます
。寄稿
すべての構成はリポジトリ内にあります。サーバーのパフォーマンスが向上するかどうかを確認できれば幸いです。