“企业级应用”好像一架天平，在可靠性一端我们已经加上了重重的砝码，而另
一 端还有 “性能”这个因素没有得到保证。
瞄准应用性能管理
企业级，这个定语前缀已经越来越
频繁地出现在IT领域，它一旦同网络，服
务器，安全，应用相结合，原有的这些名
词马上变得身价倍增，无论是成本，规模
还是被重视的程度，而一旦”开发”被赋
予了这样的前缀，原本日常的工作马上就
被套上了神奇的光环。我们不妨定义一个
专门的表示形式——企业级开发，来表
示它与—般开发的区别。
应用企业级性能需求
如何确保 ”应用企业级”性能的要
求，已经成为在可靠性之外，对于系统
得管理和运行维护人员提出的一个更高
的挑战，对于原先只关心”应用企业级”
的准确性和可靠性的开发团队而言，保
证”性能”成为应用生命周期的最后一
个链条，谁能够将其稳妥地完成，谁就
完成了 ”开发企业级”的整个闭环。
为了提高”应用企业级”的性能，最
直接的方式就是对硬件进行升级。不可
否认，它直接导致了硬件性能的快速增
长和硬件价格的迅速下滑。然而，在现
在这样一个投资紧缩的年代，精打细算
的IT管理人员已经在 应用企业级 的
更深层次寻求改善性能的方法了。
— 2004．1 2 www_swm． 。m．
在众多技术层间定位和隔离
多层次系统模型的优势是具有更强
的可扩展性，可以无限制增加的处理能
力以及灵活的部署形式使之在企业级系
统领域具有旺盛的生命力；然而，系统的
复杂性也伴随技术层次的增加而迅速增
长。相比较原有的单一技术构造的应用
而言，在出现了性能问题之后，如何将其
定位到某个技术层次上，是解决问题关
键的第一步 但是，由于缺乏统一的性能
衡量指标，这第一步却往往很难迈出。
那么，如果在缺乏可视性的情况下
找到根本性问题7以J2EE方式构建的系
统为例，客户往往能够将性能问题定位
到某个用户调用．然而。在这个方法调
用以下，可能会隐藏着几层甚至十几层
的系统调用，这对于用户是不可见的。
对处于Java应用和操作系统之间的JVM
而言，用户就更加难以对其进行调整，
原因同样是缺乏可视性。
对于单一的技术组成部分，例如数
据库、中间件或者应用服务器而言，专
门的技术人员能够解决相当数量的性能
问题，然而由于技术的迅速发展和演
化，以及更多种类的技术同时出现在一
个应用系统中，对于技术 ”全才 和快
速学习型人才的要求愈发迫切。为了达
到这个要求，更多的费用会产生在技术
培训、人才雇佣等诸多环节。如果能够
有一个软件，将每个门类技术专家的技
能都集中起来，供大家分享，这无疑是
一 个经济高效的解决方案。
对性能问题进行校验
多层次系统模型的复杂性不仅增加
了定位问题的难度，在如何确保问题的
解决方法正确性和高效性方面也提出了
挑战。在此类系统中很有可能出现．对
一 个性能问题的调整导致更多性能问题
出现的情况。而且，在生产环境中，性
能的调整将是非常慎重的，在对改进方
案没有1∞％的把握的情况下，是不可
能投入实际生产的。所以，我们需要对
改进方式，在生产环境之外进行校验。
而这种环境又不能同生产环境所产生的
真实数据完全脱离。
确保应用性能持续高水平
在生产环境和开发环境中进行应用
性能调整的一个显著区别是，前者非常
关注调整的效率，也就是从发现问题到
改正问题之间的时间越短越好。如果能
够做到在应用问题影响到用户体验之前
就进行修正，从而提供一个持续保持高
效运转的应用系统，将是每一个系统维
维普资讯
护人员的最终目标。
在这种情况下．一种对于应用性能
进行监控，报告、分析、改进以及趋势
预测的技术应运而生．我们把这类技术
成为应用性能管理(Application Perfor—
rr国nce Managerr~ t)。
APM的发展与未来
我们可以这样来定义APM：”是在实
际生产运行环境中．从应用的角度对系
统性能进行监控、分析和优化的管理方
案 ．它不同于以往针对某种技术层次的
调优工具．具有以下几个鲜明的技术特
色：APM着眼的是应用系统整体的性能管
理．而非仅仅针对某个技术层次的 烟囱
式 的解决方案。这是一个典型w由应
用的用户访问路径．通过一系列的 “访
问 ．用户能够最终实现一个完整的交易
过程。在每个 ”访问 的过程中．APM都
能够以该“访问”所花费的时间．占最终
用户总的响应时间所占的比例为主要的
衡量标准．也就是通过比较各个技术层
次对客户响应时间所做出的 贡献”．在
第一时间将问题定位于某个技术层次。
此外．APM具有从一个技术层次到
另外一个技术层次透明过渡的能力。也
就是说．如果在J2EE层发现性能下降是
由于一个JDBC访问引起的．那么APM
能够从该方法的调用反向生成SQL语
句．从J2EE应用的性能管理过渡到对数
据库层次的性能管理工具．最终通过修
改某个数据库表的索引而解决性能问
题。并且，在修改问题之后，APM也会
从应用整体响应时间的角度，将性能的
变化对于整个系统的影响显示出来，而
不仅仅限于数据库层或者J2EE层。
APM的视野不仅足够宽广．而且足
够深入。APM拥有钻取的能力，能够对
表层的性能问题．通过层层拨茧的方式．
按照访问的路径深入下去．直到搜索到问
题的根源为止。这对于在缺乏可视性的应
用中进行性能管理．例~[IEJB调用．是非
常关键的。此外．APM还必须在发现问题
之后，具有修改问题的能力。对于数据库
应用而言，APM能够提出建议来帮助用户
修改性能不佳的SOL语句．或者调整数据
库对象的属性：对于具有成百t千个参餐呐
J旺 应用服务器来说．APM能够在发现问
么。APM不仅仅是一个在性能问题出现
后进行补救的工具．而且能够为系统的
维护团队提供预警信息．在性能问题真
正开始影响用户的使用之前．就将其改
正．保证为用户提供一个性能可靠．坚如
磐石的应用系统。
A 做 件还处于其成长期．它的前身
是各个不同种类的性能调优产品．而它
的未来必将走向融合和统一。将来自于
如何确保 “应用企业级”性能。已经成为在可靠性之外，
对于系统管理和运行维护人员提出的一个更高的挑战。对
于原先只关心 “应用企业级”的准确性和可靠性的开发团队
而言，保证 “性能”成为应用生命周期的最后一个链条。谁能
够将其稳妥地完成，谁就完成了 “开发企业级”的整个闭环。
题之后．向用户提供建议如何调整参数而
达到最优性能。
APM考察应用系统的性能依据．来
自于用户的真实操作数据。同比传统性
能调优工具使用的模拟数据．APM进行
性能调整的依据是用户实际操作的数
据．将用户体验、使用习惯、业务波动
和技术指标综合考虑。显而易见．这种
数据只能来自于生产环境。传统的性能
调优工具之所以大多只用于开发环境，
是因为其过高的系统负载．而APM产品
依靠其对于应用超低的负载，能够实施
7 X 24的对于生产系统的长期监控。
ARM拥有专门的数据存储。A 牛^苷采
集的数据经分析之后存放起来，而不是
在考察之后就抛弃．或者仅仅保留短时
间的性能数据。只有这样．使用者才能
嘞 即 网 日J肭 D祠习刃田T得 星 晤
论．从而了解：过去曾经发生过什么．现
在正在发生什么．以及今后即将发生什
也只会来自于业务的需求和最终客户的
体验。技术的汇聚是IT的发展方向，这
一 特性在APM领域也不例外。
厂商也大
多提：供对于自己产品的调优l工具。同时他
们也明白，对于单一产品的监控和管理．
~t-T-当今的复杂应用环境而言会逐渐走入
一 个封闭的市场．所以．这些厂商也会在
一 个更加广泛的领域中管理其产品的性
能。APM厂商的优势是广泛的产品覆盖．而
组件厂商的优势是对于自身产品的透彻了
解．究竟谁是最后的胜者．将拭目以待。
2004．12 www．swm．com．crl
维普资讯
