WebLogic 9.2 利用Work Manager对资源进行控制

Work Manager可以对如下资源进行控制:

Fair Share Request Class: 对请求指定线程使用时间所占百分比。例如，Server上运行两个模块，Work Manager指定模块A的Fair Share Request Class为80，指定模块B的Fair Share Request Class为20。当有大业务压力时，请求数量超过线程数，这时WebLogic Server将会分别安排80％和20％的线程使用时间给模块A和模块B。
　　
　　Response Time Request Class: 指定响应时间（毫秒为单位）。此时间不是指某一具体的请求响应时间，而是请求处理的平均响应时间。 WebLogic Server会根据响应时间减去平均处理时间，得到容忍等待时间。Server调整前端请求压力，以使平均等待时间和容忍等待时间成比例。例如，Server上运行两个模块，Work Manager指定模块A的响应时间目标为2000ms，模块B的响应时间目标为5000ms，当到大压力情况下，WebLogic Server控制分配到模块A和模块B的请求，使得响应时间大致在2:5。实际的平均响应时间可能会比设定的响应时间高或者低，但响应时间比会大致相同，如模块A的响应时间为1000ms，那么模块B的响应时间会在2500ms。
　　
　　Min Threads Constraint: 最小线程限制，这样可以给一些请求分配最小线程数，防止请求申请新线程，而资源没有，产生死锁。
　　
　　Max Threads Constraint:最大线程限制，当请求达到最大的线程限制之后，Server将不会接受新的请求处理，直到当前的线程数目下降了。
　　
　　Capacity Constraint：容量限制，当到达这一容量限制时，Server会拒绝前端请求，这样保障了Server不会被资源过度消耗，达到系统可靠服务的目的。容量数目包括：等待请求和处理请求之和。
　　
　　Work Managers 可以在如下配置文件进行域级别、应用程序级别和模块级别上定义:
　　
　　config.xml—Work Manager指定应用或应用模块的约束条件，可以使用Server Console来定义Work Manager.
　　
　　weblogic-application.xml—Work Manager指定应用或应用内模块的约束条件
　　
　　weblogic-ejb-jar.xml or weblogic.xml—Work Managers 指定模块的约束条件
　　
　　weblogic-web-app.xml—Work Managers 指定应用的约束条件。
　　
　　配置示例：
　　
　　<work-manager>
　　<name>responsetime_workmanager</name>
　　<response-time-request-class>
　　<name>my_response_time</name>
　　<goal-ms>2000</goal-ms>
　　</response-time-request-class>
　　</work-manager>
　　
　　自动的线程计数调整:
　　
　　在WebLogic Server9.0版本之前，进程有多个执行队列，在不同的执行队列，基于优先级和排队顺序，执行不同的任务，这样可以避免死锁。有缺省的执行队列：weblogic.kernel.default，还有预先定义的队列来做内部管理用，如：weblogic.admin.HTTP和 weblogic.admin.RMI。对性能的调整，可以通过调整缺省队列上的线程数，或者为特定的应用配置自己的执行队列，对这个执行队列指定相应的线程数。
　　
　　对WebLogic Server9.0，建立了单一线程池，可以执行所有类型的操作。 WebLogic Server基于我们定义的规则和实时运行情况，来调整处理工作的优先级。线程池可以根据系统吞吐情况，自动调整大小。例如，根据历史吞吐量的统计，表明需要更高的线程数量时，WebLogic Server将自动增加线程数目。与此类似，当统计表明减小线程不会影响吞吐量时，WebLogic Server会减少线程数。这一新策略将使管理者更容易配置资源和性能调优，
避免向从前一样调整自己的执行队列。

过载保护
当系统的负载压力非常大时，如果不对处理容量进行配置，那么会导致内存耗尽（out-of-m异常、执行队列过载等问题。因此在WebLogic Server9.0可以对如下资源进行配置:
因为在Server9.0使用了单一线程池，因此可以在管理配置时，指定最大的队列数目。超过这一配置，Server将会拒绝请求。请求包括：Web 请求；非transaction的RMI请求。为了保证在这种情况下，管理员还可以对Server进行管理，可以配置管理通道来管理，指定的最大队列长度不会包括管理通道数目。
在Web应用中限制HTTP 会话数目。这样当到达最大的会话数目之后，Server将拒绝请求创建新的会话。如果是集群环境，其中一实例到达最大会话数，那么将通过Proxy转发到另外一个实例上。 <session-descriptor>
<max-in-memory-sessions>12</max-in-memory-sessions>
</session-descriptor>
内存溢出系统自动退出。即当系统运行时，出现内存溢出错误，Server就会自动停机，避免应用处于不稳定运行状态。然后，可以通过节点管理服务器或者其它工具将Server自动重启，缩短宕机时间。配置如下:
<overload-protection>
<panic-action>system-exit</panic-action>
</overload-protection>
过载状态。如果运行实例处于Work Manager容量超限或者低内存状态，Server9.0通过ServerRuntimeMBean.getHealthState()，可以获得Server 新的一个状态Overloaded.可以提示Server已处于不正常状态，便于管理员对系统状况清楚的了解。

