Back in the day, I drove an ’83 Pontiac Grand Prix. It was actually my mother’s car but at some point during my college years it was transferred into my name. Probably at the time I sold it right before moving to Washington State is the precise moment it became “mine” and “not mine” all at once.
Anyway, I would take that car on trips to Quebec City to visit Congress-elect (blog | Twitter) where she was studying French at Universite Laval. During one visit we were heading out with some of her friends from Newfoundland. (By the way, if you ever get a chance to listen to someone from Newfoundland speak French with their thick unique broken-English-Irish-like accents, do not pass it up. Trust me.) Her friends jumped in the back and as we were driving through the frozen streets I heard “Ha! Typical American car design. They have the clock where the speedometer should be because they don’t care how fast they are going, just how long it takes to get there!”
I have never thought about my instrument panel in such a way before (but typically I do notice such things in every car I sit in ever since that night). I was used to seeing big clocks in cars before, and never thought twice about mine or anyone else’s. But her friends were right about one thing: we usually only care about how much time has passed between events and not about how fast we were going along the way.
This is exactly what I see with regards to SQL performance and performance tuning. All too often I find people looking to scale up because they want things to go faster. But by faster they are almost always referring to time duration, and not actual speed. Sure, they will say they want speed, but what they really want is some process that takes an hour to be done in thirty minutes. And they don’t want to make any code changes; they just want it to finish sooner.
Something Old, Something New…
Once upon a time people designed systems with efficiency in mind. Resources were scarce; you had to design systems in a way that would make the most efficient use of disk I/O, memory, and CPU. A long time ago it was common for engineers to build systems that only used the last two digits of the year as opposed to all four. This saved on resources. Unfortunately (or is it fortunately?) this also lead to the Y2K scare many years later. But how often did anyone ever say to themselves “wait a minute, this code has been running for 30 years without any problems!” I rarely saw the acknowledgement that those systems were designed so efficient and so well enough that they were still running well after their intended lifespan.
As our world moves towards virtualization, we are going to need to go back to the future with regards to efficient designs. (Well, I am hoping that will be the case, but the real driving factor in everything will be cost, of course.) We are not going to focus only on time durations as we have in the past, but rather on making certain we use only the resources necessary to complete the job at hand. We will need to ensure our systems are optimized, well designed, and perform their job well without being a “resource hog”.
SQL 2008 Resource Governor
Think I am crazy? Well, how do you explain the SQL 2008 Resource Governor? It would seem to me that I am not the only one that sees the need to build systems that put a cap on resource usage. What’s great about the use of Resource Governor is that as a DBA I can force your system to only consume a specific amount of resources. So, we don’t need to spend time on a redesign, and we don’t need to change any code. With a few clicks I can limit your speed on the information highway, which could mean you will be late for every appointment you want to keep.
Or, you could look to design systems efficiently right from the start. You won’t need to worry about your speed as much as you have in the past, and you should get to the church on time, every time. Instead of just heading out in whatever direction and driving as fast as possible in order to arrive somewhere at a certain time, consider taking a new approach. What if you decided to map out a route in advance of your trip? Perhaps you could find a way through town that has fewer stoplights, less turns, less traffic, and even a shorter distance. Sure, you may not be going as fast as you were before, but you may arrive five minutes early simply by being more efficient.
If, at the end of the day, the end result is to get somewhere by a certain time, how many of you would go out and by a new sports car in order to get across town? How about if your company was buying you the sports car, as they do with servers and other hardware? That usually changes things, right? Your money versus the company money almost always changes your decision.
If you would not be willing to spend your money on the sports car, then try to map a different route before you give up and decide the company needs to buy you the sports car. When the day comes that your system needs to be placed into a resource pool you will be thankful that it is already operating efficiently.
