Apacheのabベンチマークツールの結果をどのように解釈する必要がありますか？
了解しました。どこでも検索しましたが、Apacheのabサーバーベンチマークツールの結果を解釈する方法について、オンラインで詳細なリソースを見つけることができないようです。大幅に異なるパラメーターであると考えたものを使用していくつかのテストを実行しましたが、非常に似た結果が表示されました（これが私のサイトが完全にスケーリングしていることを意味するとは思いもしません！）。このテストの結果を理解する方法について、誰かが私に指摘できる詳細なリソースがある場合、または誰かがここでそれを作成したいと思う場合、それは私や他の人にとって非常に役立つと思います。
イライラしませんか？私は同じことをしようとしています。新しくプロビジョニングおよび構成された専用サーバーが他のサーバーとどのように比較されるかを確認してください。
私がやっていることは、現在の本番サーバー（デュアルコア4GB RAM）を新しいサーバー（クアッドコア8GB RAM）と比較することです。
本番サーバーは稼働しており、ユーザーのためにサーバーを「破壊」したくないので、並べて比較して「ニースを再生」する必要があります。
Phpinfo（）を呼び出すだけのphpページで、現在のコマンドと新しいコマンドを次のコマンドで比較します。ab -kc 20 -t 6
現在の本番サーバーでは、次のようなものが表示されますが、指定された時間内にタスクを完了できませんでした。
Time taken for tests: 60.1234 seconds
Complete requests: 24538
Failed requests: 58
(Connect: 0, Length: 58, Exceptions: 0)
Requests per second: 408.96 [#/sec] (mean)
Time per request: 48.905 [ms] (mean)
Time per request: 2.445 [ms] (mean, across all concurrent requests)
すべてのテストを半分の時間で完了した新しいサーバーで以下を実行します。
Time taken for tests: 29.838791 seconds
Complete requests: 50000
Failed requests: 11
(Connect: 0, Length: 11, Exceptions: 0)
Requests per second: 1675.67 [#/sec] (mean)
Time per request: 11.936 [ms] (mean)
Time per request: 0.597 [ms] (mean, across all concurrent requests)
現在、サーバーはベンチマークテストに加えて20のWebサイトを処理しているため、これは実際には「公正な」テストではありません。また、実際にはApacheとphpのみをテストしています。
私のより複雑なホームページの1つ、現在のサーバーで「遅い」と感じるホームページに対してこれと同じテストを行うと、次のように表示されます。現在のサーバー：
Time taken for tests: 60.14170 seconds
Complete requests: 510
Requests per second: 8.50 [#/sec] (mean)
Time per request: 2353.497 [ms] (mean)
Time per request: 117.675 [ms] (mean, across all concurrent requests)
新しいサーバー：
Time taken for tests: 60.18651 seconds
Complete requests: 1974
Requests per second: 32.89 [#/sec] (mean)
Time per request: 608.092 [ms] (mean)
Time per request: 30.405 [ms] (mean, across all concurrent requests)
このテストは、動的に生成されたJoomla CMSページをロードしています。これは、もう少し「現実世界」のテストです。繰り返しになりますが、新しいサーバーは現在のサイトトラフィックを処理していないため、アップルトゥアップルの比較ではありません。これ以上難しいテストをしたくない、または自分のサイトでのエンドユーザーエクスペリエンスのリスクを冒したい。
サイトを新しいサーバーに移行した後、上記のテストを再度実行して、通常のサイトトラフィックがベンチマークに及ぼす影響を確認します。同じマシンの生産対アイドルベンチマークの結果。
今、私はまた、新しいサーバーにストレスをかけ、それがうまく反応することを確認しています。コマンドの実行ab -n 50000 -c 2topコマンドを監視しており、*f5*ブラウザでページを表示して、エラーが発生するかどうかを確認し、サーバーが応答するのにかかる時間を確認します。
私の最初のテストは私に与えました：
Concurrency Level: 200
Time taken for tests: 692.160011 seconds
Complete requests: 50000
Failed requests: 30102
(Connect: 0, Length: 30102, Exceptions: 0)
Write errors: 0
Non-2xx responses: 30102
Total transferred: 456568770 bytes
HTML transferred: 442928962 bytes
Requests per second: 72.24 [#/sec] (mean)
Time per request: 2768.640 [ms] (mean)
Time per request: 13.843 [ms] (mean, across all concurrent requests)
Transfer rate: 644.17 [Kbytes/sec] received
リクエストの失敗率が非常に高いことに注意してください。私のApacheは最大250の同時リクエストに設定されていますが、私のMySQLはわずか175でした。MySQLがここでの障害点でした。 Apacheからのすべてのリクエストを処理できませんでした。 Webブラウザーのページが読み込まれると、多くのページの更新でMySQL接続エラーページが表示されていました。
それで、MySQLを300の同時リクエストにバンプしました（すでに実行しましたが、MySQLを再起動するのを忘れていたため、これは良いテストであることがわかりました-必要な変更を特定し、誤って変更の妥当性を検証する実証テストを行いました必要性）。
次の実行では、次の結果が得られました。
Concurrency Level: 200
Time taken for tests: 1399.999463 seconds
Complete requests: 50000
Failed requests: 5054
(Connect: 0, Length: 5054, Exceptions: 0)
Write errors: 0
Non-2xx responses: 5054
Total transferred: 1016767290 bytes
HTML transferred: 995713274 bytes
Requests per second: 35.71 [#/sec] (mean)
Time per request: 5599.998 [ms] (mean)
Time per request: 28.000 [ms] (mean, across all concurrent requests)
Transfer rate: 709.24 [Kbytes/sec] received
これには2倍の時間がかかりましたが、失敗したリクエストの割合ははるかに低かった。基本的に、サーバーは私のサイトのホームページの少なくとも200の同時ページビューを処理できるように構成されていますが、ページを表示するのに5秒かかります。素晴らしいとは言えませんが、以前に発生したMySQLエラーよりもはるかに優れています。
このすべての間、サーバーのCPU使用率は100％に固定され、「負荷平均」は180を超えています。MySQLはCPUの約8〜9％を使用しており、RAM同じページを繰り返しハンマーで叩いているので、割り当てました。単一のデータベースのみを処理します。4GB以上の400MBに拡張するように構成されています。topは、バッファとキャッシュされたメモリ使用量は、使用可能なRAM全体の約50％です。したがって、このテストでマシンをロードしている間、過負荷ポイントに近づいていません。実際のデータベース使用量では、MySQLはメモリの多くを取得する必要があります。が割り当てたので、サーバーはその時点でフルロードにかなり近いはずです。
私の次のテストは、250接続の「全負荷」でApacheをテストすることでしたab -n 50000 -c 25
Concurrency Level: 250
Time taken for tests: 1442.515514 seconds
Complete requests: 50000
Failed requests: 3509
(Connect: 0, Length: 3509, Exceptions: 0)
Write errors: 0
Non-2xx responses: 3509
Total transferred: 1051321215 bytes
HTML transferred: 1029809879 bytes
Requests per second: 34.66 [#/sec] (mean)
Time per request: 7212.577 [ms] (mean)
Time per request: 28.850 [ms] (mean, across all concurrent requests)
Transfer rate: 711.73 [Kbytes/sec] received
これは、適切なMySQL接続キャップを使用した200接続テストと同様の結果を示しています。これは私にとって良いことだと思います。 7秒でページが返されるのは好きではありませんが、APCまたはMemcacheのいずれかがインストールされているがまだJoomlaで使用されていない状態で、Joomlaでキャッシュを有効にすることで、Joomlaレベルでそれを改善できると思います。
運を押し上げようとして、300回の同時接続を試してみようと思いました。 ab -n 50000 -c 3ブラウザーは、ページの迅速なロードに長時間待機しています。それ以外の場合は、結果に大きな変化はありません。
Concurrency Level: 300
Time taken for tests: 1478.35890 seconds
Complete requests: 50000
Failed requests: 2266
(Connect: 0, Length: 2266, Exceptions: 0)
Write errors: 0
Non-2xx responses: 2266
Total transferred: 1079120910 bytes
HTML transferred: 1057241646 bytes
Requests per second: 33.83 [#/sec] (mean)
Time per request: 8868.215 [ms] (mean)
Time per request: 29.561 [ms] (mean, across all concurrent requests)
Transfer rate: 712.99 [Kbytes/sec] received
これらの結果の私の解釈が「正しい」のかどうか、または価値のある何かを見逃しているのかどうかはわかりませんが、見つけることができた指示がないため、これが思いついたものです。
結果を使用して、適切な応答率が得られたことを確認しました。完全な応答率の欠如が気になりますが、検査する方法で障害を確認または再現する方法がわかりません。
リクエストごとの遅い時間も気になりますが、アプリケーション層でその多くに対処できると思います。
サーバーのクロールは遅くなりますが、負荷の高い状況を処理できると確信しています。
これらのベンチマークテストの後でMonYogのような他のパフォーマンスチューニングツールを見ると、私の現在の構成は「十分に良い」ことがわかりました。
ハードウェアの説明とソフトウェアの構成で再現できるテストの結果を人々が投稿してくれる場所があればいいのにと思います。そうすれば、自分が「競争力がある」のか、自分の機器を最大限に活用するためにまだやるべきことがたくさんあるのかがわかります。したがって、なぜ私は自分の結果を投稿しているのですか。
「失敗した要求」行の場合、失敗した要求は、後続の要求の長さを相互に比較することによって判別されることに注意してください。動的なWebサイトの場合、これは要求がまったく失敗したことを意味する必要はありません。したがって、失敗した要求行について心配する必要はありません。
クルーザームの答えの上に。ここにいくつかのより多くの情報との非常に良いリンクがあります
https://serverfault.com/questions/274252/Apache-ab-please-explain-the-output
線の違いについてもっと知りたい
Time per request: 7.303 [ms] (mean)
Time per request: 0.730 [ms] (mean, across all concurrent requests)
余談ですが、ABはシングルスレッドです（2001 Pentium 4のような古いシングルコアCPUでは問題ありません）。
WebサーバーをホストするマルチコアCPU（複数のプロセスを使用するNginx/Lighty、複数のスレッドを使用するApache）をテストするには、Weighttp（ABと互換性があります）を使用する必要があります。
「Weighttp-t6」は6つのクライアントスレッドを実行します（対照的に、「AB -t6」は6秒のテストを実行します）。
複数のクライアントスレッド（Webサーバーワーカーの数と同じ数-サーバーボックスのCPUコアの数と一致する必要があります）を使用すると、より関連性の高い結果が得られます。
Time per request: 7.303 [ms] (mean)
Time per request: 0.730 [ms] (mean, across all concurrent requests)
最初の1つは同時ユーザーあたりのリクエストの平均時間に関連しているため、1000リクエストと200の同時ユーザーをテストする場合、最初の1つは各200リクエストの平均時間になります。 2つ目は、1000回のリクエスト全体の平均時間である全体的なリクエスト時間に関連しています。