Benchmarks can best be described as a standard for comparison. What is my performance now vs. my performance from a previous point in time.
Benchmarks play a critical role in release management. As you upgrade/configure your hardware, application, or database schema you want to be able to ensure that the performance seen by the users is as good if not better then it was before:
- How does my system perform under different hardware configurations? CPU? Memory? Disk?
- How does my system perform when running on SQL Server 2005? SQL Server 2008? Server Server 2008 R2?
- Did my application/database code release increase or decrease performance?
Established benchmark tests are an important piece when discussing scalability. Giving yourself valuable data about how your environment will perform when variables are changed:
- Number of users
- Number of processes
Benchmarks can also assist in troubleshooting performance problems. If you get that oh so descriptive phone call from a user asking “Why is the system slow?” A benchmark can provide some valuable insight and help answer questions like:
- Is there an overall performance problem?
- Is this isolated to a specific use-case scenario?
- Is there a problem at all?
“You don’t know where you are going till you know where you’ve been”
Benchmarks play an important role in ensuring the performance and stability of your environment. Knowing how different changes will affect your systems performance will minimize the amount of suprises you will have to face and also provide some valuable insight as to how your system should perform over time.
In Part 2 of this series we will discuss the elements that make up a benchmark.