正文
响应慢的JavaScript、渲染或是资源阻塞？
负载均衡器、Web服务器、任一子系统或是第三方软件？
在这样树中逐层下行时，性能问题会变得越来越清晰。对于每个层次上的问题排查点，定位性能问题所需的数据必须要与对应的问题精度相匹配。这时有必要去使用性能分析工具或SQL执行计划这样的工具。
为有效地利用时间，很有必要重申一下Amdahl定律：
无论一个任务改进的程度如何，该任务中没有从改进中受益的部分限制了理论上的任务加速。
例如在一个Web请求中，假定需要100毫秒的服务器处理时间和5秒的SQL查询时间。即使你可以将服务器处理时间优化到低于1毫秒，但是这对整体响应时间的改进很小，也就是从5.1秒变成5秒。改进SQL处理所需的5秒时间是潜在收益最大的优化。
这种逐层厘清优化问题所在的自顶向下方法，对于局限在单一页面中的优化问题具有很好的效果。那么应用于跨越多个页面的优化问题上时效果又如何呢？例如，一些页面所存在的间歇性地打开慢问题，是由于子系统跟不上整体工作节奏，或是由于系统中存在某个再次重启可能就无法继续工作的老旧网络交换机。
这种情况下，侧重于应用的监控方法显示出它的局限性所在。这需要更多的软件层面和硬件层面上的指标，用于对系统中的每个组件进行评估。
在硬件层面，首先所能想到就是web服务器和数据库服务器，但它们只是冰山的一角。必须要识别和监控所有系统中的硬件组件，这包括：服务器、网络交换机、路由器、负载均衡器、防火墙、SAN等。
鉴于系统管理员的常规工作就是硬件监控，可能对于系统管理员而言上述的所有指标是显而易见的。但是这里有个重要警告：如果将这些硬件指标从软件指标中分离处理，那么从性能角度看所有这些硬件指标中的大部分是毫无用处的。换句话说，指标只有置于相应的环境中才能发挥最大作用。
例如，在一些情况下可能在数据库服务器上CPU占用率平均达50%是完全正常的，但是对于其它服务器而言这就是个定时炸弹。50%的CPU占用率，如果是在峰值时刻这意味着仍有很大空间去运行更繁重的任务。但如果是在闲暇时间段中而50%的CPU占用率频繁发生，这就意味着应用可能无法承受传入请求的突发峰值。
底线就是，为评估系统的健康度，CPU、内存和磁盘等全系统范围指标必须要与应用指标相关联。为给出更完全的系统健康状况视图，可以对请求吞吐量这样的应用指标和CPU占用率这样的系统指标进行可视化。
APM工具提供数据采集、数据存储和数据可视化这些基础性操作。通常是由代理负责采集数据并将数据发送给数据存储，并使用Web界面以集中在Web请求上的仪表盘方式对数据进行可视化。
APM可用于：
