Re: OT: performance FUD

[Brian Candler <B....@pobox.com>]

On Wed, Nov 30, 2005 at 02:58:00PM -0600, William A. Rowe, Jr. wrote:
> fork() is *painfully* slow on the darwin kernel, I haven't tested but can't
> imagine that threading isn't a huge win here.

Explain?

One preforked worker process can handle thousands of requests. Apache
doesn't have to fork for each one.

Re: OT: performance FUD

[Brian Candler <B....@pobox.com>]

On Thu, Dec 01, 2005 at 04:02:49AM -0600, William A. Rowe, Jr. wrote:
> I'm referring to shrinking or growing the pool of threads/processes as 
> needed.
> 
> If worker grows threads as needed, or even has to spawn only one more 
> process
> to create dozens of threads, this is goodness.

But is it a "huge win" (your words)?

What ratio do you observe for number of forks in relation to number of
incoming requests?

With processes being pre-forked ahead of demand, how large a problem does
this pose in practice?

Re: OT: performance FUD

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

I'm referring to shrinking or growing the pool of threads/processes as needed.

If worker grows threads as needed, or even has to spawn only one more process
to create dozens of threads, this is goodness.

Bill

Brian Candler wrote:
> On Wed, Nov 30, 2005 at 02:58:00PM -0600, William A. Rowe, Jr. wrote:
> 
>>fork() is *painfully* slow on the darwin kernel, I haven't tested but can't
>>imagine that threading isn't a huge win here.
> 
> 
> Explain?
> 
> One preforked worker process can handle thousands of requests. Apache
> doesn't have to fork for each one.
> 
> .
>