这意味着一个单一的测试,共有100个请求,始终保持20个请求.我认为你的误解是,请求都要花费相同的时间,实际上从来没有这样. ab而不是按20个批次发出请求,ab只需从20个请求开始,并在每次现有请求完成时发出一个新的请求.
例如,使用ab -n 10 -c 3进行测试将以3个并发请求开始:
[1, 2, 3]
让我们说#2第一次完成,ab替换第四个:
[1, 4, 3]
…然后#1可能完成,替换为第五:
[5, 4, 3]
…然后#3完成:
[5, 4, 6]
…等等,直到请求共有10个请求. (当请求8,9和10完成时,当然并发归档为0)
合理?
关于你的问题,为什么你看到的结果比整体请求更多的失败…我不知道答案.我不能说我已经看过了.你可以发布显示这个的链接或测试用例吗?
更新:在查看the source时,ab跟踪“Failed requests:…”行下面详细列出的四种类型的错误:
>连接 – (源中的err_conn)当ab无法设置HTTP连接时递增
>接收 – (源中的err_recv)当ab的读取失败时,递增
>长度 – (源中的err_length)当响应长度与接收到的第一个良好响应的长度不同时,递增.
>异常 – (源中的err_except)当轮询连接套接字时(例如连接被服务器杀死)时,ab看到错误时增加)
这些发生的逻辑和它们如何被计数(以及如何跟踪总坏数)是必然的,有点复杂.看来,当前版本的ab只应该根据请求计算一次失败,但也许这篇文章的作者使用的是以前的版本,它的计数不止一个?这是我最好的猜测.
如果你能够重现行为,肯定是file a bug.