On Friday 21 September 2001 01:04 pm, Joshua Slive wrote:
> Aaron was brave enough to raise this topic again, and I'd rather not see it
> fall flat, so I'm going to try to force the issue.
>
> Here are two proposals.  They work for both prefork and worker.  I have not
> thought deeply about perchild, so I don't know how it will fit in.
>
> A: All config directives deal with "workers".  Behind the scenes,
> StartWorkers and MaxWorkers are translated into processes using Aaron's
> logic.
>
> StartWorkers              50
> MaxWorkers               150
> MinSpareWorkers           10
> MaxSpareWorkers           50
> WorkersPerProcess         25
> MaxRequestsPerProcess      0
>
> B: Slightly less elegant because different units are used for different
> directives, but no behind the scenes translation is necessary, so it is
> more predictable.
>
> StartProcesses             2
> MaxProcesses               6
> MinSpareWorkers           10
> MaxSpareWorkers           50
> WorkersPerProcess         25
> MaxRequestsPerProcess      0
>
> I can live with either of these, but I don't think it makes sense to have
> "StartProcess" and "MaxWorkers".  If we are going to translate one in the
> background, we should translate both.
>
> I slightly favour B because it is simpler and involves no code changes
> except changing directive names.

I would much rather see us implement A.  It makes things more obvious to the
user.  We aren't asking them to do any multiplication to look at how many
requests they can handle at once.  This will also cut down on the number of
bugs filed.  I am mostly thinking of Unix, where threads are reported through
ps.  If people specify 6 processes to start, but ps reports 120 have been started,
they think it is a bug.  In reality, Linux is just reporting all the threads as if
they were processes.

Also, sticking with A makes us translate better from 1.3 to 2.0.  I know this isn't
a concern for most people, but it would be nice for our users.

Ryan
______________________________________________________________
Ryan Bloom                              [EMAIL PROTECTED]
Covalent Technologies                   [EMAIL PROTECTED]
--------------------------------------------------------------

Reply via email to