J2EE应用服务器性能优化方法研究

金思轶

（杭州师范大学钱江学院 计算机科学与技术专业，浙江 杭州 310012）

1 引言

J2EE是一种利用Java 2平台来简化企业解决方案的开发、部署和管理相关的复杂问题的体系结构。不同的J2EE应用服务器都有对应的具体的参数可供调整，一些J2EE应用服务器的供应商都提供一些应用指南，然而关于应用服务器资源如何优化的相关研究则很少。

2 影响J2EE应用服务器性能的关键因素

J2EE应用服务器是多模块、多线程、分布式的程序，因此影响性能的因素是多方面的，而且各因素间是相互影响，综合关联的。

2.1 Java虚拟机堆设置

任何Java应用的性能调整基础都涉及到堆的大小和垃圾回收设置。堆可分为三代，年轻的(新的)、年老的和持久的。当配置最大堆大小时可参考下面一些指导:最大大小应小于物理内存，避免虚存的页面调度。在负载测试时进行优化，需要减去其他进程使用的内存。注意不要将最大堆大小设置得过大。堆越大，内存中保存的对象越多。内存中对象越多，回收过程时间越长。配置初始堆大小的一般性策略包括:将初始大小设置为最大堆大小的1/4到1/2，对于年轻一代堆大小，Sun推荐是设置为最大堆大小的1/3。

2.2 处理线程池大小

由于应用服务器能够同时为多个并发的用户请求提供服务，而创建线程又是一项昂贵的操作，所以应用服务器必须通过一个线程池来处理各种请求。一些应用服务器把这个线程池一分为二:其中一个用来处理进入的请求，把请求放入队列;另一个从队列获取线程，然后执行调用者要求执行的处理任务。不管具体的实现方式是哪一种，线程池的大小限制了应用服务器的工作量，所以必须找出一个最佳的平衡点-如果超越这个平衡点，则线程的上下文切换(将CPU依次分配给各个线程)将产生大量开销，从而影响性能。很多应用服务器允许为特定的任务或应用配置不同大小的线程池。通常需要增加这些线程池的大小以满足应用负载的需要。线程池的设置不能过小，也不能过大，这是因为设置过大会增加上下文交换的次数，从而降低应用的性能。线程池的大小通常应该能最大利用机器上的CPU，同时又不能使CPU过载。

2.3 数据库连接配置

对于数据库连接，所有的应用服务器都提供缓冲池机制。在应用程序中创建数据库连接是一项开销很大的操作，通常要耗费0.5到2秒的时间。因此应用服务器缓冲了数据库连接，使得不同的应用程序、同一应用程序内的多个线程能够共享一组数据库连接，避免每次需要数据库连接时都从头开始创建连接。通过连接池使用数据库连接的一般的过程为:当某个线程需要访问数据库时，它向数据库连接池请求一个连接，然后用连接池返回的连接执行数据库操作 (例如SELECT或UPDATE,DELETE命令)，操作结束后再把数据库连接对象返回给连接池，以便其他组件使用该连接。

3 J2EE应用服务器性能评测标准

性能测试的原理主要是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。通过模拟上千万用户的实施并发负载及实时性能监测的方式来确认和查找问题。

性能标准依赖于所测试的应用程序类型。基于J2EE平台的应用程序一般分为两个基本类别:交互式的应用程序和批处理或后端应用程序。

3.1 对于交互式应用程序，即终端用户与应用程序同步交互，性能一般是通过大小和规划问题的容量来定义，性能评测标准可以是一个最大可接受的响应时间，这就是在得到应用程序响应之前客户愿意等待的最大时间数量。

3.2 对于批处理或后端应用程序，即不需要直接与终端用户交互，性能评测标准是每秒事务处理最小可接受的吞吐量。事务处理在具体的场合定义可能有所不同。比如对于Servlet，事务处理可能为一个请求;而对JMS，吞吐量可能就是消息。性能标准的定义分别如下:

响应时间RT(Response Time):客户端从发送请求的那一刻起到收到应用程序响应的最后一个字节时而不得不等待的时间长度。

