It perturbs me whenever somebody asks this type of question in hosting/performance related discussion groups:
My web app needs to support <X number> users with <Y number> concurrently, doing <some vague type of work/processing>. What kind of hardware specs should i be looking at?
And it happens regularly. Often, with regards to
shared hosting.
Firstly, please let me explain something about the reality of shared hosting:
forget about any performance service levels if you have such a tight budget.
Shared hosting, as the name applies, indicates you are
not alone in the machine that hosts your web site/application - you are indeed sharing the server's resources with
neighbour customers. The (combined) hosting fee you pay probably takes a while to break even the cost of the server hardware, and to remunerate the administrators taking care of the systems. So don't expect shared servers to feature an elaborate spread of spanking hardware in the first place.
On top of that, current hosting technologies have very little governing facilities to dictate just
how much resources a particular customer's application is allowed to consume. One may be performing intensive on-the-fly image processing, while another caching huge database contents in RAM. You cannot tell your neighbours what they can or cannot do just as they can't tell you. If one of them places an advertisement on TV featuring their domain name, there is nothing you can do to prevent the 10,000 simultaneous requests flooding in and choking the server. Mercy to your web site.
Keep this point in mind:
contention is constant. Performance is not a given in shared hosting, and you will never fine a sane provider with such SLA guarantees. If you want to drive fast, step out of the bus and buy a Lamborghini.
Secondly, let me highlight the reality that nobody is in a better position than
you to determine just what specifications your server(s) need. Supposing you have the budget to procure dedicated hardware.
Why so? Because nobody knows and understands the thorough details of your application, and nobody knows just what kind of performance levels you deem to be
acceptable. The typical description as above hardly makes it as an adequate service level statement; there has to be a whole level more of quantification to it.
e.g. 150 simultaneous requests for dynamic images no bigger than 1024x768 to be processed and delivered within 3 seconds.
e.g. 500 concurrent shopping cart change requests to be updated and responded within 2 seconds.
Remember, performance is not a one-sided equation where you can just throw hardware and expect it the magically fly. The quality of your appication's software architecture and engineering has just as big an influence. A team of
sinful programmers won't do you much good even if you establish a farm of web servers.
Moral of the story? You
have to stress test and gauge for yourself.
Start with a basic setup for your test lab, and write your software
right from the start to meet those performance goals. Baseline your configurations and record test results, tune hardware and software accordingly and re-run those tests to witness changes. As much as possible, alter one parameter at a time, else it can very difficult to determine which change affected the results by how much.
Expand your hardware setup when the software can no longer be written in a more efficient manner, or gets costlier than actually procuring more hardware. You know the buying can stop when the stipulated performance levels have been met (and with room to spare for growth).
Of course, if all these work blows the budget for the project, it is time to meet up with your client to mention those performance levels are impossible to fulfill with existing resources.