有关SQL Server基准测试的明确步骤列表？

在为使用SQL Server的应用程序运行性能测试/基准之前，我希望能够将实例设置为“干净”状态，而无需重新启动实例。我倾向于遵循一些步骤，但是我想建立一个确定的列表，该列表的顺序正确，没有多余的步骤。

此步骤列表是否完成将SQL Server设置为“干净”状态？

顺序逻辑/正确吗？

有多余的步骤吗？

CHECKPOINT              -- Write all dirty pages

DBCC DROPCLEANBUFFERS   -- All should be clean after checkpoint?

DBCC FREEPROCCACHE      -- Clear the plan cache

DBCC FREESYSTEMCACHE    -- Is this necessary after FREEPROCCACHE?

DBCC FREESESSIONCACHE   -- May not be necessary if distributed queries aren't used, but want to catch all scenarios

EXEC SP_UPDATESTATS     -- Refresh stats

'BEGIN TESTING!'

— 埃里克·希金斯
source

仅供参考，DROPCLEANBUFFERS可以很好地进行测试，但并不总是准确的。如果您引用的是大容量表，则很有可能几乎总是在内存中有页面，并且IO时间在该查询中不会成为重要因素。在这种情况下，您可能比实际情况更重视IO。

— JNK 2012年

您是在谈论在生产环境中还是在隔离的测试环境中进行测试？

— bopapa_1979

在Prod环境中进行测试的任何人都应该被解雇。:)是的，测试环境。

— 埃里克·希金斯

首先，我退后一步，询问您打算在测试期间收集哪些测量结果。例如，如果要通过查询来计数逻辑读取，则无需释放缓存。我是逻辑读取的忠实拥护者，因为它与数据是缓存还是存储在磁盘上无关-在生产环境中，很难猜测是否将缓存查询的数据（除非您将整个数据库缓存在内存中）。如果您调整以最小化逻辑读取，那么无论数据是否在缓存中，应用程序都会运行得更快。

接下来，我想问一下运行之间有什么变化。例如，通过按照建议在每个数据库中运行EXEC SP_UPDATESTATS，您将对已更新表的统计信息重新采样。但是，除非您要使用全扫描更新统计信息，否则您将从表中获得随机行-不太重复，而且我认为您并不是真的想要这样做。相反，您可能希望在每次运行之间还原数据库，以便始终测试完全相同的数据。如果您的测试正在执行插入/更新/删除操作，那么如果您不还原数据库（因为它们正在添加/更改数据，以及更改数据统计信息），则每次运行时它们的性能配置文件可能会有所不同-甚至更糟，

— 布伦特·奥扎尔
source

非常重要的一点是，目标是让每次运行之间的一切都相同。我在这种情况下@hand进行的测量是应用程序中特定功能的运行时间（x秒返回到应用程序列表，y秒添加队列项目，等等）。测试之间的变化可能是应用程序代码而不是SQL对象，SQL对象而不是应用程序代码，或实例/数据库级别设置（例如并发性），而无需更改应用程序代码。如果我要在每次测试之前添加一个还原，那么您对我在@以上的列表有何看法？我是否缺少任何内容，或者该序列是否需要一些工作？

— 埃里克·希金斯

Brent，您在测试中考虑了CPU吗？

— AK 2012年

@EricHiggins我不是一次测试多个对象，而是单独测试各个部分。我宁愿直接测试查询，看看哪些变化会影响那里的性能。例如，在执行应用程序中的特定功能时运行SQL跟踪，然后在进行索引/配置更改以提高性能的同时继续重放该跟踪，并观察跟踪中的逻辑读取和CPU度量等情况。

— 布伦特·奥扎

@AlexKuznetsov我不是进行测试的人，实际上-Eric是提出问题的人。在进行此类工作时，我确实会在查询级别以及整个服务器上查看CPU指标。

— 布伦特·奥扎

我们使用第三方负载生成器（并且有专职人员负责负载测试的开发）。因此，我的测试对交易，顺序，用户数量，在应用程序中执行的确切步骤等都是精确的。因此，我不必完全查看SQL仪表板类型指标。负载测试软件会跟踪应用程序模块的响应时间，以毫秒为单位。因此，执行数据库还原是一个好主意。我需要仔细检查我正在执行的其他步骤，以确保在完成每一轮测试之前，我已经完成了要寻找的“清洁状态”状态。

— 埃里克·希金斯