PHP processes & children

Igor Clark igor at pokelondon.com
Tue May 20 22:20:15 MSD 2008


Thanks very much Denis, excellent stuff.

best wishes
Igor

On 20 May 2008, at 19:01, Denis S. Filimonov wrote:

> From PHP performance perspective, one master with 32 children will  
> do better
> because they will share more memory pages and have slightly smaller  
> memory
> footprint. Besides, the master process doesn't do anything other than
> re-spawning dead children, which is a rare event.
>
> There is one case when you might want multiple master processes,  
> though.
> If your server handles multiple sites with different databases, you  
> may want
> to separate them on one php pool per database basis. The reason is  
> that in
> databases queries can stall until another query terminates  
> (particularly in
> MySQL with MyISAM tables). So, if the query takes significant time  
> compared
> to the request rate, the whole php pool will get stuck waiting for the
> database. If your other sites are handled by other php pools they'll  
> have
> little to no impact, otherwise they'll stall as well.
>
> On Tuesday 20 May 2008 10:28:01 Igor Clark wrote:
>> Hi there
>>
>> Not strictly an nginx question but don't know where else to ask and I
>> think some of you will have valuable opinions on this!
>>
>> nginx <-- fastcgi --> php
>>
>> Is it better to have 1 PHP master process on 1 port re-spawning many
>> children, or many PHP masters on many ports spawning fewer children?
>>
>> E.g.  one master with e.g. 32 worker children on 1 port, or 4 masters
>> with 8 children each on 4 ports?
>>
>> Initial thoughts would be more masters as it's a multi-core box, but
>> not sure, if all cores are switching and respawning could that get
>> expensive?
>>
>> Many thanks for any input ...
>> Igor
>>
>> --
>> Igor Clark • POKE • 10 Redchurch Street • E2 7DD • +44 (0)20 7749  
>> 5355
>> • www.pokelondon.com
>
>
>
> -- 
> Denis.
>

--
Igor Clark • POKE • 10 Redchurch Street • E2 7DD • +44 (0)20 7749 5355  
• www.pokelondon.com








More information about the nginx mailing list