部署一个应用交付控制器（ADC）的主要任务就是为了满足用户的需求：在95%的情况下，他们需要保证越来越多且越来越严格的应用服务水平（SLA）。为此，我们必须要考虑提高应用的可用性。我们不仅利用本地服务负载均衡来保证本地服务器的畅通，还用全局负载均衡（GSLB）结合灾难恢复站点来缩短全球范围的故障时间。另外，提升性能也尤为重要，一些技术手段可以合理安排由服务器下达给ADC的CPU密度级任务来降低负载，比如SSL、压缩和智能缓存。
　　但即使是在部署最好的ADC解决方案之后，我们仍须面对监控既定SLA的挑战。检测某个应用程序的不可用事件看似简单：观察其是否有反应，若无反应则发送一个错误消息。一些ADC在应用不可用时会发出提醒，但为时已晚。
　　从另一个角度而言，应用减速很难被检测到。因为用户不会经常检测应用程序，甚至不知道多长的无反应时间是不正常的，等注意到时已落后许久。带来的结果往往是对业务执行的严重损害，甚至降低员工的生产效率，同时也会影响客户的满意度和忠诚度。
　　为了填补应用减速的监控盲区，我们需要确定对哪个节点进行实时流量监控，对哪个节点制定自动执行监控任务，并且时刻准备执行。
　　在接收到应用减速提醒，并认识维护用户体验的重要性后，最痛苦的事情莫过于寻找引起应用减速的症结所在，而这需要更高级的解决方案。
　　应用性能监测系统（APM）是一套精良可视化的工具，它帮助IT管理员们获取程序的性能指数，并实时维护应用的SLA活跃度。它的重要性体现在可为潜在的问题或者是在问题出现的第一时间订制积极的解决方案，因为问题存在之后的被动反应会造成严重的经济损失。
　　一般说来，制定APM方案可以从以下两方面考虑：
　　1.利用运行预置的脚本的综合工具来浏览web应用程序并衡量其反应时长或可用性。
　　2.在每个应用程序服务器里安装专用软件客户端，收集每个用户和服务器中处理事务的数据，并以此衡量性能。
　　第一个选择是廉价的，要求应用的集成度相对较低，只需为每个应用程序运行一个非入侵性的脚本。然而这种方法有很强的局限性：一方面，它只能获取应用程序的状态，且不是实时的；另一方面，它无法改写数据来解决问题。对应用程序的实时状况（包括实际应用交易及用户体验）覆盖度明显不足。
　　第二个选择提供高端的解决方案，它能够以每个实际用户或业务为单位细致拆解，进行精确的根源分析。它要求前期较高的成本投入，同时需要和服务器操作系统的深度整合也会给生产环境带来一定的风险。
　　想像一下，如果你有第三个选择会怎样。它提供的监控方案既便捷又经济，同时更综合了前两个选择的优势，你的应用交付设备将由这样的APM工具所支持，它具备如下特性：
　　? 可监控各服务的性能；
　　? 可监控用户与数据中心之间的网络性能；
　　? 可监控实际用户体验，如响应时间，错误类型等；
　　? 可识别多用户，多业务，以及应用装载之间的关系映射；
　　? 提供一个中心APM控制台，可从多个数据中心的各项应用中收集数据，并将处理过的信息显示出来；
　　? 可为某个业务或某一组业务设置监控策略，一旦超过既定SLA就能给你提醒；
　　? 可提供根源分析的所有相关信息；
　　APM系统状态收集功能被整合在ADC中，它可以从这个绝佳位置来监督所有服务和用户。它还具备先进的报告引擎来生成和传递符合人们阅读习惯的报告，在该系统全权监控下，一旦任何应用的SLA有误差，就会发出警告。
　　当IT管理员捧着扔过来的性能数据，被要求去查明是否存在问题、问题的症结何在时，不会再手足无措。APM系统可将纵向挖掘的数据，与应用装载状态，数据中心、网络和用户之间的延时曲线等横向数据相结合，有效分析并定位影响相关SLA的根源所在。
　　因此，网络管理员不会再听到应用管理员的抱怨，说网络有问题再次造成应用减速；而应用团队也不会被告知说网络是正常的，问题出在应用本身。APM系统提供透明的监控方案，让双方都可以轻易地发现在应用交付的哪个环节出现问题，哪个环节造成了延时，哪个环节的工作需要完善等，让各应用的SLA和响应时间回归正常。
　　ADC解决方案用全新的且具有历史意义的途径来保证各项应用的SLA：它提供的工具既支持应用的可用性又满足其加速需求，同时，一个被整合或嵌入的APM系统可以孵化出最佳的方案，可支持重要应用性能监控的可视化功能，从而成为应用性能持续优化的有力保障。