为了阐明准确甄别性能问题的重要性，下面列举了一些致使Web应用响应慢的可能问题排查点：php
- JavaScript响应慢；
- 资源加载中的产生了阻塞；
- 用户端存在代理；
- DNS问题；
- ISP或网络问题；
- 交换机和路由器；
- 负载均衡器；
- 应用代码（包括第三方软件库）；
- HTTP服务器（例若有时是ASP.net或IIS）；
- 第三方服务，例如：支付服务提供商、地图服务提供商等；
- 子系统，包括：SQL Server、Redis、Elasticsearch、Rabbit MQ等。
还能够罗列出更多的性能问题排查点，这取决于需处理系统的复杂度和规模。在如此之多的系统组件均可影响性能优化问题的状况下，如何才能确诊性能问题呢？答案归纳为一个词：数据。你须要来自于每一个系统组件的、相关且有意义的数据。对于Web应用响应慢的问题，数据能够证实每一个系统组件是对问题是有影响的仍是彻底无关的。前端
数据在手，就能够开始从上述列表中按你的思路去抽取问题排查点进行分析，这相似于在排序树中进行查找。每次在树中向下走一层，就越接近于性能问题的细节和实质，依次甄别性能问题是否存在于：web
- 客户端，服务器端或是二者之间的某处？
- 响应慢的JavaScript、渲染或是资源阻塞？
- 负载均衡器、Web服务器、任一子系统或是第三方软件？
在这样树中逐层下行时，性能问题会变得愈来愈清晰。对于每一个层次上的问题排查点，定位性能问题所需的数据必需要与对应的问题精度相匹配。这时有必要去使用性能分析工具或SQL执行计划这样的工具。sql
例如在一个Web请求中，假定须要100毫秒的服务器处理时间和5秒的SQL查询时间。即便你能够将服务器处理时间优化到低于1毫秒，可是这对总体响应时间的改进很小，也就是从5.1秒变成5秒。改进SQL处理所需的5秒时间是潜在收益最大的优化。chrome
架构问题
这种逐层厘清优化问题所在的自顶向下方法，对于局限在单一页面中的优化问题具备很好的效果。那么应用于跨越多个页面的优化问题上时效果又如何呢？例如，一些页面所存在的间歇性地打开慢问题，是因为子系统跟不上总体工做节奏，或是因为系统中存在某个再次重启可能就没法继续工做的老旧网络交换机。数据库
这种状况下，侧重于应用的监控方法显示出它的局限性所在。这须要更多的软件层面和硬件层面上的指标，用于对系统中的每一个组件进行评估。后端
在硬件层面，首先所能想到就是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就是这样的一个免费工具。
系统性能相关的因素和工具的数量是很是之多，这看上去彷佛十分复杂。可是它们能够用一个词进行归纳：数据。对系统有一个清晰的和准确的视图，这使得推理性能问题成为可能。这也使你能够在现场学习如何去解决性能问题，由于性能指标和图表将会引导你去发现究竟是什么影响了系统性能。