保存Web应用程序中各个层的历史性能数据，有利于快速确定问题所在位置。典型的三层架构包括Web层、应用层和数据层。性能问题有可能出现在任一层，因而此举会增加排查问题的难度。通过保存各个层的性能数据，我们就有可能在最终用户遇到问题之前就检测并解决掉，或者，更关键的是，在这些问题影响到网站或应用中与收益相关的功能之前就将它们排除。Web开发人员必须与运维人员一起协作，监控各层的运行状况，确定各层的测试方式应该是两个团队的共同职责。例如，Web开发人员可能负责保存应用层和Web层的历史性能趋势数据，因此在如何测试这些层及执行这些层的测试上有更多的话语权。另一方面，在数据层中，可能应该由数据库管理员来创建工具或测试特定的查询和数据库功能。



对于通过网站来获得收益或占领市场的公司而言，监控最终用户的性能绝对是最重要的。如果不知道网站在一个国家或全球范围内的运行状况，那么这个公司可能就无法管理好自己的核心业务。然而，如果想要快速高效地诊断问题，并且控制好影响最终用户性能的各个层或组件，仅仅监控最终用户的性能还是不够的。

一个典型的三层Web环境，它部署了一个全球或地区性的性能监控服务，所以这家公司可以跟踪最终用户和Web性能指标。

Web应用的各个组件的每一层上只有少数监控或完全没有监控。当全球监控服务在最终用户层上发现问题时，开发和运维团队就必须仓促地搜索日志，才能够发现性能问题到底出现在什么位置。在这个例子中，当有一个修改影响到全部三层时，最终用户的性能体验就会严重下降。

事实上，这个问题可能是由外部因素导致的，如DDos攻击、网络或ISP问题，或者是访客的激增。然而，由于现在没有关于各层执行情况的历史数据，所以他们很难确定问题的根源在哪里，因此需要花费更多的时间和精力去寻找问题的根源。

相同的环境，但是现在有了每层的历史性能数据。在这种情况下，如果有一个内部修改导致最终用户性能下降或出现问题，那么它几乎可以马上被检测出来。修复网站制作问题所需要的时间显著减少，因为现在性能变化可以在更细的粒度上检测出来了，而且检测问题发生的位置也被缩小到特定的层次上。性能数据可以与修改记录和应用日志文件进行比较，由此一来，隔离问题发生位置就毫无难度了。此外，当有一位最终用户遇到性能问题时，相关人员只需要在办公地查看一些历史性能图表，就可以确定引起问题的是内部因素还是外部因素。