|
提纲：  图1-1：性能优化概况 当一个应用的性能未能满足要求，应当从哪里入手改善其性能？怎样的情况下才必须增加硬件设施？如何通过调整几个应用服务器的参数，获得比添加硬件设备更好的性能效果？这些问题都是实践中经常会遇到的问题，但遗憾的是，许多单位在看到应用的性能未能满足要求时，首先考虑的就是增加硬件设备。增加硬件设备无疑会提高应用的性能表现，但同时也会增加维护费用和硬件体系的复杂程度（更不用说购买硬件设备本身和软件许可的费用了）。 我们的目标应该是首先从现有的应用和应用服务器榨取最大的性能，在此之后才考虑添加硬件设备。从长远来看，单纯靠添加硬件来提高性能很难获得好效果：虽然有可能暂时解决眼前的性能危机，但问题仍旧存在，一旦负载增加了又会出现。 ■ 并发用户 在应用服务器上运行应用，评估其在不能响应请求或响应请求所需时间超出许可范围之前能够支持的最大并发用户数量。响应时间可以由服务水准协议（Service Level Agreement，SLA，参见用 SLA 保证 Web 服务 ）定义，规定一个请求允许消耗的最长时间，超出该时间就被认为不可接受。对应用进行负载测试时很重要的一点是必须确保测试过程反映了应用实际运行过程中出现的典型事务，因为后来的性能优化措施将针对负载测试的结果进行。如果负载测试的事务不够典型，就不能有效地保证应用能够象测试环境中表现地那样为用户提供服务。 ■ 吞吐量 应用和应用服务器的吞吐量可以用每秒完成的事务数量来表示，它从一个侧面反映了应用和应用服务器的运行是否正常，指出了服务器的能力。我们的目标是通过应用和应用服务器的调整，来尽可能地提高服务器的吞吐量。 ■ 可靠性 除了支持最大数量的并发用户、可接受的响应时间之外，另一个要求就是尽量减少请求失败的次数。Web服务器都可能出现故障，最主要的原因是网络延迟或超时，而我们优化的主要工作就是确保用户能够收到他请求的信息。 二、从哪些方面入手优化 虽然一些性能监测和优化专家会试图让你相信某个企业应用的性能瓶颈或者在于应用本身的代码，或者在于应用服务器，但实际上，性能与这两者都有着密切的关系。应用的代码写得再好，如果应用服务器的配置不当，性能也不会好；同样地，应用服务器调整得再好，也难以掩盖应用代码中存在的缺陷。因此，首先要保证应用有一个稳固可靠的体系结构，有最优质高效的代码，在此基础上再来集中精力调整应用服务器。 ■ 应用 就优化性能而言，应用本身的优化属于最艰巨的步骤之一。首先要深入地分析业务逻辑，然后找出满足业务需求的最优解决方案。每一个业务领域都有其与众不同的特点，因此也不存在适用于所有业务领域的万能解决方案。然而，人们在实践中总结出了许多优秀的设计模式，在规划应用的体系结构时合理选用设计模式对性能大有好处。 ■ 应用服务器 选择应用服务器需要考虑许多因素，至少包括：应用服务器的价格，硬件部署，应用服务器厂商的表现，性能，等等。本文后面的讨论主要针对下面四种服务器：BEA WebLogic 7，IBM WebSphere，Oracle Application Server，JBoss。 ■ 平台：硬件和JVM 应用开发完毕、服务器选定之后，还要考虑操作系统和Java虚拟机的配置选项，适当地调整这些选项无疑也能够提高性能。 ■ 后端资源 许多J2EE应用需要访问后端资源，例如关系数据库。虽然后端资源的优化已经超出了J2EE的领域，但它决不是一个可以忽略的问题。即使应用在其他方面都做得很好，如果后端数据库总是迟迟不能响应，应用的整体性能必将大受影响。 结束语：本文的目标是阐明性能优化的具体含义，即提高应用支持的并发用户数量、吞吐量和稳定性。同时，本文还介绍了性能优化应当从哪些方面入手。在下一篇文章中，我们将从方法学的角度探讨J2EE的性能优化问题 |