This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: Roger Espel Llima <espel@iagora.net> From: Stas Bekman <stas@stason.org> Subject: Re: ANNOUNCE: lingerd 0.91b Date: Tue, 5 Dec 2000 13:49:14 +0100 (CET) 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." === To: Roger Espel Llima <espel@iagora.net> From: Stas Bekman <stas@stason.org> Subject: Re: ANNOUNCE: lingerd 0.91b Date: Tue, 5 Dec 2000 18:53:15 +0100 (CET) On Tue, 5 Dec 2000, Roger Espel Llima wrote: > Stas Bekman <stas@stason.org> 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. Yup, that't the exact reason. I've seen the same behavior. > 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. Very nice. Of course this significant reduce in a number of processes required to do the same job, is due to the fast execution time, where the lingering close time had a significant wait in the request completion time. > > 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. That's cool. You didn't mention that. > 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. or even kernel level khttpd if you are on linux. === To: modperl@apache.org From: Roger Espel Llima <espel@iagora.net> Subject: UPDATE: lingerd Date: Fri, 15 Dec 2000 20:11:23 +0100 I've just released lingerd version 0.92; you can get it at ftp://iagora.com/pub/software/lingerd/lingerd-0.92.tar.gz WHAT IS LINGERD? Lingerd is a daemon that greatly improves Apache's scalability by taking over the task of lingering on closing sockets. On dynamic page servers that don't serve their own images (and where keepalives are off), the effect of lingerd on Apache's load is similar to that of a proxy front-end server. STATUS Lingerd under Linux is running on production servers, and is no longer considered beta code. Lingerd on *BSD, Solaris and other Unix systems is still beta, and I'd really appreciate some feedback (compilation success, any compilation warnings, etc). CHANGES SINCE LINGERD 0.91b: . stopped logging some harmless condition as an error . minor documentation changes Btw, I won't be around until next thursday or so; I'll answer my emails as soon as I get back. ===