ANNOUNCE: lingerd 0.91b

[Roger Espel Llima <es...@iagora.net>]

This is the first public release of lingerd.  You can download it
from ftp://iagora.com/pub/software/lingerd/lingerd-0.91b.tar.gz

WHAT IS LINGERD?

When an Apache process has handled a client connection, and before
it can go on to the next one, it must first wait a bit to make sure
that the other side has received all the data.  This is called
lingering_close, and is required because of some technical TCP/IP
complications.  

On a dynamic webserver with embedded scripting, and especially once
images are served separately and keep-alives are turned off,
lingering_close becomes Apache's #1 slowdown spot by a large margin.

Lingerd, then, is a daemon (service) designed to take over the job
of doing lingering_closes.  Unlike Apache, which uses one process
per connection, lingerd can do thousands of lingers in parallel,
from a single process.  This makes Apache use much fewer processes
to handle the same load.

In order to use lingerd, Apache must be patched to hand over its
network connections to the daemon.  This is done with file
descriptor passing over a Unix-domain socket, and, as the name
implies, is not very portable outside of Unix.


ARE THERE ANY ALTERNATIVES TO LINGERD?

Yes.  The "classical" solution to the lingering_close problem, and
more generally, to the problem of having a big Apache/mod_perl
process spoonfeed data to a slow client on a congested link, is to
run a front-end proxy server.  This can be done with of squid, or
with a light-weight Apache configured with mod_proxy and without any
scripting.

Lingerd removes the need for a front-end proxy server, and is much
easier to set up: no URL rewriting, no reverse rewriting rules, no
extra data copying and latency for the client.  Lingerd is also much
lighter on system resources than a proxy server.


USING IT

Lingerd is beta code.  It has only been tested under Linux (kernel
2.2.x) so far, with positive results.  The code has designed to be
robust and portable (to Unix systems anyway; I don't think it can be
ported to win32, but feel free to surprise me :)

There is also a standalone patch to Apache, that makes processes in
lingering_close visible in /server-status.  You can use this to
check if lingerd would be useful for your server.

For further instructions, read the files `README', `INSTALL' and
`testing/TESTING' in the tarball.

-- 
Roger Espel Llima, espel@iagora.net
http://www.iagora.com/~espel/index.html

Re: ANNOUNCE: lingerd 0.91b

[Stas Bekman <st...@stason.org>]

On Tue, 5 Dec 2000, Roger Espel Llima wrote:

> This is the first public release of lingerd.  You can download it
> from ftp://iagora.com/pub/software/lingerd/lingerd-0.91b.tar.gz
> 
> WHAT IS LINGERD?
> 
> When an Apache process has handled a client connection, and before
> it can go on to the next one, it must first wait a bit to make sure
> that the other side has received all the data.  This is called
> lingering_close, and is required because of some technical TCP/IP
> complications.  
> 
> On a dynamic webserver with embedded scripting, and especially once
> images are served separately and keep-alives are turned off,
> lingering_close becomes Apache's #1 slowdown spot by a large margin.
> 
> Lingerd, then, is a daemon (service) designed to take over the job
> of doing lingering_closes.  Unlike Apache, which uses one process
> per connection, lingerd can do thousands of lingers in parallel,
> from a single process.  This makes Apache use much fewer processes
> to handle the same load.

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.

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.

> ARE THERE ANY ALTERNATIVES TO LINGERD?
> 
> Yes.  The "classical" solution to the lingering_close problem, and
> more generally, to the problem of having a big Apache/mod_perl
> process spoonfeed data to a slow client on a congested link, is to
> run a front-end proxy server.  This can be done with of squid, or
> with a light-weight Apache configured with mod_proxy and without any
> scripting.
> 
> Lingerd removes the need for a front-end proxy server, and is much
> easier to set up: no URL rewriting, no reverse rewriting rules, no
> extra data copying and latency for the client.  Lingerd is also much
> lighter on system resources than a proxy server.

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."


_____________________________________________________________________
Stas Bekman              JAm_pH     --   Just Another mod_perl Hacker
http://stason.org/       mod_perl Guide  http://perl.apache.org/guide 
mailto:stas@stason.org   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/