You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Andrei A. Voropaev" <an...@securities.com> on 2001/09/17 08:14:57 UTC
mod_proxy and mod_perl in guide
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.
Thank you
Andrei
Re: mod_proxy and mod_perl in guide
Posted by Perrin Harkins <pe...@elem.com>.
> 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.
Maybe the thing you're missing is that mod_proxy takes care of the lingering
close. Those of us who have tried the two-server setup have all seen
dramatic reductions in the number of mod_perl processes required.
- Perrin
Re: mod_proxy and mod_perl in guide
Posted by "Andrei A. Voropaev" <an...@securities.com>.
These are protected files so we have to use authentication and authorization
that is done by mod_perl. And Internet Explorer that use most of our customers
has bug that prevents displaying of PDF (and any other large non-dynamic
non-HTML) files if the URL to that file was result of "Redirect".
Thanks for help.
Andrei
On Mon, Sep 17, 2001 at 08:55:03AM -0700, ed phillips wrote:
> Thanks Vivek,
>
> Andrei, use the front end to directly handle any binaries, static files,
> etc.
>
> I doubt they are generating of these on the fly.
>
>
>
> Vivek Khera wrote:
> >
> > >>>>> "AAV" == Andrei A Voropaev <an...@securities.com> writes:
> >
> > AAV> In our system we have to pass large PDF files thru mod_perl to
> > AAV> proxy and we noticed that it takes the same time as sending it
> > AAV> directly to customer.
> >
> > Why do you have to pass the PDF thru mod_perl? Are you generating it
> > on the fly? If not, configure your proxy front end to intercept
> > static documents like .pdf .txt .html etc. to be handled by the front
> > end directly. I use mod_rewrite for this, and my configs have been
> > posted to this list at least twice.
> >
> > --
> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > Vivek Khera, Ph.D. Khera Communications, Inc.
> > Internet: khera@kciLink.com Rockville, MD +1-240-453-8497
> > AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: mod_proxy and mod_perl in guide
Posted by ed phillips <ar...@sirius.com>.
Thanks Vivek,
Andrei, use the front end to directly handle any binaries, static files,
etc.
I doubt they are generating of these on the fly.
Vivek Khera wrote:
>
> >>>>> "AAV" == Andrei A Voropaev <an...@securities.com> writes:
>
> AAV> In our system we have to pass large PDF files thru mod_perl to
> AAV> proxy and we noticed that it takes the same time as sending it
> AAV> directly to customer.
>
> Why do you have to pass the PDF thru mod_perl? Are you generating it
> on the fly? If not, configure your proxy front end to intercept
> static documents like .pdf .txt .html etc. to be handled by the front
> end directly. I use mod_rewrite for this, and my configs have been
> posted to this list at least twice.
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Vivek Khera, Ph.D. Khera Communications, Inc.
> Internet: khera@kciLink.com Rockville, MD +1-240-453-8497
> AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: mod_proxy and mod_perl in guide
Posted by Vivek Khera <kh...@kcilink.com>.
>>>>> "AAV" == Andrei A Voropaev <an...@securities.com> writes:
AAV> In our system we have to pass large PDF files thru mod_perl to
AAV> proxy and we noticed that it takes the same time as sending it
AAV> directly to customer.
Why do you have to pass the PDF thru mod_perl? Are you generating it
on the fly? If not, configure your proxy front end to intercept
static documents like .pdf .txt .html etc. to be handled by the front
end directly. I use mod_rewrite for this, and my configs have been
posted to this list at least twice.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: mod_proxy and mod_perl in guide
Posted by Stas Bekman <st...@stason.org>.
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:stas@stason.org http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/