Mailing List Archive

> Redirect in .htaccess files is one fairly slick convenience feature
> which NCSA 1.5 has, which could be added to Apache 0.8.x with very
> little trouble. Given that the redirect code isn't terribly
> ticklish, and that it's very easy to test, it's tempting to break
> the freeze for it... thoughts?

It'd be nice to get into a patch'n'vote routine again. We're already
over a week after the date a few people wanted to release, and there's
still some things that need to be sorted out. (I'm currently very
uncomfortable with the current StartServers/MaxServers algorithm).

-1 new features
+1 concentrating on stabalising and releasing what we have.


rob

In reply to Andrew Wilson who said
>
> > Redirect in .htaccess files is one fairly slick convenience feature
> > which NCSA 1.5 has, which could be added to Apache 0.8.x with very
> > little trouble. Given that the redirect code isn't terribly
> > ticklish, and that it's very easy to test, it's tempting to break
> > the freeze for it... thoughts?
> >
> > rst
>
> Seems like a nice enough idea. Don't we have several ways to do this
> already though? I hear the patter of tiny creeping features. Oh what
> the heck, configuring Apache couldn't possibly be more difficult than
> it already is, go for it ;)

Isn't this what I've been nagging you for Andy? I'd definately like
to see this feature.

I don't think code freezes should be lifted though, that way lies
madness. Get the next release out then start working on new features.

There'll never be a release otherwise, people always think up one last
thing to add.

--
Paul Richards, Bluebird Computer Systems. FreeBSD core team member.
Internet: paul@FreeBSD.org, http://www.freebsd.org/~paul
Phone: 0370 462071 (Mobile), +44 1222 457651 (home)

> > still some things that need to be sorted out. (I'm currently very
> > uncomfortable with the current StartServers/MaxServers algorithm).
> >
> > -1 new features
> > +1 concentrating on stabalising and releasing what we have.
> >
> I'll decrement new features to -2, and increment stab/rel to +2.
>
> Rob, are you uncomfortable about the 150 process hard limit? I've thought
> about a time-to-sleep parameter, and a configurable hard maximum of overload
> (short-lived) processes.

After some email correspondance with Rob T, I'm a little more
comfortable.

My problem is with the 150 limit, but it came about as a result of not
remembering what Rob had written about it, and just making assumptions
about the config settings from their names.

I read StartServers and MaxServers as the number of children
to start and always have active, and the maximum number of children
to have after spawning more.


> StartServers is then the number of servers started, and also the number of
> servers sleeping on a quiescent system.

That's what I think is needed.

> MaxServers is then an upper limit on total number of long-lived (but not
> permanent) servers that can be forked as load increases. It could also be
> the sum of StartServers and long-lived servers, as it is now. These
> servers would have a configurable lifetime (time-to-sleep parameter).

I'm not sure what role MaxServers has in a revised system.

> AbsMaxServers (or something like that) could be servers with either a fixed
> or configurable, and presumably much shorter, time-to-sleep, or could retain
> the current forking behavior, handling one connect each. This would replace
> the hardwired 150 child limit.

Yup, there needs to be a configurable absolute maximum.

It might have to wait until after the release, but I think this is
very much needed.


I agree with Chuck on most of this.

The other thing I'd like to see (one day) is for the spawned children
to have request limit which is inversly proportional to the number of
spawned children. So if the absolute max is 50 servers, the 50th one
has a very short lifespan.. maybe just a couple of requests. This
could help reduce the number of children once a request peek had eased,
instead of them lingering for hours.



rob

Rob T writes,

> However, I am somewhat loath to let people set AbsMaxServers (or
> whatever) to 7 and think they've done themselves a favor. As it is,
> they've still got the source code, and they can screw themselves if
> they really want to, but we haven't made it easy for them.

This isn't so much of a problem if (as I suggested to Rob), the
config file has guidelines in it.

I suggested something like

# AbsMaxServers
# The absolute maximum number of processes that can be running.
#
# You should not set this to anything below 50, unless you
# understand that this has the potential to significantly limit the
# number of concurrent requests being processed, resulting in new
# requests failing to make connections with the server.
#
# If you find that AbsMaxServer processes are active for prolonged
# times, then you should consider increasing it.
AbsMaxServer 50


I don't believe that protecting people from screwing themselves is
a good enough reason to limit the useability of the server. At the
moment we don't know what the best settings are for people to use. Unless
we have full control over the configuration, it's difficult to experiment.


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

