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

Original 傅雨斌翻译新钛云服 2022-01-05

“这个网页很慢”“这个网页访问不通”是关于网站经常的抱怨，特别是因为Web应用程序开始取代桌面应用程序。虽然网络带来了一些理想的特征，如全球交付，但它也在性能水平上带来了一些挑战。

收集和使用数据背后的基本原理

用户提交了“慢”网页的网址的问题。好的，现在怎么样？缓慢来自哪里？它实际上很慢吗？对所有用户来说都很慢吗？这里要回答很多问题来解决这个问题，并确保一周后它不再变慢。

我们可以在线找到性能优化材料，通常是关于特定主题，如Jit，垃圾收集，SQL查询优化，ORM陷阱等。尽管实施优化很有吸引力，因为它看起来很有前途，但是会出现一个问题：我们如何知道这种优化实际上会在处理缓慢问题中产生良好的结果？

显然，缺少一块拼图。我们需要一种能够持续发现性能问题的方法。这样，我们知道什么是缓慢的，并采取具体措施予以支持。有了这些知识，就可以准确地确定是否需要改进性能并向利益相关者解释。

准确识别性能是一种更有效的方式来响应感知的缓慢问题。第一个问题是它可能不是一个缓慢的问题。在超时的情况下（例如，负载平衡器可能在X秒后切断连接），很明显无法区分死锁或慢响应时间，因为结果将是相同的，即超时。需要数据才能找到真正的问题。

为了说明精确识别性能问题的重要性，以下是Web应用程序中一些可能的缓慢点：

慢JavaScript
渲染加载妨碍品质
用户端的代理阻碍
DNS问题
ISP问题/网络
交换机和路由器
负载均衡器
应用程序代码（包括第三方库）
HTTP服务器（例如，来自ASP.NET或IIS的东西）
第三方服务，如支付处理器，地图提供商等。
子系统，如SQL Server，Redis，Elasticsearch，Rabbit MQ等。

根据自身问题处理的复杂性和规模，列表会继续。如此多的组件在运行时如何诊断性能问题？一个字：数据。所以需要关于一切的相关，有意义的数据。可以证明涉及缓慢请求的系统的有问题或无问题的数据。

掌握数据后，我们可以从顶部开始，随时从列表中删除组件，类似于在排序树中执行搜索。每一步都让你更接近细节和实际问题：

客户端，服务器端还是介于两者之间？
缓慢的Javascript渲染，妨碍了品质？
负载均衡器，Web服务器，任何子系统或第三方？

无论改进的程度如何，任务的理论加速总是受到无法从改进中受益的任务部分的限制。

例如，假设我们有一个Web请求需要100ms的服务器处理和5秒的SQL查询。即使将服务器处理时间降至1毫秒，整体改进在响应时间方面也是微不足道的，从5.1秒到5秒。SQL处理的5秒是潜在收益最高的地方。

基础架构问题

一种自上而下的方法，即越来越精确地识别问题，在本地化到单个页面的问题的上下文中很好地工作。产生多个页面的问题怎么样？例如，如果由于子系统无法跟上而导致各种页面出现间歇性的慢响应时间，或者每次重启可能是最后一次的古董网络切换，该怎么办？
这是专注于应用程序的监控方法显示其局限性的地方。在此级别，需要其他指标来评估系统中每个组件（包括软件和硬件级别）的健康状况。

在硬件级别，首先想到的是Web和数据库服务器。然而，这些只是冰山一角。必须识别和监控所有硬件组件：服务器，网络交换机，路由器，负载平衡器，防火墙，SAN等。

所有这些对于系统管理员来说似乎都很明显，因为硬件监控是一种常见做法。但是，有一个重要的警告：如果它们与应用程序指标分开，那么所有这些硬件指标在性能观点上大多无用。换句话说，指标在放入上下文时最有用。

例如，数据库服务器上平均50％的CPU使用率在某些情况下可能是完全正常的，而在其他情况下则是滴答作响的定时炸弹。在高峰时段，50％的CPU使用率表明仍有一些空间可容纳更大的流量。如果在空闲期间频繁发生相同的50％，则表明应用程序不太可能在突然的传入请求高峰期内存活。

底线，系统范围的指标（如CPU，内存和磁盘）必须与应用程序指标相关联，以确定系统健康状况。能够可视化应用程序指标（如请求吞吐量和CPU使用率等系统指标），可以更全面地了解系统的健康状况。

应用程序性能管理（APM）工具

APM工具提供以下基本操作：数据收集，数据存储和数据可视化。代理通常负责收集数据并将其发送到数据存储。使用Web界面，可以通过以Web请求为中心的仪表板显示数据。

APM工具对以下方面很有用：