有人可以解释这些 apache bench 结果吗？有什么突出的吗？
下面是一个针对 10K 请求和 50 个并发线程运行的 apache 工作台。
我需要帮助理解结果，结果中是否有任何突出的内容可能表明每秒阻止和限制更多请求？
我正在查看连接时间部分，并看到“等待”和“处理”。它显示平均等待时间是 208，平均连接时间是 0，处理时间是 208。但总数是 208。有人可以向我解释一下吗，因为这对我来说没有多大意义。
Below is a apache bench run for 10K requests with 50 concurrent threads.
I need help understanding the results, does anything stand out in the results that might be pointing to something blocking and restricting more requests per second?
I'm looking at the connection time section, and see 'waiting' and 'processing'. It shows the mean time for waiting is 208, and the mean time to connect is 0 and processing is 208..yet the total is 208. Can someone explain this to me as it doesn't make much sense to me.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
连接时间是ab与您的服务器建立连接所花费的时间。您可能在同一台服务器上或 LAN 内运行它，因此您的连接时间为 0。
处理时间是服务器处理和发送完整响应所花费的总时间。
等待时间是发送请求和接收响应的第一个字节之间的时间。
同样，由于您在同一台服务器上运行，并且文件大小较小，因此您的处理时间==等待时间。
对于真正的基准测试，请从目标市场附近的多个点尝试 ab，以了解延迟的真实情况。现在您拥有的所有信息都是等待时间。
Connect time is time it took ab to establish connection with your server. you are probably running it on same server or within LAN, so your connect time is 0.
Processing time is total time server took to process and send complete response.
Wait time is time between sending request and receiving 1st byte of response.
Again, since you are running on same server, and small size of file, your processing time == wait time.
For real benchmark, try ab from multiple points near your target market to get real idea of latency. Right now all the info you have is the wait time.
这个问题已经过时了，但我遇到了同样的问题，所以我不妨提供一个答案。
您可能会受益于禁用代理端的 TCP nagle 或服务器端的 ACK 延迟。它们可能会产生不良交互并导致不必要的延迟。像我一样，这可能就是为什么你的最短时间恰好是 200 毫秒。
我无法确认，但我的理解是问题是跨平台的，因为它是 TCP 规范的一部分。它可能只是为了快速连接发送和接收的少量数据，尽管我也看到过有关较大传输的问题的报告。也许更了解 TCP 的人可以参与进来。
参考：
http://en.wikipedia.org/wiki/TCP_delayed_acknowledgment#Problems
This question is getting old, but I've run into the same problem so I might as well contribute an answer.
You might benefit from disabling either TCP nagle on the agent side, or ACK delay on the server side. They can interact badly and cause an unwanted delay. Like me, that's probably why your minimum time is exactly 200ms.
I can't confirm, but my understanding is that the problem is cross-platform since it's part of the TCP spec. It might be just for quick connections with a small amount of data sent and received, though I've seen reports of issues for larger transfers too. Maybe somebody who knows TCP better can pitch in.
Reference:
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