Improvement after tuning
Reading from disk is the slowest operation SQL Server does.
Therefore, tuning for less disk “reads” is often the primary goal.
Problem
The client's billing process was slow because the stored procedure took 34,256 ms on average to run.
Here’s a glance at the pre-tuning metrics:
- Duration (ms): 34,256
- CPU (ms): 33,968
- Disk (number of read operations): 3,298,493
Solution
This stored procedure was slow due to the large number of disk reads it was performing.
We refactored the code to reduce the number of reads it needed to perform.
Instead of hauling millions of rows, we trimmed it down to just what was needed.
Before vs. After
The most interesting part...
Here's the before-and-after snapshot that showcases the efficiency gains:
Disk (number of read operations)
Disk reads took a massive dive, plummeting from 3,298,493 down to just 147,424.
That's more than a 22-fold decrease!
Here is the breakdown:
| Before | After | Improvement | |
|---|---|---|---|
| Duration (ms)* | 34,256 | 3,859 | ~9x or 888% |
| CPU (ms)* | 33,968 | 3,854 | ~9x or 881% |
| Disk (number of read operations)* | 3,298,493 | 147,424 | ~22x or 2,237% |
After our tuning, the stored procedure became significantly faster, showing an overall improvement of 888%!
That's almost 9x faster!
That means that through refactoring, we've reduced the overall duration time from 34,256 ms to just 3,859 ms!
Duration (ms)
Final thoughts
Most SQL Servers' bottleneck is on Disk access (or disk “reads”).
It’s not CPU or RAM, which most customers often suspect first.
And that makes much sense. Here is why:
- Inefficient queries scan (or read) much data.
- Data read in is stored in RAM. As more data is read in, “older” data is pushed out from RAM.
- If there isn’t enough RAM to keep ALL data in memory (which is often not possible), SQL Server has to read from disk – and that is the slowest operation SQL Server can do.
- When the query can be tuned to read 10 rows vs. 10 million – less CPU and RAM automatically are necessary.
Since 95% of SQL Server bottlenecks are due to disk resources, cutting down on disk reads is the main goal.
To the end-user, nothing is more important than Speed (or Duration of the query).
Tuning to reduce CPU/RAM resources is helpful too.
When queries are tuned to need less CPU & RAM, it means that the same server now has more capacity.