平均响应时间ART(Average Response Time):某个特定请求所有用户响应时间的算术平均。

最大平均响应时间MART (Maximum Average Response Time):一个测试脚本中所有单独的平均响应时间中最高的值。

吞吐量:每秒处理的事务数量(Transactions Per Second,RPS)。

拒绝率(Reject Rate):为了保证已连接客户的性能，而不得不能提供服务的客户数目。

每种度量标准都需要结合一个规定的用户负载，比如性能评测标准为400个用户负载最多3秒的最大响应时间。

4 应用服务器资源优化方法

4.1 基于策略方法

系统管理员编写策略，如:事件一条件一动作(ECA)的规则集合。当一些前置条件被满足时，就会触发这些规则(通常一个或多个系统的可观察的变化超出管理员定义的阂值)。基于规则的方法是建立在Hewitt模式导向范式。模式非常类似事件一条件定义。在不同的系统状态下，规则集作为“打包的处方”决定怎样调用正确的动作。运行时，管理模块只调用合适的规则基于事件和系统条件。只有拥有多年丰富经验的专家如系统架构设计者和管理者才能编写管理规则。然而随着系统变得更复杂，即使专家也会遇到以下类型的问题，设计强鲁棒性的自动管理框架相当困难的。

复杂性:编写规则集合是非常困难的工作。原因如下:(1)从大量可能的观察集合中难以选择适宜的系统参数配置。(2)在考虑各类系统变量的交互后难以确定恰当的阂值。(3)从大量的竞争选择选项中难以选择详细而清晰的动作。

脆弱性:系统厂商无法为自身的产品提供预先打包的ECA规则集。规则集与变化的系统配置、用户工作负载、商业约束间的关系是非常脆弱的。更新和操作规则语意不是容易的事。预先构思各种运行场景及对应的规则是有难度的。

4.2 基于经验方法

传统上应用服务器的性能调优没有更好的办法，更多的时候都是依靠配置人员的自觉、经验和实践来决定资源和参数的配置。为此一些商家还专门出了对应的白皮书，给出推荐的参数设置值。经验方法是通过一系列的测试标识不同配置参数集的情况下的系统性能瓶颈和系统特性。测试是一个需要反复进行的过程:第一次只能从一个看起来似乎不错的配置开始，一般参数的取值可使用系统默认值，或由软件供应商提供的指导，然后测试、分析系统，再根据测试结果调整、配置系统，具体寻找好的配置的步骤如下:

为每个参数选择分配合理的区间，如:JVM最大堆栈区间，我们推荐的范围是256-512M；每个参数的具体值从参数的区间随机生成；使用从步骤2中得到值部署应用；对应用服务器进行负载测试，并度量其性能数据，如:响应时间和吞吐量；如果需要，重复上述步骤。

该方法之所以有效，是因为同一组参数多次测试，性能情况都差不多;因此不同参数获得不同性能，可以认为是参数配置而引起的，从而可以发现问题所在和选取有效的参数配置。但这种测试方法需要时间长，试验次数多。因此为减少测试的次数，加快寻优的步伐，可采用优化抽样、搜索算法与少量测试结合的方法寻找最佳配置集。总之经验方法为应用服务器参数静态优化提供较好的途径，然而此方法不能解决应用服务器在线动态调优。

4.3 基于反馈控制方法

在反馈驱动的方法中，OAA框架基于收敛或背离于管理员所定义单个或多个性能度量值的目标，对控制柄反复迭代调整。例如:如果OAA框架正设法为J2EE应用服务器维持某个管理员指定的响应时间，对系统当前的响应时间与一些目标响应时间比较的前提下，OAA框架必须对调节柄反复控制。基于反馈的解决方案中，使用了一系列古典的控制理论技术(如简化启发式探试学和估计技术)确定特定的控制柄集合。OAA框架评估调优后的效果，确定是否需要其他的调整。由于关于性能度量的结果被反馈到调整器，确定下一步的调整策略;所以观察和调整的动作构成了反馈循环。

[1]黄涛，一个面向QoS的Web应用服务器，软件学报，2004,

[2]谢希仁，计算机网络，大连理工大学出版社，2003