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:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
