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

问题描述

基准的文件说，并发有多少请求同时进行，而请求数量是请求的总数。我想知道，如果我把一个100请求在20的并发级别，是否意味着在同一时间在每个同时5次测试20的请求，或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.

编辑：显示上述数字的网站：<一href=\"http://zgadzaj.com/benchmarking-nodejs-basic-performance-tests-against-apache-php\">http://zgadzaj.com/benchmarking-nodejs-basic-performance-tests-against-apache-php

the site that displays the aforementioned numbers: 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个请求在任何时候都开放。我认为你有误解是请求都以相同的时间，这是实际上从未如此。代替在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 将开始with3并发请求：

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 the request 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:

• 连接 - （ err_conn 在源代码），当AB未能建立HTTP连接递增


• 接收 - （ err_recv 源）时递增AB失败连接的读取失败


• 长度 - （ err_length 源）递增当响应长度是从第一的好响应的长度不同的接收


• 例外 - （例如连接服务器杀死）（ err_except 源）递增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?)

中的逻辑，当围绕这些发生，他们是怎么算的（总坏计数跟踪如何）是必要的，有点复杂。它看起来像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.

如果你能重现行为，绝对一个bug 。

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

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