怎么逐层保存网站历史性能数据？

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


 
对于通过网站来获得收益或霸占市场的公司而言，监控最终用户的性能绝对是最紧张的。假如不知道网站在一个国家或全球范围内的运行状态，那么这个公司可能就无法管理好本身的核心营业。然而，假如想要快速高效地诊断问题，并且控制好影响最终用户性能的各个层或组件，仅仅监控最终用户的性能照旧不够的。
 
一个典型的三层Web环境，它部署了一个全球或地区性的性能监控服务，所以这家公司可以跟踪最终用户和Web性能指标。
 
Web应用的各个组件的每一层上只有少数监控或完全没有监控。当全球监控服务在最终用户层上发现问题时，开发和运维团队就必须仓促地搜索日志，才能够发现性能问题到底出如今什么位置。在这个例子中，当有一个修改影响到悉数三层时，最终用户的性能体验就会紧张降落。
 
事实上，这个问题可能是由外部因素导致的，如DDos攻击、网络或ISP问题，或者是访客的激增。然而，因为如今没有关于各层实行情况的历史数据，所以他们很难确定问题的根源在哪里，因此必须要花费更多的时间和精力去探求问题的根源。
 
雷同的环境，但是如今有了每层的历史性能数据。在这种情况下，假如有一个内部修改导致最终用户性能降落或出现问题，那么它几乎可以立刻被检测出来。修复网站制作问题所必须要的时间明显削减，由于如今性能转变可以在更细的粒度上检测出来了，而且检测问题发生的位置也被缩小到特定的条理上。性能数据可以与修改记录和应用日志文件进行比较，由此一来，隔离问题发生位置就毫无难度了。此外，当有一位最终用户碰到性能问题时，相干人员只必须要在办公地查看一些历史性能图表，就可以确定引起问题的是内部因素照旧外部因素。