ANTS 性能分析器如何拯救了我

“巧妙简单的工具”，包装盒上这样承诺。是啊，没错——我早就听过这话了。我半信半疑地安装了又一个工具：Red Gate 的 ANTS Performance Profiler。当进度条填满时，我开始怀疑自己是否能在时间——或者我的理智——耗尽，或者我 CEO 的耐心消失之前找到解决问题的方法。

我的故事始于三个星期前，在开普敦。作为一家金融机构的 IT 经理和资深开发人员，当出现代码问题时，一切都由我负责。我们有一个小型的开发团队，而小团队的性质决定了我们常常身兼数职。

尽管团队很小，但公司却高度依赖我们的技术，尤其依赖我们快速做出变革的能力。这让我们在竞争对手的技术变革周期更长的情况下具有优势。

在我们的环境中，我们有几个 SQL Server 数据库；我们有管理客户账簿、账款和催收策略的第三方软件；除此之外，我们还有一个内部开发的 ASP.NET 应用程序，我们的 80 多名用户每天都在使用。该应用程序执行各种任务，从 CRM、账户维护、账目管理到会计。每个月，高峰期每天的数据库交易量约为 100,000 笔。

我们最关键的应用程序每天都在使用，如果它出了问题，后果不堪设想。这是一个大约八年前用 .NET Framework 2 编写的控制台应用程序。有好几个人接触过这个代码，随着时间的推移，为了应对不断变化的业务需求，进行了一些快速修复。

该应用程序每天早上会将一个催收文件上传到一家局，该局会从债务人的银行账户中扣除分期付款金额，然后转入我们的银行账户。如果未能从账户中扣款，债务人将这笔钱收回的可能性将每天降低 25%，这将导致现金流问题，并增加催收团队的工作量和压力。简而言之：千万不要搞砸这个应用程序。

软件每天早上 10 点启动，从各个数据库收集债务人信息。然后编译几个文件，通过 Web 服务连接到外部局，并上传文件。应用程序接着轮询返回文件，然后进行一系列操作。最后一步是人工流程，必须授权催收文件。所有这些都必须在 10:30 的截止时间之前完成。错过截止时间，那么，你知道会有什么糟糕的事情发生。

一天早上，应用程序崩溃了，出现了一个模糊的数据库超时错误。然后又发生了一次。又一次。几周以来，应用程序会不定期崩溃，我们却无能为力——因为它连接到三个数据库，我们甚至不确定超时发生在哪个环节。崩溃开始给我的团队带来压力：为了赶上紧迫的截止日期，我们通常需要通过电子邮件上传文件，然后手动将数据录入数据库。

我们不得不越来越早地开始这个过程，以确保我们能赶上截止时间，这反过来又给催收团队带来了压力，因为他们只有几个小时的时间来做出任何调整并为每日运行加载账户。催收经理每天都勃然大怒，命令他的团队更早来上班以应对。

作为一名在公司工作了 20 多年的 IT 经理，在紧急管理会议上，面对我的领导和同事，却不得不说出我最厌恶的几个字：“我不知道”，这是一种可怕的经历。

更糟糕的是，最大也是最关键的月度结算期即将来临。这次结算影响着人们的生活，因为我们的催收员是靠佣金工作的。想到那些人可能因为我不知道原因而拿不到钱，这给我带来了沉重的负担。我必须找到一个答案。

我们像着了魔一样，攻击并分析了每一个单独的存储过程和 SQL 语句，却一无所获。数据库中没有瓶颈：数据库循环工作正常。

但是，应用程序的哪个部分导致了数据库超时呢？我们仔细检查代码，直到眼泪都流出来了，却无法确定瓶颈在哪里。最终，在谷歌搜索后，我下载了一些工具来帮助识别瓶颈。大多数工具都太复杂难以设置，有些需要更改代码，还有些本应在八年前就应该实现。其中有一个工具似乎提供了更多的希望——Red Gate 的 .NET 分析器，名为 ANTS Performance Profiler。Red Gate 的 .NET 分析器，名为 ANTS Performance Profiler。

我安装并迅速加载了项目。到目前为止一切顺利——易于使用，没有出现任何问题。我运行了项目并查看了分析结果。界面非常棒，包含了很多信息，而且这次的信息确实有意义。一个不错的亮点是：它在一次分析会话中同时提供了我的 .NET 代码和 SQL Server 查询的性能数据。很棒！

让我兴奋不已的是，我看到了之前从未在任何地方看到过的东西：在流程进行到一分钟时，出现了墙上时钟 CPU 时间的尖峰。

经过进一步调查，找到了！高命中次数和超时直接将我引向了真正的罪魁祸首：basTools。

basTools 模块中包含了一些我们在每个项目中使用的标准基本工具。我们从未想过检查它们是否可能导致 SQL Server 超时问题。

这个问题花了仅仅两秒钟就解决了，直到今天，我有时仍然会猛敲自己的脑袋，重温那一刻。

问题是什么呢？当一个账户有警报时，会自动向客户经理发送一封电子邮件。我们已经停用了一种产品类型，最近又重新启用了它。这触发了一个警报，该警报调用了一个旧的“已停用”邮件例程。在邮件例程中——请注意——有一个硬编码的代理服务器 IP 地址。该 IP 地址属于一个已不存在的服务器。应用程序正在 SQL 循环中尝试解析该代理，失败了，最终放弃了，报告了一个超时。

我们将 IP 地址指向了一个新服务器（这次，我们将设置存储在配置文件中），并成功运行了项目。到目前为止，希望一切顺利，我们再也没有遇到过任何超时问题。

总而言之，ANTS Performance Profiler 拯救了这一天，也保全了我的名誉，我的团队也因此看起来像英雄。错误消息看起来像是超时来自数据库。我们从未怀疑过是代码有误。这个 .NET 分析器在几分钟内就找到了罪魁祸首（一段与数据库关系相对较远的遗留代码），我们得以几乎立即提高应用程序的性能。

ANTS Performance Profiler 确实是一个巧妙的简单工具。一个能做到它承诺的事情，并且做得很好的工具。

不过，我不喜欢 ANTS Performance Profiler 的一点是，我们没有早些年就安装它。