Arvind,<br><br>Thanks for your helpful suggestions.<br><br>I will start doing tests with different class of machines and pick the ones that work best.<br><br>I will report to the list of my results.<br>best regards<br><br>
<br><br><div class="gmail_quote">On Tue, Jan 27, 2009 at 4:04 PM, Arvind <span dir="ltr"><<a href="mailto:work@anomalizer.net">work@anomalizer.net</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">On Jan 24, Atif Ghaffar wrote:<br>
>But this is now. I want to scale the system to be tranquille for the next 2<br>
>years.<br>
>So would a 2 - 4 of these servers (<br>
><a href="http://www.sun.com/servers/coolthreads/t5140/" target="_blank">http://www.sun.com/servers/coolthreads/t5140/</a> ) with 32GB RAM be overkill<br>
><br>
>Would these more more suitable<br>
>2-4 <a href="http://www.sun.com/servers/x64/x4150/" target="_blank">http://www.sun.com/servers/x64/x4150/</a> with 8 cores and 32-64GB RAM.<br>
><br>
>From price level I think they will come to more or less the same.<br>
>I like the idea to take some extra RAM and put the tmp files, cached opcode<br>
>files and smarty generated template in the RAM.<br>
>With the low prices of RAM it wont make a hole in the budget neither.<br>
><br>
>Oh and for page views we have around 0.5M at the moment but this is growing<br>
>quiet fast.<br>
<br>
<br>
</div>Atif, I'd suggest you do not go about buying beefier machines without<br>
strong justifications.<br>
<br>
RAM scaling<br>
=========<br>
I've worked with many websites that do millions of requests a day in<br>
apache+php and am yet to see any application that needs even 32GB of<br>
RAM. When you are trying to consolidate web servers, the following math<br>
*does not* hold true in general:<br>
'x' machines with 'y' amount of RAM needs to be replaced by a single<br>
machine with x*y amount of memory.<br>
<br>
In a well designed web application, large portions of memory is used by<br>
shared resources (code segments, shared cache etc. etc.) The amount of<br>
memory required for actual connection handling is very lowThis is all<br>
the more true in the case of nginx as compared to apache. (not even<br>
close to 1MB per request). So, memory needs to be scaled less than<br>
linearly when you consolidate servers. The only exception is when both<br>
of the following conditions hold true:<br>
1) Large amounts of memory is used purely for application caching<br>
2) There is some sort of a well defined partitioning of cached data<br>
across nodes to ensure that the overlap is minimal<br>
<br>
Where nginx should make a huge difference over apache: If your php<br>
application is I/O bound and a large number of connections need to be<br>
held in waiting state, then nginx should help in better memory and cpu<br>
usage.<br>
<br>
CPU scaling<br>
===========<br>
As you might know, adding more CPUs scales less than lineraly. Much of<br>
the problems arise from lock contentions. So unless you know that your<br>
entire application stack is known to scale well on a large number of<br>
cores, do not try to use something like a 64 core machine; the results<br>
might be devastating<br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>best regards<br>Atif Ghaffar<br>