Re: 5000 CPS for haproxy

This is true; however, in application your first concern with the infrastructure is the first bottleneck, and (frankly) in many archotectures it's probably not (properly tuned) HAProxy. That's all I'm saying and again I understand why that's not relevant. I hope others on this list understand why I mention this when folks talk of benchmarks.

We are not yet ready to release our benchmark examples. This is Ops' (my) fault. We will, however, release them under our public repositories at https://github.com/borderstylo.

On Tuesday, August 2, 2011, Baptiste <bedis9#gmail.com> wrote:
> Hi Carlo,
>
> Before testing the application itself, you must first test the
infrastructure ;)
> Once you know how much your infrastructure can deliver, then your
> bench makes sense.
> This is a step by step method, from the lower layer to the higher one.
>
> Before testing your application in a virtualized environment, you
> should bench it on physical servers.
> Because on a virtualized environment, you're sharing resources with
> anybody and the behavior may be odd under "heavy" load.
>
> By the way, do you have a few ruby examples, I'm interested by your
> way of testing applications.
> Long time ago, I used perl and libwww.
>
> cheers :)
>
>
> On Tue, Aug 2, 2011 at 9:08 AM, carlo flores <carlo#petalphile.com> wrote:
>> 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:32