You're right. I just tried an equivalent config with the worker mpm
with 1 process with 50 threads, no keepalive enabled and I tried a
range for PerlInterpMax (and associated vars) and couldn't get a
config I liked. Either there weren't enough interpreters and threads
were stuck waiting for an interpreter or I had as many interpreters as
I had prefork processes without the benefit of shared mem.

So I'm sticking with prefork. Also, my requests average around 2937
B/request which means they're serviced very quickly even for slow
clients, so I think I can get away without implementing a proxy
accelerator for now, but something I'll keep reevaluating.

Also, Michael I just got your comments about non-thread-safety in many
cpan modules including GD. Thanks - that reinforces the case for
prefork for me.

This morning was the first peak time I ran with prefork based on
Perrin's suggestions yesterday. Thanks to you guys, for the first time
in 10 days I didn't get any timeout warnings this morning during our
peak hour from our site monitor - and our traffic increases daily.

Thanks again!!


On 10/17/07, Perrin Harkins wrote:
> On 10/17/07, Mark Maunder wrote:
> > Assuming threaded and prefork work equally well in my config, doesn't
> > it therefore make sense to run a threaded MPM with a small interpreter
> > pool instead of running prefork with a reverse proxy?

> Well, you're going to use more memory with threads, but if you don't
> mind that then there's no reason I know of to avoid it.
> I should also add that since I don't run threads my information on how
> the worker MPM works is all second hand. The memory thing is pretty
> well established though.
> - Perrin

Mark Maunder