On Fri, Jun 10, 2011 at 07:00:40PM -0700, Matt Christiansen wrote:
> Thats good to know, while 2000 concurrent connections what we do right
> now, it will be closer to 10,000 concurrent connections come the
> holiday season which is closer to 2.5 GB of ram (still less then whats
> on the server).
>
> One though I have is our requests can be very large at times (big
> headers, super huge cookies), it may not be packet loss that the
> bigger buffer is fixing but a better ability to buffer our large
> requests. Which might explain why nginx wasn't showing this issue
> where as haproxy was.
No, because if a complete request (headers) doesn't fit in a buffer, it's reported as invalid and rejected. And quite frankly, if you make your clients send 16kB of headers due to cookies, they will experience terrible performance because they will have to upload that amount of data for each object on the page.
> We don't have any HP Servers or Broadcom NICs (all Intel). I too have
> had a lot of issues in general with both HP and Broadcom and choose
> hardware for our LB that didn't have those nics.
>
> Our switches are new, but not super high quality (netgears) its
> possible they are not performing as well as we would like, ill have to
> do some more tests on them.
Some netgear switches support a basic QoS setting which consists in dropping packets above a certain rate... Also, you may have to try with enabling or disabling flow control on the ports.
> I'm working on creating a more production like lab where I can test a
> number of different aspects of the LB to see what else I can do in
> terms of performance. I will make lots of use of halog -srv along with
> other tools to measure performance and to see if I can crackdown any
> issues in our current H/W setup.
OK
Regards,
Willy
Received on 2011/06/11 08:25
This archive was generated by hypermail 2.2.0 : 2011/06/11 08:30 CEST