A Manager’s Guide to Tuning Code

SQL Server

In your business application, you have a slow screen or function. Your team is pointing fingers between the application code, the database, and the hardware.

To make it go faster, here are your main options:

Tuning Options - Mark All That Apply
Tuning Options – Mark All That Apply

Check all of the options you’re willing to consider, and X out all of the options you’re NOT willing to consider.

The more boxes you X out, the more expensive the rest of the boxes become.

For example, on some projects with third party vendor software – say, SharePoint or Dynamics – managers give me requirements like this:

Tuning third party software
Tuning third party software

If those are my only options, I’m going to have to push those limits pretty hard, and I’m going to have to sink a lot of money into those options. I may have to step up to SQL Server Enterprise Edition and cache the entire database in RAM.

On the other hand, when I’m dealing with an in-house application with really agile developers, with the application hosted in Amazon Web Services, the grid looks more like this:

Tuning apps in the cloud
Tuning apps in the cloud

As you can probably guess, the tuning options are much more flexible here – not to mention cheaper.

So when you need to make your app go faster, tell your staff what options are on the table, and which ones are off.

Previous Post
Why You’re Tuning Stored Procedures Wrong (the Problem with Local Variables)
Next Post
Temp Tables vs Table Variables vs Memory Optimized Table Variables [Video]

3 Comments. Leave new

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.