Re: 5000 CPS for haproxy

To add to this is a great automated tool and ideas from The Chicago Tribune called Bees With Machine Guns, which spins up n AWS micro instances to push traffic to the target server.

https://github.com/newsapps/beeswithmachineguns

My CTO makes the argument that connections/s or sessions/s don't mean much unless those sessions are testing realistic user traffic (which tests the application/database/etc). This is not the methodology you're using to test HAProxy, of course, but it is something I think about enough that I feel obligated to type about it. If you care, we do this with Ruby's Net:HTTP libraries making specific calls on existing sessions to our RESTful servers, and those calls are built on random but real user data.

On Monday, August 1, 2011, Willy Tarreau <w#1wt.eu> wrote:
> Hello,
>
> On Mon, Aug 01, 2011 at 07:00:37PM +0530, appasaheb bagali wrote:
>> hello,
>>
>> we have deployed the Haproxy on amazon cloud.
>>
>> its working fine we would like to do testing 5000 CPS .
>> Please suggest the way to test
>
> There are various tools for that. The principle is that you should
> start some dummy servers on other instances (or at least fast static
> servers such as nginx), and run injection tools on other instances.
> Such tools might be httperf, ab, inject or any such thing. You will
> then configure your haproxy to forward to the dummy servers and will
> send your injectors' requests to haproxy. The tools will tell you
> the data rate, connection rate, etc... You're encouraged to enable
> the stats page on haproxy so that you can check rates and errors in
> live.
>
> In general, for 5k CPS, you need a bit of system tuning, because most
> Linux distros come with a conntrack setting which is only valid for a
> desktop usage but not for a server usage, so the traffic will suddenly
> stop after a few seconds. Or better, simply disable the module.
>
> Also, it is important that you have at least two machines for the
> servers and at least two for the clients, because in such environments,
> you have no visibility on anything, and it's quite common that some VMs
> are struggling or that some network paths are saturated. If you see that
> two servers behave differently, at least it's easier to spot where the
> problem is.
>
> Regards,
> Willy
>
>
>
Received on 2011/08/02 09:08