WebLogic Server 性能优化 (2) JDBC连接池篇

JDBC连接池是J2EE应用最常用的一个服务，JDBC连接池的设置相对比较简单一些。JDBC连接池的设置最主要的是Intial Capcity和Maximum Capacity两个属性。下面对于JDBC连接池的几个属性及优化配置方案进行描述：

Initial Capacity: 初始容量，即WebLogic Server在建立连接池的时候创建的连接数量

Maximum Capacity: 最大容量，即WebLogic Server允许的在这个连接池中的连接的最大数量。

通 常，初始容量和最大容量设置为相等，并且不小于执行线程的数量。如果你的应用中配置了自定义执行线程队列，那么就要计算全部的用来给应用工作的线程的数 量。如此设置才能够起到Pool的作用，避免在应用运行过程中出现创建JDBC连接的请求。因为创建JDBC连接对于WebLogic Server和数据库服务器来说，都是开销比较大的动作。如果应用中存在在一个线程中获取多个连接的情况，那么初始容量和最大容量应该大于执行线程的数 量，甚至需要成倍增加。比如下面的JSP代码就会导致一个线程工作占用2个连接：

ctx = new InitialContext();
ds = (DataSource)ctx.lookup(”lab.ds.pbjade”);
conn = ds.getConnection();
// do some query operations

conn2 = ds.getConnection();
// do some query operations

以 上这段代码，在执行过程中，第一个连接conn关闭之前，又获取了第二个连接conn2，这样一来，这个JSP页面在执行的时候（由一个线程来执行），会 同时获取2个连接，连接池容量的最优化设置是执行线程的数量的2倍。因为在极端情况下，如果在同一时刻，所有的请求都指向这个页面，那么就需要执行线程数 量2倍的连接才不会出现连接等待。

Capcity Increment: 增长步长。如果初始容量和最大容量不相等，并且需要更多的连接时，WebLogic Server一次建立新连接的数量。

Allow Shrinking: 允许自动收缩。如果连接池的初始容量和最大容量不相等，那么当池中的连接大于初始容量时，经过Shrink Frequency时间，如果连接池中的活动连接不高于初始容量个，那么连接池中连接的数量会减少到初始容量大。

上面这几个参数是配置相关的，通常Initial Capacity=Maximum Capacity 并且>=执行线程的数量，并且不选择Allow Shrinking选项，避免不必要的周期检查。

如 果WebLogic Server和数据库服务器之间的网络连接不稳定，或者两个服务器之间存在防火墙，导致JDBC连接不稳定，WebLogic Server还提供了一些测试策略以尽量保证应用难道的连接是有效的。主要有3个选项：Test Reserved Connections、Test Created Connections、Test Released Connections。测试的时机分别是应用获取连接、WebLogic Server创建连接、应用释放连接。通常这3个选项只需选择Test Reserved Connections即可，无需全部选择。根据测试数据，可能会有3%左右的性能下降。所以如果不是必要，也不必使用这些选项。

在 使用JDBC连接池的过程中，最常见的一个问题就是连接池泄漏问题。一个池里面的资源是有限的，应用用完之后应该还回到池中，否则池中的资源会被耗尽。 WebLogic Server提供了一个Inactive Connection Timeout选项，默认是60秒，如果一个连接被应用拿走之后，超过这个时间还没有还回来，WebLogic Server会强制将这个连接回收。如果应用中不存在连接泄漏的问题，则不需要这个选项。设置为0即可禁用。

总结一下，连接池的设置相对比较简单，主要是初始容量及最大容量两个参数。其他的选项不需要的可以去掉，避免不必要的性能开销。