ProblemWhen conducting performance testing and tuning on a new system, most of the time a number of options are outlined to potentially correct the performance problem. To determine the best overall solution, each option is tested and the results are recorded. As lessons are learned options may be combine for a better end result and often as data is cached the overall query performance improves. Unfortunately, with the data in cache testing each subsequent option may lend itself to an apples to oranges comparison. How can I ensure during each execution of a new set of code that the data is not cached?
SolutionIf all of the performance testing is conducted in SQL Server the best approach may be to issue a CHECKPOINT and then issue the DBCC DROPCLEANBUFFERS command. Although the CHECKPOINT process is an automatic internal system process in SQL Server and occurs on a regular basis, it is important to issue this command to write all of the dirty pages for the current database to disk and clean the buffers. Then the DBCC DROPCLEANBUFFERS command can be executed to remove all buffers from the buffer pool. Here is a quick code snippet to serve as an example:
GO DBCC DROPCLEANBUFFERS; GO |
Although the CHECKPOINT and DBCC DROPCLEANBUFFERS commands seem to be the most elegant approach because they can be included in your T-SQL test scripts, you also can achieve the same results by either restarting the SQL Server instance or restarting Windows. If you are testing via a batch file (or similar) then you could issue 'net stop mssqlserver' and 'net start mssqlserver' DOS commands. As a side note, you also have the option to shutdown SQL Server via the T-SQL SHUTDOWN command, but would need to restart the services via either the 'net start' command or via one of the GUI tools. Although these options are possible, they are not recommended. These last set of commands will shut down your SQL Server instance or machine, which is probably unneeded.
A few words of caution...
It is not recommended to issue the CHECKPOINT\DBCC DROPCLEANBUFFERS, the 'net stop mssqlserver', T-SQLSHUTDOWN command or restarting Windows on production systems just for the sake of testing. These commands could have detrimental results to your environment. It is recommended to only issue these types of commands in testing environments with coordination among your team due to the impact to the overall SQL Server. In addition, keep in mind that if you do issue these commands only in test environments that if multiple tests are being conducted simultaneously issuing the CHECKPOINT and DBCC DROPCLEANBUFFERS commands may skew results for other testers.
Next Steps
- As you conduct performance testing in the future consider including the CHECKPOINT and DBCC DROPCLEANBUFFERS command in each of your scripts to ensure cached data is not benefiting later executions of your code.
- As you test, it may be a good idea to capture the query execution results for cold and warm cache.
- Although, time needed for a query is important, it is also a good idea to review the query plans for the code to determine the best cost among the options.
- For related information check out the following:
Use DBCC FREEPROCCACHE to clear the procedure cache. Freeing the procedure cache would cause, for example, an ad-hoc SQL statement to be recompiled rather than reused from the cache. If observing through SQL Profiler, one can watch the Cache Remove events occur as DBCC FREEPROCCACHE goes to work. DBCC FREEPROCCACHE will invalidate all stored procedure plans that the optimizer has cached in memory and force SQL Server to compile new plans the next time those procedures are run.
Use DBCC DROPCLEANBUFFERS to test queries with a cold buffer cache without shutting down and restarting the server. DBCC DROPCLEANBUFFERS serves to empty the data cache. Any data loaded into the buffer cache due to the prior execution of a query is removed.
DBCC FREEPROCCACHEDBCC DROPCLEANBUFFERS
No comments:
Post a Comment