11 messages in ru.sysoev.nginxRe: Server optimizations for php
FromSent OnAttachments
Atif GhaffarJan 22, 2009 4:24 pm 
Atif GhaffarJan 23, 2009 6:23 am 
Jure PečarJan 23, 2009 6:52 am 
Marlon de BoerJan 23, 2009 7:46 am 
Atif GhaffarJan 23, 2009 4:18 pm 
Atif GhaffarJan 23, 2009 4:35 pm 
Atif GhaffarJan 24, 2009 6:59 am 
ArvindJan 27, 2009 7:03 am 
Arvind JayaprakashJan 27, 2009 7:13 am 
Atif GhaffarJan 27, 2009 7:33 am 
Atif GhaffarFeb 6, 2009 6:10 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: Server optimizations for phpActions...
From:Atif Ghaffar (atif@gmail.com)
Date:Jan 23, 2009 4:35:45 pm
List:ru.sysoev.nginx

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

Jure Pečar wrote:

On Fri, 23 Jan 2009 15:24:01 +0100 Atif Ghaffar <atif@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.