WebLogic Server 性能及调优调优 WebLogic Server.docx
《WebLogic Server 性能及调优调优 WebLogic Server.docx》由会员分享，可在线阅读，更多相关《WebLogic Server 性能及调优调优 WebLogic Server.docx（15页珍藏版）》请在冰豆网上搜索。
WebLogicServer性能及调优调优WebLogicServer
WebLogicServer性能及调整
-调整WebLogicServer
以下部分描述如何调整WebLogicServer以满足应用程序需要。
∙设置启动WebLogicServer的Java参数
∙开发与生产模式的默认调整值
∙线程管理
∙调整网络I/O
∙设置编译器选项
∙使用WebLogicServer群集提高性能
∙监视WebLogicServer域
设置启动WebLogicServer的Java参数
无论何时启动WebLogicServer，都必须指定Java参数。
为了便于调用，可以使用weblogic.Server命令从命令行完成这一操作。
但是，因为从命令行启动WebLogicServer所需的参数可能非常冗长并且易于出错，所以BEA建议将此命令组合到脚本中。
为简化这一过程，可以在启动WebLogicServer时WebLogic分发附带的示例脚步中修改默认值，如为WebLogicServer实例指定Java选项中所述。
如果已使用配置向导创建域，则WebLogic启动脚本位于您指定域的domain-name目录中。
默认情况下，此目录是BEA_HOME\user_projects\domain\domain-name，其中BEA_HOME是包含产品安装的目录，domain-name是由选定配置模板定义的域目录的名称。
有关使用ConfigurationWizard创建域的详细信息，请参阅使用ConfigurationWizard创建域。
需要在这些脚本中修改某些默认Java值才能满足您的环境和应用程序的需要。
这些文件中重要的性能调整参数是JAVA_HOME参数和Java堆大小参数：
∙将变量JAVA_HOME的值更改为JDK的位置。
例如：
setJAVA_HOME=C:
\bea\jdk150_03
∙为得到更高性能的吞吐量，可将最小Java堆大小设置成等于最大堆大小。
例如：
"%JAVA_HOME%\bin\java"-server-Xms512m-Xmx512m-classpath%CLASSPATH%-
有关设置堆大小选项的详细信息，请参阅指定堆大小值。
开发与生产模式的默认调整值
可以指定在开发环境还是在生产环境中使用域。
WebLogicServer为各种服务使用不同的默认值，这取决于指定的环境类型。
如下表所示，指定域的启动模式。
表6-1启动模式选择此模式
适用情况.
开发模式
适用于创建应用程序之时。
在此模式中，安全性配置相对宽松，允许自动部署应用程序。
生产模式
适用于应用程序以最终形式运行之时。
在此模式中，全面配置安全性。
表6-2列出了从开发启动模式切换为生产启动模式时与性能相关的不同配置参数。
表6-2开发模式与生产模式之间的区别调整参数
开发模式.
生产模式.
SSL
可以使用WebLogicServer安全服务提供的示范数字证书和示范密钥库。
利用这些证书，可设计出在由SSL担保的环境中工作的应用程序。
有关管理安全的详细信息，请参阅“确保WebLogicServer安全”中的配置SSL。
不应使用示范数字证书和示范密钥库。
如果这样做，将会显示警告消息。
部署应用程序
WebLogicServer实例可以自动部署和更新驻留在domain_name/autodeploy目录中的应用程序（其中domain_name为域名）。
建议只在单服务器开发环境中使用此方法。
有关详细信息，请参阅“将应用程序部署到WeblogicServer”中的在开发域中自动部署应用程序。
由于自动部署功能已禁用，因此必须使用WebLogicServer管理控制台、weblogic.Deployer工具或WebLogic脚本工具（WLST）。
有关详细信息，请参阅将应用程序部署到WebLogicServer。
有关从开发到生产启动模式切换的信息，请参阅“管理控制台联机帮助”中的更改至生产模式。
线程管理
WebLogicServer提供下列机制管理执行工作的线程。
∙调整工作管理器
∙调整执行队列
∙了解工作管理器与执行队列之间的区别
∙调整阻塞线程检测行为
调整工作管理器
在本版本中，WebLogicServer允许配置应用程序优先执行其工作的方式。
基于您定义的规则并通过监视实际的运行时性能，WebLogicServer可以优化应用程序的性能并维护服务级协议（SLA）。
您可以调整服务器实例的线程利用率，方法是：
通过定义工作管理器并将其全局应用到WebLogicServer域，或应用到特定的应用程序组件来定义应用程序规则和约束。
主要调整注意事项：
∙需要多少个工作管理器？
∙每个工作管理器的SLA要求是什么？
请参阅“配置WebLogicServer环境”中的使用工作管理器优化调度的工作。
需要多少个工作管理器？
每个不同的SLA要求都需要唯一的工作管理器。
每个工作管理器的SLA要求是什么？
服务级协议（SLA）要求是由请求类的实例定义的。
请求类表达服务器实例用来分配线程的调度准则。
请参阅“配置WebLogicServer环境”中的了解工作管理器。
调整执行队列
注意：
在本版本的WebLogicServer中不赞成使用执行队列。
BEA建议迁移应用程序以使用工作管理器。
在WebLogicServer的以前版本中，执行处理是在多个执行队列中进行的。
根据优先级和顺序要求，不同类别的工作在不同的队列中执行以避免死锁。
请参阅使用WebLogic8.1线程缓冲池模型。
了解工作管理器与执行队列之间的区别
从概念上直观区分以前版本的执行队列与工作管理器的最简单方法是，将执行队列（准确地说是执行队列管理器）与工作管理器关联，并消除执行队列和线程缓冲池之间的一一对应关系。
对于WebLogicServer9.0之前的版本，传入请求都放在默认执行队列或用户定义的执行队列中。
每个执行队列都有一个相关联的执行队列管理器，该管理器控制着一个专有独占的线程缓冲池，其中包含固定数量的线程。
基于先请求先服务原则向队列添加请求。
然后，执行队列管理器从此队列中选取第一个请求，从相关联的线程缓冲池中选取可用的线程，并调度请求由该线程执行。
对于WebLogicServer9.0及更高版本，在服务器中存在一个基于优先级的执行队列。
根据管理由应用程序执行的工作而创建的工作管理器的配置，将分配给传入请求一个内部优先级。
服务器将根据各种工作管理器的要求增加或减少执行队列可用的线程。
请求在执行队列中的位置由其内部优先级确定：
∙优先级越高，位置越靠近执行队列的头。
∙越靠近队列的头，调度线程使用的请求也越快速。
与使用执行队列相比，使用工作管理器能够更好的控制线程利用率（服务器性能），主要原因是可以为基于优先级的线程缓冲池指定调度准则的方法非常多。
这些调度准则既可以根据数字值设置，也可以根据服务器管理的资源（如JDBC连接缓冲池）容量设置。
从以前的版本迁移
如果从包含执行队列的以前版本升级应用程序域，则会使生成的9.x域包含执行队列。
∙从以前的版本将应用程序域迁移到WebLogicServer9.x不会自动将执行队列转换为工作管理器。
∙如果在已升级的应用程序配置中存在执行队列，则服务器实例将把工作请求相应地分配给在dispatch-policy中指定的执行队列。
∙不带dispatch-policy的请求将使用自调整线程缓冲池。
有关迁移域的详细信息，请参阅升级WebLogic应用程序域。
调整阻塞线程检测行为
WebLogicServer自动检测执行队列中的线程发生“阻塞”的时间。
因为阻塞的线程无法完成其当前工作或接受新工作，所以，服务器每次诊断阻塞的线程时均会记录一条消息。
如果线程在某一设定的时间段内连续工作（非空闲），WebLogicServer会将其诊断为阻塞线程。
通过更改线程被诊断为阻塞线程之前经过的时间长度，以及更改服务器检查阻塞线程的频率，可以调整服务器的线程检测行为。
尽管可以更改WebLogicServer用来确定线程是否阻塞的条件，但是当在特定执行队列中的所有线程都阻塞时，就无法更改设置“警告”和“严重”运行状况的默认行为。
有关详细信息，请参阅“配置WebLogicServer环境”中的配置WebLogicServer以避免超载情况。
要配置阻塞线程检测行为，请参阅“管理控制台联机帮助”中的调整执行线程检测行为。
调整网络I/O
以下部分提供了有关在客户端与服务器（包括T3和IIOP协议以及它们的安全版本）之间进行网络通信的信息：
∙调整Muxer
∙哪个平台具有性能包？
∙启用性能包
∙更改可用套接口读取器的数量
∙网络通道
∙调整消息大小
∙调整块参数
∙调整连接预备连接缓冲
调整Muxer
WebLogicServer使用称为muxer的软件模块读取服务器上的传入请求和客户端上的传入响应。
这些muxer有两种主要类型：
Javamuxer或本地muxer。
Javamuxer具有下列特征：
∙使用纯Java从套接口读取数据。
∙它也是RMI客户端唯一可用的muxer。
∙在从套接口读取数据之前一直阻塞读取。
当存在大量的套接口和/或极少有数据到达套接口时，此行为不能很好地调整。
通常，这不是客户端的问题，但这种行为会给服务器造成巨大的瓶颈。
本地muxer使用平台特定的本地二进制从套接口读取数据。
绝大多数的平台都提供某些轮询套接口数据的机制。
例如，Unix系统使用轮询系统，而Windows体系结构则使用完成端口。
本地提供超级可伸缩性，因为它们实现了无阻塞线程模型。
使用本地muxer时，服务器将创建固定数量、专用于读取传入请求的线程。
BEA建议使用为EnableNativeIO参数选定的默认设置，该参数允许服务器自动选择适用于该服务器使用的muxer。
如果未选定EnableNativeIO参数，服务器实例将只使用Javamuxer。
如果客户端较少并且请求达到服务器的频率相当高，则可以接受这种情况。
在这些条件下，Javamuxer与本地muxer执行得一样好，并且消除了Java本地接口（JNI）的开销。
与本地muxer不同，Javamuxer用来读取请求的线程数不固定，并且通过配置管理控制台中的PercentSocketReaders参数设置，还可以调整线程数。
请参阅更改可用套接口读取器的数量。
理想情况下，应该配置这一参数，以使线程数近似等于远程并发连接的客户端数（最多为线程缓冲池总大小的50%）。
每个线程都等待一段固定的时间以便数据在套接口变得可用。
如果没有数据到达，则线程移动到下一个套接口。
哪个平台具有性能包？
在承载WebLogicServer实例的计算机上使用本地性能包时，基准点可显示主要的性能改进。
性能包使用平台优化的本地套接口多路传输器提高服务器性能。
例如，本地的套接口读取器多路传输器线程有其自己的执行队列，不用从默认执行队列借用线程，这样可释放默认执行线程以执行应用程序工作。
要查看当前哪些平台具有性能包，请执行下列操作：
1转至CertificationsPages。
1从已认证平台列表中选择您的平台。
1使用浏览器的“编辑”
“查找”查找所有的“性能包”实例，以验证此平台中是否包含性能包。
启用性能包
默认情况下，在分发附带的配置中，本地性能包的使用处于启用状态。
可以使用管理控制台验证性能包是否已启用。
请参阅“管理控制台联机帮助”中的启用本地IO。
更改可用套接口读取器的数量
如果主机必须使用纯Java套接口读取器实现，则可以通过为每个服务器实例和客户端计算机配置正确的套接口读取器线程数，提高套接口通信的性能。
请参阅“管理控制台联机帮助”中的调整可用套接口读取器的数目。
网络通道
网络通道也称为网络访问点，使用它可以为网络通信指定不同的服务质量（QOS）参数。
每个网络通道都与其自己的使用唯一IP地址和端口的专用套接口关联。
默认情况下，通过同一个远程连接多路传输来自多线程客户端的请求，并且服务器实例一次只能从套接口读取一个请求。
如果请求大小太大，这将成为一个瓶颈。
尽管网络通道的主要角色是控制服务器实例的网络流量，但是可以利用这种能力创建多个自定义通道，以允许多线程客户端通过多个连接与服务器实例通信，从而减少潜在的瓶颈。
要配置自定义多通道通信，请执行下列操作：
1使用不同的IP和端口设置配置多个网络通道。
请参阅“管理控制台联机帮助”中的配置自定义网络通道。
1在客户端代码中，使用JNDIURL模式，该模式类似于群集环境中所用的那种模式。
下面是一个使用两个网络通道的客户端示例：
t3:
//:
,:
请参阅“配置WebLogicServer环境”中的了解网络通道。
调整消息大小
WebLogicServer允许指定最大传入请求大小，这样可阻止服务器免遭一系列较大请求的轰炸，从而降低了潜在的拒绝服务（DoS）攻击。
可以设置全局值，或者为不同协议和网络通道设置特定值。
尽管这不直接影响性能，但JMS应用程序在发送到目标之前会聚合消息，如果聚合的消息大于指定值，则可能会拒绝该应用程序。
请参阅“管理控制台联机帮助”中的服务器:
协议:
常规和使用顺序单元调整应用程序。
调整块参数
块是客户端和服务器端上的WebLogicServer网络层用来从中读取数据并将数据写入套接口的内存单元。
为降低内存分配成本，服务器实例会为这些块维护一个缓冲池。
对于处理每个请求含有大量数据的应用程序，在客户端和服务器上增大该值可以提高性能。
默认块大小约为4K。
使用下列属性可调整块大小和块缓冲池大小：
∙weblogic.Chunksize-设置块的大小（字节）。
该属性可能需要增加的主要情形是在请求大小较大时。
该属性应设置成网络最大传输单元（MTU）减去任何Ethernet或TCP头值大小所得结果的倍数。
在客户端和服务器上将些参数设置成相同的值。
∙weblogic.utils.io.chunkpoolsize-设置块缓冲池的最大大小。
默认值是2048。
如果服务器在稳定状态下开始分配和放弃块，则此值可能需要增大。
要确定是否需要增加此值，可监视CPU配置文件或使用调用构造方法weblogic.utils.io.Chunk的调用堆栈的内存/堆配置文件。
∙weblogic.PartitionSize-设置使用的缓冲池分区数目（默认值是4）。
块缓冲池可以是重要锁定争用的来源，因为每个访问缓冲池的请求必须同步。
分区线程缓冲池与一个分区相比，扩大了潜在的争用。
调整连接预备连接缓冲
可以调整WebLogicServer实例在拒绝其他请求之前可以接受的连接请求数。
AcceptBacklog参数指定在等待队列中可以缓冲的传输控制协议（TCP）连接。
此固定大小的队列由TCP堆站已接收到而应用程序尚未接收到的连接请求进行填充。
有关TCP调整的详细信息，请参阅基本OS调整概念。
可以调整WebLogicServer实例在拒绝其他请求之前可以接收的连接请求数，请参阅“管理控制台联机帮助”中的调整预备连接缓冲。
设置编译器选项
可以通过调整服务器编译器的选项来提高性能。
编译EJB类
使用weblogic.appc实用工具编译EJB容器类。
如果编译要部署到EJB容器的Jar文件，则必须使用weblogic.appc来生成容器类。
默认情况下，ejbc使用javac编译器。
通过使用-compiler标志或使用管理控制台来指定另一个编译器（比如IBMJikes），可以提高性能。
有关详细信息，请参阅：
∙“WebLogicEJB编程”中的实现EnterpriseJavaBean。
∙“管理控制台联机帮助”中的配置编译器选项。
设置JSP编译器选项
WebLogicServer使用Javelin来编译JSP。
在weblogic.xml文件中，jsp-descriptor元素定义servletJSP的参数名和值。
使用precompile参数来配置WebLogicServer，以便在WebLogicServer启动时预编译JSP。
请参阅jsp-descriptor元素。
如果在UNIX计算机上编译JSP文件时收到下列错误消息：
failed:
java.io.IOException:
Notenoughspace
请尝试下列任何一个或全部解决方案：
∙添加更多的RAM（如果仅有256MB）。
∙提高文件描述符限制，例如：
setrlim_fd_max=4096
setrlim_fd_cur=1024
使用WebLogicServer群集提高性能
WebLogicServer群集是一组WebLogicServer实例，这组实例共同提供故障转移和复制服务，以支持域中客户端的可伸缩、高可用性操作。
从客户端看来，群集好像是一个服务器，但实现上是一组服务器充当一个服务器以提供增强的可伸缩性和可靠性。
一个域可以包含多个WebLogicServer群集和非群集的WebLogicServer实例。
域中群集的WebLogicServer实例除提供故障转移和负载平衡外，其他行为与非群集的实例相同。
无论群集还是非群集实例，其配置参数都是由域的管理服务器管理的。
有关群集的详细信息，请参阅了解WebLogicServer群集。
可伸缩性和高可用性
可伸缩性是指随着更多的资源添加到系统，系统在一个维度或多个维度进一步扩展的能力。
通常，这些维度包括（但不限于）可支持的并发用户数和可在给定时间单元内处理的事务数。
对于设计良好的应用程序，完全可以通过简单添加更多的资源来提高性能。
为了提高WebLogicServer的负载处理能力，可将其他WebLogicServer实例添加到群集中-无需更改您的应用程序。
群集可提供一个服务器无法提供的两个关键优势是：
可伸缩性和可用性。
WebLogicServer群集以一种对应用程序开发人员透明的方法为JavaEE应用程序带来了可伸缩性和高可用性。
可伸缩性扩展了中层的容量，这是一个WebLogicServer或一台计算机无法做到的。
群集成员资格的唯一限制是所有WebLogicServer都必须能够通过IP多播进行通信。
可以动态地向群集添加新的WebLogicServer以增加其容量。
WebLogicServer群集通过使用多台服务器冗余消除客户端故障保证了高可用性。
同一个服务可由群集中多个服务器提供。
当一个服务器出现故障时，另一个服务器便可以接管其工作。
让功能正常的服务器接管出现故障的服务器能够提高应用程序对客户端的可用性。
警告：
若您已解决所有应用程序和环境瓶颈问题，向群集添加其他服务器应提供线性可伸缩性。
执行基准点或初始配置测试时，要先将问题隔离到单个服务器环境，然后才移动到群集环境中。
消息传递服务中的群集由分布式目标、连接集中器、连接负载平衡（由连接工厂目标决定）和群集存储转发（SAF）提供。
与分布式目标有关的客户端负载平衡可在连接工厂进行调整。
定位到同一群集（承载分布式目标）的分布式目标消息驱动Bean（MDB）只能自动部署在承载分布式目标成员的群集服务器上，并且只能从其本地目标处理消息。
定位到不同服务器或群集（承载分布式目标）的分布式队列MDB为每一个分布式目标成员自动创建使用者。
例如，每个运行的MDB都有一个针对每个分布式目标队列成员的使用者。
如何确保WebLogic群集的可伸缩性
通常，任何要求在群集中的服务器之间进行通信的操作都是潜在的可伸缩性障碍。
以下部分提供了有关影响线性调整群集WebLogic服务器能力问题的信息：
∙数据库瓶颈
∙会话复制
∙实体EJB的失效
∙HTTP会话的失效
∙JNDI绑定、取消绑定和重新绑定
数据库瓶颈
在WebLogic服务器的群集无法扩展的许多情况下，数据库是一个瓶颈。
在这种情况下，唯一的解决方案是调整数据库，或者利用其他选项降低数据库的负载。
请参阅数据库调整和调整JDBC应用程序。
会话复制
可以通过两种标准方法在JavaEE应用程序中存储用户会话数据：
有状态的会话EJB或HTTP会话。
这些会话本身极少影响群集的可伸缩性。
但是，当与提供高可用性所需的会话复制机制联系在一起时，就会引入瓶颈。
如果JavaEE应用程序具有Web和EJB组件，您应当使用HTTP会话存储用户会话数据：
∙HTTP会话管理为处理故障转移提供了更多的选项，如复制、共享数据库或文件。
∙超级可伸缩性。
∙HTTP会话状态的复制出现在任何事务的外部。
有状态会话Bean复制出现在更多资源密集的事务中。
∙与有状态会话Bean复制相比，HTTP会话复制机制更加复杂，并且提供了对范围更广的各种情形的优化。
请参阅会话管理。
实体EJB的失效
这应用到使用Optimistic并发战略的，或具有读写模式的ReadOnly的并发策略的实体EJB。
Optimistic-当更新Optimistic并发Bean时，EJB容器将向其他群集成员发送多播消息，以使其Bean本地副本失效。
这样做可避免由其他服务器引发的优化并发异常和重试事务的需要。
如果经常更新EJB，则由服务器完成以便使每个其他本地缓冲失效的这一工作将成为一个严重的瓶颈。
称为cluster-invalidation-disabled（默认值为false）的标志用于关闭这种失效。
这在rdbms描述符文件中进行设置。
具有读写模式的ReadOnly-在这种模式中，通过一个EJB表示的持久性数据实际上由两个EJB表示：
一个只读的和一个可更新的EJB。
当可更新Bean的状态更改时，容器自动使相应的只读EJB实例失效。
如果经常更新EJB，则由服务器完成以便使只读EJB失效这一工作将成为一个严重的瓶颈。
HTTP会话的失效
与实体EJB的失效类似，HTTP会话也可以失效。
与实体EJB失效相比，此会话失效成本不大，因为只有存储在次级服务器上的会话数据需要失效。
BEA建议用户仅当绝对必要时才让会话失效。
JNDI绑定、取消绑定和重新绑定
通常，JNDI绑定、取消绑定和重新绑定都是成本很高的操作。
但是，这些操作在群集环境中成了一个更大的瓶颈，因为JNDI树更改必须传播到群集中的所有成员。
如果这些操作执行太频繁，则它们会大大降低群集的可伸缩性。
在多CPU计算机上运行多个服务
升级会员 