httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: Server directives
Date Fri, 16 Feb 2001 14:59:37 GMT

> Uuugh, sorry, I don't like those directives, not one little bit :-)
> 
> I'm in no rush to 'do something' here so lets just keep bouncing ideas around.
> Perhaps we have conflicting goals.  I like (though not addicted to) the idea
> of keeping the directive names the same (or nearly so) across MPMs.  I like
> the following:
> 
> StartWorkers - workers are processes in the prefork mpm and threads in
> threaded mpms
> MaxWorkers - upper limit on the max number of workers
> MinSpareWorkers - minimum number of idle workers to maintain
> MaxSpareWorkers - max, number of idle workers to maintain
> MaxWorkersPerChildProcess - Not a great name. This directive only applies to a
> threaded MPM. a.k.a, threadsperchild.
> 
> Notice that for a threaded MPM, you have no direct way to specify number of
> child processes started. Number of child processes is
> StartWorkers/MaxWorkersPerChildProcess.

One MAJOR problem with this.  Perchild requires that the admin be able to
specify how many processes are started.

> My reasoning for this is pretty simple... Any decent http server admin should
> understand the difference between a worker process MPM and a worker thread
> MPM. The key thing for them to realize is that a worker corresponds to a
> connected client (a browser). Rob Thau wrestled with how to convey this notion
> back in 1995 and finally settled on the "MaxClients" directive.   So "workers'
> corresponds to 'conected clients'. If you want to support 3000 concurrent
> clients, you need 3000 'workers'. A decent admin can do the right calculations
> to balance the threads vs process issues.
> 
> For newbie admins (who generally don't run critical busy sites), we will ship
> binaries enabled for threaded MPMs by default. If they want to support more
> clients, they bump up 'StartWorkers' and they get more workers.
> 
> It makes sense to me that directives that are conceptually identical  have the
> same name.  Makes documentation easier. Makes folks writing books jobs easier.
> Makes understanding how the webserver work a bit easier (fewer directives to
> learn).  Gets rid of questions like: Does MaxProcessWorkers work in a thread
> MPM? Why not? Why am I getting an illegal directive message on
> MaxThreadWorkers when I start Apache? etc.

My own opinion is that we are going at this wrong.  We are trying to make
all of the directives be the same, but they all do different things.  To
help us make the directives the same, we are going to force the MPMs to be
configured in the same way, even if it doesn't always make sense.

Each MPM has a different execution profile, that is on purpose.  Hiding
that execution profile from the guy who is setting up the server is asking
for trouble.  I have no problem at all making sure that all instances of
MaxClients in all MPMs are symantically similar, that just makes
sense.  If MaxClients is maximum processes, then it is always maximum
processes.  If we are talking about maximum threads, then that should be
named something else.

I am also not at all tied to the directives names we have now.  Feel free
to change them to something that makes sense.

I am opposed to saying:

StartServers 10

means:

on Prefork:       Start ten child processes
on Windows:       Start ten threads in the child process
on Perchild:      Start ten child processes????
on mpmt_pthread:  Start enough children to have ten threads (this means
                  this depends on ThreadsPerChild, BTW, which nothing else
                  does.)
on OS/2:          Start ten worker threads in this child process.

IMHO the solution for this, is to grab all of the execution profile
directives from the MPMs, and make sure that any directives that share the
same name also share the same code.  Put that code in a common location,
and make it easy for new MPMs to leverage it.  Then, feel free to go in
and change the names so that they make sense.  Right now, we really don't
know how many names we have, because I think we will find that Perchild
will have some directives that no other MPM needs.

Ryan
_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------



Mime
View raw message