ASP.NET 性能监控和优化入门

关键要点：

只有与应用指标相关联，基础设施指标才能最大发挥作用。

高效性能优化的关键在于性能数据。

一些APM工具为ASP.NET提供了开箱即用的支持，这样入门使用ASP.NET仅需最小限度的初始设置。

代码分析工具为程序性能给出了最为详尽的视图。

轻量级分析工具给出了网页性能的实时视图，可用在开发环境和生产环境中。

“这个网页打开太慢了！”，对Web网站这样的抱怨是经常性的和普遍性的，尤其是自从Web应用开始逐渐替代桌面应用以来。虽然Web带来了全球交付这样的理想特性，但是也在性能层面带来了相应的挑战。

数据采集与使用的基本原理

用户给了你一个“龟速”网页的url，那好，你该怎么做呢？网页打开慢的问题是源自于哪里？是一开始就是这么慢吗？是对所有用户都很慢吗？要解决网页打开慢的问题并且确保在一周后不会再次变慢，有许多诸如此类的问题需要得到解决。

虽然在网上可以搜索到一些性能优化的资料，但它们通常都是关于Jit、垃圾回收、SQL查询优化、ORM陷阱等这样一些特定主题的。考虑到实现优化的美好前景是诱人的，这里冒出了这样的一个问题：针对当前的性能问题，如何知道所选定的优化方法将会切实地产生好的结果？

无疑在这个工作中的某一环是有所缺失的。我们需要能可持续地找到性能问题所在的方法。通过使用该方法，我们能发现系统中较慢的部分，并有切实措施支持我们对性能问题的诊断。掌握了性能问题所在，我们就可以进一步地确定是否需要进行性能改进，并对利益相关者解释所有这一切。

对于所发现的上述性能问题，进行准确地甄别是更有效的处理方法。问题在一开始可能并非是一个网页加载慢的问题。在存在超时的情况下（例如负载均衡器可能几秒后才会为连接提供服务），完全无法被区分开这是一个死锁问题或是响应时间慢的问题，因为这两个问题导致了同样的结果，就是产生了超时。这需要数据去找到导致问题的真正原因。

为了阐明准确甄别性能问题的重要性，下面列举了一些导致Web应用响应慢的可能问题排查点：

JavaScript响应慢；
资源加载中的产生了阻塞；
用户端存在代理；
DNS问题；
ISP或网络问题；
交换机和路由器；
负载均衡器；
应用代码（包括第三方软件库）；
HTTP服务器（例如有时是ASP.net或IIS）；
第三方服务，例如：支付服务提供商、地图服务提供商等；
子系统，包括：SQL Server、Redis、Elasticsearch、Rabbit MQ等。

还可以罗列出更多的性能问题排查点，这取决于需处理系统的复杂度和规模。在如此之多的系统组件都可影响性能优化问题的情况下，如何才能确诊性能问题呢？答案概括为一个词：数据。你需要来自于每个系统组件的、相关且有意义的数据。对于Web应用响应慢的问题，数据可以证明每个系统组件是对问题是有影响的还是完全无关的。

数据在手，就可以开始从上述列表中按你的思路去抽取问题排查点进行分析，这类似于在排序树中进行查找。每次在树中向下走一层，就越接近于性能问题的细节和实质，依次甄别性能问题是否存在于：

客户端，服务器端或是两者之间的某处？
响应慢的JavaScript、渲染或是资源阻塞？
负载均衡器、Web服务器、任一子系统或是第三方软件？

在这样树中逐层下行时，性能问题会变得越来越清晰。对于每个层次上的问题排查点，定位性能问题所需的数据必须要与对应的问题精度相匹配。这时有必要去使用性能分析工具或SQL执行计划这样的工具。

为有效地利用时间，很有必要重申一下Amdahl定律：

无论一个任务改进的程度如何，该任务中没有从改进中受益的部分限制了理论上的任务加速。

例如在一个Web请求中，假定需要100毫秒的服务器处理时间和5秒的SQL查询时间。即使你可以将服务器处理时间优化到低于1毫秒，但是这对整体响应时间的改进很小，也就是从5.1秒变成5秒。改进SQL处理所需的5秒时间是潜在收益最大的优化。

架构问题

这种逐层厘清优化问题所在的自顶向下方法，对于局限在单一页面中的优化问题具有很好的效果。那么应用于跨越多个页面的优化问题上时效果又如何呢？例如，一些页面所存在的间歇性地打开慢问题，是由于子系统跟不上整体工作节奏，或是由于系统中存在某个再次重启可能就无法继续工作的老旧网络交换机。

这种情况下，侧重于应用的监控方法显示出它的局限性所在。这需要更多的软件层面和硬件层面上的指标，用于对系统中的每个组件进行评估。

在硬件层面，首先所能想到就是web服务器和数据库服务器，但它们只是冰山的一角。必须要识别和监控所有系统中的硬件组件，这包括：服务器、网络交换机、路由器、负载均衡器、防火墙、SAN等。

