Server optimizations for php
atif.ghaffar at gmail.com
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
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 (
http://www.sun.com/servers/coolthreads/t5140/ ) with 32GB RAM be overkill
Would these more more suitable
2-4 http://www.sun.com/servers/x64/x4150/ 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
Thanks and keep the ideas coming.
On Fri, Jan 23, 2009 at 3:53 PM, Jure Pečar <pegasus at nerv.eu.org> wrote:
> On Fri, 23 Jan 2009 15:24:01 +0100
> Atif Ghaffar <atif.ghaffar at gmail.com> 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
> 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...
More information about the nginx