httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Erickson" <>
Subject Re: question about keepalive and child processes (Apache/prefork 2.2.3)
Date Fri, 23 Feb 2007 23:52:59 GMT
On 2/20/07, Aaron Bannert < > wrote:
> On Sun, Feb 11, 2007 at 11:14:59AM -0500, Bill Erickson wrote:
> > I'm developing a Perl module for Apache2, and while I was testing
> keepalives
> > on Apache2 (prefork, 2.2.3, default Debian package), I noticed that
> requests
> > were being handled by different children, even though they were inside a
> > single keepalive session.
> >
> > 1. Is this the expected behavior?
> > 2. Is there any way to force apache to send all keepalive requests to
> the
> > same child process?
> Are you sure the client library you were using was actually using
> keepalives?
> With all of the current Apache MPM architectures, all keepalives requests
> will be handled by the same thread in the same process. Each time you
> make a new TCP/IP connection, however, it will be processed by a new
> thread/process.

Yep, I was wrong.  There was something in my environment that was causing
the connections to close.  Testing elsewhere gives me the behavior I was
expecting.  (Long story, but I was getting worried there for a bit...)

> Basically, I'm trying to leverage keepalives to allow for multiple
> requests
> > inside a single database transaction.  For that, the client needs to be
> able
> > to communicate with the same child process throughout the transaction.
> I can't see how this will work. Since keepalive connections are not
> guaranteed to be supported by the server, and because the server can
> close off a keepalive connection at any time (see the spec for details),
> you can't assume that the entire multi-request transaction will be
> complete before the server stops processing. In other words, if your
> transaction requires 10 commands, you can't assume that the server
> will allow you to send all 10 corresponding HTTP requests, or even more
> than 1 per keepalive connection.

Let's say I can guarantee persistent connections (previous problems
notwithstanding).  I administer the server.  I write the application.  I
know Apache well enough to know why a persistent connection will be
severed.  Regardless of whether my application is portable (not my concern
right now), is this just off-the-wall crazy? :) Are there any other obvious
gotchas I'm missing?

An alternative might be to build up the transaction data in some server-side
> session state, and then when all the data is accumulated you can make one
> transactional call to the database.

Thanks for the excellent feedback.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message