Re: increasing TCP throughput

Hi,

On Wed, Feb 24, 2010 at 05:08:24PM -0800, AJ Asver wrote:
> Hi all,
>
> I'm using HAProxy combined with beanstalkd to create redundant queueing
> system. Everything is working except that I've noticed that I can queue far
> more messages when I push them directly to beanstalkd rather than through
> the HAProxy server.
>
> There's a max of about 300 connections at any one time so i'm not sure
> what's causing the limit in throughput.
>
> Here is my conf: http://friendpaste.com/4RH2zuDnuGVHEWWNlMo9k5
>
> And my stats: http://img.skitch.com/20100225-x9mjub8tqqaffgfqw52umyiiup.png
>
> Any help would be really appreciated!

Well, I don't know where to start from. The stats page indicates an ancient version (1.3.15.X probably) and show somewhat low numbers. 239 MB input bytes in 14 minutes is only 3 Mb/s, which is almost nothing. 1675 connections over 14 mn is just 2 connections per second !

How do you measure your performance and/or the limitations you observe ? Is it in terms of byte rate per connection, connections per second, concurrent connections, ... ?

The numbers are so low that I can't even imagine that anything on the system could slow that down. I remember that some old versions of haproxy had a bug which could cause some data to be delayed, but this was fixed. This bug was present in 1.3.15 and 1.3.15.1. Maybe you're running such a version ?

Also, what does the protocol workflow look like ? Let's take a silly example. Imagine you have something which sends one byte at a time and waits for one byte from the server before sending a new one. Such a protocol would be extremely sensible to latency and would work well between two local processes over the loopback but would get a lot slower as soon as you put any network component in the middle. The same would be true for any intermediate process on the machine if it causes lots of context switching. Obviously your protocol is unlikely to be designed like this, but it was an example of how we could get low numbers with a small number of connections.

Regards,
Willy Received on 2010/02/25 09:44