下面是一个运行 10K 请求和 50 个并发线程的 apache bench。
我需要帮助来理解结果,结果中是否有任何突出的东西可能指向阻塞和限制每秒更多请求的东西?
我正在查看连接时间部分,并查看“等待”和“处理”。它显示平均等待时间为 208,平均连接时间为 0,处理时间为 208..但总数为 208。有人可以向我解释一下,因为这对我来说没有多大意义。
下面是一个运行 10K 请求和 50 个并发线程的 apache bench。
我需要帮助来理解结果,结果中是否有任何突出的东西可能指向阻塞和限制每秒更多请求的东西?
我正在查看连接时间部分,并查看“等待”和“处理”。它显示平均等待时间为 208,平均连接时间为 0,处理时间为 208..但总数为 208。有人可以向我解释一下,因为这对我来说没有多大意义。
连接时间是 ab 与您的服务器建立连接所花费的时间。您可能在同一台服务器或局域网内运行它,因此您的连接时间为 0。 处理时间是服务器处理和发送完整响应所花费的总时间。 等待时间是从发送请求到接收到响应的第一个字节之间的时间。
同样,由于您在同一台服务器上运行,并且文件很小,因此您的处理时间 == 等待时间。
对于真正的基准,请从目标市场附近的多个点尝试 ab,以真正了解延迟。现在,您拥有的所有信息都是等待时间。
这个问题已经老了,但我遇到了同样的问题,所以我不妨提供一个答案。
您可能会受益于在代理端禁用 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