I have a website that contains one PHP page that runs 3 simple SQL queries to MySQL database 2 simple select queries and 1 simple update.

The HTML output with some images is 500 KB

The server needs to deal with 50-150 requests per second.

Can you help me decide the minimum specifications that the server needs in order to ensure 100% uptime?

  • 1
    this should be on server fault – Mantas Vidutis Apr 30 '11 at 19:43
  • 1
    100% uptime is impossible and how to reach approximate is a science. – zaub3r3r Apr 30 '11 at 19:56
  • If amazon can't do 100% uptime, neither can you. – EJB Apr 30 '11 at 20:23
  • I think you're use of the phrase "100% uptime" is going to throw people off track. Is what you really mean to say something like "Can you help me decide the minimum specifications that the server needs to ensure it can handle peak load without degrading the response time?" – sciurus Apr 30 '11 at 21:03
  • Is this website going to be on the internet? Or hosted to local clients? – muncherelli Apr 30 '11 at 21:29

500 KB * 150 req/s = 73 MByte/sec, or 586 Mbit/sec. That's a significant amount of bandwidth: almost 190 TByte/month of transfer. Putting hardware in place to support this is actually pretty easy; you could probably get by on a (beefy) VPS if "simple" really means "simple", but the bandwidth is going to be a stumbling block, as most VPS hosts are going to balk at (or charge exorbitant rates for) that kind of monthly transfer.

Do you want to host everything yourself in full, geo-dispersed HA, or is it worth offloading some of the hosting onto a CDN?

  • +1 on the CDN, thanks that had slipped my mind. Caching + CDN is essential. ;-) – tsykoduk May 1 '11 at 5:49

That's kind of like saying "What kind of car will win the Baja 1000?". It depends.

Also, 100% uptime is not possible. You can get darn close, however

That being said, there are a few things that you will want to do.

1) What ever solution you put into place, make sure that you are measuring everything that you can. With metrics you can determine if you are over or under provisioned and take action. You can also see trends, and make informed choices before things start to break.

2) Redundancy is your friend. Geographic redundancy (splitting up the app into different data centers in different geographic regions), horizontal (splitting the app servers from the DB's and the content servers) and vertical (a few small with a load balancer is better then 1 big).

So, that's the 10k foot view.

Specifically, in your case, I would define a group of servers that could handle about 75% of your traffic. Possibly 2 - 3 Nginx servers (my personal choice, use what you are comfortable with) fronting a pair of DB servers (1 master, 1 Read only Replica). Use the web server to proxy back to some sort of FCGI or other app server. Make sure that the front end servers are serving your cached pages (you ARE caching, right??).

Now, you'll need to drop some sort of LB in front of this. A single will be fine, because...

You'll be setting up an copy of this in another datacenter. All read only DB replicas, unless you want to dig in and get master/master replication set up.

Use round robin DNS to split traffic between the DNS CNAMES of the two load balancers.

In case of failure at one of the DC, just swing the effected cname over to the up site.

This is going to be expensive and hard to do.

Honestly, most folks will just do it in a single DC, as it's simply not cost effective to go all of the way.

Personally, I'd start small, and see how it holds. It should be easy to add servers, and after a bit of time, you'll be able to see where your application needs the help.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy