startup causing what appear to be false timeouts about wrk2

[ckstettler]

The duplicate output that I was focused on appears to be behavior of the server. Almost like it is caching. I do see access logs indicate quick response and it did not go into my java handler that does the incrementing. So this part of my tale looks like a red-herring. I still dont understand the timeout behavior but and still looking.

[ckstettler]

I figured it out. It is primarily related to the number of connections and the low rate. Because the connections are large relative to the rate each request sends very infrequently and the c->start from the last send triggers a timeout.

I added a c->start = 0 in response_complete() and added a check in check_timeouts() to ignore 0 then things worked fine.

[ckstettler]

I have updated the code to submit a PR if you agree with and are interested in the fix.

[Geal]

hello, here's a friendly ping about this. I think I encountered the same problem (as outlined in sozu-proxy/sozu#424 ).
From my tests (performed over the network and on loopback), it appears that at low rates, wrk2 is working in batches. Like, with ./wrk -L -d 20s -c 5 -t 1 -R 1 http://unhandledexpression.com it will send 5 requests in the first second, then wait 5 seconds, then send 5 new requests (in keep alive), then wait again 5 seconds.

[jberryman]

@ckstettler a PR would be appreciated even if author doesn't merge.

I wonder if there is a workaround? And is latency reported correctly when erroneous timeouts get reported?