On Tue, 26 Nov 2002, Philip Mak wrote: > On Tue, Nov 26, 2002 at 11:40:00AM -0800, Grant Cooper wrote: > > What do yo mean a modem will tie up the Server? I've never heard this > > before. > > Let's say you have a mod_perl page that returns a 100k document, and a > 28.8k modem downloads that document. > > The mod_perl process that is serving that document will be tied up > until that modem finishes downloading the document, which is > inefficient since the mod_perl processes take up a lot of memory. A > lightweight front-end proxy that loads the data from the mod_perl > process all at once and then feeds it to the modem would save memory.
Things are bit complicated. Kernel can buffer some part of document and there is Apache feature named lingering close. For example, client's speed is 3K/s. If you have 64K kernel TCP send buffer then mod_perl will write 64K very soon but it will wait about 12 seconds to write other 36K. And after mod_perl will have written these 36K it will wait 2 second in lingering close. Even you increase kernel TCP send buffer (it's not always good idea) to 100K anyway you still 2 second lingering close delay for slow clients. Note that you never see lingering close state in /server-status (at least in Apache 1.3) - such processes are marked as idle but they are not really idle - they can not handle requests. Also lingering close time is not accounted in %T directive in the log. You can only estimate the count of Apache processes that is in linegring close state using netstat utulity and looking for FIN_WAIT2 socket states. Igor Sysoev http://sysoev.ru/en/
