NYCPHP Meetup

NYPHP.org

[nycphp-talk] advice on scaling up

Anirudh Zala arzala at gmail.com
Wed Jul 11 08:34:00 EDT 2007


On Tuesday 10 Jul 2007 23:17:13 Marc Antony Vose wrote:
> Hi all:
>
> I'm a developer who has concentrated more on smaller-scale projects,
> but as it turns out one of my projects is beginning to stress the
> limits of a single server, and so I'm about to begin venturing into
> the unknown.
>
> The project is currently in the "tens of thousands" of users range,
> but it looks like we need to start drafting a plan to scale it up to
> "hundreds of thousands" to a million or so users.
>
> This is a site that is running on a custom built PHP framework (which
> seems to be performing rather well), and MySQL.  The server's running
> Apache and Linux (Red Hat). There is some image and data uploading
> from users, and most pages are served dynamically, currently, with
> very simple SQL.  I have taken the step of caching any page elements
> that require any kind of recursion or iteration to produce (such as a
> list of categories that displays the number of related items from
> other tables in it), but I have not cached, for example, database
> calls to just one item matching on the primary key.  I think this
> approach has been sensible so far.
>
> If I had to classify the site, I'd say it follows a similar usage
> pattern as something like last.fm, or facebook, only much smaller.
> Social networking-type thing, but users are not constantly visiting
> and reloading pages, like a news site.
>
> So, more than the PHP coding strategy, my question is about what kind
> of hosting/server arrangement I would be looking at to handle the
> kind of load I'm talking about.
>
> How many servers will I need to handle the kind of traffic I
> require?  If this question is not so easily answered, then what would
> be my equation for figuring this out?  A friend told me he works on a
> site that has 4,000,000 users and they have their system optimized to
> handle 500 requests per second.  This is for a search engine-type
> site...is this a reasonable metric?
>
> When you separate database and http servers, then what should be the
> hardware priorities for each?  CPU speed? RAM?  hard disk speed,
> etc.?  Perhaps the database is more RAM and HD dependent, and the web
> server will need more CPU and RAM?
>
> I'd be interesting in learning a bit from those of you who are
> working on larger-scale projects what's powering your servers, and
> what kind of capacity you think your setup's giving you.
>
> Thanks for helping me determine exactly where to research.
>
> Cheers,
>
> Marc Vose
> Suzerain Studios

Let me  try to suggest some general points.

At client environment you may use Ajax (and JSON) to increase responsiveness 
of your website. But effective implementation of Ajax requires good knowledge 
of JS and how it interacts with server.

On server side you may split your application in 3 type of environments viz:

Database environment, Static server environment for serving static contents of 
your site like images, css etc and Main environment for executing PHP code 
and serving output. Hence good configuration and well written code can 
effectively utilize all of 3 environments.

Database environment may include Replication of Clustering depending upon 
requirement, load and budget, Static environment may be running on 
lightweight web server like Lighttpd just to serve static data, and Main 
server environment may be implemented using LVS (type of clustering) to 
execute PHP code and to server output from more than 1 servers to balance 
load.

Additionally, you may also implementing caching of output and code at various 
levels. For that, you can use Opcode/Bytecode cacheres like XCache, APC, 
eAccelerator etc. to execute your PHP scripts more faster, if you are using 
frameworks like Symfony, Zend etc. then you can use their own caching methods 
and finally reverse proxies like Varnish, Squid to cache static and dynamic 
data at web server level.

I hope these suggestions will help you in understanding scaling of your 
application.

-- 

Anirudh Zala



More information about the talk mailing list