[nycphp-talk] advice on scaling up
Hans Zaunere
lists at zaunere.com
Tue Jul 10 14:34:06 EDT 2007
> 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?
Sounds fairly reasonable, but of course it depends dramatically on the type
of site it is. Social networks typically have a "heavier" traffic pattern.
There's generally more complex application logic, session storage needs,
etc.
And I think it could be argued that the users would be more likely to
constantly refresh and visit pages, as opposed to a search engine or news
site. The idea of social networking sites are to keep the user navigating
through the site - there's no "external" usage really. And serving socially
matched metrics is going to be more intensive - heavier - than a more
static-orientated news or search site.
Add in Ajax magic, and you could be generating a substantial number of
requests per page load. If Ajax is important to the site, get a good
JavaScript developer that understands server interaction, load, etc. (I
know, I can't believe I just said that).
> 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?
Throw the big iron at your database - CPU, RAM, HD. The database is the
aggregation point for your application. It's easier to add web servers than
to add database servers (and take full advantage of them). And since this
is a social networking site, the database will be busy looking up
matches/etc (ie, whatever the social magic is in this case).
For the web server, I've found that 1gb of RAM, snappy CPU, and any HD
works.
Put your money in the database hardware, or in development time so that your
application knows how to scale across databases completely (read/write).
memcached is very useful for session storage, as can a dedicated database
be.
H
More information about the talk
mailing list