> However, I am somewhat loath to let people set AbsMaxServers (or
> whatever) to 7 and think they've done themselves a favor. As it is,
> they've still got the source code, and they can screw themselves if
> they really want to, but we haven't made it easy for them.

I though it was the government's job to protect people from themselves ?

Anyway, it was this protection from ourselves which caused the process table
on our main server to overflow the other day when a disk went bad, and
Apache 0.8.2 spawned away as fast as it could.

We know that we don't need more than 25 children running at any time for
the load we get here (20k /day). I know the risks, and don't need my
hand held.

I could just as easily screw myself by setting MaxRequestsPerChild to 1
and StartServers/MaxServers to 1, but there's no guardian angel to save
me there.

Whatever hard-coded limit we choose, it'll be too high for some
and too low for others, and most people won't even think about (or
want to) recompile Apache to change this.


The term "MaxServers" is crazy in the current setup (maybe with NCSA too) -
it defines some *lower* limit of the number of children to keep active, not
an upper limit.

Ship 0.8.x as it is, but doesn't this need some attention ?, and if so,
any likely changes should be noted in the config files and documentation,
so that people realise that the meanings of some variables are expected to
change.


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

From: Chuck Murcko <chuck@telebase.com>
Date: Tue, 25 Jul 1995 13:50:08 -0400 (EDT)

[. Mentions the idea of having servers die off when idle for longer
than a specified period... ]

Hmmm... this would allow for dieback beyond MaxServers when MaxServers
has been reached, and seems the most sensible way to do it; the only
problem would be deciding whether to worry about unlikely coincidences
where a whole bunch of servers would die off all at once. The code
which does this sort of thing is ticklish enough that I'm a bit
reluctant to do it for the current release, but it seems reasonable
for TNR.

AbsMaxServers (or something like that) could be servers with either a fixed
or configurable, and presumably much shorter, time-to-sleep, or could retain
the current forking behavior, handling one connect each. This would replace
the hardwired 150 child limit.

Let me say here why I decided *not* to make this configurable. It's
been my experience, and apparently that of some other people, that
when people have the opportunity to set hard server limits, they
invariably set them way too low. For instance, Chuck guessed that
this configuration:

StartServers: 1
MaxServers: 1
AbsMaxServers: 10

behaves like an old-style forking server, for those with limited resources.

Nope. I've got resources as limited as anybody's (heck, my server is
a Sparc 2), but when I was running a forking server (~100K hits/day),
I rarely had as few as ten server processes active at once in prime
time --- this configuration would have resulted in numerous requests
being dropped on the floor, and very poor service for clients.

I can see the case for a hard limit, BTW, but only to keep a server
which has already failed catastrophically from taking the Unix kernel
with it by filling up the process table (or something more critical).
For this purpose, I can see lowering the hard max to 50 --- which
consumes (at ~200K/process, which is than what's in my server pool
now) about 10M of swap space, which *anyone* can afford.

However, I am somewhat loath to let people set AbsMaxServers (or
whatever) to 7 and think they've done themselves a favor. As it is,
they've still got the source code, and they can screw themselves if
they really want to, but we haven't made it easy for them.

chuck
Chuck Murcko Telebase Systems, Inc. Wayne PA chuck@telebase.com
And now, on a lighter note:
Democracy is good. I say this because other systems are worse.
-- Jawaharlal Nehru

Hmmm... I thought Churchill said it better --- "The worst system of
government that has ever been devised, except for all the others".

rst

> Redirect in .htaccess files is one fairly slick convenience feature
> which NCSA 1.5 has, which could be added to Apache 0.8.x with very
> little trouble. Given that the redirect code isn't terribly
> ticklish, and that it's very easy to test, it's tempting to break
> the freeze for it... thoughts?
>
> rst

Seems like a nice enough idea. Don't we have several ways to do this
already though? I hear the patter of tiny creeping features. Oh what
the heck, configuring Apache couldn't possibly be more difficult than
it already is, go for it ;)

Ay.

> Isn't this what I've been nagging you for Andy? I'd definately like
> to see this feature.

Uuuh, yeah, it is. I was just ignoring you. ;) Seriously tho, yeah it's
a good feature and makes redirection something that non www-admin people
can do easily (editing their own files in their own filespace) without
needing to pester Jo Random Web-admin. [almost] anything that makes an
admin's life easier has to be a good thing.

[.Paul's just started a new job but wants references to his old web pages to
be redirected to his new site]

