Mailing List Archive: MaxServers/StartServers

MaxServers/StartServers

Jul 25, 1995, 3:26 PM

Post #1 of 5 (419 views)

I have a vague memory of a discussion with Bob McGrath
about when they were trying find a way to handle the
large number of requests coming in to the www.ncsa site.

When they limited the number of servers spawned, they
had some kind of overflow occurring in a TCP/IP buffer
that caused a ton of problems (and brought down one
of their systems). I don't really remember what exactly
the problem was, but it raised the issue of what to do
when you've reached your pre-spawned limit. It may have
been related to the way the old (pre-1.3) server handled
incoming requests. I'm pretty sure it was related to
some system code the server called, not server code itself.

In any event, I suggest that someone test the apache
server with a low absolute maximum and a high network
load just to make sure that you don't run into anything
worse than horrible performance if the absolute maximum
is set way too low.

Sincerely,

Elizabeth (Beth) Frank
NCSA Server Development Team
efrank@ncsa.uiuc.edu

Re: MaxServers/StartServers [ In reply to ]

brian at organic

Jul 25, 1995, 3:37 PM

Post #2 of 5 (400 views)

Permalink

On Tue, 25 Jul 1995, Beth Frank wrote:
> In any event, I suggest that someone test the apache
> server with a low absolute maximum and a high network
> load just to make sure that you don't run into anything
> worse than horrible performance if the absolute maximum
> is set way too low.

Part of the algorithm should be a determination of when to send a "503"
code, indicating the server was just to busy to respond to the request,
and to try again later. Those should be very easy to send (no path
analysis or disk I/O needed).

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

Re: MaxServers/StartServers [ In reply to ]

hartill at ooo

Jul 25, 1995, 4:51 PM

Post #3 of 5 (408 views)

Permalink

> On Tue, 25 Jul 1995, Beth Frank wrote:
> > In any event, I suggest that someone test the apache
> > server with a low absolute maximum and a high network
> > load just to make sure that you don't run into anything
> > worse than horrible performance if the absolute maximum
> > is set way too low.

> Part of the algorithm should be a determination of when to send a "503"
> code, indicating the server was just to busy to respond to the request,
> and to try again later. Those should be very easy to send (no path
> analysis or disk I/O needed).

I suppose that'd require all the children switching to a special
"answer everything with 503" mode for a time long enough to
reduce the "load" (however that is defined). If you spawn new
children to answer "503", the others could continue to hog resources,
and you gain very little.

rob
--
http://nqcd.lanl.gov/~hartill/

Re: MaxServers/StartServers [ In reply to ]

efrank at ncsa

Jul 26, 1995, 10:26 AM

Post #4 of 5 (402 views)

Permalink

Another idea is to spawn a single new special child
that just sends 503 messages until the parent tells
it to die. It should process requests faster than
the other children, and therefore work its way through
the waiting queue. In the meantime, you're still servicing
at least Maxserver requests. You end up with Maxserver +1
children running (once the "single request" children finish).

-Beth Frank
efrank@ncsa.uiuc.edu

On Jul 25, 4:51pm, Rob Hartill wrote:
} Subject: Re: MaxServers/StartServers
>
> > On Tue, 25 Jul 1995, Beth Frank wrote:
> > > In any event, I suggest that someone test the apache
> > > server with a low absolute maximum and a high network
> > > load just to make sure that you don't run into anything
> > > worse than horrible performance if the absolute maximum
> > > is set way too low.
>
> > Part of the algorithm should be a determination of when to send a "503"
> > code, indicating the server was just to busy to respond to the request,
> > and to try again later. Those should be very easy to send (no path
> > analysis or disk I/O needed).
>
> I suppose that'd require all the children switching to a special
> "answer everything with 503" mode for a time long enough to
> reduce the "load" (however that is defined). If you spawn new
> children to answer "503", the others could continue to hog resources,
> and you gain very little.
>
> rob
> --
> http://nqcd.lanl.gov/~hartill/
>
}-- End of excerpt from Rob Hartill

Re: MaxServers/StartServers [ In reply to ]

hartill at ooo

Jul 26, 1995, 12:27 PM

Post #5 of 5 (404 views)

Permalink

> Another idea is to spawn a single new special child
> that just sends 503 messages until the parent tells
> it to die. It should process requests faster than
> the other children, and therefore work its way through
> the waiting queue. In the meantime, you're still servicing
> at least Maxserver requests. You end up with Maxserver +1
> children running (once the "single request" children finish).

Trouble is, there's a good chance that lots of requests will be serviced,
with only a few random ones are rejected.. so lots of inline
images and stuff will end up with those annoying default icons.

By keeping Maxserver processes running as usual, there's no guarantee
you're doing anything to releave the load.

By switching all the the servers to a 503 state, you reduce the load,
and the response is consistent... people are more likely to get the
message.. hitting reload over and over will keep giving 503 until the
problem has gone.

rob