Stas Bekman <[EMAIL PROTECTED]> wrote:
> Very cool!
> Any benchmarks? The theoretical explanation, is quite good for those who
> understand the problem, but far from being convincing for those who don't.
Yep. Benchmarking with a copy of 'ab' modified to keep the client
sockets open for a while (like NS and IE do), doing 12 concurrent
requests on a slow dynamic Apache/mod_perl page, I get:
* without lingerd: number of Apache processes grows from 10 to 39,
with a peak at 43. Load average reaches 14.
* with lingerd: number of Apache processes grows from 10 to 20, with
a peak at 22. Load average reaches 10.
The speed of the server improved slightly (from 17 to 20 pages per
second), probably because of the lessened memory and scheduling
pressure.
With only 6 concurrent requests, the speed stayed exactly the same
with or without lingerd, but the number of servers went from 27 to
12.
> Also I suppose that you must say that Lingerd becomes the new Achilles
> heel, since if this daemon goes down the whole server won't work.
By default, if Apache can't find lingerd, it will do the lingering
itself, the usual (slow) way.
If you come to depend on the extra scalability that lingerd brings,
you can configure Apache to not do lingering_close at all if lingerd
fails. It sucks, but it's better to having the server fall over
with the load... then again, that's what MaxClients is for.
> May I suggest a correction here? "It removes the need for a front-end
> proxy server only if you needed it in first place to solve the downstream
> client feeding problem."
Yep, you're right :)
A proxy front-end can also serve images and do load-balancing. In
the `README' for lingerd I suggest using thttpd and Piranha for each
of these, but it's true that mod_proxy or mod_rewrite works too.
--
Roger Espel Llima, [EMAIL PROTECTED]
http://www.iagora.com/~espel/index.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
