以下は、50の同時スレッドを使用した10Kリクエストのapacheベンチ実行です。
結果を理解するのに助けが必要ですが、1秒あたりのリクエスト数をブロックおよび制限しているものを指している可能性のある結果で目立つものはありますか？
接続時間のセクションを見ていて、「待機中」と「処理中」が表示されています。待機の平均時間は208、接続の平均時間は0、処理は208です。ただし、合計は208です。あまり意味がないので、誰かがこれを説明してもらえますか。
1412 次
2 に答える
10
接続時間は、サーバーとの接続を確立するのにかかった時間です。おそらく同じサーバーまたはLAN内で実行しているため、接続時間は0です 。処理時間は、サーバーが完全な応答を処理して送信するのにかかった合計時間です。 待ち時間は、リクエストを送信してからレスポンスの 1 バイト目を受信するまでの時間です。
繰り返しますが、同じサーバーで実行していて、ファイルのサイズが小さいため、処理時間 == 待機時間です。
実際のベンチマークについては、ターゲット市場の近くの複数のポイントから ab を試して、レイテンシの実際のアイデアを取得してください。現在、あなたが持っているすべての情報は待ち時間です。
于 2011-12-16T04:43:02.430 に答える
0
この質問は古くなりつつありますが、同じ問題に遭遇したので、回答に貢献することもできます。
エージェント側で TCP nagle を無効にするか、サーバー側で ACK 遅延を無効にすることでメリットが得られる場合があります。それらは相互作用が悪く、不要な遅延を引き起こす可能性があります。私のように、それがおそらく最小時間が正確に200ミリ秒である理由です。
確認はできませんが、TCP 仕様の一部であるため、問題はクロスプラットフォームにあると理解しています。送受信される少量のデータをすばやく接続するためのものかもしれませんが、大規模な転送の問題の報告も見ました. TCP をよく知っている人なら参加できるかもしれません。
参照: http://en.wikipedia.org/wiki/TCP_delayed_acknowledgment#Problems http://blogs.technet.com/b/nettracer/archive/2013/01/05/tcp-delayed-ack-combined-with-nagle -algorithm-can-badly-impact-communication-performance.aspx
于 2014-11-12T22:47:14.640 に答える