What kind of server do I need to handle 10 million requests and mySQL queries a day?
Solution 1:
A cheap desktop?
Let's get into the math.
- 10 million requests.
- That breaks down to 416667 requests per hour.
- That breaks down to 6944 requests per minute.
- That breaks down to 116 requests per second.
Double that (peak load) and we talk of a load a cheap quad core desktop can handle IF the queries are simple enough, and you don't really say how complex they are.
- 5000 GB per month is trivial - seriously, same math applies.
- That breaks down to 208GB / day
- That breaks down to 8GB / hour
- That breaks down to 148MB / minute
That breaks down to 2,5MB / second, 25Mbit. Double for peak - 50Mbit, trivial for any hosting center. Will cost you, though.
Store 2000 GB on the hard disc. That is 2x2000 GB hard discs in a RAID? Unless: it is for the database, an has lots of complex IO, then it is anything between some dozen discs and a LOT of 73GB 15.000RPM SAS discs in a RAID 10 (around 60 discs) to get the I/O needed - this question is not answerable without a LOT more info on data access patterns.
Runs PHP and MySQL - My mobile phone can do that ;) The question is how complex the application is. MySQL MAY or MAY NOT be an acceptable solution here, BTW l. - that would require more testing. There is a reason some people still use other larger commercial databases.
What CPU/Ram do I need for a Dedicated Server or VPS?
One would say that depends on logic (how much calculations in the PHP part, smartness or lack of programmers and a lot of other questions.
Seriously, this is a non-trivial setup. Get some specialists look into it.
Basically you need to get down and get your homework done. A lot of the questions are not answerable in this form. Especially because you don't seem to care about your data...
- Backups?
- No contingency plan? I mean, servers die - so you are OK with the site being down for days while replacement is configured?
Solution 2:
To add some of my experience which may be helpful:
- As TomTom mentioned it is difficult/impossible to give exact specifications as a lot of it depends on the design and implementation of your application. Hardware that gives me or someone else X requests/sec may not work well for you.
- I have a low end dedicated MySQL server (Intel Core2 Duo E4600 2.40 GHz, 4 GB RAM) serving an average of 100 requests/sec (close to 10 million/day) with a CPU idle rate of 90%. Other than some basic tweaks to the configuration it is running well due to being read heavy (+95% reads) and the active record set is easily contained in memory. Consider the size of your active set when choosing the amount of server RAM as it can make a big difference. Make sure you understand the difference between your database size and active record set size. For example, my databases total ~7GB but the active set is likely only a few 100MB.
- Similarly, I have an Apache server of similar specs serving ~1 million requests per day which has an average ~95% CPU idle rate. Requests are a mix of very simple map data AJAX queries and more complex MediaWiki pages.
- Benchmarking your specific application is a good start in trying to determine exactly what you need. You don't want to under estimate but over estimating can be just as bad due to the potential waste of money and effort.
- Consider not only the average request rate but the peak rate. You don't want a server that just barely can handle the average rate as request rates can vary significantly over the day, week, and month. For example, I can get 3-4x the traffic during peak hours on weekends as I do in the minimum hours during the week. How much it varies will depend on your application and user base.
- Can you cache any of your database/HTTP requests? This can drastically increase your request rate with cheaper/less hardware depending on how much you can cache.
- Consider your scaling options for future growth now instead of later. A good option may be to use horizontal scaling which would let you start with minimal hardware and easily grow as needed.
- Proper design of your application layer can have a huge effect on its ultimate performance. A bad SQL query on a table with no indexes can be orders of magnitude slower than a properly designed one. Similarly, poorly configured Apache/MySQL servers can be many of times slower than when correctly setup.