ASP.NET性能：计算SQL请求

Question

我们在客户部署ASP.NET应用程序时遇到了巨大的性能问题，客户的数据库位于远程位置。

我们发现这是因为页面向DB提出了大量单独的SQL查询。这从来都不是我们注意到的问题，因为通常，网络和数据库都在同一个本地网络上（低延迟）。但是在这个（突然的）低延迟配置上，它非常非常慢。

（请注意，每个sql请求本身都很快，序列的数量和串行性质是问题）。

我让工程团队能够报告并维护一个“羞耻墙”（或统计数据）告诉我们每个页面的SQL请求数量，以便我们可以将其用作参考。他们声称它很贵......

任何人都可以告诉我如何能够便宜而轻松地维护或获得此类报告？

---

• 我们正在使用SQL Server 2005
• 我们混合使用自己的数据库访问层和亚音速
• 我知道并使用了探查器，但这有点手册。在这里询问是否有关于如何自动化的提示或者我只是疯了？

Answer 1

如果您使用的是SQL Server，请阅读Profiler。

http://msdn.microsoft.com/en-us/library/ms187929.aspx

从UI运行探查器非常昂贵，但您可以在没有UI的情况下运行跟踪，这将为您提供所需的功能。

Answer 2

首先，查看SubSonic的BatchQuery功能 - 它可能有助于减轻第一次切割中的压力，而不会对代码进行重大修改。

您可以从SQL服务器的末尾安排跟踪作业/转储。您还可以运行perfmon计数器以查看应用程序正在服务的数据库请求数。

所有这一切，我都会尝试鼓励客户将数据库（或数据库的镜像副本）移近您的应用程序。从长远来看，它可能是最便宜的解决方案，具体取决于应用程序的厚度。

Answer 3

过去我使用此工具取得了不错的成功，不确定价格是否适合您，但它会发现您可能遇到的任何问题：

Spotlight on SQL Server

Answer 4

在这种情况下，MiniProfiler（以前称为MVC迷你探查器;但它适用于所有MVC和Webforms）都是必须的。如果创建数据库连接的代码架构良好，那么几乎任何ASP.NET应用程序都可以运行它。

它在每个呈现的页面上生成一个报告，其中包含分析统计信息，包括发送到请求的数据库的每个SQL查询。您可以在Stack Exchange Data Explorer页面（左上角）看到它的运行情况。