Server Fault is a question and answer site for system and network administrators. It only takes a minute to sign up.
Sign up to join this community
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?
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?
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.
