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 a