Hi All -
> I'm hoping for some enlightenment about how KeepAlive is implemented in
> Apache and whether KeepAlive even comes into play when front-end and
> back-end mod_perl servers communicate with each other via HTTP.
I suppose I shouldn't have started off my previous post with such a
general-sounding comment. Thanks for all the pointers to the KeepAlive
section in the mod_perl guide, which I have read before and which doesn't
answer the questions I was asking below.
I'll try rephrasing, I'm still hoping for info regarding the questions
that follow:
mod_backhand takes advantage of KeepAlive to speed up communications
between a front-end server and a set a back-end servers that feed data to
the front-end. I'm trying to figure out how that works and if I can take
advantage of KeepAlive the same way using mod_perl front-end and back-end
servers but without running mod_backhand.
Suppose front-end server A is handling user requests. In the process of
handling a front-end request, suppose I use LWP or equivalent to make a
HTTP request from A to a back-end server B to get some data that is
needed. Assuming all the right headers are set for KeepAlive to work
(content length, etc.), can the connection between A and B even take
advantage of KeepAlive for the next time A makes the same request to B?
One problem is that I'm not sure what processes would actually be
"keeping" the ends of the "kept alive" connections. At each end, would it
be the parent httpd process, or the individual httpd child process that
made/answered the request?
I'm thinking that if A had to fork a CGI that in turn talked to B, the
kept-alive connection would be lost as soon as the CGI process on A died
(socket timeouts notwithstanding). But what if the request from A to B is
made from within a mod_perl module, or within an Apache::Registry script?
Along the same line of thought (assuming this has made any sense so far),
what happens when you throw ProxyPass/ProxyPassReverse into the mix? What
(if anything) can be done to take advantage of KeepAlive then?
Thanks,
Larry Leszczynski
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
