一次Weblogic JMS集群调优

问题背景：如何对Weblogic JMS集群进行调优。

调优参考指标：

对于Weblogic JMS集群的性能调优，在如下这篇文章中有一些总结：
1. 增加-Dweblogic.JMSThreadPoolSize=n(至少为5),以提高处理JMS的线程数,在
jRockit上增加-XXenablefatspin以减少加锁冲突;
2. 采用文件存储策略,将同步写策略设置为Direct-Write,同时在windows平台上启用磁盘写入缓存;
3. 使用分布式目的地时,激活连接工厂Load Balancing Enabled ,Server Affinity Enabled;
4. 为减少服务器不必要的JMS请求路由,如果多个目的地之间存在事务,则部署在同一JMS服务器上,尽量将连接工厂部署到JMS服务器所在的WebLogic实例上,集群环境下，则最好将连接工厂部署到集群中的所有服务器上,而集群中每个JMS服务器和目的地成员尽量使用类似的设置；
5. 启用消息分页存储功能,以释放内存,可以为JMS服务器和目的地设置, 激活Messages Paging Enabled和Bytes Paging Enabled,同时使用限额防止服务器耗尽接收消息的所有可用内存空间;
6. 在运行WebLogic Server进程之外的生产者务必使用流控制, 并增大Send Timeout;
7. 将JMS Server Expiration Scan Interval设很大的值，能禁止主动扫描过期消息;
8. 使用FIFO或者LIFO方式处理目的地消息;
9. MDB的max-beans-in-free-pool不应大于最大MDB线程数(默认线程数/2+1)。

对于web应用服务器和后台处理服务器：

监控服务器资源，发现集群平台服务器负载并不高，而web应用服务器负载同样也不高，服务器性能并没达到瓶颈。进入weblogic控制台，查看线程池，发现在压1000并发的时候，请求积压队列明显较多，而线程数只有50左右。说明一下，weblogic产品模式下，默认初始线程数为25，开发模式下好像是15，weblogic11g采用的是自调整线程池，看名字就可以猜出，他会根据应用情况自动增加减少线程数，而实际情况下，在压力增大的情况下，weblogic也确实增加了线程数，但是增加的线程数不足以应付该需求，于是自然而然地想到了增加线程数。

1.增加前台Weblogic服务器和后端Weblogic服务器内存和线程数。一般原则为一个cpu对应50个线程。

weblogic11g已经不支持在控制台修改线程数，只能通过配置文件，网上有朋友说可以通过增加weblogic启动参数来配置线程数: 
-Dweblogic.threadpool.MinPoolSize=100 
-Dweblogic.threadpool.MaxPoolSize=500 
该方法经试验，并不能生效，还好还一种方法，修改域下面conf里面的config.xml文件： 
<server> 
<name>AdminServer</name> 
<self-tuning-thread-pool-size-min>400</self-tuning-thread-pool-size-min> 
<self-tuning-thread-pool-size-max>400</self-tuning-thread-pool-size-max> 
<listen-address/> 
</server> 
在这里把线程数最大值最小值都设成了400，400这个数值不是乱设的，WebLogic可以近乎线性地提高线程数。线程数越多，花费在线程切换的时间也就越多；线程数越小，CPU可能无法得到充分的利用。为获取一个理想的线程数，需要经过反复的测试。一般来说一个CPU最好小于50个线程数

2.在后台Weblogic服务器工程中，对JMS消息的处理启动多线程。

3.JDBC连接池限制

如果网络和数据量都没有问题，则会考虑交易到数据库的连接数是否有限制，和数据库操作的那些交易的SQL请求根本没有到达数据库服务器。我们可以通过中间件的控制台查看JDBC的最大容量（此连接缓冲池可容纳的最大物理连接数）

4.1数据库JDBC连接池限制，设置的本来就小，weblogic默认最大容量为50。

4.2如果一台应用服务器上是多路进行部署的话，查看各路JDBC连接是否均衡

调优原则：

1、出现性能瓶颈时，先找出现瓶颈的地方，是应用服务器还是数据库服务器 
2、判断是否需要修改weblogic线程数以及数据库连接池的值 
3、多次测试，得出一组合适的weblogic线程数的值以及数据库连接数的值