Vegeta: HTTP load testing tool written in Go | Hacker News Reader

Vegeta: HTTP load testing tool written in Go

github.com

99 pointstsenart27 comments

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.

+1 for those suggestions. And perhaps I would add :

(4) Support for methods other than GET and their data bodies when applicable.

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

+1 to the request headers and HTTPS support

HTTPs is on the TODO.

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#...

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

Cheers

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

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

What, 9000!? There's no way that can be right!

:D It just keeps growing horizontally.

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

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.

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

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.

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

If you want something more configurable / heavyweight checkout Tsung: http://tsung.erlang-projects.org/

Perhaps could serve as inspiration for future work :)

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!

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

Useful with https://github.com/QLeelulu/goku

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

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.

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

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

I am glad it is of some use :)

I approve

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.

Reply on news.ycombinator.com