<br><br><div class="gmail_quote">On Fri, Jan 23, 2009 at 4:46 PM, Marlon de Boer <span dir="ltr"><<a href="mailto:marlon@hyves.nl">marlon@hyves.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Jure Pečar wrote:<br>
> On Fri, 23 Jan 2009 15:24:01 +0100<br>
> Atif Ghaffar <<a href="mailto:atif.ghaffar@gmail.com">atif.ghaffar@gmail.com</a>> wrote:<br>
><br>
>> Hi. Jure,<br>
>><br>
>> Thanks for the valuable advice.<br>
>> I will look in the cool-thread servers from Sun. We are usually buying<br>
>> from Sun but moslty the x64 server.<br>
</div></blockquote><div><br>Hi Marlon,<br>firstly thanks for your helpful response.<br>Please see my comments below.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
</div>I tested a cool-thread t2250 with 64 threads from sun a couple of weeks<br>
ago. My conclusion is that for our php application was that one thread<br>
wasn't powerful enough to serve a php page fast enough. So in our case<br>
we would end up with a lot of parallel but slower processes. Our current<br>
x86_64 hardware could deliver the pages about 2 secs faster per php-cgi<br>
process.<br>
</blockquote><div><br> I have ordered a T5120 also for a test.<br>Usually we stick with x86_64 systems too. <br>If I understand correctly you are suggesting to stay on a x86_64 system for the php processors.<br>We use also nginx+php-cgi+fpm<br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
The company I work for (<a href="http://www.hyves.nl" target="_blank">http://www.hyves.nl</a>) now has over 500<br>
webservers, serving +200M pageviews a day and 17.7M per hour max. This<br>
is done with quadcores or 2 x quadcores with 8G mem. I'm currently<br>
migrating them to nginx + php-fpm because we gain about 20% performance<br>
over apache.</blockquote><div> <br>Definitely. We have recently moved from apache+mod-php to nginx+php-cgi+fpm and not going back.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
Some tips I would like to give you,<br>
<br>
- use a optcacher like eaccelerator, apc or xcache, you can win about 8<br>
times performance.</blockquote><div><br>Yup we are using eaccelerator. </div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
- benchmark what will be the ideal number of php-cgi processes for your<br>
application, too much will lead to unnecessary context switches which<br>
costs performance, waits for backend connections etc. Not enough<br>
processes will lead to wait times between nginx and php fastcgi. For our<br>
application I spawn about 5 php-cgi's per cpu core.</blockquote><div> </div><div>so with this calculation on a 2xquadcore box there will be 30 php-cgi processes.<br>Would it not mean that on a 32 core be better to have all these processes use differnt cores?<br>
<br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
- If nginx and php-fpm run on the same host use unix sockets, these are<br>
slightly faster than tcp sockets.</blockquote><div>At the moment the nginx and php-cgi share the host but not in future.<br><br>In future nginx run on its own and php server on their own.<br><br>The php servers run php-cgi+fpm and that only.<br>
<br>Ngiinx servers serve some localy static content and some files from cache.<br>For the rest they redirect to generic php backend.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
- cache complex sql queries in memcached or in shared memory (all above<br>
optcode caches provide api's for it).</blockquote><div>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.<br>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.<br>
<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
- Tune your nginx config accordantly, we also serve static content from<br>
the same webservers. We set totally different headers like expire etc,<br>
to save bandwidth and cpu cycles which are matched by location regexes.</blockquote><div>We are separating static content to localy static (css for <a href="http://website1.com">website1.com</a>) and globaly static (a javscript file that is used on all websites).<br>
for the globaly static we use yet other nginx servers.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Don't know if all the rules apply in your environment but see what you<br>
can use from the above tips :-)</blockquote><div><br>All the tips are very useful.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<font color="#888888"><br>
Marlon de Boer<br>
System Administrator <a href="http://www.hyves.nl" target="_blank">http://www.hyves.nl</a><br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>best regards<br>Atif Ghaffar<br>