[users@httpd] Does ab have some sort of a slow start?

[Reto Habluetzel <re...@pm.me.INVALID>]

Hi,

I have tried to test one of my services using ab. The behavior of this service is that it does not respond unless five requests have been made (kind of a queuing). However, if five requests are not coming in within 10s, then it fails.

So my expectation was that when I send requests like `ab -c5 -n 5 localhost:8080/myservice` that it would work, because five requests would be sent at the same time.

That does not seem to be the case though. It looks like ab is first sending only one request. Once the first request returns, the remaining four are sent. To verify this, I both looked at wireshark and modified the source of ab to print the state of the connections. Please find those logs below.

My question is: Is this expected behavior? That is, testing this type of service with ab is not a very good idea? Or should I invoke ab differently?

Thank you very much for any hints.

- Reto

Logs (note that the first column is a timestamp in milliseconds):
Benchmarking localhost (be patient)...
[488267168] start_connect function
[488267168] first connection initialized (concurrency=5)
[488267168] Poll state[0]: CONNECTING
[488277204] Poll state[0]: READ
[488277204] start_connect function
[488277205] start_connect function
[488277205] start_connect function
[488277205] start_connect function
[488277205] Poll state[0]: READ
[488277206] start_connect function
[488277206] Poll state[1]: CONNECTING
[488277206] Poll state[2]: CONNECTING
[488277206] Poll state[3]: CONNECTING
[488277206] Poll state[4]: CONNECTING
[488277206] Poll state[0]: CONNECTING
[488277257] Poll state[0]: READ
[488277257] Poll state[0]: READ
[488277257] Poll state[1]: READ
[488277257] Poll state[2]: READ
[488277257] Poll state[3]: READ
[488277257] Poll state[0]: READ
[488277257] Poll state[1]: READ
[488277257] Poll state[2]: READ
..done

[users@httpd] Re: Does ab have some sort of a slow start?

[Reto Habluetzel <re...@pm.me.INVALID>]

Answering my own question in case someone else comes across this issue.

ab does indeed have this behavior. It starts the first connection and sends the request. Only once the header of that first response has been received, the other connections are initialized.


Here's the relevant piece of code (function read_connection):

/* We have received the header, so we know this destination socket
 * address is working, so initialize all remaining requests. */
if (!requests_initialized) {
  for (i = 1; i < concurrency; i++) {
    con[i].socknum = i;
    start_connect(&con[i]);
  }
  requests_initialized = 1;
}


- Reto

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Op woensdag 10 maart 2021 18:12, Reto Habluetzel <re...@pm.me> schreef:

> Hi,
>
> I have tried to test one of my services using ab. The behavior of this service is that it does not respond unless five requests have been made (kind of a queuing). However, if five requests are not coming in within 10s, then it fails.
>
> So my expectation was that when I send requests like `ab -c5 -n 5 localhost:8080/myservice` that it would work, because five requests would be sent at the same time.
>
> That does not seem to be the case though. It looks like ab is first sending only one request. Once the first request returns, the remaining four are sent. To verify this, I both looked at wireshark and modified the source of ab to print the state of the connections. Please find those logs below.
>
> My question is: Is this expected behavior? That is, testing this type of service with ab is not a very good idea? Or should I invoke ab differently?
>
> Thank you very much for any hints.
>
> - Reto
>
> Logs (note that the first column is a timestamp in milliseconds):
> Benchmarking localhost (be patient)...
> [488267168] start_connect function
> [488267168] first connection initialized (concurrency=5)
> [488267168] Poll state[0]: CONNECTING
> [488277204] Poll state[0]: READ
> [488277204] start_connect function
> [488277205] start_connect function
> [488277205] start_connect function
> [488277205] start_connect function
> [488277205] Poll state[0]: READ
> [488277206] start_connect function
> [488277206] Poll state[1]: CONNECTING
> [488277206] Poll state[2]: CONNECTING
> [488277206] Poll state[3]: CONNECTING
> [488277206] Poll state[4]: CONNECTING
> [488277206] Poll state[0]: CONNECTING
> [488277257] Poll state[0]: READ
> [488277257] Poll state[0]: READ
> [488277257] Poll state[1]: READ
> [488277257] Poll state[2]: READ
> [488277257] Poll state[3]: READ
> [488277257] Poll state[0]: READ
> [488277257] Poll state[1]: READ
> [488277257] Poll state[2]: READ
> ..done
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org