从您的 .NET 代码到 SQL 进行性能分析
0/5 (0投票)
使用 Red Gate 的 ANTS Performance Profiler，了解您的 .NET 代码、数据库和 HTTP 请求之间的关系。在一个工具中获取您需要的所有性能数据来解决问题。
引言
理解应用程序性能不佳的原因可能是一个乏味的过程。可能性如此之多，很难知道从哪里开始，尤其是如果您正在处理一个依赖数据库查询的 ASP.NET 应用程序。最新版本的 ANTS Performance Profiler 为您提供了识别瓶颈所需的所有上下文信息。
演练
让我们通过分析一个名为 NerdDinner 的示例 ASP.NET MVC 应用程序来测试 ANTS Performance Profiler。在本演练中，Jeremiah Peschka 修改了来自 CodePlex 的原始 NerdDinner 应用程序，使其现在包含性能问题。 您可以在此处下载我们修改后的版本。 NerdDinner 网站包含几个严重依赖数据库查询的页面，以及一些静态 HTML。
用户报告称该网站的位置搜索功能很慢。搜索功能旨在返回附近某个位置的活动列表。为了进行调查，让我们启动 ANTS Performance Profiler，看看 NerdDinner 幕后发生了什么。
ANTS Performance Profiler 将在 Internet Explorer 中自动启动 NerdDinner。现在应用程序已启动、运行并正在被分析，我们可以通过在搜索栏中输入地点名称并点击“搜索”来开始调查搜索问题。
在我们使用该网站时，ANTS Performance Profiler 的时间线显示了应用程序的 CPU 使用率
我们可以看到 CPU 使用率上升到近 200%（两个 CPU 核心各 100%），并且即使在返回第一个结果后仍然很高。这是性能瓶颈的明确指标，所以让我们在 ANTS Performance Profiler 中探索结果。
在调用堆栈的顶部，ANTS Performance Profiler 显示了消耗 CPU 时间比例最大的代码。在这种情况下，我们可以看到由 SearchByLocation HTTP 请求触发的 .NET 方法位于顶部，占分析会话期间总时间的近 95%。
查看显示所选区域中耗时最长调用堆栈的热点堆栈，我们可以看到此请求调用了一个 .NET 方法 NerdDinner.Models.DinnerRepository.NearestDinners(double latitude, double longitude)。该方法被击中了近 4000 次——它最终运行的 SQL SELECT 查询也是如此。
如果我们选择该方法的父级 NerdDinner.Controllers.SearchController.SearchByLocation(float latitude, float longitude)，我们可以查看其源代码。这表明该方法从数据库中检索所有已记录晚餐事件的完整列表
然后，方法 NerdDinner.Models.DinnerRepository.FindByLocation(float latitude, float longitude) 尝试在网页中处理结果集，以按位置进行过滤
这些方法是优化的良好候选者。可以通过 AJAX 调用实现相同的结果，并通过仅从数据库返回满足指定纬度和经度条件的晚餐。
切换到“数据库调用”视图，我们可以看到返回完整结果集的查询被运行了数千次。总而言之，该网站仅等待此查询实例返回其第一个结果就花费了超过 30 秒。
同样，很明显这个非常宽泛的请求被反复运行，导致总运行时间很长。运行更精确的请求次数更少会更有效。
分析后，我们现在清楚地知道哪些 HTTP 请求与性能缓慢相关，以及我们的哪些 .NET 方法是导致这些减慢的原因。我们清楚地了解 .NET 代码是如何调用数据库的，以及数据库的性能如何。在一个工具中访问这些数据意味着我们可以快速看到需要重写哪些方法来消除瓶颈，以及我们需要在应用程序中执行哪些步骤来检查问题是否已解决。