> I don't think code freezes should be lifted though, that way lies
> madness. Get the next release out then start working on new features.
>
> There'll never be a release otherwise, people always think up one last
> thing to add.

There've been a few bugs raised in this new version, it's nice to be
thorough once in a while. I personally get confused by version updates
that happen too quickly for me to really get down and try to make things
break.

On a different note, I've done quite a bit of research on who's using Apache
and which versions of the server (and other servers) are out there. The
user base is quite big (over 150 .com sites alone) and certainly
comprises far more people than are on this list. There's also evidence to
suggest that people using Apache don't keep in step with new releases; there
are quite a few pre-Apache/0.6.5's out there. It would be nice to maintain
Apache's reputation and only release when we've taken a sensible amount of
time to review changes. By which I mean at least another week.

> Paul Richards, Bluebird Computer Systems. FreeBSD core team member.
> Internet: paul@FreeBSD.org, http://www.freebsd.org/~paul
> Phone: 0370 462071 (Mobile), +44 1222 457651 (home)

Cheers,
Ay.

Andrew Wilson URL: http://www.cm.cf.ac.uk/User/Andrew.Wilson/
Elsevier Science, Oxford Office: +44 01865 843155 Mobile: +44 0589 616144

David R wrote,
> This is all way too complicated for the user. There only needs to be one
> parameter, which supplies the functionality of MaxServers, but is called
> something like FreeServers.

I've polled a few of the people on this list to find out what
they have for

StartServers and MaxServers

It's not just too complicated for users, it's too complicted for us.
Everyone seems to have misconfigured these.

I've also looked at the NCSA blurb on the two, and they don't have the
same meaning as ours.

I vote -1 on releasing 0.8.x with these two names, unless there's
a damn good reason to keep them.

As alternatives I'd suggest

StartServers -> ServersToKeepReady
MaxServers -> ServerPoolSize

> With the apache model, having StartServers > 1 is a waste of time.

NCSA 1.4 users will have this far too high for Apache to drop in
and work efficiently.

Lots of us have or had it set to >>10, which is certainly a waste
of time.
I lowered Cardiff's from 25 to 4 and it improved performance enormously.
For busy servers, I do think that StartServers >1 is useful, but
certainly not with that name.

> It's simpler to set FreeServers to 5 if you want 5 servers right away.
>
> I have yet to be convinced that AbsMaxServers is needed for load throttling,
> rather than relying on the limited CPU.

I'd like it, not for load throttling, but as a safety valve to stop
Apache overflowing the process table (our main server here has a small
process limit).

AbsMaxServers -> ForkSafetyMax

> So:
> * StartServers and AbsMAxServers are #defines, set to 1 and 100 (say)
> respectively.

If our main server tried to fork 100 processes, it would have already
brought the whole machine to a grinding halt. #define'ing it just makes
it less accessible.

> * Rename MaxServers as FreeServers.

Yes !, rename MaxServers and StartServer. They need to be intuitive...
people don't expect to see documentation in CHANGES files. That's the only
source of real information on these settings I could find. Yes I'm lazy,
but no lazier than Joe Average web master.


rob

> This means having to do *something* about StartServers and MaxServers
> directives in peoples' NCSA 1.4 config files, or fail to be a drop-in
> replacement. -1 on that.

Better to get them to configure it properly than have it misconfigured.

> If you want to have a StartServers parameter which means *exactly*

No, just a change of the existing names to make them obvious, and to
stop 1.4 users falling into a hole.

People on this list have shown that the names mislead and result in
misconfigured systems.

> To be blunt, I'm getting very frustrated with the whole tone of this
> discussion. I thought we had an agreement to stop monkeying around,
> and get something out the door. Very well then --- this is *not* the
> time to be doing design work!

renaming is not redesining. It's a simple change that'd take a
couple of minutes. I think it is worth it.

> I thought that agreement to release something was firm enough that I
> told someone in public, a week ago, that we would have something out
> the door just about now. At this point, I think I've broken that
> promise, and I don't feel very good at all about that.

I've done that too. This isn't the only thing that has held up the
release, so please don't blame it...

> So, are we trying to get something out the door, or would we rather
> just dicker *indefinitely*?

We're talking about a 2 minute change to some *new* Apache config
variables.. that's all.

Keeping the existing names will cause more trouble that telling 1.4
users to switch to more meaningful ones. We never made it a policy
to stay in sync with 1.4, only 1.3.


rob

