WebLogic Server 性能优化 (1) 执行线程篇

qinling072

　　说实话，执行线程的设置没有什么准确的计算公式，一切都得依赖测试和实际的运行情况。设置少了，会有等待队列；设置多了，性能也未必高。但是，对于调优，我还是建议先不足再增加，即先少后多。通常情况下，如果一开始就把各种资源设置的很高，那么很可能问题就被掩盖了。如果设置的少，当出现故障时会有比较明显的表征。
　　虽然没有计算公式，但是根据经验值，一颗CPU可以配置25-30之间的执行线程，当然，也有人说可以按照50线程/CPU计算。这个经验值的前提是，主机上没有其他的大型的占用资源较多的应用在运行。也就是说，一台主机上WebLogic Server实例，无论是一个，还是多个，他们的执行线程的总和大概是25*CPU数量到30*CPU数量之间。我经历过一个应用的压力测试，4CPU的 HP主机，同样的测试脚本，在不同的执行线程配置下进行测试和比较。结果是配置50和120的时候，TPS在300左右，当配置70的时候，能够达到 400左右。有可能70也不是最好的，但是至少说明执行线程的配置不是越多越好。
　　说到这里，想起来另外一个比较常见的问题，就是设置的执行线程的数量还算合适，没有过高也没有过低，但是就是在压力测试的时候，发现TPS值很低，CPU的利用率也上不去。我遇到的有两种情况：
　　1. 操作系统的补丁问题
　　在HP-UX上执行大型Java应用，需要打上很多的补丁，在HP的官方站点可以查到
　　http://www.hp.com/products1/unix/java/patches/index.html
　　其中有一个补丁包就是和线程调度相关的，如果不打上这些补丁，那么对于Java的线程调度存在问题，导致CPU利用率也不高，但是执行效率较低，甚至可能导致进程Crash。所以在安装软件之前去官方网站查看所需要的补丁以及经过认证的相关产品是一个好习惯。
　　2. 同步代码
　　如果代码中存在同步方法，并且是调用率比较高的，那么可能会出现CPU利用率低并且TPS也低的情况。通常Java应用自身的同步代码并不是很多，但是所用到的一些扩展的包，就有可能用到了同步代码。最典型的一个例子是Log4j. 给出一个示例的Thread Dump
　　“ExecuteThread: ‘152′ for queue: ‘weblogic.kernel.Default’” daemon prio=1 tid=0×08d9fef8 nid=0×1f28 waiting for monitor entry [5a1fd000..5a1fe24c]
at org.apache.log4j.Category.callAppenders(Category.java:185)
- waiting to lock <0×838664b0> (a org.apache.log4j.spi.RootCategory)
at org.apache.log4j.Category.forcedLog(Category.java:372)
at org.apache.log4j.Category.info(Category.java:674)
　　…
　　152号执行线程在等待<0×838664b0> (a org.apache.log4j.spi.RootCategory) 对象被其他线程释放同步锁。在完整的Thread dump中可以看出，有大量的线程都在等待同一个对象。这个对象被158号线程使用：
　　“ExecuteThread: ‘158′ for queue: ‘weblogic.kernel.Default’” daemon prio=1 tid=0×08da4d28 nid=0×1f28 waiting for monitor entry [59efd000..59efe24c]
at java.lang.StackTraceElement.toString(StackTraceElement.java:130)
at java.lang.String.valueOf(String.java:2131)
at java.lang.StringBuffer.append(StringBuffer.java:370)
- locked <0xa32e5370> (a java.lang.StringBuffer)
at java.lang.Throwable.printStackTrace(Throwable.java:512)
- locked <0xa326af28> (a org.apache.log4j.spi.VectorWriter)
at org.apache.log4j.spi.ThrowableInformation.getThrowableStrRep(ThrowableInformation.java:50)
at org.apache.log4j.spi.LoggingEvent.getThrowableStrRep(LoggingEvent.java:333)
at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:295)
at org.apache.log4j.WriterAppender.append(WriterAppender.java:150)
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:221)
- locked <0×83866430> (a org.apache.log4j.ConsoleAppender)
at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:57)
at org.apache.log4j.Category.callAppenders(Category.java:187)
- locked <0×838664b0> (a org.apache.log4j.spi.RootCategory)
at org.apache.log4j.Category.forcedLog(Category.java:372)
　　由于Log4j的同步代码导致出现上述的问题。所以，如果不是为了跟踪问题，尽量将Log4j的日志级别设置的高一些。减少同步代码的调用，能够极大的利用硬件资源。
　　如果一个应用中有部分页面执行时间较长，并且使用频率较低，可以为这些JSP/Servlet或者EJB配置独立的执行线程（当然了，尽量优化应用才是治本之道），将执行效率低下的放到一个执行线程队列，将效率高的放到一个执行线程队列，这样就避免因为一个执行效率低的页面影响整个应用了。
　　下面是简单的步骤说明：
　　1. 配置整个Web应用到单独的执行队列
　　编辑web应用的weblogic.xml，加入<wl-dispatch-policy>节点： <wl-dispatch-policy>yourexecutequeue</wl-dispatch-policy>
　　2. 配置JSP/Servlet到单独的执行队列
　　如果是JSP，编辑web应用的web.xml，加入一个<servlet>节点
　　<servlet>
<servlet-name>myServlet</servlet-name>
<jsp-file>/context/package/file.jsp</jsp-file>
</servlet>
　　然后在weblogic.xml中对这些Servlet进行配置
　　<servlet-descriptor>
<servlet-name>the servlet name or the servlet for the jsp file</servlet-name>
<dispatch-policy>your customized queue name</dispatch-policy>
</servlet-descriptor>
　　3. 配置EJB到单独的执行队列
　　编辑weblogic-ejb-jar.xml，例如：
　　<weblogic-enterprise-bean>
<ejb-name>Hello</ejb-name>
<jndi-name>lab.ejb.Hello</jndi-name>
<dispatch-policy>your customized queue name</dispatch-policy>
</weblogic-enterprise-bean>
　　详细可以参考：
　　Developing Web Applications for WebLogic Server http://edocs.bea.com/wls/docs81/webapp/index.html
　　Programming WebLogic Enterprise JavaBeans http://edocs.bea.com/wls/docs81/ejb/index.html