WebLogic 配置文件（config.xml）包含了大量很直观的与性能有关的参数，能通过配置环境与应用程序得到很好的优化。基于系统的需要调整这些参数不仅能改善单个点的性能，而且能提高整个应用程序性能的可衡量性。 试着采用下列WebLogic配置方法，或许能使你的系统达到最佳状态： 一 修改运行队列线程数的值。在WebLogic 中队列元素的线程数等于同时占用运行队列的应用程序的数目。当任务加入一个WebLogic 实例，它就被放到执行队列中，然后分配给任务一个线程来运行。线程消耗资源，因此要小心处理这个属性——增加不需要的值，会降低性能。 二，如果可能，使用自带的性能包（NativeIOEnabled=true）。 三，使用特定的应用程序执行队列。 四，使用JDBC连接池时，修改下列属性： n 驱动名称：使用小的驱动或者jDriver。 n 初始容量：设为与最大容量相同的值。 n 最大容量：其值至少应与线程数相同。 五，把连接池的大小设为与执行队列的线程数相同。 六，设置缓冲。 七，为Servlet和JSP使用多个执行队列。 八，改变JSP默认的Java编译器，javac 比jikes或sj要慢。 优化WebLogic 提要： n 为WebLogic启动设置Java参数。 n 设置与性能有关的配置参数。 n 调整开发与产品模式默认值。 n 使用WebLogic“自有的IO”性能包。 n 优化默认执行队列线程。 n 优化连接缓存。 n 如何提高JDBC连接池的性能。 n 设置Java编译器。 n 使用WebLogic集群提高性能。 n 监视WebLogic域。 一、为WebLogic启动设置Java参数 只要启动WebLogic，就必须指定Java参数，简单来说，通过WebLogic.Server域的命令行就可以完成，不过，由于这样启动的过程冗长并且易于出错，BEA 公司推荐你把这个命令写进脚本里。为了简化这个过程，你可以修改样例脚本里的默认值，样例脚本是提供WebLogic启动服务器的。 如果你用配置向导创建你的域，WebLogic启动脚本（startWebLogic.cmd）放在domain-name目录里。默认情况下，这个目录是BEA_HOME/user_projects/domain/domain-name，BEA_HOME表示安装路径，domain-name是在配置模板中设置的域名称。 你需要在这个脚本中修改一些默认的Java参数值，使之适合你的应用环境和程序。在这个文件中主要的性能参数是JAVA_HOME和Java堆的大小。 n 设JAVA_HOME的值为JDK所在的位置，如： set JAVA_HOME=C:/bea/jdk141_03 n 为得到高性能的吞吐量，把Java堆的最小值与最大值设为相等。如： "%JAVA_HOME%/bin/java" -hotspot -Xms512m -Xmx512m -classpath %CLASSPATH% - 二、设置与性能有关的配置参数 在一个WebLogic域中，配置文件（config.xml）位于与管理服务器通信的机器里，提供WebLogic MBean的长期存储。管理服务器作为连接的中心点，为服务实例与系统管理工具提供服务。域也可以包括其他的WebLogic实例，称之为从服务，主要为应用程序提供服务。 当启动管理服务器是，首先读域配置文件，然后跳过建立在配置文件中管理MBean 默认的属性值，每一次用系统管理工具（不管是命令行界面还是管理控制台）改变一个属性值，它都会被存到相应的管理MBean，并且写进配置文件。 下表列出了config.xml文件中影响服务器性能的参数。
| 元素 | 属性 | 控制台标签 | 备注 |
| Server | NativeIOEnabled | Native IO Enabled | |
| ExecuteQueue | ThreadCount | Thread Count | |
| ExecuteQueue | QueueLengthQueueLengthThresholdPercentThreadsIncreaseThreadsMaximumThreadPriority | Queue LengthQueue Length Threshold Percent（队列长限度百分比）Threads IncreaseThreads MaximumThread Priority | |
| Server | StuckThreadMaxTimeStuckThreadTimerInteral | Stuck Thread Max Time（堵塞线程的最长时间）Stuck Thread Timer Interval（堵塞线程的时间间隔） | |
| Server | ThreadPoolPercentSocketReaders | Socket Readers | |
| Server | AcceptBacklog | Accept Backlog（接受缓存数） | |
| JDBCConnectionPool | InitialCapacityMaxCapacity | Initial CapacityMax Capacity | |
| JDBCConnectionPool | StatementCacheSize | Statement Cache Size(声明高速缓冲大小) |
| 优化参数 | 开发模式 | 产品模式 |
| Execute Queue: ThreadCount | 15 threads | 25 threads |
| JDBC Connection Pool: MaxCapacity | 15 connections | 25 connections |
| 功用名称 | 开发模式 | 产品模式 |
| SSL | 你可以使用WebLogic安全服务提供的验证数字证书。有这些证书，你开发的应用程序会在SSL保护的环境下运行。 | 如果你使用验证数字证书，会收到警告信息。 |
| 部署应用程序 | WEBLOGIC实例会自动部署和更新位于domain_name/applications目录下的应用程序（domain_name为域的名称）。 | 不能使用自动部署功能，必须使用WebLogic控制台或者WebLogiceblogic Deployer工具。 |
| Log File Rotation | 启动服务器后，服务器自动重命名本地日志文件为server-name.log.n，为了滞留的session ，只要日志文件的达到500kb，日志文件就会滚转一次。 | 当日志文件达到500kb，就会滚转。 |
| Execute Queues | 默认的执行线程为15。 | 默认的执行线程为25。 |
| JDBC Connection Pool Capacity | 默认的容量为15。 | 默认的容量为25。 |
| 如果… | 结果 | 应该： |
| 线程数<CPU的数量 | 线程数太少，如果：CPU正等着工作，但有工作被完成。CPU利用率不能达到100％。 | 增加线程数。 |
| 线程数＝CPU的数量 | 理论上理想，但是CPU仍然低利用。 | 增加线程数。 |
| 线程数（适当的）>CPU的数量 | 实际中理想，有个适当的上下文转换程序数量和高的CPU利用率。 | 调整适当的线程数并且比较性能结果。 |
| 线程数（较大的）>CPU的数量 | 过多的上下文转换程序，能导致重大的性能降级。当你降低线程数时，性能可以增强。 | 减少线程数，使它等于CPU的数量，然后仅仅增加已经得出的“堵塞”线程的数量。例如，如果你有4个处理器，它们都同时运行，并出现堵塞线程，于是，你想要的执行线程就是4＋堵塞线程的数 |
<servlet-name>MainServlet</servlet-name>
<jsp-file>/myapplication/critical.jsp</jsp-file>
<init-param>
<param-name>wl-dispatch-policy</param-name>
<param-value>CriticalAppQueue</param-value>
</init-param>
</servlet> 5．7指派EJB和RMI对象到执行队列 为了把EJB分配到指定的队列，可以使用weblogic-ejb-jar.xml文件中dispatch-policy元素。 然而你也可以通过使用appc编译器－dispatchPolicy选项来设置派遣策略，BEA强烈推荐使用部署描述元素。因为用这种方式，如果EJB重编译，在部署用例期间，这个设置不会被丢失。 为了把RMI对象分配到指定的队列，可以使用rmic编译器的－dispatchPolicy选项，如： java weblogic.rmic -dispatchPolicy CriticalAppQueue ... 5．8分配执行队列担任Socket读 为了获得更好的socket性能，BEA 推荐你使用自有的socket读执行工具，它更优于纯Java执行工具。然而，如果你一定要在主机上用纯Java 的socket读，你仍然可以通过配置恰当的执行线程数以提高socket通信性能，为每个服务器实例和客户机器担负socket读线程的任务。 Socket读占线程池百分比（ThreadPoolPercentSocketReader）属性可以设置用来从socket读消息的执行线程的最大百分比。这个属性的最优值是根据应用程序的需要指定的。默认值是33，有效范围在1－99之间。 分配执行线程担任socket读增加了服务器处理速度和接受客户请求的能力。有必要平衡执行线程数，使其专注于从socket读消息，也有必要平衡那些在服务器处理实际任务的执行线程。 5．9为服务器实例设置socket读的线程数的操作 1． 启动管理服务器，访问域控制台。 2． 展开左边面板Servers节点，显示域服务配置。 3． 点击你要配置的服务名称。 4． 选择配置（Configuration）――>调整（Tuning）标签。 5． 在Socket Reader中编辑Java读线程的百分比。Java socket读线程数是根据所有的执行线程数的百分比计算得到的。 6． 应用（Apply）这个调整。 5．10在客户机设置Socket读线程数 在客户机上，你可以配置运行在JVM（Java虚拟机）上的socket读线程数。指定Socket读，需要通过用java命令行定义下列参数： -Dweblogic.ThreadPoolSize=value
-Dweblogic.ThreadPoolPercentSocketReaders=value 5．11优化溢出情况时的执行队列 你可以配置WEBLOGIC监测并且随时应对潜在的溢出，不管其发生在默认的执行队列还是用户定义的队列。一旦当前队列大小快达到用户定义的百分比，WebLogic认为队列中有一个可能的溢出产生。 当这个限度到达时，服务器改变它的良好状态为“警告”，随即分配额外的线程去处理超负荷的工作，从而还原它的大小。 为了自动监测和应对溢出，你可以配置以下项： 1． 队列长限制百分比，这个值是队列大小的百分比。 2． 当溢出发生时，增加到队列的线程数。这些额外的线程以还原队列到正常的运行的大小。 3． 线程的最大数，在特殊情况下，线程最大数用来保护服务器在响应过载情况下过度分配线程数。 5．12优化执行队列的监测行为 当一个线程在队列中变成堵塞状态时，WebLogic会自动监测到。因为堵塞线程不能完成它当前的工作或接受新的工作，服务器每次诊断一个堵塞线程，就记入一个消息到日志中。如果一个队列中所有的线程变成堵塞，服务器改变良好状态成“警告”或者“危机”，依赖于下列情况： n 如果默认队列中所有的线程变成堵塞，服务器状态变成“危机”。（你可以设立节点管理器（Node Manager）应用去自动关闭及重启服务器。） n 如果在weblogic.admin.HTTP, weblogic.admin.RMI或用户定义的队列中所有线程变成堵塞，服务器状态变成“警告”。 WebLogic诊断到一个堵塞线程，如果它是在指定的时间内连续不断的工作（没有空闲）。你可以调整服务器线程监测行为，它是通过改变堵塞线程被诊断前的时间长度和服务器核查堵塞线程的频率。 注意：尽管你能改变标准WebLogic去决定一个线程是否堵塞，但，你不能改变默认行为，就是出现堵塞时把服务器设置成“警告”或“危机”的行为。 配置WebLogic堵塞线程监测行为的步骤： 1． 启动WebLogic，访问管理控制台。 2． 点击你想为改善堵塞线监测而修改的服务器实例的名称。 3． 选择配置（Configuration）――>调整（Tuning）标签。 4． 修改下列参数： n 堵塞线程最大时间（Stuck Thread Max Time）：输入秒数，线程一定是不断的运行，服务器才会诊断这个线程作为堵塞。默认情况下，WebLogic认为线程连续不断运行600秒后置为堵塞。 n 堵塞线程时间间隔（Stuck Thread Timer Interval）：输入秒数，这个时间是WebLogic周期性的扫描线程以察觉它们是否连续不断运行了某一线程的时间达到通过堵塞线程最大时间属性指定的时间长度。默认时间间隔为600秒。 5． 应用（Apply）设置。 6． 重启服务器。 六、优化连接缓存 Config.xml文件中的元素接受缓存数（AcceptBacklog）属性是用来设定请求WebLogic实例的连接数，在拒绝额外的请求之前，能接受设定的缓存数。AcceptBacklog属性指定有多少TCP连接缓存在等待队列，这个固定的队列存放了TCP堆栈已经收到但应用程序还没有收到的连接请求。默认值是50，最大值由操作系统决定。 在控制台调整接受缓存数的步骤： 1． 启动WebLogic，访问控制台。 2． 展开左边面板Servers节点。 3． 点击你要配置的服务器实例的名称。 4． 选择配置（Configuration）――>调整（Tuning）标签。 5． 根据需要修改默认的接受缓存数（Accept Backlog）： n 在运行期间，如果许多客户端连接得不到响应或被拒绝，并且服务器端也没有错误消息，说明接受缓存的值可能太小。 n 在你访问WebLogic时，如果收到“拒绝连接（connection refused）”的提示，则应该增加接受缓存的默认值的25％。继续增加其值的25％，直到停止出现这样的提示。 6． 点击应用（Apply），保存设置。 七、如何提高JDBC连接池的性能 创建一个带DBMS的JDBC连接是非常慢的。如果应用程序需要数据库不断的连接和断开，这种创建方式会造成一个重大的性能问题。WebLogic连接池提供了一种高效的解决方案来解决这个问题。 当启动WebLogic，就打开连接池，以便于所有客户连接。当一个客户关闭一个连接，这个连接就返回到连接池，供其他的客户使用。连接本身不会关闭。如此就用极少的代价实现了连接和断开连接池。 在连接池里应该创建多少连接呢？连接池会根据配置参数中的最大数与最小数之间增加或减少连接。最好的性能应该是连接数与当前客户会话（Session）数相同。 7．1调整JDBC连接池的初始容量 在配置连接池时， JDBCConnectionPool元素中的InitialCapacity属性能设定连接数，创建物理的数据库连接。如果服务器不能创建这个连接数，连接池的创建就会失败。 在开发期间，为了使服务器启动更快，可以很方便的设置InitialCapacity属性的值小一点。在产品系统中，就应该把InitialCapacity的值设为与MaxCapacity值相同，默认产品模式的值为25。这样，在服务器启动时，所有的连接就会被创建。如果你调整了MaxCapacity值后，一定要确信InitialCapacity值设置与MaxCapacity值相同。 如果InitialCapacity比MaxCapacity值少，当负荷增加时，服务器需要创建额外的数据库连接。当服务器处于低负荷时，所有的资源应该是尽快的完成请求，而不是创建新的数据库连接。 7．2调整JDBC连接池的最大容量 JDBCConnectonPool元素中的MaxCapacity属性设置连接池包含的最大的物理数据库连接数。不同的JDBC驱动程序和数据库服务器可能限制物理连接数。 默认的最大容量数与默认的线程数相等：开发模式为15，产品模式为25。不过，在产品模式下，建议连接数与当前的客户会话（Session）数相等。在服务器端，连接池的容量与执行线程数是无关的，正在进行的用户会话比执行线程更多。 八、设置Java编译器 编译JSP Servlet的标准Java编译器是javac。你可以把java编译器设置为si或jikes代替javac，这样能极大的提高性能。下面讨论设置步骤及其要考虑的事项。 8．1通过控制台改变编译器 1． 启动服务器，访问控制台。 2． 展开左边面板Servers节点。 3． 点击要配置的服务器实例的名称。 4． 选择配置（Configuration）――>常规（General），在Java Compiler编辑框输入编译器的完全路径。如：c:/visualcafe31/bin/sj.exe 5． 点击高级选项（Advanced Option）――>Show，显示其他的属性。 6． 用添加（Append）把完全路径通过Classpath框输入到JRE rt.jar 库。如：BEA_HOME/jdk141_02/jre/lib/rt.jar 7． 点击应用。 8． 重启服务器。 8．2在Weblogic.xml文件中设置编译器 n 使用compileCommand参数指定Java编译器。 n 使用procompile参数配置WebLogic，在启动WebLogic时预编译JSP。 8．3编译EJB容器类 使用Weblogic.appc的功能去编译EJB2.0和1.1容器类。如果编译Jar文件部署EJB容器，你必须使用weblogic.appc生成容器类。默认情况下，EJB使用javac编译器。为了得到跟好的性能，使用－compiler标志指定不同的编译器（如Symantec公司的sj） 8．4在UNIX环境下编译 在UNIX机器上编译JSP文件，如果收到下列错误消息： failed：java.io.IOException:Not enough space 试试下列一些或所有的解决方法： n 如果你只有256MB的内存，增加更大的内存。 n 提高文件描述文件的限制，如： set rlim_fd_max=4096 set rlim_fd_cur=1024 n 启动JVM时，用－native标志来使用自有的线程。 九、使用WebLogic集群提高性能 WebLogic集群是指一组WebLogic实例在一起提供具有防过载和自有复制的功能，以用一个域为所有客户支持可伸缩的高可用性运行。集群对于客户是一个单一的服务器，但实际上是一组服务器来提高可靠性和可伸缩性。 9．1可伸缩性和高的可用性 可伸缩性是系统增加一个或更多部件作为系统资源的能力。很典型的是，这些部件使并发用户得到支持，使并发事务能在特定的时间单位能被处理。 假定应用程序设计良好，它完全可以简单的增加更多的资源来提高性能。为了增加WebLogic处理的负荷量，只需增加一个WebLogic实例到你的集群――不需改变应用程序。集群提高两个关键的好处：可伸缩性和可用性，这是单一服务器无法比拟的。 WebLogic集群给J2EE带来了可伸缩性和高的可用性，而且对于应用程序的开发者是透明的。可伸缩性扩展了中间层的能力，超过了单一的WebLogic服务器或单一的计算机能处理的。集群成员唯一的限制是所有WebLogic必须要用IP多点传送通信。新的WebLogic能动态的增加到集群，以增加处理能力。 WebLogic集群保证高的可用性是通过多个服务器的冗余，减少客户的请求失败。集群中多个服务器能提供同一服务。如果一个服务器停止运行，另一个能接替运行。这种功能为客户增加了可用性。 警告：如果你要解决应用程序和环境的颈瓶问题，增加额外的服务器到集群，应该提供线性的可伸缩性。定基准和初始配置测试运行时，在移到集群环境之前，应把应用隔离在单独的服务器上测试。 9．2在多CPU机器上运行多服务器实例，应考虑的性能问题 多处理器的机器上，必须考虑群集WebLogic实例数应与CPU的数量成比例。因为WebLogic没有内置限制的服务器实例数位于集群里，规模大的、多处理器服务器，如Sun公司的Sun Enterprise 10000，有着当作非常大的集群或多集群主机的潜能。 在决定最佳的服务器与CPU比例前，彻底测试你的应用程序并确定如下： n 网络要求 如果你发现Web 应用程序是主要受网络I/O限制，在增加CPU数前，考虑测试网络的吞吐量。如果实际是网络I/O限制，安装一个更快的网络接口卡（NIC）可以提供性能，而不是增加额外的CPU，因为在等着读socket时，更多的CPU会处于闲置。 n 磁盘I/O要求 如果你发现Web应用程序主要受磁盘I/O限制。在配置额外的CPU前，就应该考虑增加磁盘转速或单个磁盘。 总之，在配置额外的CPU前，必须确定Web应用程序是受CUP限制，而不是受网络或磁盘I/O限制。 对于受CPU限制的应用，最初在每个CPU上对一个WebLogic实例进行性能测试。如果CPU利用率是一致的或者接近100％，然后增加CPU比重（例如，为一个WebLogic实例配置两个CUP），记住在产品模式下，应该有一些空闲的CPU周期存在去执行管理任务。 虽然Web应用程序的处理需求变化多端，但BEA公司发现WebLogic实例与CPU最理想的比例是1：2。 十、监视WebLogic域 监视WebLogic域的健康状况和性能的工具是管理控制台。通过控制台，你可以观察到WebLogic资源的状态和统计信息，如服务器，HTTP，JTA 子系统，JNDI,安全，CORBA连接池，EJB，JDBC以及JMS。 举个例子，在Server――>Monitoring――>Performance为当前服务器实例提供了与等待和运行状态的请求有关的性能参考。它包括下列信息： n 队列中空闲线程数。 n 队列中等待时间最长的请求。 n 吞吐量，根据已经处理的请求数来衡量的。 n 队列长度，根据队列中等待请求数来衡量的。 n JVM堆还有的内存量。