On Fri, Jan 23, 2009 at 4:46 PM, Marlon de Boer email@example.com wrote:
Jure PeÄar wrote:
On Fri, 23 Jan 2009 15:24:01 +0100
Atif G. firstname.lastname@example.org wrote:
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.
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
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
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
Definitely. We have recently moved from apache+mod-php to
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
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
Would it not mean that on a 32 core be better to have all these
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
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
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
own name. so caching a “select * from users” would need to be done with
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)
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.