ApacheBenchを使用してUbuntu13.10VPSで負荷テストを行う方法
序章
負荷テストは、展開する前に行うことをお勧めします。 将来、より詳細なテストを実行する前に、プロジェクトのベストケースシナリオをすばやく確立するのは良いことです。
ApacheBench ツール(ab)は、任意の数の同時リクエストを送信することでテストサーバーをロードできます。 abはApacheのインストールをテストするために設計されましたが、任意のHTTPサーバーのベンチマークに使用できます。
このチュートリアルでは、さまざまなサーバーを使用するRubyインタープリターが負荷の下でどのように機能するかを確認します。 チュートリアルの手順は、新しいUbuntu13.10×32イメージを想定しています。 結果は512MBの液滴から得られました。
インストール
パッケージデータベースを更新します。
apt-get update
apache2-utilsパッケージをインストールして、ApacheBenchにアクセスします。
apt-get install apache2-utils
制限付き特権ユーザー
次に、Rubyを管理するユーザーを作成します。 次のセクションのコマンドの一部をrootとして実行することはお勧めできません。
useradd -m -d /home/test -s /bin/bash -g sudo test
このコマンドの実行内容:
-
useradd-新しいユーザーを作成します
-
-m-ホームディレクトリを作成します
-
-d / home/test-ユーザーのホームディレクトリを/home/testに設定します
-
-s / bin / bash-ユーザーのデフォルトのシェルbashを作成します(Ubuntuはデフォルトでダッシュを使用します)
-
-g sudo-sudoグループにユーザーを追加します(sudoでコマンドを実行する場合)
-
test-新しいユーザーの名前
新しいユーザーのパスワードを設定します。
passwd test
新しいユーザーに切り替えます。
su test
RVM
Rubyバージョンマネージャーを使用すると、さまざまなRuby環境で簡単に作業できます。 特定のRubyバージョンをインストールしてgemsetを分離するプロセスを処理します。 現在、Webサイトからbashスクリプトを実行してインストールされています。
\curl -L https://get.rvm.io | bash -s stable
rvmコマンドを使用するには、最初にrvmスクリプトを実行する必要があります。
source ~/.rvm/scripts/rvm
必要に応じて、それを.bashrcに配置して、ユーザーとしてログインするたびにrvmを使用できるようにすることができます。
echo "source ~/.rvm/scripts/rvm" >> ~./bashrc
タイプの先頭を確認することで、rvmスクリプトが使用されていることを確認できます。 これは関数であり、ハッシュされてはなりません。
type rvm | head -1
rvm is a function
次に、Ruby2.0.0をインストールします。 RVMは、Rubyを作成する前にさまざまな依存関係をインストールする必要があるため、ユーザーのパスワードを要求します。 RVMはソースからRubyを構築するため、この手順には時間がかかる場合があります。
rvm install 2.0.0
新しいRubyに切り替えます。 これは、インストール後にデフォルトで発生する可能性がありますが、チェックしても問題はありません。
rvm use 2.0.0
テスト
Rubyがインストールされたので、簡単なサイトを作成して、処理できるリクエストの数を確認できます。
Sinatraをインストールします。 これは、RubyWebアプリケーションを作成するためのマイクロフレームワーク/DSLです。 –no-*フラグはドキュメントをスキップします。
gem install sinatra --no-rdoc --no-ri
「helloworld」をエコーするだけのサンプルsinatraアプリを作成します。
cd ~
vim app.rb
# app.rb
require 'sinatra'
get '/' do
'hello world'
end
サーバーを実行します。
ruby app.rb
サーバーが最終的に稼働したら、負荷テストを開始できます。 abの呼び出しは次のようになります。
ab -n <num_requests> -c <concurrency> <addr>:<port><path>
別のターミナルを開き、サーバーにSSH接続します。 ApacheBenchを使用してテストを実行します。 100の同時実行で1000のリクエストを使用しました。 パスの最後の「/」を忘れないでください。
ab -n 1000 -c 100 http://localhost:4567/
Server Software: WEBrick/1.3.1
Server Hostname: localhost
Server Port: 4567
Document Path: /
Document Length: 11 bytes
Concurrency Level: 100
Time taken for tests: 3.410 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 288000 bytes
HTML transferred: 11000 bytes
Requests per second: 293.23 [#/sec] (mean)
Time per request: 341.034 [ms] (mean)
Time per request: 3.410 [ms] (mean, across all concurrent requests)
Transfer rate: 82.47 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 2.0 0 11
Processing: 185 332 90.3 311 578
Waiting: 28 280 83.2 267 574
Total: 193 333 89.7 311 578
Percentage of the requests served within a certain time (ms)
50% 311
66% 357
75% 423
80% 446
90% 467
95% 480
98% 490
99% 501
100% 578 (longest request)
私の結果は約300リクエスト/秒に収束しました。 WEBrickはその速度で知られていません。 先に進み、Ctrl-cでサーバーに割り込んでください。
Thinをインストールする
Thin は、解析にMongrelを使用し、非ブロッキングIOにEventMachineを使用する人気のあるrubyWebサーバーです。 Thinをインストールして、サーバーを再実行します。 SinatraはThinを自動的にロードし、通知する必要があります(「…Thinからのバックアップあり」)。
gem install thin
ruby app.rb
ここで、負荷テストを再試行します。 今回はもう少し速いはずです。
Server Software: thin
Server Hostname: localhost
Server Port: 4567
Document Path: /
Document Length: 11 bytes
Concurrency Level: 100
Time taken for tests: 1.339 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 244000 bytes
HTML transferred: 11000 bytes
Requests per second: 747.00 [#/sec] (mean)
Time per request: 133.870 [ms] (mean)
Time per request: 1.339 [ms] (mean, across all concurrent requests)
Transfer rate: 178.00 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 1.8 0 8
Processing: 55 128 19.9 132 155
Waiting: 42 116 19.7 121 144
Total: 62 129 18.5 132 156
Percentage of the requests served within a certain time (ms)
50% 132
66% 135
75% 137
80% 139
90% 144
95% 149
98% 152
99% 155
100% 156 (longest request)
少なくともこの場合、Thinは700リクエスト/秒以上でWEBrickよりも著しく高速なサーバーを作成しているように見えます(リクエストの総数を増やすことを試みることができますが、私にとってはそれほど高くなりませんでした)。
注:ArchLinuxドロップレットで1000リクエスト/秒を取得できました。
結論
明らかに、これらの結果は現実的なサーバーパフォーマンスを反映していません。 HTTPはパズルのほんの一部です。 遅いテンプレートエンジンやデータベースは、これらの数値を大幅に引き下げます。 それでも、それはあなたに比較のための簡単な球場の数字を与えます。
あなたが興味を持っているかもしれない他のパフォーマンスツール: