• subscribe
June 23, 2011 02:58 PM

Will SSDs Cause Performance Tuning Experts to Go the Way of the Milkman?

SQL Server Pro
InstantDoc ID #139591
Will SSDs make performance tuning experts irrelevant? Consider the following two quotes before we go any further.

"When a tree falls in a lonely forest, and no animal is near by to hear it, does it make a sound?” –Physics published in 1910 by Charles Riborg Mann and George Ransom Twiss


“If your SQL Server application is not running at peak theoretical speed, and no one is talking about it, do you have a performance problem?” –Brian Moran. Today.

Several months ago, I wrote about the $10,000 server of the future (“The $10K Server of the Future”). I touched briefly on the topic of solid state disks (SSDs) and the art and science of performance tuning. This month I want to explore this topic through the filter of how it will impact the careers of the many people who make their living tuning SQL Server, whether it’s by their own hand or by the advice they provide in written and verbal form (i.e., books, magazines, classes, conferences). First, let me say that I’m not trying to pick on these people. I was one of them for 15 years. I’ll always have a soft spot for performance-tuning artists, and yes, it’s as much art as it is science. But consider the following anecdote. I think it will make my thoughts on the topic at hand pretty obvious.

I was talking with my business partner, Andy Leonard, about this topic recently. He shared the following story from a past engagement. (Note that I’m simplifying the story and rounding the numbers to make the point of the story easier to follow.) Andy had been responsible for tuning a complex SQL Server Integration Services (SSIS) process for a large data warehouse. Andy was the project manager and the architect, and he had several other people involved. Weeks of work tuning the code dropped the process’s run time from about four hours to 12 minutes. Can anyone tweet #winning? Sometime later, they added SSDs to the server for additional gains and other reasons. Execution time for the process dropped to about 10 minutes. Just for fun and giggles, Andy decided to run the old version of the SSIS code on the server with the new SSDs. The process took about 12 minutes. Think about that—weeks of work by highly skilled, highly paid software engineers and architects for a net difference of about two minutes compared to simply throwing hardware at the problem. Isn’t throwing hardware at a performance problem one of the seven deadly sins and typically a horrible return on investment (ROI)?

Today, server CPU and memory are so blazingly fast and cheap that it’s not usually cheaper to throw hardware at a memory or CPU problem unless you’re talking about big data. I/O bottlenecks have been the most common type of bottleneck that database performance tuning experts have faced since I joined the SQL Server community in 1990. Until recently, ROI analysis dictated that it made sense to spend a lot of time and energy trying to solve the problem through human intervention and labor. But SSDs will eventually change this ROI math. It’s inevitable.

I had planned to explore a different topic this month when I read a Twitter post by Jorge Segarra (@SQLChicken) talking about the rapid decline of SSDs. Currently, SSDs aren’t as cheap as physical disks, but I think they will be eventually. If you think about it, an SSD is actually a simpler device to build and calibrate compared to a metal box that contains magnets spinning at ridiculously high speeds. Do vendors give away 16G thumb drives based on spinning magnets at conferences? That’s why I think SSDs will eventually be cheaper than traditional media.
Consider the future when SSDs are a heck of a lot cheaper and more widely adopted and a company ponders the following question: “Should we spend weeks of time and energy, and perhaps hire a really expensive consultant to help us fix the problem, or should we spend less money, add a terabyte of SSD, and fix the problem in a few days?” I think that will be like a milkman knocking on your door and asking if you need any milk.

Let me rein this back in a bit before I wrap up. Performance-tuning artists will never go away entirely, and this skill will always be among the most highly paid. But I’m convinced that the natural evolution of hardware will reduce the quantity of performance tuning experts necessary to satisfy market demand. This supply and demand imbalance will create a lot of pain for old-school performance tuning experts who can’t change with the times. But heck, milk is still a big business. We just don’t have it delivered two quarts at a time to our porch.

One final point in hope of reducing some of the flame mail I know I’ll get. Yes, I know that SSDs have been around for decades. I get that. No, I don’t think that magically fast hardware will always make up for horribly written SQL and application code. However, this is the first time I’ve started to see a pattern of throwing hardware at the problem being a decent answer. It was hardly ever the right answer a decade ago. And I know that big data and topics du jour will always push the envelope, and those environments will also need performance tuning artists. But most businesses don’t need big data speed, and we’re quickly getting to the point in which throwing an extra $25,000 into your server will solve most of your performance needs more quickly and less expensively than performance tuning can. Until recently, that ROI math just didn’t exist.

What do you think? (Astute readers will notice I didn’t address the question I posed in my quote in the introduction. I have my thoughts and I might explore this topic at a later time. But keeping with the grand tradition of philosophy, don’t you think it’s a question that you should answer for yourself?)

Are you interested in learning more about the origins of the question “If a tree falls in the forest, and no one is around to hear it, does it make a sound?” Check out the following links for more than perhaps you ever cared to know about the history, science, and philosophy of this question. Enjoy!

http://en.wikipedia.org/wiki/If_a_tree_falls_in_a_forest


http://wiki.answers.com/Q/If_a_tree_falls_in_the_forest_and_no_one_is_around_to_hear_it_does_it_make_a_sound


ARTICLE TOOLS

Comments
  • Maurice Pelchat
    8 months ago
    Sep 02, 2011

    Some queries execution times are growing exponentially with data size. Performance increase in hardware is no help in these cases.

    Some other performance problems are contention problems. Hardware doesn't help much but usually reduces contention, because individual transactions are faster.

    Some other performance problems are not on hardware at all! I mean human problems related to poorly understandable queries. The server get slow but much more the programmer doing maintenance on it!

    However SSD may get a big speed bumps and reliability and price drop with the advent of ReRam HP promise to delivers with Hynix next year. This Reram is a lot faster and smaller per bit and very reliable.

    So there is going to be less and less job in performing some actual slow queries, which will not be anymore. But there are going to be more and more monster queries on monster databases. Tanks to BI !

  • kenambrose
    10 months ago
    Jul 21, 2011

    I am tasked with querying multiple data marts with fact tables in the 100's of millions. My query tuning needs are not going to disappear just because of a 10X improvement in physical disk querying.

    The improvement would probably need to be 3 orders of magnitude, not 1.
    kj

  • 10 months ago
    Jul 10, 2011

    My Reference point for this argument is asking Paul Randal to run poorly performing cursor based code from http://ask.sqlservercentral.com/questions/826/the-fifo-stock-inventory-sql-problem on his SSD test rig , HDD = 60 mins , SSD = 45 Mins, tuning the code = 3 seconds. I rest my case. ;)

  • 11 months ago
    Jun 29, 2011

    I agree with John on "I personally believe the database design, the application code and accompanying SQL has much to do with what we are seeing." I would like to add that It's in the Application and its interaction with the database where most significant performance improvements can be made after a DBA has dealt with poor indexing, blocking queries, etc. Adding a faster disk subsystem does improve performance significantly but it has a limit that sometimes is not enough to satisfy customer needs.

  • ajsongy
    11 months ago
    Jun 25, 2011

    Bad software (table/index design, TSQL) beats good hardware. That will never change. On this we agree.

    With each boost in performance gain comes the new "gotta have" feature requiring more consumption of even greater amounts of resources. It is a cycle that will only end when man's curiosity and need to know ends.

You must log on before posting a comment.

Are you a new visitor? Register Here