I am flagging this as a question and not a bug because I haven't gathered sufficient proof yet, but I have a strong suspicion that maxBody=0 causes the target to leak connections.
I performed the same test multiple times against the exact same server and observed similar results: a ramp to 8000 req/s with a payload of 2 KB and a client timeout of 3s.
The charts below show the receive throughput measured from the target (not from vegeta), in one case with maxBody=-1, in the other case with maxBody=0. The "rt" series is the receive throughput, the "q" series is just an internal queue which has no influence on the results of the attack.
In the second case, I do observe some failures at about the same threshold every time, and noticed that the wait time was about 5s, which is my server's IdleConnTimeout (this could also be a pure coincidence).
This particular server only returns HTTP headers and no body, so I suppose it is normal to see 0 byte in in both results, regardless of the value of maxBody(?)
I checked the code of the lib and confirmed that the response body was being closed correctly in a deferred statement, so I'm a bit puzzled about what may be happening here.
Sorry for not responding to this when you first posted it. I'm spending time maintaining Vegeta again. If you're still interested in looking into this, please re-open.
Question
I am flagging this as a question and not a bug because I haven't gathered sufficient proof yet, but I have a strong suspicion that
maxBody=0
causes the target to leak connections.I performed the same test multiple times against the exact same server and observed similar results: a ramp to 8000 req/s with a payload of 2 KB and a client timeout of 3s.
The charts below show the receive throughput measured from the target (not from vegeta), in one case with
maxBody=-1
, in the other case withmaxBody=0
. The "rt" series is the receive throughput, the "q" series is just an internal queue which has no influence on the results of the attack.maxBody=-1
maxBody=0
In the second case, I do observe some failures at about the same threshold every time, and noticed that the wait time was about 5s, which is my server's
IdleConnTimeout
(this could also be a pure coincidence).This particular server only returns HTTP headers and no body, so I suppose it is normal to see
0 byte in
in both results, regardless of the value ofmaxBody
(?)I checked the code of the lib and confirmed that the response body was being closed correctly in a deferred statement, so I'm a bit puzzled about what may be happening here.