使用 Visual Studio 进行云性能工程

高性能的应用并非偶然。它需要认真的工程投入，这种投入在编写第一行代码之前很久就开始，并持续到产品发布很久之后。

许多组织仍然沿用旧的思维模式，要么完全不做性能测试，要么只在发布周期结束时还有时间才做。随着越来越多的应用程序迁移到云托管的复杂多租户应用服务器，开发人员必须从开发周期的最初阶段就开始关注代码的“成本”。

本文展示了 Visual Studio 的 PerfTips、Diagnostics Hub 和 Performance Analyzer 等功能，如何帮助开发人员在开发云端应用的过程中，有意义地衡量其代码的成本。 我将首先重点介绍使用传统方法来调查与性能相关的问题。

性能定义

性能工程可以从多种方式来定义。以下是 维基百科 的定义。

“性能工程包含在系统开发生命周期中应用的各种技术，以确保满足性能相关的非功能性需求（如吞吐量、延迟或内存使用量）。”

这个定义是一个好的起点，但性能工程是一个复杂的领域，根据不同的背景，对不同的人来说可能意味着很多不同的东西。然而，普遍的共识是，应用程序的性能直接影响产品的收入和运营成本。

性能工程的关键方面围绕着测量这一理念。为应用程序定义特定的性能目标，并定期进行适当的测量，以检查目标是否已达成。如果需要，则采取纠正措施，然后重复相同的测量和纠正措施过程，直到达到目标。

云中的应用程序性能

云计算彻底改变了组织进行日常运营的方式，无论其规模、业务类型或地理位置如何。多年来，基于云的解决方案经历了基础设施即服务 (IaaS)、平台即服务 (PaaS) 或软件即服务 (SaaS) 等平台的演进。行业广泛采用了这些平台，不仅是为了降低企业的拥有成本，也是为了向客户提供更好的解决方案可用性、可伸缩性和可靠性。

然而，天下没有免费的午餐。基于云的解决方案也有其自身的薄弱环节。“吵闹的邻居” 和 级联效应 是与云解决方案相关的 一些常见问题。这对软件开发人员来说意味着，他们现在承担着更重的责任，以确保他们编写的代码能够很好地适应更高的负载。他们需要高度关注代码的成本，因为随着云产品的发展，规模会发生巨大的变化，这使得代码成本更加突出。

范围

在编写以性能为中心的代码时，基本原则之一在 Vance Morrison 的一篇旧文章 “尽早并经常测量” 中得到了最好的阐述。然而，许多开发人员要么忽略，要么难以在日常工作流程中使用他们选择的工具来实践这些原则。为了应用 Vance 的思想来遵循以性能为中心的设计，我总是回到 Joe Duffy 的博客文章 “过早优化是邪恶的”神话 中的以下摘录。我强烈推荐阅读全文以了解此引言的背景。

“要做到这一点，你需要知道事物的成本。如果你不知道事物的成本，你就是在黑暗中摸索，寄希望于好运。”

这是一个需要被理解并严格遵循的绝佳观点。然而，执行这一点存在实际的挑战。在测量应用程序性能时，许多开发人员会添加日志条目来“感受”代码的性能。更高级的用户可能会使用 StopWatch 类型的机制来尝试更精确地测量应用程序的性能。这两种方法都有其局限性和约束。

有许多有效且强大的工具可用于衡量应用程序在开发、QA 或生产环境中的成本。然而，作为一名软件开发人员，你需要了解在日常开发工作中，在使用你编写和调试代码的相同工具时所产生的成本。

示例应用程序设置

本文的方法将是展示一个具有性能问题的示例应用程序，然后演示找到这些问题根本原因的可能方法。该示例应用程序是一个简单的 WPF 应用程序，它提供起点和终点之间的行车路线。

在插图中您无法看到这一点，但在这个例子中，问题在于用户单击“获取路线”按钮后，需要一段时间才能在应用程序中显示行车路线。此外，在单击此按钮后，应用程序似乎消耗了大量的资源。

在此期间，内存消耗似乎也在不断增加。

重要的是要重复观察应用程序行为的过程几次，以确保问题在合理的样本集中是一致的。同样重要的是要注意，仅仅查看任务管理器中的 CPU 和内存使用率图表并不是得出任何性能、内存或 CPU 问题结论的最佳方法。应用程序之所以（或多个应用程序）消耗这些资源，可能存在合法的理由。作为开发人员，必须对你编写的代码的成本有很好的理解。

传统的故障排除方法

有许多商业和免费的工具可用于帮助排查应用程序并找到内存和 CPU 消耗的根本原因。Windbg、DebugDiag、ProcDump、PerfView 是一些来自微软的免费工具，它们通常因为在开发、测试、暂存甚至现场问题中使用时的灵活性而被认为很好。本节不会使用所有这些工具，但希望能提供足够的信息，让你对这些工具能提供什么有所了解。

PerfView

让我们首先查看 PerfView 工具收集的跟踪。此工具可以从 Microsoft GitHub 仓库 下载。它提供了不同的机制来分析 CPU 和 内存 相关问题。

此图显示了 PerfView 收集和分析的应用程序跟踪。CallTree 视图提供了各种线程的 CPU 消耗分布。正如你所看到的，第一个线程 (ID 3204) 负责应用程序 40% 的 CPU 消耗。此视图还显示了其他线程 (ID 10484, 932, 10140) 及其 CPU 消耗。

在此图中，我深入研究了第一个线程 (ID 3204)。它显示，该线程 40% 的 CPU 使用率大部分被应用程序的 RouteViewer.DisplayDirection 和 RouteCalculator.CalculateRoute 方法所消耗。

同样，此图突出了另外两个线程 (ID 10484, 932)。这还显示了应用程序的 RouteCalculator.XmlDataProcessor 方法的显着 CPU 使用率。

很明显，PerfView 可以帮助精确定位负责高 CPU 使用率的代码部分。

DebugDiag

现在，让我们来找出哪些对象导致了高内存消耗。下图显示了针对同一进程的内存快照生成的 DebugDiag 报告。

此报告显示 GC 堆的总大小约为 2GB。然后，此报告还提供了导致内存消耗的最昂贵对象的列表。XmlElement 在该列表的顶部，负责约 80% 的内存消耗。这可以为开发人员提供关于应用程序的哪个区域可能导致高内存消耗的明确线索。

结论

鉴于 PerfView 和 DebugDiag 的强大功能，我们仅触及了使用这些工具的灵活性来查找示例应用程序问题的根本原因的表面。这些工具不仅可以用于检索更详细的信息，还可以用于排查更复杂的问题。

然而，大多数开发人员在其日常工作中不使用 PerfView 或 DebugDiag 等工具。他们而是使用 Visual Studio 来编写、编译、排除故障和测试他们的代码。这对开发人员来说是一个巨大的困境，如何在日常工作中利用 Visual Studio 的便利性来解决复杂问题、进行任何必要的测量和采取纠正措施。

在未来的文章中，我们将使用 Visual Studio 在开发周期的更早期找到问题的根源。

历史

• 2019 年 6 月 11 日：初始版本