|
|
如果在此版本之前，您一直在使用执行队列来提高性能，则将应用程序域升级到 WebLogic Server 9.x 之后，您可以继续使用它们。
| 注意： | BEA 建议使用工作管理器从使用执行队列转为使用自调整性执行队列。请参阅“配置 WebLogic Server 环境”中的使用工作管理器优化调度的工作。 |
BEA 提供了一种标志，可用于禁用自调整性执行缓冲池，它还为升级应用程序提供了向后兼容性以继续使用用户定义的执行队列。
config.xml 文件中 ExecuteQueue 元素的 ThreadCount 特性的值等于使用执行队列的应用程序同时执行的操作数。随着工作进入 WebLogic Server 实例，会将此工作放置在执行队列中。然后将此工作分配到执行它的线程上。线程会使用资源，因此根据此特性处理时需小心 - 增加不必要的值会降低性能。由于服务器实例的启动模式不同，WebLogic Server 所使用的默认执行队列的线程计数的默认值也会不同。请参阅“管理控制台联机帮助”中的指定启动模式。
除非配置其他执行队列并将应用程序分配到这些队列，否则服务器实例会将请求分配到默认的执行队列。
| 注意： | 如果您的平台没有使用本地性能包，则可能需要调整执行队列线程的默认数值和作为套接口读取器的线程的百分比，以获得最佳性能。有关详细信息，请参阅分配执行线程以充当套接口读取器。 |
将更多的线程添加到默认执行队列不表示必然能够处理更多的工作。即使添加了更多的线程，仍然要受到处理器能力的限制。不必要地增加 ThreadCount 的值会降低性能。较大的执行线程计数会导致占用更多的内存，并且增加上下文的切换，因此会降低性能。
ThreadCount 特性的值主要取决于应用程序的工作类型。例如，如果客户端应用程序较小并且大部分工作通过远程调用完成，那么，与主要进行客户端处理的客户端应用程序相比，前者将花费更多的时间进行连接，因此需要更大的线程计数。
如果您的工作所需要的线程数不超过 15 个（开发模式默认值）或 25 个（生产模式默认值），则不要更改该特性的值。作为一般规则，如果应用程序执行返回时间较长的数据库调用，则相对于另一个执行短小且可快速返回的调用的应用程序来说，需要更多的执行线程。对于后一种情况，使用较少的执行线程可提高性能。
要为执行队列确定理想的线程计数，可在队列中的所有应用程序运行负载最大的情况下监视队列的吞吐量。增加队列中的线程数并重复负载试验，直至队列的吞吐量达到最优值。（线程数增加到某个点时，将导致上下文切换过多而使队列的吞吐量开始下降。）
| 注意： | WebLogic Server 管理控制台可显示服务器上所有执行队列的累计吞吐量。要访问该吞吐量值，请按照使用执行队列控制线程使用中的步骤 1-6 执行。 |
表 B-2 显示了用于调整可用线程数的默认方案，该线程数与 WebLogic Server 域中的可用 CPU 数有关。这些方案也假定 WebLogic Server 在最大负载下运行，而且通过使用默认执行队列可满足所有线程的请求。如果配置其他执行队列并将应用程序分配到特定队列，则可在缓冲池相连的基础上监视结果。
通过使用 WebLogic Server 中用户定义的执行队列，可以微调应用程序对执行线程的访问（从而优化或降低其性能）。但是，请记住，未使用的线程表示在 WebLogic Server 系统中有重大的资源浪费。您会发现已配置执行队列中的可用线程未得到使用，而同时其他队列中的任务却处于空闲中等待可用的线程。在这种情况下，与使用默认的单个执行队列相比，将线程分配到多个队列会使整体性能变得更差。
在 WebLogic Server 的默认安装上配置有默认执行队列，供在该服务器实例上运行的所有应用程序使用。您可能希望配置其他队列以执行下列操作：
请务必监视每个执行队列，确保在整个系统中正确地使用线程。有关优化线程数的常规信息，请参阅是否要修改默认线程计数？
执行队列指对于一个或多个已指定的 Servlet、JSP、EJB 或 RMI 对象可用的执行线程的已命名集合。
Queue Length - 通常保留队列长度的默认值 65536 条。队列长度是指服务器在队列中能够保持的同时请求的最大数。默认值 65536 是一个很大的请求数；队列中未完成的请求数很少能达到此最大值。
如果达到最大队列长度，则 WebLogic Server 自动将队列长度增加一倍以处理新增的任务。但是要注意，队列中请求数超过 65536 是队列中线程的问题，而不是队列长度本身的问题；请在执行队列中检查是否存在阻塞线程或线程计数是否不足。
Queue Length Threshold Percent - 在该服务器指出队列溢出条件之前可以达到的队列长度大小的百分比（从 1 到 99）。低于该阈值百分比的所有实际队列长度大小被视为正常；高于该阈值百分比的大小表示溢出。达到溢出条件时，WebLogic Server 将记录错误消息，并根据“线程数增加”特性的值来增加队列中的线程数，从而减少工作负荷。
“队列长度阈值百分比”值百分比默认为 90%。在多数情况下，应将值保留为 90% 或近似值，以便处理任何可能需要额外的线程来处理意外的工作请求峰值的情况。记住，请勿将“队列长度阈值百分比”当作一个自动调整参数 - 在正常运行环境下该阈值永远不会触发线程计数的增加。
Thread Count - 分配到此队列的线程数。如果您的工作所需要的线程数不超过 15 个（默认值），则不要更改该特性的值。（有关详细信息，请参阅是否要修改默认线程计数？。）
Threads Increase - WebLogic Server 检测到溢出条件时应添加到此执行队列的线程数。如果您指定增加零个线程（默认值），则服务器会将其运行状态更改为“警告”以响应线程中的溢出条件，但不会分配额外的线程数来减少工作负荷。
| 注意： | 如果 WebLogic Server 为响应溢出条件而增加线程数，则新增的线程数会一直保留在执行队列中直至重新启动服务器。监视错误日志以确定引起溢出条件的原因，并在必要时重新配置线程计数以阻止未来出现类似的条件。请不要将“线程数增加”和“队列长度阈值百分比”组合起来作为自动调整工具使用；这样做的后果通常是使执行队列分配大于实际所需的线程数，并因频繁的上下文切换导致性能下降。 |
Threads Minimum - WebLogic Server 应在此执行队列中保留的最小线程数，用来阻止出现不必要的溢出条件。默认情况下，“最小线程数”设置为 5。
Threads Maximum - 该执行队列能够拥有的最大线程数，该值将阻止 WebLogic Server 为了响应连续溢出而在队列中创建过高的线程计数。默认情况下，“最大线程数”设置为 400。
可以配置 WebLogic Server 以检测并访问（可选）默认执行队列或任何用户定义的执行队列中的潜在溢出条件。WebLogic Server 认为，当队列的当前大小达到其最大大小的用户定义百分比时，就有可能发生溢出。当达到该阈值时，服务器会将其运行状态更改为“警告”，并分配（可选）额外的线程执行队列中的未完成任务，从而减小队列长度。
要使用 WebLogic Server 管理控制台调整执行队列，请执行下列操作：
Queue Length - 指定服务器在队列中能够保持的同时请求的最大数。默认值 65536 是一个很大的请求数；队列中未完成的请求数很少能达到此最大值。通常将此“队列长度”值保留为默认值 65536 条。
Queue Length Threshold Percent - 在该服务器指出队列溢出条件之前可以达到的队列长度大小的百分比（从 1 到 99）。低于该阈值百分比的所有实际队列长度大小被视为正常；高于该阈值百分比的大小表示溢出。默认情况下，“队列长度阈值百分比”被设置为 90%。
Threads Increase - WebLogic Server 检测到溢出条件时应添加到此执行队列的线程数。如果您指定增加零个线程（默认值），则服务器会将其运行状态更改为“警告”以响应执行线程中的溢出条件，但不会分配额外的线程数以减少工作负荷。
Threads Minimum - WebLogic Server 应在此执行队列中保留的最小线程数，用来阻止出现不必要的溢出条件。默认情况下，“最小线程数”设置为 5。
Threads Maximum - 该执行队列能够拥有的最大线程数，该值将阻止 WebLogic Server 为了响应连续溢出而在队列中创建过高的线程计数。默认情况下，“最大线程数”设置为 400。
通过在初始化参数中标识执行队列的名称，可以将 Servlet 或 JSP 分配到一个已配置的执行队列中。初始化参数属于 Servlet 或 JSP 的部署描述符文件 web.xml 的 init-param 元素。要分配执行队列，请输入队列名称作为 wl-dispatch-policy 参数的值，如下面的示例所示：
<servlet>
<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>
有关在 web.xml 中指定初始化参数的详细信息，请参阅“开发 WebLogic Server 的 Web 应用程序、Servlet 和 JSP”中的创建和配置 Servlet。
要将 EJB object对象分配到已配置的执行队列，可使用 weblogic-ejb-jar.xml 中的新 dispatch-policy 元素。有关详细信息，请参阅 dispatch-policy。
也可以通过 appc 编译器 -dispatchPolicy 标志设置调度策略，不过 BEA 强烈建议使用部署描述符元素。这样的话，如果重新编译 EJB，则在诸如部署的过程中，不会丢失设置。
要将 RMI 对象分配到已配置的执行队列，可使用 rmic 编译器的 -dispatchPolicy 选项。例如：
java weblogic.rmic -dispatchPolicy CriticalAppQueue ...
为获得最佳性能，BEA 建议在承载 WebLogic Server 实例的计算机上，使用本地套接口读取器实现而非纯 Java 实现（请参阅线程管理）。但是，如果必须要在主机上使用纯 Java 套接口读取器实现，则可以配置恰当的执行线程数以作为每个服务器实例的套接口读取器线程，从而仍可以提高套接口通信的性能。
ThreadPoolPercentSocketReaders 特性可设置用于从套接口读取消息的执行线程的最大百分比。此特性的最优值是应用程序特定的。默认值是 33，有效范围是 1-99。
分配执行线程以充当套接口读取器线程可增加服务器接受客户端请求的速度和能力。在专门用于从套接口中读取消息的执行线程数和在服务器中执行实际任务的线程数之间，保持这两个数字的平衡是非常重要的。
要使用管理控制台设置从套接口读取消息的执行线程的最大百分比，请执行下列操作：
在客户端计算机上，可以配置运行客户端的 JVM 中的可用套接口读取器线程数。通过在客户端的 java 命令行中定义下列参数可以指定套接口读取器：
-Dweblogic.ThreadPoolSize=value-Dweblogic.ThreadPoolPercentSocketReaders=value
当执行队列中的线程“阻塞”时，WebLogic Server 会自动检测。因为阻塞线程无法完成其当前的任务或接受新的任务，因此服务器会在每一次诊断到阻塞线程的时候记录一条消息。
如果线程在某一设定的时间段内连续工作（非空闲），WebLogic Server 会将其诊断为阻塞线程。通过更改线程被诊断为阻塞线程之前经过的时间长度，以及更改服务器检查阻塞线程的频率，可以调整服务器的线程检测行为。尽管可以更改 WebLogic Server 用来确定线程是否阻塞的条件，但是当在特定执行队列中的所有线程都阻塞时，就无法更改设置“警告”和“严重”运行状况的默认行为。有关详细信息，请参阅“配置日志文件和筛选日志消息”中的了解 WebLogic 日志记录服务。
Stuck Thread Max Time - 服务器实例将线程诊断为阻塞线程之前，该线程必须连续工作的时间（秒）。
Stuck Thread Timer Interval - 服务器实例定期扫描线程，以查看线程连续工作的时间是否达到配置的“阻塞线程最长时间”的时间间隔（秒）。
  
|
