

Vegeta: HTTP load testing tool written in Go - tsenart
https://github.com/tsenart/vegeta

======
otterley
Good start!

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.

~~~
tsenart
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#...](https://github.com/tsenart/vegeta/blob/master/lib/attack.go#L44)

3) Agreed. I have to think the best way to fit this into the targets file
format.

Cheers

~~~
otterley
> 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.

------
FoeNyx
What happens to the plot when it's way over 9000 ?

~~~
zhemao
Came to the comment thread to see if anyone made that joke. Was not
disappointed.

------
rubbingalcohol
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?

~~~
tsenart
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.

~~~
vukmir
... and a bit more trivia about the name ... for the folks from the ex-
Yugoslavia, when you say Vegeta it means this:
[http://en.wikipedia.org/wiki/Vegeta_(food)](http://en.wikipedia.org/wiki/Vegeta_\(food\))

------
networked
I like the style of it but I'm afraid that using a copyrighted image right in
the README invites a completely needless DMCA takedown.

~~~
tsenart
Thanks for the warning. That's something I didn't consider at first. I have
changed it to a Creative Commons licensed image.

------
0bit
If you want something more configurable / heavyweight checkout Tsung:
[http://tsung.erlang-projects.org/](http://tsung.erlang-projects.org/)

Perhaps could serve as inspiration for future work :)

------
AYBABTME
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!

~~~
tsenart
It was pretty straightforward to add the plotter. +1 for Plotinum :)

------
agumonkey
Useful with
[https://github.com/QLeelulu/goku](https://github.com/QLeelulu/goku)

~~~
chourobin
So many frameworks popping left and right for Go. Any thoughts on how this
compares with something like Revel?

~~~
agumonkey
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.

------
darxius
This looks awesome. Personally, I would have gone with a Super Saiyan 4 Vegeta
for the logo though.

~~~
kenshiro_o
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:-)

~~~
tsenart
I am glad it is of some use :)

------
supersaiyan
I approve

~~~
stcredzero
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.)

EDIT: Outside of The Last Starfighter.

