重放捕获的跟踪比捕获它需要更长的时间

Question

我正在尝试使用跟踪捕获来确定有多少性能问题与数据库相关以及有多少与代码相关。但是，重放跟踪所需的时间比最初捕获所需的时间长。

我所追求的是单独运行我们的 SQL 语句所需的总时间，而没有我们实际代码的开销。如果重播花费了捕获总时间的一半，我将假设错误是代码和数据库，如果重播花费的时间与捕获几乎相同，我将假设它是数据库，如果重播与我们的捕获相比几乎没有时间，我会假设这是我们的代码。我假设重放是执行所有语句的一种非常有效的方式。

相反，当我重放我的跟踪时，运行时间至少是原始捕获时间的两倍。无论我允许多个线程还是要求它是顺序的，这都是正确的。我对此很陌生，所以我可能会做一些愚蠢的事情（可能这里的整个想法都是愚蠢的），但在我看来重播应该更快，而不是更慢。

我的捕获跟踪是重放模板 + SQL:statement completed （因此它兼作调整捕获）。

Answer 1

SQL Server 可以同时处理来自多台机器和线程的多个并发请求。不幸的是，重放一次只能从一台机器连续地将它们吐出 - 引入了多层瓶颈。重播中可能还有一些开销来读取和准备要发送的语句，这在您的应用程序中不存在。

如果您希望重播更真实，您应该查看SQL Server 2012 的 Distributed Replay，它能够在多台机器上分发重播。也就是说，您不可能完全匹配原始加载时间，并且在重放期间准备每个语句时可能仍然存在一些固有开销，即使您能够消除一些并发瓶颈。