is it better to upstream php processes via nginx or use a front facing load balancer?

[Ilan Berkner]

1.6mm page views per day and growing (all dynamic php), this does not inclue
a large number of static files (mostly mp3 files) being served as well.

Nginx is serving both PHP and static files all from the same server.

Main bottleneck right now is PHP processes getting overloaded, probably due
to high number of connections (we are working on reducing this number - we
have some inefficiencies where a single page may make over 120 requests
before completely loading).  The other issue is the number of database
requests per page can be very high which delays PHP response times and
increases queue.

Regardless, we need to add another box, but I'm trying to figure out if best
approach is physical LB in front of duplicate nginx boxes, i.e. each box
serving both PHP and static files OR more complex solution with one of the
boxes acting as master and routing PHP requests via Nginx to other boxes,
etc. as well as possibly adding a static server specifically for images and
mp3 files.

On Thu, Sep 10, 2009 at 5:35 AM, Dinh Pham <lists at ruby-forum.com> wrote:

> How high traffic have your sites got?
>
> In my system, Nginx plays a role of a LB and static file server. It
> dispatches .php requests to a pool of Apache instances and PHP FCGI. It
> works great for 600 000+ page views per day.
>
> Ilan Berkner wrote:
> > Hi,
> > Is it better to use a hardware load balancer in front of multiple nginx
> > boxes, each running their own php processes or is it better to use
> > nginx's
> > upstream functionality and round robin php requests?
>
> --
> Posted via http://www.ruby-forum.com/.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20090910/cd09cab7/attachment.html>