Server optimizations for php

[Atif Ghaffar]

On Fri, Jan 23, 2009 at 4:46 PM, Marlon de Boer <marlon at hyves.nl> wrote:

> Jure Pečar 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.
>

Hi Marlon,
firstly thanks for your helpful response.
Please see my comments below.


>
> I tested a cool-thread t2250 with 64 threads from sun a couple of weeks
> ago. My conclusion is that for our php application was that one thread
> wasn't powerful enough to serve a php page fast enough. So in our case
> we would end up with a lot of parallel but slower processes. Our current
> x86_64 hardware could deliver the pages about 2 secs faster per php-cgi
> process.
>

 I have ordered a T5120 also for a test.
Usually we stick with x86_64 systems too.
If I understand correctly you are suggesting to stay on a x86_64 system for
the php processors.
We use also nginx+php-cgi+fpm



> The company I work for (http://www.hyves.nl) now has over 500
> webservers, serving +200M pageviews a day and 17.7M per hour max. This
> is done with quadcores or 2 x quadcores with 8G mem. I'm currently
> migrating them to nginx + php-fpm because we gain about 20% performance
> over apache.


Definitely. We have recently moved from apache+mod-php to nginx+php-cgi+fpm
and not going back.


>
> Some tips I would like to give you,
>
> - use a optcacher like eaccelerator, apc or xcache, you can win about 8
> times performance.


Yup we are using eaccelerator.


>
> - benchmark what will be the ideal number of php-cgi processes for your
> application, too much will lead to unnecessary context switches which
> costs performance, waits for backend connections etc. Not enough
> processes will lead to wait times between nginx and php fastcgi. For our
> application I spawn about 5 php-cgi's per cpu core.


so with this calculation on a 2xquadcore box there will be 30 php-cgi
processes.
Would it not mean that on a 32 core be better to have all these processes
use differnt cores?



>
> - If nginx and php-fpm run on the same host use unix sockets, these are
> slightly faster than tcp sockets.

At the moment the nginx and php-cgi share the host but not in future.

In future  nginx run on its own and php server on their own.

The php servers run php-cgi+fpm and that only.

Ngiinx servers serve some localy static  content and some files from cache.
For the rest they redirect to generic php backend.


> - cache complex sql queries in memcached or in shared memory (all above
> optcode caches provide api's for it).

Yes, we heavily use caching but not using memcached (did not work for us) or
shared memory as the cache must persist between all hosts.
We are cms provider and each cms instance runs from its own db and under its
own name. so caching a "select * from users" would need to be done with on
eah domain. Anyway, on the caching side we are fine.



>
> - Tune your nginx config accordantly, we also serve static content from
> the same webservers. We set totally different headers like expire etc,
> to save bandwidth and cpu cycles which are matched by location regexes.

We are separating static content to localy static (css for website1.com) and
globaly static (a javscript file that is used on all websites).
for the globaly static we use yet other nginx servers.


>
>
> Don't know if all the rules apply in your environment but see what you
> can use from the above tips :-)


All the tips are very useful.


>
>
> Marlon de Boer
> System Administrator http://www.hyves.nl
>
>


-- 
best regards
Atif Ghaffar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20090124/309b74de/attachment.html>