On Wed, 26 Jul 1995, Robert S. Thau wrote:
> As far as I can tell, my proposed changes, which were to create a
> separate StartServers parameter, rename the current StartServers to MinFree,
> and provide MaxFreeServers as an alternate and preferred name for MaxServers,
> eliminate the confusion which you keep griping about.

+1 on this.

> As to votes, you want a vote you got it. Apache 0.8.2 is presently a
> drop-in replacement for NCSA 1.4. To any proposed change which would alter
> this, I vote:
>
> -1

Agreed.

Brian

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

> From: Rob Hartill <hartill@ooo.lanl.gov>
> Date: Wed, 26 Jul 95 12:35:52 MDT
>
> No, just a change of the existing names to make them obvious, and to
> stop 1.4 users falling into a hole.
>
> People on this list have shown that the names mislead and result in
> misconfigured systems.
>
> OK, I'm willing to deal with that, provided that 1.4 config files
> still work (see below) but my patience is getting very thin --- from
> this point on, I will be very inclined to veto every change except
> for:
>
> 1) new *experimental* modules (meaning advertised as "experimental",
> as for mod_dld, and *disabled* in the default Configuration).
>
> 2) Clear fixes to real bugs (meaning that some existing service fails,
> which used to work).
>
> [Rob goes on...]
>
> .... We never made it a policy
> to stay in sync with 1.4, only 1.3.
>
> Pardon my French, but the hell we didn't. The first bulleted item on
> our "about the project" page reads:
>
> The Apache httpd server (beta) ...
>
> *) is a plug-in replacement for NCSA 1.3 or 1.4

okay that needs changing, because it isn't even true for 0.6.5

> You wrote that --- I didn't. I'm just trying to deliver, however
> belatedly, on that promise (before 1.5 is widely enough distributed to
> make the issue moot), and I see no reason at all not to do so.

0.6.5 doesn't handle StartServers or MaxServers, so we have no obligation
to use them, and moreover we shouldn't abuse their meanings because
they just happen to be there.

Someone off this list just mailed me to see he was using 0.8.2, I'm
waiting to see what he set those two config values to, I'd be surprised
if he set them appropriately. They need renaming.

It's a trivial job for 1.4 users to change 2 things in a config file in
order to get an efficient server. Because of the differences in meaning,
those people need to be asked to change these two anyway, so lets name
them properly and be done with it.

Let's put it to a vote.

rob

From: Rob Hartill <hartill@ooo.lanl.gov>
Date: Wed, 26 Jul 95 11:38:58 MDT

I've polled a few of the people on this list to find out what
they have for

StartServers and MaxServers

It's not just too complicated for users, it's too complicted for us.
Everyone seems to have misconfigured these.

I've also looked at the NCSA blurb on the two, and they don't have the
same meaning as ours.

I vote -1 on releasing 0.8.x with these two names, unless there's
a damn good reason to keep them.

As alternatives I'd suggest

StartServers -> ServersToKeepReady
MaxServers -> ServerPoolSize

This means having to do *something* about StartServers and MaxServers
directives in peoples' NCSA 1.4 config files, or fail to be a drop-in
replacement. -1 on that.

If you want to have a StartServers parameter which means *exactly*
that, a new MinFree parameter which has the effect of the current
StartServers (also defaulting to 5 --- there is a measurable
performance difference between that and, say, 3), and a more mnemonic
alternative name for MaxServers, I could live with that, if only
because it doesn't involve major changes to the code. However, at
this point, I vote -1 on *any* major change to the code itself.

To be blunt, I'm getting very frustrated with the whole tone of this
discussion. I thought we had an agreement to stop monkeying around,
and get something out the door. Very well then --- this is *not* the
time to be doing design work!

I thought that agreement to release something was firm enough that I
told someone in public, a week ago, that we would have something out
the door just about now. At this point, I think I've broken that
promise, and I don't feel very good at all about that.

So, are we trying to get something out the door, or would we rather
just dicker *indefinitely*?

rst

> As far as I can tell, my proposed changes, which were to create a
> separate StartServers parameter, rename the current StartServers to MinFree,
> and provide MaxFreeServers as an alternate and preferred name for MaxServers,
> eliminate the confusion which you keep griping about.

I've been suggesting a subset of this.

- create a separate StartServers parameter
I don't think it's needed, but if it is, it could just
refer the user to info on setting the replacement variables.

If you want to do something more sophistacted with it, fine, but
that'd break the freeze.

- rename the current StartServers to MinFre
I don't think 'MinFree' describes it correctly, but it's better
than what we have. The CHANGES file suggests the meaning is the
number of servers that the parent tries to keep in a ready to accept
state, so 'ServersKeptReady' seems more intuitive.

