FWIW, I appreciate the response, but I'm not sure how event-ports, epoll vs poll and select is going to cause load times to increase for us by 500% with one client hitting haproxy vs that same one client hitting apache directly. I can see it having a negative effect with a heavy load (exclusively) but that (to me - I claim no expertise in the matter) doesn't explain the performance hit of one single client loading one web page.
matt
On May 19, 2010, at 4:52 PM, Jason J. W. Williams wrote:
> Hi Matt,
>
> I'm new to HAProxy myself, but I'm going to guess it does NOT have
> support for event-ports (Solaris' version of epoll or kqueues) which
> means it's going to use poll() and be much less performant. It's
> pretty much impossible to do efficient asynchronous network servers
> without epoll, kqueue or event-port support depending on your OS.
>
> -J
>
> On Wed, May 19, 2010 at 4:45 PM, Matt Banks <mattbanks#gmail.com> wrote:
>> All,
>> In a nutshell, we REALLY like HAProxy. We've been using it on RHEL/Cent for
>> a while with great success (running under VMWare/VSphere.) However, most of
>> what we do is under Solaris, and we're finding that we don't get nearly as
>> good of results running under Solaris 10 x86. We've compiled it using gcc 3
>> and gcc 4, we've tried with USE_STATIC_PCRE=1 and without. (With proved
>> better.) We've even tried tweaking some of the ndd settings (rather blindly
>> after a google search gave us
>> this: http://serverfault.com/questions/134578/solaris-tcp-stack-tuning) to
>> no avail. We've tried it in a zone with up to 1GB of RAM, and directly on
>> the server itself pointing to 127.0.0.1. Things are just slower. They
>> work, but slowly.
>> Frankly, we're baffled. Using a backend of two servers, there are delays of
>> up to 5 seconds over a direct connection to the apache server itself. An
>> offsite RHEL version of HAProxy (with a latency of around 30ms) provided us
>> MUCH faster results than any Solaris install has.
>> Is there something we're missing? We're about to the point of invoking
>> dtrace to dig into what's going on, but I just wanted to make sure we
>> weren't missing something obvious...
>> Thanks,
>> matt
Received on 2010/05/20 02:10