Server optimizations for php

Atif Ghaffar atif.ghaffar at
Sat Jan 24 18:00:18 MSK 2009

Jure and Marlon,

Here are some more informations which might give some more insights.

The current system looks like this

16 x  single-core AMD based system with 2GB RAM.
Each system is running nginx + php-cgi-fpm (10 instances of)
Here is a graph of a typical day's load on  CPU

Here is a weekly graph which shows almost no CPU activity for half a day on
The only thing I changed was redirected the php requests to a dedicated

And here you can see the graph on one server on 21st. between 00:00 and

It seems like the server was doing nothing but was getting the same amount
of requests.
So from this I know that moving the php-cgi to dedicate host will allow me
to better scale the system.

Now about the php-processes.
I have a memory log for each php-request  and it takes between 0.5MB to
2.5MB (this is after the opcache eaccelerator)

But this is now. I want to scale the system to be tranquille for the next 2
So would a 2 - 4  of these servers ( ) with 32GB RAM be overkill

Would these more more suitable
2-4 with 8 cores and 32-64GB RAM.

>From price level I think they will come to more or less the same.
I like the idea to take some extra RAM and put the tmp files, cached opcode
files  and smarty generated template in the RAM.
With the low prices of RAM it wont make  a hole in the budget neither.

Oh and for page views we have around 0.5M at the moment but this is growing
quiet fast.

Thanks and keep the ideas coming.

best regards

On Fri, Jan 23, 2009 at 3:53 PM, Jure Pečar <pegasus at> wrote:

> On Fri, 23 Jan 2009 15:24:01 +0100
> Atif Ghaffar <atif.ghaffar at> wrote:
> > Hi. Jure,
> >
> > Thanks for the valuable advice.
> > I will look in the cool-thread servers from Sun. We are usually buying
> > from Sun but moslty the x64 server.
> >
> > The php application is a typical CMS for a hosting company.
> Then you should analyze it further. Are you sure your bottleneck is really
> cpu?
> Because "typical CMS" usualy means poorly designed database and there's
> where your bottleneck is. For those kind of problems it's usually more
> efficient at the longer term to throw expirienced programmers at the
> problem :)
> --
> Jure Pečar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the nginx mailing list