(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.
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.
> 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.
Other methods are already supported. However, I wouldn't recommend you to load test non-idempotent behaviour.
POST for instance is not idempotent by definition.
Unless of course, you're ready to clean-up all the side-effects after the test :)
This is seriously an awesome name for a load tester. The concept totally fits that "desperation" attack Vegeta would use on any season boss before he got his ass kicked (the screaming and throwing a million fireballs thing)
Nice project, btw. Do you think it's worth building cluster mode into the tool itself when there are existing methods of sync'ing commands across boxes?
Hey there! A little bit of trivia about the name: I have been working at an internal project at SoundCloud called goku (not the web framework). It came the time where I needed to load test it and didn't find the available solutions to my taste.
Hence, vegeta was born :)
Regarding the cluster mode, it's trivial to sync commands across machines but it's not trivial to sync the state that generates the reports. That's what cluster mode would do.
Some sort of master-slave architecture scatter execution and gather and compute the aggregated reports.
Cool stuff, I saw your submission on the mailing list yesterday and there wasn't yet a plotter. You got around with it pretty quickly! This speaks to the quality of Plotinum!
Sorry but I was only quoting this one because of the name (vegeta, goku, same cartoon). I actually only knew Revel prior this post, and didn't know about golang being filled with web frameworks.
I am starring your project as I think it could be very useful for me and many others.
Btw I think you should show Vegeta doing the Big Bang Attack as the project image - it would look cooler:-)
Is it just me, or does anyone else want to see missile/beam/energy bold spam in a situation where it's tactically relevant and very effective? (Instead of just a chance to let the hero shrug it off and look tough.)
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.