【WebLogic性能优化】优化WebLogic 服务器性能参数

提要：
1 为 WebLogic 启动设置 Java 参数。
2 设置与性能有关的配置参数。
3 调整开发与产品模式默认值。
4 使用 WebLogic “自有的 IO ”性能包。
5 优化默认执行队列线程。
6 优化连接缓存。
7 如何提高 JDBC 连接池的性能。
8 设置 Java 编译器。
9 使用 WebLogic 集群提高性能。
10 监视 WebLogic 域。

WebLogic 配置文件（config.xml）包含了大量很直观的与性能有关的参数，能通过配置环境与应用程序得到很好的优化。基于系统的需要调整这些参数不仅能改善单个点的性能，而且能提高整个应用程序性能的可衡量性。
试着采用下列WebLogic配置方法，或许能使你的系统达到最佳状态：
一 修改运行队列线程数的值。在WebLogic 中队列元素的线程数等于同时占用运行队列的应用程序的数目。当任务加入一个WebLogic 实例，它就被放到执行队列中，然后分配给任务一个线程来运行。线程消耗资源，因此要小心处理这个属性——增加不需要的值，会降低性能。
二，如果可能，使用自带的性能包（NativeIOEnabled=true）。
三，使用特定的应用程序执行队列。
四，使用JDBC连接池时，修改下列属性：
n 驱动名称：使用小的驱动或者jDriver。
n 初始容量：设为与最大容量相同的值。
n 最大容量：其值至少应与线程数相同。
五，把连接池的大小设为与执行队列的线程数相同。
六，设置缓冲。
七，为Servlet和JSP使用多个执行队列。
八，改变JSP默认的Java编译器，javac 比jikes或sj要慢。

一、为 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

QueueLength
QueueLengthThresholdPercent
ThreadsIncrease
ThreadsMaximum
ThreadPriority

Queue Length
Queue Length Threshold Percent
（队列长限度百分比）
Threads Increase
Threads Maximum
Thread Priority

Server

StuckThreadMaxTime
StuckThreadTimerInteral

Stuck Thread Max Time
（堵塞线程的最长时间）
Stuck Thread Timer Interval
（堵塞线程的时间间隔）

Server

ThreadPoolPercentSocketReaders

Socket Readers

Server

AcceptBacklog

Accept Backlog
（接受缓存数）

JDBCConnectionPool

InitialCapacity
MaxCapacity

Initial Capacity
Max Capacity

JDBCConnectionPool

StatementCacheSize

Statement Cache Size
(声明高速缓冲大小)

三、调整开发模式与产品模式默认值
你可以指定域为开发环境或为产品环境。 WebLogic 会根据你指定的环境类型使用不同的默认值提供不同的服务。
下表列出了两种模式下的默认值

优化参数

开发模式

产品模式

Execute Queue: ThreadCount

15 threads

25 threads

JDBC Connection Pool: MaxCapacity

15 connections

25 connections

六、优化连接缓存
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 堆还有的内存量。

六、优化连接缓存
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 ）数相等。在服务器端，连接池的容量与执行线程数是无关的，正在进行的用户会话比执行线程更多。