On 07/15/2008 5:45:54 PM +0200, Ron <[EMAIL PROTECTED]> wrote:

>         IdleTimeout 10
>         IdleScanInterval 5
>         MaxProcessCount 0
>         DefaultMaxClassProcessCount 1
>         SpawnScoreUpLimit 0

Setting values to 0 cannot make mod_fcgid behave as expected. More on 
this below.

>  The browser opens this script 2-2-2 etc (possibly due to the 
> maxSimultanousPersistentConnections setting in browsers). When we open 
> this script however in multiple browsers a fatal DOS-like number of 
> processes is forked, even when we use the settings above 
> (MaxProcessCount = 0).

You have to use MaxProcessCount = 1 to limit to one process. Using 0 is 
not really handled, so I think it could mean "unlimited".

> We understand that each 'main fcgi process' has 4 children, so 5 
> processes in total. There appears however to be one 'main fcgi process' 
> per (running) browser without a limit. When we close all browsers and 
> neatly run the iframe-page in only one browser, then no more extra 
> processes are forked.

Setting PHP children is completely independant of the fcgid module. So 
mod_fcgid will only rely on the processes it spawned itself, not the 
ones PHP spawned afterwards.

> How can we prevent that this many processes are forked? Ideally we want 
> only a maximum of one 'main fcgi process'.

Try setting MaxClassProcessCount to 1 in the global scope (not inside a 
<VirtualHost>). I'm not sure how local scopes are handled/merged with 
the global config.

What you are really looking for is not a dynamic process spawning, but a 
static process handling like the old mod_fastcgi behavior. This method 
is not available in mod_fcgid, so you may have to use mod_fastcgi 
instead and switch to mod_fcgid later.

> Some background information is that we also use the module xcache. This 
> module loads php-opcode in a mmap shared between forked processes. So 
> each time a new 'main fcgi process' is created the xcache re-caches all 
> opcode for the php pages. When only one 'main fcgi process' with its 
> children stays running the xcache also remains in memory for optimal 
> performance.

This doesn't really matters. You will have a duplicated cache and a bit 
of memory waste when spawning multiple main processes, but except if you 
are very tight on memory, that is not really a problem. In fact, by 
doing this, you are reducing the pressure on the xcache shared memory 
area because you are spreading the read and write locks onto multiple 
independant areas.

> (we also use suexec if that matters)

You should always use it :) Using PHP without suexec shouldn't even be 
possible, given how big the security hole is without suexec and with 
multiple PHP users.


This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Mod-fcgid-users mailing list

Reply via email to