Server optimizations for php

[Atif Ghaffar]

Arvind,

Thanks for your helpful suggestions.

I will start doing tests with  different class of machines and pick the ones
that work best.

I will report to the list of my results.
best regards



On Tue, Jan 27, 2009 at 4:04 PM, Arvind <work at anomalizer.net> wrote:

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


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