Re: [Proposal] Concurrency tuning by adding a limit to http-server-close

Hi Cyril,

On Tue, Sep 13, 2011 at 10:13:14PM +0200, Cyril Bonté wrote:
> More seriously, I've got a first version that looks to work quite well.
> I couldn't raise <maxconn> keep-alive connections but <maxconn> - 1, due to
> the way haproxy pauses the listener when they are full or when the proxy is.

I don't know if you have checked 1.5-dev7, there's a function there to wake up the listeners that are waiting for maxconn to be OK again. It's already used to apply maxconn without burning CPU cycles. And I don't see there anything that would prevent you to use up to <maxconn> connections ; in fact, I even ran some tests with maxconn 1 to check that it worked fine :-)

> I still have to optimize some pathes added to resume the listeners when a
> connection goes back to the idle list. This is more true for proxies that have
> lots of listeners. I don't know such configurations but maybe you've already
> met some ;-)

Check in session.c:process_session, you have this :

       if (s->listener->state == LI_FULL)
                resume_listener(s->listener);

I think you can make use of this for your code. Since listeners are individually full or not full, you don't need to scan the whole listeners anymore. BTW, the worst config I have ever seen was someone binding to a *large* port range. This means tens of thousands of listeners...

> During a test today, I had 2 minutes of panic due to an unexplained segfault
> but gdb quickly reminded me that I recompiled the sources with DEBUG_DEV
> enabled !

I think I remember about a recent patch from Simon to fix some breakage in DEBUG_DEV, so 1.5-dev7 might be OK. But I've not used DEBUG_DEV for a long time now and I don't know what shape it's in.

> Except that, it never crashed.

Fine !

Cheers,
Willy Received on 2011/09/14 00:10