2 Connections per Worker Unexpected

[murphye]

When I use the -c switch, I was expecting that there would be 1 connection per worker. That doesn't seem to be the case.

As you can see in the picture, there is a graph generated from Envoy statistics. It is a stacked graph to more easily see the total number of connections.

Here you can see two runs... one with concurrency to 100, one with 50. The total number of connections for each is double the number of workers (200 and 100).

This was not expected and cause a lot of confusion on why my benchmarks were getting worse numbers than they should be. More connections yielded higher P95/P99 scores. I believe these numbers to be true, because k6 100 virtual users had results that matched my -c 50.

I would recommend that hey either clearly document that there are 2 connections opened per worker, or resolve this as a defect where 1 worker has 1 connection.

[amnonbc]

The code in question is https://github.com/rakyll/hey/blob/master/requester/requester.go#L243

I believe that this is working as designed, and consistent with the HTTP spec.

See: https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html

Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.

Browsers generally open two connection per host (unless they are using http2).

[murphye]

@amnonbc OK this may simply be a docs issue. hey behaves differently than k6 than other load-balancing tools, as I understand it based on my own testing. It may be as simple as adding more detail here:

  -c  Number of workers to run concurrently. Total number of requests cannot 
be smaller than the concurrency level. Default is 50.

change to:

  -c  Number of workers to run concurrently. Total number of requests cannot 
be smaller than the concurrency level. Default is 50. 
Each worker opens 2 connections to the host.