ASP.NET 性能：统计 SQL 请求答案

【问题标题】：ASP.NET performance: counting SQL requestsASP.NET 性能：统计 SQL 请求
【发布时间】：2009-11-02 18:09:29
【问题描述】：

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

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

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

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

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

【问题讨论】：

这个练习在任何设计良好的应用程序中都应该是微不足道的。您可以将其用作确定应用程序代码质量的粗略基准。如果这样的东西“昂贵”，那应该是一个危险信号。
这不能回答你的问题，但我有一个建议，可以在这种情况下提高性能。从远程位置使用数据库时，创建和关闭连接可能比平常更昂贵。如果您还没有这样做，请向其中添加一些逻辑，每个页面请求仅打开一个数据库连接。这个想法是使用一个全局连接，当第一次查询时自动打开，当调用 Page.Unload 事件时自动关闭。

【解决方案1】：

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

从 UI 运行探查器的成本很高，但您可以在没有 UI 的情况下运行跟踪，这将为您提供所需的内容。

【讨论】：

【解决方案2】：

首先，查看 SubSonic 的 BatchQuery 功能——它可能有助于减轻第一次剪辑时的压力，而无需对代码进行实质性修改。

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

综上所述，我会尝试并鼓励客户将数据库（或数据库的镜像副本）移动到更靠近您的应用的位置。从长远来看，这可能是最便宜的解决方案，具体取决于应用程序的厚度。

【讨论】：

【解决方案3】：

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

【讨论】：

【解决方案4】：

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

它会在每个呈现的页面上生成一个带有分析统计信息的报告，包括发送到数据库以获取请求的每个 SQL 查询。您可以在Stack Exchange Data Explorer 页面（左上角）上看到它的实际效果。

【讨论】：