PHP/FCGI balancing

[Phillip B Oldham]

Igor Clark wrote:
> I'm considering whether to:
>
> - leave all web serving to 8GB box 1, and dedicate 8GB box 2 to PHP 
> application serving, or
>
> - load-balance web traffic between both 8GB boxes, say 70% to existing 
> box and 30% to new box, and run PHP app server on new 8GB box.
>
> As per Q1, I'd like to be able to specify some weighting on the 
> fastcgi-->PHP traffic so that I could tune which box processes what a 
> bit more finely, but from what I can see in the nginx documentation, 
> this isn't possible.
>
> The latter way seems to spread the load, but the former way dedicates 
> machines to doing one thing at a time. Given that the nginx box is 
> currently running at loads of less than 0.1 and has over 2GB of RAM 
> free, perhaps the extra nginx muscle isn't necessary.
>
> There is a bit of processing overhead on the PHP side, as the AMF 
> codec processing has to be done in PHP (the PHP AMF C extension has a 
> bug with AMF3 which breaks our app) - although we're using APC, which 
> seems to speed things up nicely.
>
> What do you think would be most sensible?
Would it not be better to use the two 8's for MySQL and PHP (same set-up 
on both, with the mysql db replicating from one to the other), and have 
the two 4's as nginx servers in a fail-over scenario? I'd've thought 
that nginx wouldn't benefit as much from the ram as PHP & MySQL would, 
and ensuring that if one of the "app" servers goes down its not the end 
of the world as you can still serve content.

-- 

*Phillip B Oldham*
The Activity People
phill at theactivitypeople.co.uk <mailto:phill at theactivitypeople.co.uk>

------------------------------------------------------------------------

*Policies*

This e-mail and its attachments are intended for the above named 
recipient(s) only and may be confidential. If they have come to you in 
error, please reply to this e-mail and highlight the error. No action 
should be taken regarding content, nor must you copy or show them to anyone.

This e-mail has been created in the knowledge that Internet e-mail is 
not a 100% secure communications medium, and we have taken steps to 
ensure that this e-mail and attachments are free from any virus. We must 
advise that in keeping with good computing practice the recipient should 
ensure they are completely virus free, and that you understand and 
observe the lack of security when e-mailing us.

------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: phill.vcf
Type: text/x-vcard
Size: 261 bytes
Desc: not available
URL: <http://nginx.org/pipermail/nginx/attachments/20080618/1c0a3875/attachment.vcf>