WAS 调优之路(一)

2003 年 11 月 01 日

部署在WAS上的J2EE应用程序，其性能是由多个因素决定的。例如网络、数据库、内存分配、WAS服务器的配置以及应用程序的设计。本文主要讲述了WAS性能优化的一些常见因素和通用方法。
概述


部署在WAS上的J2EE应用程序，其性能是由多个因素决定的。例如网络、数据库、内存分配、WAS服务器的配置以及应用程序的设计。本文主要讲述了WAS性能优化的一些常见因素和通用方法。

在本文开始前，我想说的是，性能调优不是起死回生的灵丹，好的性能源自好的代码设计。一般说来，性能调优大概可以提高10％－40％效率，而糟糕的代码设计却会使得性能几倍的下降。

队列(Queue)的性能调优


对于一个标准的J2EE应用，一个请求到来时，往往需要经过多次转发：网络->Web服务器Web容器->EJB容器->数据库。而每一次转发，都可能造成请求处理的瓶颈，使得应用程序整体性能下降。

本文中，我们把每一次转发的待处理资源都看成一个队列，如图一：


图一：WAS队列


对于WAS调优，要记住的一个基本原则就是，使得在队列中等待的请求的数量最小化。在实践中我们发现，为了达到这个目的，最有效的配置方式就是使得队列成为一个"漏斗"。也就是说，越靠近客户端的队列，其容量越大，而后面的队列，其容量要略小于或等于前面的队列。

让我们举个例子来说明一下，现在有200个并发用户请求到达。

首先，我们要设置的是WebServer的最大并发用户，这个设置是在conf/httpd.conf这个文件里面配置的。在Unix系统中，对应的属性是MaxClient；在Windows系统中，对应的属性是ThreadsPerChild。如图二：我们设置ThreadsPerChild75：


图二：Http服务器并发用户配置




其次，我们要设置Web Container的最大并发用户，Web Container维护着一个线程池，用来处理接受到的jsp/servlet请求，我们将依次点击Servers->Application Servers,然后选择需要的server，接着点击Additional Properties->Web Container->Thread Pool，如图三，我们将设置相应的线程池大小,把最大值设为50：


图三：Web容器线程池配置




然后，我们要来设置对象请求代理（ORB）的线程池大小。我们将依次点击Servers->Application Servers,然后选择需要的server，接着点击Additional Properties->ORB Service->Thread Pool，如图四，在这里我们将可以设置线程池的大小，把最大值设为50；同时，在这里也可以设置线程池自增长功能，点选Growable thread pool选项，使得即使设置了最大的线程池大小，当并发的EJB请求过多，线程池的大小还是可以超过预先设置的最大值。


图四：ORB线程池配置




最后，我们还要来设置数据库的连接池属性。在Resource项下面，点击JDBC Providers->DB2 JDBC Provider->Data Source，选择对应的JDBC连接，进入Connection Pools选项，在这里可以设置数据连接池的最大和最小值，我们将把最大值设置为25，如图：


图五：JDBC线程池配置




做了这么多修改后，千万不要忘记保存设置。如下图，点选Save后会出现一个确认窗口，让你确定是保存所有修改还是放弃所作修改。


图六：保存配置的修改




到目前为止，我们所有的操作都遵循一个原则，那就是让并发用户的等待尽可能停留在网络传输和Web服务器上，而让所有到达WebSphere应用服务器的客户请求能够很快的被执行。经过我们的配置，用户消息到达后，形成的队列如图七所示：


图七：Was 队列等待




JVM堆参数设置的性能调优


可以在WAS中配置JVM的堆大小。对于不同的应用程序，最优化堆大小的设置都有可能不同。堆设置过大，会占用过多的内存，使内存资源耗尽，从而会频繁的进行IO操作来使用虚拟内存。堆设置过小，会使得对象可分配空间变小，从而会频繁的使用垃圾收集机制来释放内存空间，而每次垃圾收集，都会耗用一定的系统资源。应此，我们要通过试验和监控数据，设法使的我们所设置的堆大小能够使得我们的程序运行最优化。我们将依次点击Servers->Application Servers,然后选择需要的server，接着点击Process Definition->Java Virtual Machine，如图，在这里我们就可以设置初始堆大小和最大的堆大小。


图八：Java虚拟机内存堆设置




ORB参数调用方式的性能调优


在EJB1.1的规范中，要求远程方法一律使用参数值传递方式来调用，即在每次方法调用的时候，把参数的值Copy入调用堆栈。这样，如果参数对象比较大的话，这么做的代价无疑是很昂贵的。如果调用EJB的Servlet或者其它EJB是部署在同一个应用服务器下，那么它们是共享一个JVM的，也就是说可以使得函数调用的方式变为参数引用传递，这样的话，视参数对象的复杂程度而定，可以提高5%-50%的函数调用效率。我们将依次点击Servers->Application Servers,然后选择需要的server，接着点击Additional Properties->ORB Service，如图九，我们可以通过点击 Pass by reference 选项来调整ORB的参数传递方式


图九：ORB引用方式的修改




关于上面的调优，我们要注意两点：

1. 当传递的参数是原始数据类型，如int，char，那么性能不会得到优化。

2. 如果参数接收者对参数进行修改，那么使用参数引用传递会带来很多意想不到的问题。为此，IBM开发了一个工具CmpOPT，用来测试使用参数引用传递方式调用一个EJB是否安全。这个工具的相关帮助文章可以在 http://www.ibm.com/developerworks/ibm/library/i-optimize上看到。


关闭动态加载开关


动态加载是一个很有用的功能，它可以使得我们在程序运行的时候动态更新servlet文件，web容器能够自动识别这种更新，并且重新载入新的servlet类。在我们进行程序的调试和开发时，这项技术能够给我们带来很大的方便，避免了我们频繁的重启应用服务。但是，这种方便性是以牺牲性能为代价的，服务器为了监视文件是否更新，需要耗费一定的系统资源。而对部署的程序来说，一般程序不会进行改动了，因此，我们应该把这个开关关闭。

在Applications项下面，点击Enterprise Applicaton，选择一个应用程序，然后把Enalbe class reload选项取消：


图十：动态加载设置




关闭会话序列化


WAS可以把会话信息序列化存入数据库，对于集群和克隆的WAS服务器来说，这一特性是建议启用的。与在内存中保存会话信息相比较，启用这一特性会降低WAS的性能。因此，如果你不想持久化你的会话，可以把该选项关闭。在Applications项下面，点击Enterprise Applicaton，选择一个应用程序，然后在其它属性里面选择Session Manage，在配置的最后一行点选其它属性->分布式环境设置，然后可以选择是否在数据库中保存会话：


图十一：会话持久化设置




小结


本文是WAS调优系列的第一部分，主要讨论了利用WAS服务器参数的调整来优化应用程序的性能。在接下来的部分，我们将会讨论如何通过控制代码的质量来提高基于WAS的应用程序的性能以及如何利用Tivoli来监控系统的性能，诊断程序运行的瓶颈，从而对参数做出相应调整来提高系统性能。