Oracle官方文档说明如下：

Using Work Managers, Request Classes, and Constraints
Work Managers, Request Classes, and Constraints require the following:

A definition. You may define a Work Managers, Request Classes, or Constraints globally in the domain's configuration using the Administration Console, (see Environments > Work Managers in the Administration Console) or you may define them in one of the deployment descriptors listed above. In either case, you assign a name to each.
A mapping. In your deployment descriptors you reference one of the Work Managers, Request Classes, or Constraints by its name.
Dispatch Policy for EJB
weblogic-ejb-jar.xml—the value of the existing dispatch-policy tag under weblogic-enterprise-bean can be a named dispatch-policy. For backwards compatibility, it can also name an ExecuteQueue. In addition, we allow dispatch-policy, max-threads, and min-threads, to specify named (or unnamed with numeric value for constraints) policy and constraints for a list of methods, analogously to the present isolation-level tag.

Dispatch Policy for Web Applications
weblogic.xml—also supports mappings analogous to the filter-mapping of the web.xml, where named dispatch-policy, max-threads, or min-threads are mapped for url-patterns or servlet names.

--------------------------------------------------------------------------------

Deployment Descriptor Examples
This section contains examples for defining Work Managers in various types of deployment descriptors.

For additional reference, see also the schema for these deployment descriptors:

weblogic-ejb-jar.xml schema
weblogic-application.xml schema
weblogic.xml schema
Listing 2-5 weblogic-ejb-jar.xml With Work Manager Entries
<weblogic-ejb-jar xmlns="http://www.bea.com/ns/weblogic/90" xmlns:j2ee="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-ejb-jar.xsd"><weblogic-enterprise-bean> <ejb-name>WorkEJB</ejb-name> <jndi-name>core_work_ejb_workbean_WorkEJB</jndi-name> <dispatch-policy>weblogic.kernel.System</dispatch-policy> </weblogic-enterprise-bean><weblogic-enterprise-bean> <ejb-name>NonSystemWorkEJB</ejb-name> <jndi-name>core_work_ejb_workbean_NonSystemWorkEJB</jndi-name> <dispatch-policy>workbean_workmanager</dispatch-policy> </weblogic-enterprise-bean><weblogic-enterprise-bean> <ejb-name>MinThreadsWorkEJB</ejb-name> <jndi-name>core_work_ejb_workbean_MinThreadsWorkEJB</jndi-name> <dispatch-policy>MinThreadsCountFive</dispatch-policy> </weblogic-enterprise-bean><work-manager> <name>workbean_workmanager</name></work-manager><work-manager> <name>stuckthread_workmanager</name> <work-manager-shutdown-trigger> <max-stuck-thread-time>30</max-stuck-thread-time> <stuck-thread-count>2</stuck-thread-count> </work-manager-shutdown-trigger></work-manager><work-manager> <name>minthreads_workmanager</name> <min-threads-constraint> <name>MinThreadsCountFive</name> <count>5</count> </min-threads-constraint></work-manager><work-manager> <name>lowpriority_workmanager</name> <fair-share-request-class> <name>low_priority</name> <fair-share>10</fair-share> </fair-share-request-class></work-manager><work-manager><name>highpriority_workmanager</name> <fair-share-request-class> <name>high_priority</name> <fair-share>100</fair-share> </fair-share-request-class></work-manager><work-manager><name>veryhighpriority_workmanager</name> <fair-share-request-class> <name>veryhigh_priority</name> <fair-share>1000</fair-share> </fair-share-request-class></work-manager>Listing 2-6 weblogic-ejb-jar.xml with Connection Pool Based Max Thread Constraint
These EJBs are configured to get as many threads as there are instances of a resource they depend upon—a connection pool, and an application scoped connection pool.

