Apache Benchmark - 并发性和请求数 [英] Apache Benchmark - concurrency and number of requests

问题描述

基准文档说并发是同时完成的请求数，而请求数是请求总数.我想知道的是，如果我将 100 个请求置于 20 的并发级别，这是否意味着同时对 20 个请求进行 5 次测试，还是每次对 20 个请求进行 100 次测试?我假设第二个选项，因为下面引用的示例数字..

The benchmark documentation says concurrency is how many requests are done simultaneously, while number of requests is total number of requests. What I'm wondering is, if I put a 100 requests at a concurrency level of 20, does that mean 5 tests of 20 requests at the same time, or 100 tests of 20 requests at the same time each? I'm assuming the second option, because of the example numbers quoted below..

我想知道，因为我经常在一些测试博客上看到这样的结果:

I'm wondering because I frequently see results such as this one on some testing blogs:

Complete requests: 1000000
Failed requests: 2617614

这似乎不太可信，因为失败的请求数高于总请求数.

This seems implausible, since the number of failed requests is higher than the number of total requests.

显示上述数字的站点:http://zgadzaj.com/benchmarking-nodejs-basic-performance-tests-against-apache-php

或者它会一直尝试直到达到一百万次成功吗?嗯...

OR could it be that it keeps trying until it reaches one million successes? Hm...

推荐答案

表示一次测试总共有 100 个请求，始终保持 20 个请求处于打开状态.我认为您的误解是请求都花费相同的时间，实际上从来没有这样.ab 不是分批发出 20 个请求，而是简单地从 20 个请求开始，并在每次现有请求完成时发出一个新请求.

It means a single test with a total of 100 requests, keeping 20 requests open at all times. I think the misconception you have is that requests all take the same amount of time, which is virtually never the case. Instead of issuing requests in batches of 20, ab simply starts with 20 requests and issues a new one each time an existing request finishes.

例如，使用 ab -n 10 -c 3 进行测试将从 3 个并发请求开始:

For example, testing with ab -n 10 -c 3 would start with3 concurrent requests:

[1, 2, 3]

假设 #2 首先完成，ab 将其替换为第四个:

Let's say #2 finishes first, ab replaces it with a fourth:

[1, 4, 3]

... 那么#1 可能会结束，被第五个替换:

... then #1 may finish, replaced by a fifth:

[5, 4, 3]

... 然后#3 结束:

... Then #3 finishes:

[5, 4, 6]

... 依此类推，直到总共发出 10 个请求.(当然，随着请求 8、9 和 10 完成并发逐渐减少到 0.)

... and so on, until a total of 10 requests have been made. (As requests 8, 9, and 10 complete the concurrency tapers off to 0 of course.)

有意义吗?

至于你为什么看到失败次数多于请求总数的问题... 我不知道答案.我不能说我见过.您可以发布显示此内容的链接或测试用例吗?

As to your question about why you see results with more failures than total requests... I don't know the answer to that. I can't say I've seen that. Can you post links or test cases that show this?

更新:查看来源, ab 跟踪四种类型的错误，这些错误在失败的请求:..."行下方详述:

Update: In looking at the source, ab tracks four types of errors which are detailed below the "Failed requests: ..." line:

• Connect - (err_conn in source) 当 ab 无法建立 HTTP 连接时增加
• 接收 - (err_recv in source) 当 ab 失败读取连接失败时增加
• Length - (err_length in source) 当响应长度与收到的第一个好的响应长度不同时增加.
• 异常 - (err_except in source) 当 ab 在轮询连接套接字时发现错误时增加(例如连接被服务器终止?)

• Connect - (err_conn in source) Incremented when ab fails to set up the HTTP connection
• Receive - (err_recv in source) Incremented when ab fails a read of the connection fails
• Length - (err_length in source) Incremented when the response length is different from the length of the first good response received.
• Exceptions - (err_except in source) Incremented when ab sees an error while polling the connection socket (e.g. the connection is killed by the server?)

关于这些事件何时发生以及如何计数(以及如何跟踪总 bad 计数)的逻辑必然有点复杂.看起来当前版本的 ab 应该只对每个请求计数一次失败，但也许那篇文章的作者使用的先前版本不知何故计数不止一次?这是我最好的猜测.

The logic around when these occur and how they are counted (and how the total bad count is tracked) is, of necessity, a bit complex. It looks like the current version of ab should only count a failure once per request, but perhaps the author of that article was using a prior version that was somehow counting more than one? That's my best guess.

如果您能够重现该行为，请务必提交错误.

If you're able to reproduce the behavior, definitely file a bug.

这篇关于Apache Benchmark - 并发性和请求数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！