3 ms·

Hey there, Thanks for the thoughts. Let me answer to those. 1) That's something I could do but it wasn't really the goal originally as what I wanted to test w

by tsenart 13y ago

Hey there, Thanks for the thoughts. Let me answer to those. 1) That's something I could do but it wasn't really the goal originally as what I wanted to test was not so much the latencies of connection establishment (TCP Handshaking) but rather an HTTP service itself. I will give it some thought though. 2) I explicitly wanted to abstract the concurrency away from the user of the tool. The API is simplified purposefully. However, I am not sure why you think the requests are sequential. Have a look at this line of code https://github.com/tsenart/vegeta/blob/master/lib/attack.go#L44 https://github.com/tsenart/vegeta/blob/master/lib/attack.go#... 3) Agreed. I have to think the best way to fit this into the targets file format. Cheers

otterley 13y ago
> That's something I could do but it wasn't really the goal originally as what I wanted to test was not so much the latencies of connection establishment (TCP Handshaking) but rather an HTTP service itself. I will give it some thought though. It's not the TCP connection latency you're testing; that is effectively a constant. What you're testing here is the performance of new-connection initialization by a web server after the accept() function has returned a new file descriptor. The code path in a webserver relating to a newly-accepted socket will be different from the path for a reused one. > I explicitly wanted to abstract the concurrency away from the user of the tool. The API is simplified purposefully. I think you'll sacrifice some utility by doing that. An event-driven webserver exhibits certain properties at various concurrency levels, while a forking one exhibits others. That's why good benchmarks have concurrency levels as variables in them.