</weblogic-ejb-jar><weblogic-ejb-jar xmlns="http://www.bea.com/ns/weblogic/90" xmlns:j2ee="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-ejb-jar.xsd"> <weblogic-enterprise-bean> <ejb-name>ResourceConstraintEJB</ejb-name> <jndi-name>core_work_ejb_resource_ResourceConstraintEJB</jndi-name> <dispatch-policy>test_resource</dispatch-policy> </weblogic-enterprise-bean> <weblogic-enterprise-bean> <ejb-name>AppScopedResourceConstraintEJB</ejb-name> <jndi-name>core_work_ejb_resource_AppScopedResourceConstraintEJB </jndi-name> <dispatch-policy>test_appscoped_resource</dispatch-policy> </weblogic-enterprise-bean><work-manager> <name>test_resource</name> <max-threads-constraint> <name>pool_constraint</name> <pool-name>testPool</pool-name> </max-threads-constraint></work-manager><work-manager> <name>test_appscoped_resource</name> <max-threads-constraint> <name>appscoped_pool_constraint</name> <pool-name>AppScopedDataSource</pool-name> </max-threads-constraint></work-manager></weblogic-ejb-jar>Listing 2-7 weblogic-ejb-jar.xml with commonJ Work Managers
For information using commonJ, see Using CommonJ With WebLogic Serverand the commonJ Javadocs.

Listing 2-8 weblogic-application.xml
<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90" xmlns:j2ee="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-application.xsd"> <max-threads-constraint> <name>j2ee_maxthreads</name> <count>1</count> </max-threads-constraint> <min-threads-constraint> <name>j2ee_minthreads</name> count>1</count> </min-threads-constraint> <work-manager> <name>J2EEScopedWorkManager</name> </work-manager></weblogic-application>Listing 2-9 web application descriptor
This Web Application is deployed as part of the Enterprise Application defined in Listing 2-8, weblogic-application.xml, on page 2-13. This Web Application's descriptor defines two Work Managers. Both Work Managers point to the same max threads constraint, j2ee_maxthreads which is defined in the application's weblogic-application.xml file. Each Work Manager specifies a different response time request class.

<weblogic xmlns="http://www.bea.com/ns/weblogic/90" xmlns:j2ee="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic.xsd"> <work-manager> <name>fast_response_time</name> <response-time-request-class> <name>fast_response_time</name> <goal-ms>2000</goal-ms> </response-time-request-class> <max-threads-constraint-name>j2ee_maxthreads </max-threads-constraint-name> </work-manager> <work-manager> <name>slow_response_time</name> <max-threads-constraint-name>j2ee_maxthreads </max-threads-constraint-name <response-time-request-class> <name>slow_response_time</name> <goal-ms>5000</goal-ms> </response-time-request-class> </work-manager></weblogic>Listing 2-10 web application descriptor
This descriptor defines a Work Manager using the context-request-class.

<?xml version="1.0" encoding="UTF-8"?><weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90"xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://www.bea.com/ns/weblogic/90http://www.bea.com/ns/weblogic/90/weblogic-web-app.xsd"> <work-manager> <name>foo-servlet-1</name> <request-class-name>test-fairshare2</request-class-name> <max-threads-constraint> <name>foo-mtc</name> <pool-name>oraclePool</pool-name> </max-threads-constraint> </work-manager> <work-manager> <name>foo-servlet</name> <context-request-class> <name>test-context</name> <context-case> <user-name>anonymous</user-name> <request-class-name>test-fairshare1</request-class-name> </context-case> <context-case> <group-name>everyone</group-name> <request-class-name>test-fairshare2</request-class-name> </context-case> </context-request-class> </work-manager></weblogic-web-app>

--------------------------------------------------------------------------------

Work Managers and Execute Queues
This section discusses how to enable backward compatibility with Execute Queues and how to migrate applications from using Execute Queues to Work Managers.

Enabling Execute Queues

WebLogic Server, Version 8.1 implemented Execute Queues to handle thread management which allowed you to cread thread-pools to determine how workload was handled. WebLogic Server still provides Execute Queues for backward compaitibility, primarily to facilitate application migration. However, new application development should utilize Work Managers to peform thread management more efficiently.

You can enable Execute Queues in the following ways:

Using the command line option
-Dweblogic.Use81StyleExecuteQueues=trueSetting the Use81StyleExecuteQueues property via the Kernel MBean in config.xml.
Enabling Execute Queues disables all Work Manager configuration and thread self tuning. Execute Queues behave exactly as they did in WebLogic Server 8.1. See Using User-Defined Execute Queues in WebLogic Server Performance and Tuning.

