from http://haproxy.1wt.eu/#othe

Pound
Pound can be seen as a complement to HAProxy. It supports SSL, and can
direct traffic according to the requested URL. Its code is very small
and will stay small for easy auditing. Its configuration file is very
small too. However, it does not support persistence, and the
performance associated to its multi-threaded model limits its usage to
medium sites only.

is that true  Pound is limited for medium sites only?

any figure? such as throughtput, cpu loading etc.?

thanks.

On Wed, 2007-01-10 at 16:53 +0800, howard chen wrote:[...]

That depends very much on what you define as "medium"...

The main difference between HAProxy and Pound is the programming model:
HAProxy is event-driven (little overhead, high performance, but can do
only one thing at a time), Pound is thread-based (more overhead, but can
do many things in parallel). The result is that on a single CPU HAProxy
will be faster, but Pound will scale much better with the hardware (it
is able to use additional CPUs, which HAProxy can't). With the current
crop of multi-core/multi-CPU machines I believe Pound to be the better
choice, but it's your call: in final instance it really depends on your
needs and hardware availability.[...]

----- Original Message ----- 
From: "howard chen" <howachen(at)gmail.com>[...]

Yes, Squid with ESI support (google: zope esi squid) is for large sites like 
cnn, akamai or so. If you have large site, you need different management and 
possibilities than with medium or small sites. Zope could tell to squid 
(acting in reverse proxy mode of course) how long it will cache pages or 
some parts of pages (it is called ESI, developed for akamai and cnn or so). 
In large sites, caching is very big science and magic too.

JL.

Up to a point, Robert's comments are correct, but HAProxy can run multiple
processes very well.

The real fact is that neither HAProxy nor pound cut it on really high volume
sites and it isn't just throughput.  In large sites, it is common to run
internal API's through load balancing to allow the operations staff to hide
details about which hosts and how many are running internal services.  This
can easily run the total transaction rate into the thousands per second.
The real kicker, though, is that when you have a high volume site, the cost
of downtime goes up dramatically.  This means that you really have to have
bomb-proof hardware fail-over that picks up within a fraction of a second
without losing session information and you have to be able to make changes
to the hot system.  Without those capabilities, nothing else much matters.

My definition of a high volume site is one where the 15-50 K$ for the load
balancing hardware is a number that doesn't stand out like a sore thumb on
the budget projections.  If you have four multi-CPU systems working on their
own disks sitting behind a 100MB feed, then adding a hardware load balancer
just isn't going to happen.  If you have 100's or 1000's of boxes running
dozens of internal services with redundant gigabit feeds accessing redundant
and high-end networked storage devices, hardware load balancers make a lot
more sense.


On 1/10/07 9:26 AM, "Robert Segall" <roseg(at)apsis.ch> wrote:
[...][...][...]

> The main difference between HAProxy and Pound is the programming
model:[...]

from
http://plb.sunsite.dk/performance.html:

...
Unlike traditional forking servers, there are very few context
switches. This means that performance will scale linearly. The load
balancer is too slow to handle your full bandwidth? Just change the
CPU and add some memory. If the new CPU is twice faster, you will
probably be able to handle twice the previous load.
...

so that means:

1. if we use single cpu system, haproxy's model is better if you scale
up the cpu speed

2. if using dual/quad core system, multi-thread model should be better

i am really interested in any benchmark comparing those SW load balacner.


regards,
howa

On 1/11/07, Jaroslav Lukesh <lukesh(at)seznam.cz> wrote:[...]
interesting, this is my first time to hear abt ESI, but seems not so
popular? even not widely discussed in the Squid community...

regards,

On 1/10/07 11:51 PM, "howard chen" <howachen(at)gmail.com> wrote:
[...]

Actually, pound will scale almost as well for faster single CPU's.
[...]

It isn't nearly this simple.

Essentially what is happening with HAProxy is that many threads are being
simulated using an explicit state machine and explicit storage of the thread
context.  This is a well known technique for getting around some of the
limitations of normal threaded implementations.  The advantage is that much
less memory is consumed for the state of each "thread" and thus the thread
to thread switching is enormously faster.  On the down side, coding is much,
much harder to get exactly right and thus features are very difficult to add
to a system such as HAProxy.  Some experiments in C++ have resulted in some
fantastically high performance results for threaded code such as used in
pound, but these results aren't likely to be portable enough to make the
pound developers happy.

This leads to a much more clear dichotomy between the two systems.  HAProxy
does hot configuration changes very, very well.  Pound can dispatch based on
URL.  HAProxy can currently handle somehwat higher loads than Pound.  Pound
can be audited.

As a result performance and theoretical scaling issues probably aren't going
to be the deciding factor between these two systems.  It is much more likely
that one system or the other will lack a feature and that will be a
show-stopper.

On 1/12/07, Ted Dunning <tdunning(at)veoh.com> wrote:[...]

i think it would be great if there are some benchmark comparing all
these load balacning system, on single process/dual system, under high
load, etc. isn't?

regards,

howard chen wrote:[...][...][...]
Hello, interesting thread about ESI. ESI is very, very good standard but 
there is no stable software implementation right now:

http://mail.zope.org/pipermail/zope/2006-January/164375.html

Best Regards
Maciej Bogucki
[...]

> 1. if we use single cpu system, haproxy's model is better if you
scale[...]

Hello,

Haproxy can run several processes between which the operating system 
will spread the incoming connections. It is usefull with dual/quac core 
system. You could do this, by setting "nbproc" to 2  or 4 in haproxy.cfg

Regards
Maciej Bogucki
[...]

> This leads to a much more clear dichotomy between the two systems. 
HAProxy[...]
The latest version of haproxy can dispatch based on URL also.  It is 
possible to dispatch depending on any parameter in the request! I didn't 
test it on production sites right now but in the lab it works great.
[...]
I completly agree with You.

Best Regards
Maciej Bogucki
[...]

Willy,

Thanks for this excellent post.  I hadn't realized that haproxy had scaled
to these volumes ... We will be considering it for some of our internal
processes.

I should add, however, that many of the hardware LB's now do lots of layer 7
stuff in hardware.  Netscaler, for instance can handle multi Gbps loads
while doing regex replacements on HTTP responses.  Very impressive stuff
that, but not cheap.


On 1/20/07 1:43 AM, "Willy Tarreau" <w(at)1wt.eu> wrote:
[...]