- provide MaxFreeServers as an alternate and preferred name for MaxServers
That's better, but the "Free" can be misinterpreted. 'ServerPoolSize'
doesn't mention a min/max or any kind of process state.



If anyone has better names, fine.


rob

From: Rob Hartill <hartill@ooo.lanl.gov>
Date: Wed, 26 Jul 95 12:35:52 MDT

No, just a change of the existing names to make them obvious, and to
stop 1.4 users falling into a hole.

People on this list have shown that the names mislead and result in
misconfigured systems.

OK, I'm willing to deal with that, provided that 1.4 config files
still work (see below) but my patience is getting very thin --- from
this point on, I will be very inclined to veto every change except
for:

1) new *experimental* modules (meaning advertised as "experimental",
as for mod_dld, and *disabled* in the default Configuration).

2) Clear fixes to real bugs (meaning that some existing service fails,
which used to work).

[Rob goes on...]

.... We never made it a policy
to stay in sync with 1.4, only 1.3.

Pardon my French, but the hell we didn't. The first bulleted item on
our "about the project" page reads:

The Apache httpd server (beta) ...

*) is a plug-in replacement for NCSA 1.3 or 1.4

You wrote that --- I didn't. I'm just trying to deliver, however
belatedly, on that promise (before 1.5 is widely enough distributed to
make the issue moot), and I see no reason at all not to do so.

rst

> From: Rob Hartill <hartill@ooo.lanl.gov>
> Date: Wed, 26 Jul 95 14:54:17 MDT
>
> > As far as I can tell, my proposed changes, which were to create a
> > separate StartServers parameter, rename the current StartServers
> > to MinFree, and provide MaxFreeServers as an alternate and
> > preferred name for MaxServers, eliminate the confusion which you
> > keep griping about.
>
> I've been suggesting a subset of this.
>
> - create a separate StartServers parameter
> I don't think it's needed, but if it is, it could just
> refer the user to info on setting the replacement variables.
>
> If you want to do something more sophistacted with it, fine, but
> that'd break the freeze.
>
> *Any* change is breaking the freeze. You asked for it. In any case,

The freeze is on new features. StartServers can be unsupported as far
as I'm converned.

I'm not imposing the freeze on anyone, just pointing out that if such
a change was made, it'd break the freeze on new features... in this case
it might be worth it.

> As to the names of the other two --- recall that the way the mechanism
> works is to try to keep the number of free servers between what I'm
> calling MinFreeServers and MaxFreeServers. I feel any change which is
> supposed to "clarify" matters should make it clear that there is a
> *range*, meaning that neither parameter is, by itself, a target value,
> and should also make it clear which bound (lower or upper) is which.
>
> Your suggestions ("ServersKeptReady" and "ServerPoolSize") fail on
> both counts --- both look like targets, rather than lower and upper
> bounds of a range, and even if you know that they're lower and upper
> bounds, I for one have no idea which is which looking just at the
> names.

Once I read these (my comments above) meanings into the variables, I was
able to set them to realistic values and reap the benefits. StartServers just
happens to define a lower limit, but it's real
and powerful purpose (if the CHANGES file is to be believed)
is to define how many processes the parent tries to keep in a ready to
go state, i.e. how many future requests can be processed immediately.
With a 100k site, with peeks of say 2 requests per second of some given
time, a low value is needed (<5).
Thinking of it as some lower range value gives the wrong impression, e.g.
if I set them to 4 and 6, this doesn't mean that I think I need somewhere
between 4 and 6 servers, it means that typically 6 servers should
always exist and of those 6, 4 of them need to be
in the "ready to go state" - that leaves
two which are doing any real work. In order to process a third simultaneous
request the parent needs to fork another process so as to keep 4 "ready".

If you think of it in terms of the way I described, it's actually a
workable and nice system. If you think of it as a range, you stand a
good chance of misconfiguring it and forcing lots of unecessary forking().

