Improvement after tuning
Disk (number of reads)
Reading from disk is the slowest operation SQL Server does.
Therefore, tuning for less disk “reads” is often the target.
Problem
The stored procedure was too slow and performed too many disk reads.
Solution
Here is what was done to get this improvement:
Before vs. After
The disk reads plummeted from 884,014 to just 767.
That’s an unimaginable 1,152 times less!
| Before | After | Improvement | |
|---|---|---|---|
| Disk, number of reads* | 884,014 | 767 | ~1152x (or 115,256%) |
Final thoughts
The most common bottleneck for SQL Servers is disk access (or disk “reads”).
It’s neither the CPU nor the RAM, which are usually the first suspects for most customers.
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.
Disk resources are the cause of 95% of SQL Server bottlenecks, so reducing the disk reads is usually the primary objective.
For the end-user, nothing is more crucial than the speed (or duration) of the query, in every case.
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.
