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!! Mark. On 10/17/07, Perrin Harkins <[EMAIL PROTECTED]> wrote: > On 10/17/07, Mark Maunder <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> http://markmaunder.com/ +1-206-6978723
