Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am involved in the worldwide launch of a social networking site. For how many server capacity we must plan ? what are the average ratios per thousand registered users ? what are the assumptions used ? Note : the site is based on MVC PHP/MySQL with the Yii Framework.

EDIT : I am looking for real life examples/industry standards of social networking sites with tens/hunderds of thousands of registered users. Assuming the code is "well" written, MySQL is denormalized and SQL queries are kept to a minimal.

share|improve this question

migrated from Sep 6 '10 at 11:11

This question came from our site for professional and enthusiast programmers.

closed as not a real question by John Gardeniers, TomTom, GregD, Izzy, Zypher Sep 7 '10 at 4:46

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

I think it belongs on socialnetworkingfault. – mario Sep 6 '10 at 10:28
Besides the fact that SO is not the place to ask this question, you supply way too little information. Give some more information on your architecture, functionalities, planned promotion etc. – Dennis Haarbrink Sep 6 '10 at 10:30
The reason i think this must be closed because it's totally unanswerable. He even didn't say anything about their current plannings/resources except they're using PHP/MySQL. This can be anything. – fabrik Sep 6 '10 at 10:30
Question isn't about coding issues, but about requirements for network infrastructure. Vote for move to serverfault – Mark Baker Sep 6 '10 at 11:10
+1 vote for closing. I would not even know where to start - NO sensible information provided. – TomTom Sep 6 '10 at 11:28
up vote 0 down vote accepted

Write the code so that content doesn't rely on files on the disk except for the website itself and the databases.
Write it so that as much as possible is static and can be determined by the URL.
Write it so that the database it reads to and writes from it not hardcoded (returned by a function) and is not necessarily the same database.
Write it so that it uses MySQL's autoincrement keys rather than code generated ones.
Think about all of this before you write it.

If you do all the above, run it on one server. Then, if it gets heavy, you can move the database onto another server. Still heavy? Replicate the database onto another server. Then add a loadbalancer for your webservers. See how you can scale afterwards if you wrote the code well?

Roughly, the amount of servers you need will depend on how good a coder you are and how much of the site can be cached. If it really is big, you'll probably end up with: User->Internet->Firewall (with failover)->Varnish server->Load Balancer (maybe Squid) with failover->Servers with duplicate content talking to replicated databases.

share|improve this answer
If you can cache most of the site in Varnish, you're unlikely to need more than 3 or 4 servers at the bottom unless you're seriously huge or seriously terrible at writing queries. – James L Sep 6 '10 at 11:32
this is helpful thanks – jaz Sep 6 '10 at 13:12

Generic answer:

  • Worldwide launch sounds like hyperbole. One server will suffice.
  • Do some server stress testing (ab/jmeter) to see how many request/sec your site handles.
  • Requests/sec * 24 * 60 * 60 sec / 250 (?) = Number of Users
  • xdebug and kcachegrind
  • denormalize database
share|improve this answer
Thanks mario, but how did you come up with 250 ? – jaz Sep 6 '10 at 13:11

Depends how much resilience you need... what level of downtime is acceptable? At a minimum, I'd recommend at least two web servers and two database servers using MySQL replication to provide failover... though they could be the same two physical machines. If you're using memcache, another server for that.

Assess your infrastructure for any single point of failure and assess the risks or eliminate it as a SPOF.

Then (as mario has said) stress test it to see what response times you get at different levels of requests/sec. Test with both read-only and with read/write requests.

Monitor both webservers and database servers.

share|improve this answer
How many simultaneous users do you think this setup can handle ? (I know it can be rough, but are we talking hundreds ? thousands ? more ? – jaz Sep 6 '10 at 13:13
I can't tell you that... it's for you to find out by actually testing. I don't know how powerful your servers are, what memory you might have for PHP, the bandwidth of your network pipe, how efficiently your application is written, what data volumes you expect, etc. Only you have the information needed to even run tests, let alone estimate the usage, and identify whether the performance is acceptable or not – Mark Baker Sep 7 '10 at 12:54

Not the answer you're looking for? Browse other questions tagged or ask your own question.