消息确认间隔不应设置得过短?D?D发送确认的比率越大，处理消息的速度可能会越慢。同时，如果设置得过大，则意味着系统发生故障时，消息会丢失或者被重复发送。
　　一般说来，应在单个服务器上对多个JMS目的地进行配置，而不是将它们分散在多个JMS服务器，除非不再需要扩展。

　　关闭消息页面调度(paging)可能会提高性能，但会影响可扩展性。如果打开消息页面调度(paging)，则需要额外的I/O操作以便将消息串行化到硬盘，在必要的时候再读进来，但同时也降低了对内存的要求。

　　一般来说，异步过程比同步过程更好操作，更易于调节。

　　Web容器

　　Web层在应用中更多的是用来生成表达逻辑。广泛使用的体系结构是从应用层读取数据，然后使用servlet和JSP生成动态内容，其中应用层一般由EJB组成。在这种结构中，servlet 和JSP保留对EJB的引用，以防它们与数据库或数据源直接对话。将这些引用保存起来是个不错的主意。如果JSP和servlet没有和EJB部署在同一台应用服务器上，则利用JNDI进行查询的费用是很昂贵的。

　　JSP缓存标记符可以用于存储JSP页面内的数据。这些标记符都支持对缓存的输入和输出。对缓存的输出涉及到标记符内的代码所生成的内容，对缓存的输入涉及到标记符内的代码对变量的赋值。如果不希望Web层频繁变化，则可以通过将ServletReloadCheckSecs 设置为-1，从而关闭自动装载(auto-reloading)功能。使用这种方法以后，服务器将不再轮询Web层是否有变化，如果JSP和servlet的数量很多，则效果是非常明显的。

　　这里也建议不要在HTTP会话中储存过多的信息。如果信息是必须的，可以考虑使用有状态会话bean来替代。

　　JVM调试

　　如今的大多数JVM具有自主调节功能，因为它们能够探测到代码中的危险区域并对它们进行优化。开发和部署人员能够考虑的调试参数大概就是堆设置了。设置这些并没有一般的规则。JVM一般堆空间，按新空间或保留空间一般设置为整个堆空间的三分之一或一半组织。整个堆空间不能指定得过大以致于无法支持并发的内存垃圾回收(GC)处理。在这种设置环境中，如果堆太大的话，垃圾回收的间隔应设为一分钟或更长。最后，需要引起注意的是这些设置在很大程度上依赖于部署在服务器上的应用使用内存的模式。有关调试JVM的其它信息可以参考:

　　服务器调试

　　除了由各个子系统提供的调试参数以外，还有适用于服务器的参数能够帮助提升性能。其中最重要的是配置线程数和执行队列数。增加线程数并非总能奏效，仅当下列情况成立时再考虑使用这种方法:预定的吞吐量没有达到;等待队列(未开始处理的请求)过长;CPU仍有剩余。当然，这样做并不一定能改善性能。CPU使用率低可能是由于对服务器的其它资源竞争所致，如，没有足够的JDBC连接。当改变线程数时应考虑到这些类似的因素。

　　在WebLogic Server 7.0中，提供了配置多个执行队列的功能，并且能够在部署中定义处理特殊的EJB或JSP/servlet请求的执行队列。要做到这些，只要在运行weblogic.ejbc时将标志-dispatchPolicy <队列名称> 传送给bean 即可。对于JSP/servlet，可将设置Web应用的weblogic部署描述符中初始化参数(init-param) wl-dispatch-policy的值设为执行队列的名字即可。有时应用中的某些bean/JSP对操作的响应时间比其它的要长，此时，可以对这些bean/JSP设置单独的执行队列。至于队列的大小，要达到最好的性能，还取决于经验。

　　另一个比较大的问题是决定在何种情况下应该使用WebLogic性能包(http://e-docs.bea.com/wls/docs70/perform/WLSTuning.html - 1112119)。如果socket数不太多(每个服务器上都有一个socket用于客户端JVM的远程方法调用连接)，而且总是忙于读取从客户端发送过来的请求数据，那么此时使用性能包恐怕不会有明显的改进。也有可能不用性能包会导致相似或更好的结果，这取决于JVM在处理网络I/O时的具体实现。

　　Socket读取线程取自缺省执行队列。在Windows 环境下，每个CPU有两个socket读取线程，在solaris环境下，共有三个socket用于本地输入输出(native I/O)。对于Java 输入输出(I/O)，读取线程数由配置文件config.xml中的参数PercentSocketReaderThreads 进行设置。它的缺省值是33%, 上限是50%，这是显而易见的，因为如果没有线程用于处理请求，则同样不会有更多的读取线程啦。对于Java I/O，应使读取线程数尽量接近客户端连接数，因为在等待请求时，Java I/O会阻塞。这也是为什么当客户端的连接数增加时，线程数不能一直同等增加的原因。

　　结论

　　我们上面只讨论了调试服务器的部分方法。需要记住的是，一个设计蹩脚，编写欠佳的应用，通常都不会有好的性能表现，无论对服务器及其参数如何调试。贯穿应用开发周期的各个阶段从设计到部署，性能始终应该是考虑的关键因素。经常发生的情况是性能被放在了功能之后，等到发现了问题再去修改，已经很困难了。