Keepalive question,,,

[Tom Harrington <tp...@crosstor.com>]

I'm nearly done with my Apache port, but I could really use some help
understanding keepalive.  (This is 1.3.x, hopefully it's not too much
of a distraction from the 2.x development).

I understand that the main request-processing loop will keep calling
ap_read_request() until there's nothing left-- at which point it will
block trying to read a request until KeepAliveTimeout seconds have
passed.

Does this _always_ happen?  And if so, why doesn't it cause an enormous
number of idle server processes under any significant server load?  (Or
does it?)  It seems as though this would mean that each server process
can only handle incoming requests once every KeepAliveTimeout seconds.
I have this vision of hundreds of server processes waiting for
KeepAliveTimeout over and over, on every request, but somehow this
doesn't seem like it can be correct.

-- 
Tom Harrington
CrosStor Software, Inc.
tph@crosstor.com

Re: Keepalive question,,,

[Tom Harrington <tp...@crosstor.com>]

Bill Stoddard wrote:
> 
> > I'm nearly done with my Apache port, but I could really use some help
> > understanding keepalive.  (This is 1.3.x, hopefully it's not too much
> > of a distraction from the 2.x development).
> >
> > I understand that the main request-processing loop will keep calling
> > ap_read_request() until there's nothing left-- at which point it will
> > block trying to read a request until KeepAliveTimeout seconds have
> > passed.
> >
> > Does this _always_ happen?
> No, the server can be configured to turn off keep alive entirely.

Yeah, I suppose I should have said "does this always happen when
keepalive is enabled", but I think you covered that.

> > And if so, why doesn't it cause an enormous
> > number of idle server processes under any significant server load?
> It does. Some sites that support large numbers of concurrent clients turn off keep-alive
> to eliminate processes blocking on network reads to inactive clients.
> 
> > (Or
> > does it?)  It seems as though this would mean that each server process
> > can only handle incoming requests once every KeepAliveTimeout seconds.
> 
> The process can handle connections from the client is is waiting for immediately. However,
> the process cannot handle requests coming in on other connections. Keep alive binds a
> process to a connection. If no requests come in on that connection, the process is taking
> up system resources but doing no work. Apache 1.3 can still handle a vary large number of
> concurrent clients with proper tuning.

Thanks, this is exactly what I needed to know.


> Apache 2.0 will be able to handle more concurrent clients because it uses threads, rather
> than processes to handle requests. Threads are lighter weight than processes, so you can
> have more of them for a given hardware configuration. 

Hmm, as it happens, this port is to a threaded environment (many
thanks to the Netware and NT folks for exposing where changes were
needed for this!), so maybe it's not as bad as I feared.  I just
didn't really understand the implications of keepalive until today,
so I found the number of idling servers to be alarming.

-- 
Tom Harrington
CrosStor Software, Inc.
tph@crosstor.com

Re: Keepalive question,,,

[Bill Stoddard <st...@raleigh.ibm.com>]

> I'm nearly done with my Apache port, but I could really use some help
> understanding keepalive.  (This is 1.3.x, hopefully it's not too much
> of a distraction from the 2.x development).
>
> I understand that the main request-processing loop will keep calling
> ap_read_request() until there's nothing left-- at which point it will
> block trying to read a request until KeepAliveTimeout seconds have
> passed.
>
> Does this _always_ happen?
No, the server can be configured to turn off keep alive entirely.

> And if so, why doesn't it cause an enormous
> number of idle server processes under any significant server load?
It does. Some sites that support large numbers of concurrent clients turn off keep-alive
to eliminate processes blocking on network reads to inactive clients.

> (Or
> does it?)  It seems as though this would mean that each server process
> can only handle incoming requests once every KeepAliveTimeout seconds.

The process can handle connections from the client is is waiting for immediately. However,
the process cannot handle requests coming in on other connections. Keep alive binds a
process to a connection. If no requests come in on that connection, the process is taking
up system resources but doing no work. Apache 1.3 can still handle a vary large number of
concurrent clients with proper tuning.

Apache 2.0 will be able to handle more concurrent clients because it uses threads, rather
than processes to handle requests. Threads are lighter weight than processes, so you can
have more of them for a given hardware configuration. The next step is to eliminate the
necessity of binding a process or thread to a connection at all using asynchronous network
i/o.

Bill