ABによる負荷テスト…偽の失敗したリクエスト（長さ）

自分の好奇心のために、サーバーで負荷テストを行うために実行しました。

ab -kc 50 -t 200 http://localhost/index.php

これにより、200秒で50のキープアライブ接続が開かれ、index.phpのリクエストでサーバーがスラムします。

私の結果では、私は得ます：

Concurrency Level:      50
Time taken for tests:   200.007 seconds
Complete requests:      33106
Failed requests:        32951
   (Connect: 0, Receive: 0, Length: 32951, Exceptions: 0)
Write errors:           0
Keep-Alive requests:    0
Total transferred:      1948268960 bytes
HTML transferred:       1938001392 bytes
Requests per second:    165.52 [#/sec] (mean)
Time per request:       302.071 [ms] (mean)
Time per request:       6.041 [ms] (mean, across all concurrent requests)
Transfer rate:          9512.69 [Kbytes/sec] received

32951の「失敗した」要求に注意してください。これはわかりません。

テストが実行されている間、ページの下部にあるページの読み込み時間は通常の.02ではなく.5と報告されていましたが、自宅のコンピューターからWebサイトに完全にアクセスできました。ただし、リクエストに失敗したことは一度もありません。

では、なぜABは接続の半分が失敗したと報告しているのですか？その意味で「長さ」とはどういう意味ですか？

気にしないで。「長さの失敗」は、応答の長さが異なる時間の約半分であることを単に示しています。

コンテンツは動的であるため、おそらくセッション識別子かそのようなものです。

別の言葉で問題を説明するには：

Apacheベンチマークツール（ab）は、テスト全体で応答コンテンツの長さが同じであることを前提としています。最初の応答のコンテンツの長さを格納します。以降の応答のいずれかでコンテンツの長さが異なる場合、「長さの失敗」が発生します。

次のapacheバグレポートは、次のことを確認しているようです：ASFバグ42040

要約：可変長のコンテンツを提供する場合は、この種のabリクエストの失敗を無視する必要があります。

編集：abコマンドに新しい（少なくとも私にとっては）オプションがあることに最近気づきました。

-l   Accept variable document length (use this for dynamic pages)

私はそれを見ることができるABバージョン2.3 <$リビジョン：1528965 $>が、でそれを見ることができないABバージョン2.3 <$リビジョン：655654 $>それはおそらく、比較的最近追加されたので、。

古い質問を復活させて申し訳ありませんが、それはグーグルでポップアップした最初のものでした。abによって報告される長さエラーは、実際の問題が原因である場合があります。Content-Lengthヘッダーで宣言された合計バイト数がクライアントによって受信されないうちにサーバー側で接続が閉じられた場合。これは、クライアントとサーバーの間に他のパーティ、たとえば、単純な手作りのロードバランサー（私の場合）がある場合に発生する可能性があります。