基准文档说并发是同时完成的请求数，而请求数是请求总数。我想知道的是，如果我将 100 个请求放在 20 个并发级别，这是否意味着同时对 20 个请求进行 5 次测试，还是同时对 20 个请求进行 100 次测试？我假设第二个选项，因为下面引用的示例数字。
我想知道，因为我经常在一些测试博客上看到这样的结果：
Complete requests: 1000000
Failed requests: 2617614
这似乎难以置信，因为失败的请求数大于总请求数。
编辑：显示上述数字的网站：http://zgadzaj.com/benchmarking-nodejs-basic-performance-tests-against-apache-php
还是它一直在努力，直到达到一百万的成功？嗯......
这意味着一个测试总共有 100 个请求，始终保持 20 个请求处于打开状态。我认为你的误解是，请求都花费相同的时间，这几乎从来都不是这样。ab 不是分批发出 20 个请求，而是从 20 个请求开始，并在现有请求完成时发出一个新请求。
例如，测试 with 将从 3 个并发请求开始：ab -n 10 -c 3
[1, 2, 3]
假设 #2 首先完成，ab 将其替换为第四个：
[1, 4, 3]
...然后#1可能会完成，取而代之的是第五个：
[5, 4, 3]
...然后#3完成：
[5, 4, 6]
...以此类推，直到总共提出 10 个请求。（当请求 8、9 和 10 完成时，并发性当然会逐渐减少到 0。
有意义？
至于你的问题，为什么你看到的结果失败次数多于请求总数......我不知道答案。我不能说我见过。你能发布显示这一点的链接或测试用例吗？
更新：在查看源代码时，ab 会跟踪四种类型的错误，这些错误在“失败的请求：...”下面有详细说明。线：
err_connerr_recverr_lengtherr_except关于这些何时发生以及如何计数（以及如何跟踪总数）的逻辑必然有点复杂。看起来当前版本的ab应该只对每个请求计算一次失败，但是也许该文章的作者使用的是先前的版本，该版本以某种方式计数了多个？这是我最好的猜测。bad
如果您能够重现该行为，请务必提交错误。
我看没有错。失败的请求可能会增加多个错误。这就是工作原理。ab
有各种固定长度的静态声明缓冲区。结合命令行参数的延迟解析，来自服务器的响应标头和其他外部输入，这可能会咬你。
例如，您可能会注意到，对于 3 个错误计数器，前面的节点结果具有相似的计数。最有可能的是，在发出的 100 000 个请求中，只有 8409 个失败，而不是 25227 个。
Receive: 8409, Length: 8409, Exceptions: 8409
