On Mon, 17 Sep 2001, Andrei A. Voropaev wrote:

> Hi!
>
> I have one question. According to the Guide there's buffering feature of
> mod_proxy that allows to release heavy mod_perl process from delivering data
> over slow connection to the user.
>
> In our system we have to pass large PDF files thru mod_perl to proxy and we
> noticed that it takes the same time as sending it directly to customer.
>
> After checking Apache code for mod_proxy looks like it is normal behaviour.
> File modules/proxy/proxy_util.c function ap_proxy_send_fb. This function
> reads from originating server into buffer and then writes to the customer from
> this buffer. BUT the socket is closed AFTER all the data is sent to the
> client (file module/proxy/proxy_http.c function ap_proxy_http_handler. So
> the heavy mod_perl server is not released for serving other requests untill
> the data is sent to the client by proxy.
>
> Maybe I'm missing something but the practice shows that this is true and Guide
> contains error. Please someone check this.

Your observation is correct. But you didn't finish reading the whole
thing.  Have you read this section:

http://perl.apache.org/guide/scenario.html#Setting_the_Buffering_Limits_on_

Also check the archives for 'lingerd' keyword. Here is what I've but it
didn't enter the guide yet, since it's waiting to be reviewed by Roger
Espel Llima, the author of lingerd. ...and waiting, and waiting, and
waiting :(

=head2 Closing Lingering Connections with Lingerd

Because of some technical complications in TCP/IP, at the end of each
client connection, it is not enough for Apache to close the socket and
forget about it; instead, it needs to spend about one second
I<lingering> on the client.  (More details can be found at
http://httpd.apache.org/docs/misc/fin_wait_2.html)

Lingerd is a daemon (service) designed to take over the job of
properly closing network connections from an http server like Apache
and immediately freeing it to handle a new connection.

C<lingerd> can only do an effective job if HTTP C<Keep-Alive>s are
turned off; since C<Keep-Alive>s are useful for images, the
recommended setup is to have C<lingerd> serving mod_perl enabled
Apache and plain Apache for images and other static objects.

With a C<lingerd> setup, you don't have the proxy, so the buffering
chain we have presented before for the proxy setup is much shorter
here:

FIGURE:

 |   Apache     Kernel   |TCP/IP  `o'
 | [mod_perl]=>[sendbuf] |======> /|\
 |                       |        / \

Hence in this setup it becomes more important to have a big enough
kernel send buffer.

With lingerd, a big enough kernel send buffer, and keep-alives off,
the job of spoonfeeding the data to a slow client is done by the OS
kernel in the background. As a result, C<lingerd> makes it possible to
serve the same load using considerably fewer Apache processes. This
translates into a reduced load on the server. It can be used as an
alternative to the proxy setups we have seen so far.

For more information about C<lingerd> see:
http://www.iagora.com/about/software/lingerd/

Let me know if it was useful and correct, and I'll put it into the guide.


_____________________________________________________________________
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://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/


Reply via email to