如何监控ASP.NET性能

　　介绍

小编给大家分享一下如何监控ASP.NET性能,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大家阅读完这篇文章后大有收获、下面让我们一起去了解一下吧!

　　关键要点:

<李>

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

<李>


<李>

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

<李>


<李>

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

<李>


<李>

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

<李>


<李>

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

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

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

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

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

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

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

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

<李>

　　JavaScript响应慢;

<李>


<李>

　　资源加载中的产生了阻塞;

<李>


<李>

　　用户端存在代理;

<李>


<李>

　　DNS问题;

<李>


<李>

　　ISP或网络问题;

<李>


<李>

　　交换机和路由器;

<李>


<李>

　　负载均衡器;

<李>


<李>

　　应用代码(包括第三方软件库),

<李>


<李>

　　HTTP服务器(例如有时是ASP.net或IIS);

<李>


<李>

　　第三方服务,例如:支付服务提供商,地图服务提供商等;

<李>


<李>

　　子系统,包括:SQL Server,复述,Elasticsearch,兔子MQ等。

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

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

<李>

　　客户端,服务器端或是两者之间的某处?

<李>


<李>

　　响应慢的JavaScript,渲染或是资源阻塞?

<李>


<李>

　　负载均衡器、Web服务器,任一子系统或是第三方软件?

如何监控ASP.NET性能