鉴于系统管理员的常规工作就是硬件监控，可能对于系统管理员而言上述的所有指标是显而易见的。但是这里有个重要警告：如果将这些硬件指标从软件指标中分离处理，那么从性能角度看所有这些硬件指标中的大部分是毫无用处的。换句话说，指标只有置于相应的环境中才能发挥最大作用。

例如，在一些情况下可能在数据库服务器上CPU占用率平均达50%是完全正常的，但是对于其它服务器而言这就是个定时炸弹。50%的CPU占用率，如果是在峰值时刻这意味着仍有很大空间去运行更繁重的任务。但如果是在闲暇时间段中而50%的CPU占用率频繁发生，这就意味着应用可能无法承受传入请求的突发峰值。

底线就是，为评估系统的健康度，CPU、内存和磁盘等全系统范围指标必须要与应用指标相关联。为给出更完全的系统健康状况视图，可以对请求吞吐量这样的应用指标和CPU占用率这样的系统指标进行可视化。

应用性能管理（Application Performance Management，APM）工具

APM工具提供数据采集、数据存储和数据可视化这些基础性操作。通常是由代理负责采集数据并将数据发送给数据存储，并使用Web界面以集中在Web请求上的仪表盘方式对数据进行可视化。

APM可用于：

对Web应用性能做整体可视化；
对特定的Web请求性能进行可视化；
在Web应用性能变差时或者多个错误出现时，自动发送告警；
在业务量大时，对应用的响应方式进行验证。

在这里给出了实例。

下面并非详尽地列出了支持对ASP.NET和IIS开箱即用的APM工具清单：

基础设施监控工具

基础设施监控工具在主机层面采集指标，这可更完整地反映性能。这些指标是在硬件和软件层面采集的。

轻量级分析工具

轻量级分析工具为特定Web请求提供了高层次的指标，并在开发人员浏览Web页面时就可提供实时反馈。这些工具可用于所有的环境类型中（包括开发环境、QA验证、模拟环境、生产环境等），因此非常适合于对特定页面性能的快速评估。

与相应的具有完全功能的分析工具相比，轻量级分析工具的本质差异在于它们并非附属于过程，这意味着在使用轻量级分析工具时无需操心它们所产生的开销。

在开发环境中，轻量级分析工具对当前正编写的代码提供了实时反馈。这对于发现N+1或响应时间慢等问题是非常有用的，因为响应时间总是显示在页面的一角上。

用性能计数器填补空白

Windows系统中的性能计数器（Performance counter）提供了硬件和软件层次上不同方面的指标。监控工具通常以性能计数器为报告方式，例如CPU和内存占用情况。但是通常会缺失一些有用的计数器，例如垃圾回收时间等。最切实可行的入门方法是使用基本列表并在迭代中添加必要的相关计数器。此外，使用perfmon对性能计数器进行实时地采集和可视化是可行的。在很多情况下，将用户定制指标或插件与APM工具进行集成也是可行的。

SQL工具

由于在很多应用中普遍地使用了数据库，持久层（即SQL数据库）常常成为性能的瓶颈。用于SQL监控的专业工具可提供资源使用指标，以及一些特定的指标，例如等待时间、每秒编译次数等，在这里仅列举几个。

在提供下列数据情况下，可以发现一些类型的问题并可对性能进行改进：

在一个或数个查询上存在过度的吞吐量；
过度的CPU占用，这暗示了查询问题的存在或者是索引的缺失；
可被缓存的高吞吐量查询。

SQL监控工具包括：

其它的持久系统

所有子系统都需要在某种程度上进行监控。对于低吞吐量或非关键的系统，简单的数据采集和可视化即足矣。在此外的情况下则需要更加高级的、专业的监控。

代码分析工具

当已确诊某个特定页面或代码段检测是响应慢的，代码分析工具可为性能问题鉴定提供最详尽的视图。代码分析工具还可为数据库查询和Web请求这样的外部调用提供了精准视图。

分析工具：

内存分析工具

内存监控和垃圾回收指标有助于潜在问题的检测。但这些指标在显示了存在问题的同时，通常并未给出问题的所在。如果需要队内存和垃圾回收问题进行深入地探究，内存分析工具就可派上用场。

分析工具：

用户端分析工具

性能问题也可能来自于前端。当前这个问题十分常见，因为以JavaScript主导的单页应用的大量涌现。所有的主流浏览器都已嵌入了诸如代码分析和内存分析这样的工具。显示事件和请求的序列的工具有利于一眼就确定问题是源于前端还是后端。

工具：Tools:

页面分析工具

高层次客户端工具为发现并解决性能问题的提供了便利着手点。这些工具可以针对响应时间问题的产生根源提供高层次的视图，并给出一些相应的建议。例如Google的PageSpeed Insights就是这样的一个免费工具。

系统性能相关的因素和工具的数量是非常之多，这看上去似乎十分复杂。但是它们可以用一个词进行概括：数据。对系统有一个清晰的和准确的视图，这使得推理性能问题成为可能。这也使你可以在现场学习如何去解决性能问题，因为性能指标和图表将会引导你去发现到底是什么影响了系统性能。