Kristian Lyngstøl's blog. spew posts. A free software hacker's random rants. spew posts. http://kly.no/ 2022-05-09T00:00:00Z Kristian Lyngstol kly@kly.no Announcing Spew http://kly.no/posts/2012_04_25_Announcing_Spew.html 2012-04-25T00:00:00Z 2012-04-25T00:00:00Z Spew just hit github. It can generate HTTP requests really fast, and that's all it's supposed to do. Kristian Lyngstølkly@kly.no Posted on 2012-04-25

I just pushed my HTTP request spewer, spew, to github.

http://github.com/varnish/spew

It's Linux-specific, since it uses epoll, and the http.c-code is still nasty, but it's also fast.

A reminder of what it can do:

http://kly.no/misc/no_stress_2.png

The feature list contains:

  • Spew opens N connections, sends M requests over each connection and then re-opens the connection and repeats.
  • Fast request generation
  • "Keep-Alive support" (sort of!)
  • No analysis at all.
  • Native IPv6 support
  • Configurable, both on the command line and config file
  • It survives despite what happens if you bring your HTTP server down for a moment. It might need some time to catch up, though.

Most of the boilerplate code is actually from an old defunct project I abandoned in 2009. All the stuff that deals with options and config files and debug messages and whatnot. The only thing I've done recently is src/http.c and integration.

Also: I know the code is still horrible. Patches are welcome, as are requests, (constructive!) comments, etc.

Comments ]]> No Stress http://kly.no/posts/2012_04_23_No_stress.html 2012-04-23T00:00:00Z 2012-04-23T00:00:00Z I spent a day hacking on a PoC for simple stress testing of HTTP (read: Varnish). This is a sneak preview of what I saw was possible. Kristian Lyngstølkly@kly.no Posted on 2012-04-23

After my last post about testing Varnish (http://kly.no/posts/2012_04_19_Testing_Varnish.html), and a few years of frustration, I decided to take a look at what is actually possible.

So this is an example:

http://kly.no/misc/no_stress.png

What you are seeing is Varnish doing 183k req/s on my home machine. The important thing, however, is that the tool generating this load, cleverly called a.out, is running at 22% CPU load, and it's the single-threaded result of one day of dirty hacking. Compare this to httperf which is hard to get over 100k req/s, or siege which kills itself at about 15k req/s on the same machine.

This being a prototype, the code will never see the light of day. Trust me when I say it's horrible - that's what you get from a day of fiddling. However, it has demonstrated to me what's possible, and I might re-start this project now that I have an idea of what I want to do.

As for how a.out works? It's connection-oriented, so it maintains N open connections at any given time and spews M requests over each connection in rather large (configurable) bursts. It also manages to NOT die if you stop the server for a while (httperf doesn't like this and siege doesn't really need any help to murder itself). It collects roughly 0 statistics and it does not really care about response.

So no, it's not very good. But it's fast, and that was what I set out to achieve.

Update: So this tool is a bit more powerful. I've been able to do 280-290k req/s with a single process (and thread). This is the same machine I did the 275k req/s record with using httperf, but that required two extra machines to generate traffic.... Will be interesting to try booting those tomorrow.

http://kly.no/misc/no_stress_2.png Comments ]]>