When enabled, Work Managers are converted to Execute Queues based on the following rules:

If the Work Manager implements a minimum or maximum threads constraint, then an Execute Queue is created with the same name as the Work Manager. The thread count of the Execute Queue is based on the value defined in the constraint.
If the Work Manager does not implement any constraints, the the global default Execute Queue is used.
Migrating from Execute Queues to Work Managers
When an application is migrated from WebLogic Server 8.1, any Execute Queues defined in the server configuration before migration will still be present. WebLogic Server does not automatically convert the Execute Queues to Work Managers.

When an 8.1 application implementing Execute Queues is deployed on WebLogic Server 9.x, the Execute Queues are created and used handle thread management for requests. However, only those requests whose dispatch-policy maps to an Execute Queue will take advantage of this feature.

--------------------------------------------------------------------------------

Accessing Work Managers Using MBeans
Work Managers can be accessed using the WorkManagerMBean configuration MBean. For more information, see WorkManagerMBean

WorkManagerMBean is accessed in the runtime tree or configuration tree depending on how the Work Manager is accessed by an application.

If the Work Manager is defined at the module level, the WorkManagerRuntime MBean is available through the corresponding ComponentRuntimeMBean.
If a Work Manager is defined at the application level, then WorkManagerRuntime is available through ApplicationRuntime.
If a Work Manager is defined globally in config.xml, each application creates its own instance of the Work Manager. Each application has its own corresponding WorkManagerRuntime available at the application level.

--------------------------------------------------------------------------------

Using CommonJ With WebLogic Server
WebLogic Server Work Managers provide server-level configuration that allows administrators a way to set dispatch-policies to their servlets and EJBs.

WebLogic Server also provides a programmatic way of handling work from within an application. This is provided via the CommonJ API. Weblogic Server implements the commonj.work and commonj.timers packages of the CommonJ specificaion.

For general information on the CommonJ specification, see http://dev2dev.bea.com/wlplatform/commonj/twm.html. For specific information WebLogic Server's implementation of CommonJ, see the CommonJ Javadocs.

The WebLogic Server implementation of CommonJ enables an application to break a single request task into multiple work items, and assign those work items to execute concurrently using multiple Work Managers configured in WebLogic Server. Applications that do not need to execute concurrent work items can also use configured Work Managers by referencing or creating Work Managers in their deployment descriptors or, for J2EE Connectors, using the JCA API.

Following are some differences between the WebLogic Server implementation and the CommonJ specification:

The RemoteWorkItem interface is an optional interface provided by the CommonJ specification and is not supported in WebLogic Server. WebLogic Server implements its own cluster load balancing and failover policies. Workload management is based on these policies.
WebLogic CommonJ timers behave differently than java.util.Timer. When the execution is greater that twice the period, the WebLogic CommonJ timer will skip some periods to avoid falling further behind. The java.util.Timer does not do this.
Accessing CommonJ Work Managers
Unlike WebLogic Server Work Managers, which can only be accessed from an application via dispatch policies, you can access CommonJ Work Managers directly from an application. The following code example demonstrates how to lookup a CommonJ work manager using JNDI:

InitialContext ic = new InitialContext();commonj.work.WorkManager wm = (WorkManager);ic.lookup(`java:comp/env/wm/myWM');For more information on using CommonJ Work Managers, see the CommonJ Javadocs.

Mapping CommonJ to WebLogic Server Work Managers
You can map an externally defined CommonJ Work Manager to a WebLogic Server Work Manager. For example, if you have a CommonJ Work Manager defined in a descriptor, ejb-jar.xml for example, as:

<resource-ref><res-ref-name>minthreads_workmanager</res-ref-name><res-type>commonj.work.WorkManager</res-type><res-auth>Container</res-auth><res-sharing-scope>Shareable</res-sharing-scope></resource-ref>You can link this to a WebLogic Server Work Manager by ensuring that the name element is identical in the WebLogic Server descriptor such as weblogic-ejb-jar.xml:

<work-manager><name>minthreads_workmanager</name><min-threads-constraint><count>5</count></min-threads-constraint></work-manager>This procedure is similar for a resource-ref defined in web.xml. The WebLogic Server Work Manager can be defined in either a module descriptor (weblogic-ejb-jar.xml or weblogic.xml, for example) or in the application descriptor (weblogic-application.xml).