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#...
3) Agreed. I have to think the best way to fit this into the targets file format.
Cheers
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.
(4) Support for methods other than GET and their data bodies when applicable.
Some useful feature additions would be:
(1) Tunable number of requests per connection: it's often useful to be able to see how webserver performance differs when multiple requests are made per connection (Connection: Keep-Alive) vs. a single request per connection (Connection: Close).
(2) Tunable concurrency: webservers have to serve requests from different clients concurrently. It's much more illuminating to see how a webserver performs when multiple requests are coming in simultaneously than sequentially. Simply divide the total request rate by the number of threads/goroutines created, and assign each the fractional request rate.
(3) The ability to specify custom request headers. Enough said.