It can be argued that almost everyone on this list though that
StartServers and MaxServers did define a range (that's what I though).
My understanding now is that they don't. They define a "keep ready" value
which guarantees fast connections, and a pool size which people think
they need to optimize space/forking tradeoffs.


If I've misunderstood the concept again, god help people webmasters
everywhere.


rob

As far as I can tell, my proposed changes, which were to create a
separate StartServers parameter, rename the current StartServers to MinFree,
and provide MaxFreeServers as an alternate and preferred name for MaxServers,
eliminate the confusion which you keep griping about.

As to votes, you want a vote you got it. Apache 0.8.2 is presently a
drop-in replacement for NCSA 1.4. To any proposed change which would alter
this, I vote:

-1

rst

yeah yeah, yawn yawn.

It might help if I added this; having read the description of
how the thing works, in CHANGES. I sat for a long time thinking
what it meant. Using my interpretation, I was able to configure
the Cardiff server according to what I needed. I tweaked it a little
while it was running, and am now *very* pleased with the results.
The improvements went beyond my expectations. I saw a >30% increase
in requests and a much lower load average.

I want to share these benefits with others.

On Wed, 26 Jul 1995, Robert S. Thau wrote:

> As far as I can tell, my proposed changes, which were to create a
> separate StartServers parameter, rename the current StartServers to MinFree,
> and provide MaxFreeServers as an alternate and preferred name for MaxServers,
> eliminate the confusion which you keep griping about.
>
> As to votes, you want a vote you got it. Apache 0.8.2 is presently a
> drop-in replacement for NCSA 1.4. To any proposed change which would alter
> this, I vote:
>
> -1

If I may be so bold as to jump in, I agree. On www.io.org we get
about 150,000 hits a day and have a lot of users who scream at me if
something doesn't work. We were having a lot of SIGSEGVs with NCSA
1.4.1, switched to Apache 0.6.5, still got them, went to NCSA 1.4.2
and things got somewhat better. I want to go to Apache 0.8.whatever,
and I can make some minor modifications, but we don't have another
machine we can thrash on which to test Apache. Dropping it right in
would be really nice.

I've been following this list for a while now, and I've learned a
lot. I want to thank all you folks.

Bill
--------------
William Denton | <URL:http://www.io.org/~buff> | buff@io.org | Caveat lector.
The line forms on the right, babe.

From: Rob Hartill <hartill@ooo.lanl.gov>
Date: Wed, 26 Jul 95 14:54:17 MDT

> As far as I can tell, my proposed changes, which were to create a
> separate StartServers parameter, rename the current StartServers
> to MinFree, and provide MaxFreeServers as an alternate and
> preferred name for MaxServers, eliminate the confusion which you
> keep griping about.

I've been suggesting a subset of this.

- create a separate StartServers parameter
I don't think it's needed, but if it is, it could just
refer the user to info on setting the replacement variables.

If you want to do something more sophistacted with it, fine, but
that'd break the freeze.

*Any* change is breaking the freeze. You asked for it. In any case,
the actual changes to the code required here are minimal --- it
amounts to replacing two uses of one variable with one use of each of
two variables.

As to the names of the other two --- recall that the way the mechanism
works is to try to keep the number of free servers between what I'm
calling MinFreeServers and MaxFreeServers. I feel any change which is
supposed to "clarify" matters should make it clear that there is a
*range*, meaning that neither parameter is, by itself, a target value,
and should also make it clear which bound (lower or upper) is which.

Your suggestions ("ServersKeptReady" and "ServerPoolSize") fail on
both counts --- both look like targets, rather than lower and upper
bounds of a range, and even if you know that they're lower and upper
bounds, I for one have no idea which is which looking just at the
names.

rst

>From: Chuck Murcko <chuck@telebase.com>
>Date: Tue, 25 Jul 1995 13:50:08 -0400 (EDT)
>
>...
>StartServers is then the number of servers started, and also the number of
>servers sleeping on a quiescent system.
>
>MaxServers is then an upper limit on total number of long-lived (but not
>permanent) servers that can be forked as load increases. It could also be
>the sum of StartServers and long-lived servers, as it is now. These
>servers would have a configurable lifetime (time-to-sleep parameter).
>
>AbsMaxServers (or something like that) could be servers with either a fixed
>or configurable, and presumably much shorter, time-to-sleep, or could retain
>the current forking behavior, handling one connect each. This would replace
>the hardwired 150 child limit.
>...

This is all way too complicated for the user. There only needs to be one
parameter, which supplies the functionality of MaxServers, but is called
something like FreeServers.

With the apache model, having StartServers > 1 is a waste of time.
It's simpler to set FreeServers to 5 if you want 5 servers right away.

I have yet to be convinced that AbsMaxServers is needed for load throttling,
rather than relying on the limited CPU.

So:
* StartServers and AbsMAxServers are #defines, set to 1 and 100 (say)
respectively.

* Rename MaxServers as FreeServers.

David.