Load balancer test cluster emulator Copyright 2009 Dormando ([email protected])

Pre-CPAN release of some quick test cluster software I wrote for a talk at Velocity 2009.

Dependencies:

Danga::Socket (though future releases might switch to AnyEvent)

To start

$ ./lbemu examples/ideal-test.yaml initialized "basic webserver" listener on 127.0.0.1:5000 initialized "basic webserver" listener on 127.0.0.1:5001 initialized "basic webserver" listener on 127.0.0.1:5002 initialized "basic webserver" listener on 127.0.0.1:5003 initialized "basic webserver" listener on 127.0.0.1:5004 initialized "basic webserver" listener on 127.0.0.1:5005 initialized "basic webserver" listener on 127.0.0.1:5006 initialized "basic webserver" listener on 127.0.0.1:5007 initialized "basic webserver" listener on 127.0.0.1:5008 initialized "basic webserver" listener on 127.0.0.1:5009

Look in examples/ directory for a few examples.

HTTP parsing is ultra simple. It supports an 'OPTIONS *' command, and a GET vs any configured URL's. No other processing is done. Responses consist of 'x' characters up to the requested response length.

It's pretty fast. Disabling the scheduling algorithm I can get over 10,000 requests/sec on my laptop. With the algo it's a lot lower but still pretty good. A big point with this software is not to push a huge volume of requests through it, however.

What lbemu is

lbemu is a no-frills web cluster emulator. It allows you to create fake webservers listening on many IPs or ports, which you can then configure into your load balancer or proxy. It is useful in tuning paramters on your load balancer and for comparing effectiveness of different load balancers, if you are evaluating hardware/software solutions.

Lbemu contains a fake even-balanced CPU scheduler in order to emulate how much time it takes to process a request.

• Specify a machine as having 1-n CPU's (lets say four)
• Specify each CPU as being able to process n 'ticks' per second (lets say 5000)
• lbemu runs at 50 'frames' per second. This is tunable in the top of your sourcecode if you frequently lag on a loop.
• Requests are specified as having 0 or more ticks. a 0 tick doesn't enter the scheduler, it's immediately responded to. This is for requests like OPTIONS or a small static file.
• lbemu attempts to have a request process in that amount of time, per scheduled across the CPUs.

So if you have a request that takes 1000 ticks, with 4 cpus with a 5000 tick capacity each, a single request against the server should complete in roughly 200 milliseconds.

If you issue 4 requests all at once, they should all return in roughly 200 milliseconds.

If you issue 8 requests all at once, they should all return in roughly 400 milliseconds. This is what sets lbemu aside as far as lightweight server emulation goes; it's not simply taking a request and returning a response after N amount of time. Based on the requests presently being processed, finished, running in parallel, requests will fluctuate and slow down at least somewhat similar to a real web cluster.

You can also specify the equivalent of an apache MaxClients, which allows you to properly test perlbal or similar load balancer.

The real power of this software comes in its ability to quickly define various cluster scenarios. If you look through the examples/ directory, you'll find a very quick way of testing ideal conditions, and any mix of servers you can come up with. Fast/slow servers, servers which handle different requests. See how your load balancing setup handles having a few broken tarpitting machines. Or if you can really roll out those new ultra-fast webservers along with your old, slow ones.

It doesn't have anything in the way of collecting server side statistics. Could certainly be added in the future.

If you think this stuff is useful, have a patch or idea, or want to say thanks or how much you hate me, feel free to shoot me an e-mail :) If there's interest, or if I continue to use the software, I'll continue to make releases.

• Dormando ([email protected])