Hi

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.

Gabriel

-------------------------------------------------------------------------
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
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Mod-fcgid-users mailing list
Mod-fcgid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users

Reply via email to