This editorial was originally published on 29 Apr 2016. It is being re-run as Steve is on vacation.

Many of the DBAs that manage production systems will at some point determine what level of hardware is needed to support a workload. Whether this is a physical server purchase or a cloud "rental", someone has to decide what hardware is needed. How many cores, the amount of RAM, the number of disks, which hopefully correspond to some level of IOPs, and more. Even in the Azure SQL Database world, you must decide what database capacity you will pay for.

Since this is a big decision, and changes can be hard to make, many DBAs overbuy hardware. After all, no one wants to have a slow server. This is true for Azure as well, at least for many people I know. While changing from an S3 to a P2 is quick and easy in the Azure portal, it's not such an easy sell to management. If they've budgeted $150/month and you tell them we want to go to $900/month, the technical change is the easiest part of this.

As a result, I'm surprised that we don't really have better ways to determine if hardware will support our workload. I see this question asked all the time, and although there are tools and techniques suggested, I've yet to see many people that have a set, known standard way of evaluating hardware and a particular workload.

One one hand, I think there should be better tools to do this, whether from Microsoft or someone else. I suspect since this is such a rare activity and businesses have been willing to overbuy hardware (or deal with substandard performance), that there isn't any large impetus to solve this issue. It's probably not a commerically viable product, so either Microsoft or the open source community would have to tackle this problem.

However I wanted to ask if any of you actually stress test hardware? Either your current hardware or new purchases. If you don't know what your level your current hardware performs at, how do you compare that to new hardware?

Do you have a way to replay and measure a workload? Do you have the time to do so when new hardware arrives? Meaning time is set aside before the system is put into production. Is there a documented method you use? Apart from discussing this today, I'd love to see some articles that detail exactly how you test hardware from a technical tool perspective, and then a followup that examines and evaluates the results.