[AIX Solaris HP-UX Linux Windows]

队列配置最佳实践

存在一种配置 WebSphere® Application Server 队列的方法。将数据库服务器移动到另一台机器上,或提供更强大的资源(例如具有更多内存的一组更快的 CPU),可以显著改变系统的动态特性。

有四种排队的技巧:
  • WebSphere Application Server 队列中的请求数减至最少

    通常,请求在 Web 服务器前面的网络中等待,而不是在 WebSphere Application Server 中等待。此配置仅支持那些准备处理以进入排队网络的请求。请将最远的上游队列或者离客户机最近的队列指定得稍微大一些,而将较远的下游队列或者离客户机最远的队列指定为逐渐变小。

    上游排队网络
    工作流向下游时,排队网络中的队列逐渐变小。由于 Web 服务器设置为处理 75 个并发客户机,因此 200 个客户机请求到达 Web 服务器时,有 125 个请求在网络中保持排队。将 75 个请求从 Web 服务器传递到 Web 容器时,25 个请求在 Web 服务器中保持排队,而其余 50 个请求由 Web 容器处理。此过程在数据源进行,直到 25 个用户请求到达最终目标 - 数据库服务器。由于有工作正在等待进入每个上游的点上的组件,所以此系统中没有组件必须等待工作到达。成批的请求在 WebSphere Application Server 外部的网络中等待。此配置类型会增加稳定性,因为没有组件超负荷。

    然后,您可以使用 Edge Server 将等待用户引向 WebSphere Application Server 集群中的其他服务器。

  • 画吞吐量曲线以确定何时最大化系统功能

    您可以这样使用表示生产应用程序的全部本质的测试用例:使用所有有意义的代码路径或使用生产应用程序。运行一组实验以确定系统功能何时完全激发,或何时达到饱和点。在从应用程序除去大多数瓶颈后,才进行这些测试。这些测试的目标是推动 CPU 的利用率接近 100%。要获取整个系统的最大并发性,用大队列启动初始基线实验。例如,限定排队网络(Web 服务器、Web 容器和数据源)中每个服务器中的队列大小为 100,开始第一个实验。开始一系列实验以标绘吞吐量曲线,在每次实验后增加并发用户负载。例如,与 1 个用户、2 个用户、5 个、10 个、25 个、50 个、100 个、150 个和 200 个用户协同执行实验。在每次运行后,记录每秒的吞吐量请求数,和每个请求的响应时间(以秒为单位)。由基线实验产生的曲线与以下所示典型吞吐量曲线类似:

    吞吐量曲线

    WebSphere Application Server 吞吐量是整个系统中存在的并发请求数的应变量。A 部分(轻负载区域)显示并发用户请求数增加,吞吐量几乎随请求数线性增加。负载较轻时,并发请求在 WebSphere Application Server 系统队列中遇到的拥塞很少。达到某个程度后,拥塞开始变得愈加严重,而且吞吐量的增加速率大幅下降,直到达到表示最大吞吐量值(由 WebSphere Application Server 系统中的某些瓶颈确定)的饱和点为止。WebSphere Application Server 机器 CPU 充分利用时发生的瓶颈是最容易管理的类型,这是因为添加 CPU 或添加更强大的 CPU 即可消除瓶颈。

    在重负载区域或 B 部分中,当并发客户机负载增加时,吞吐量保持相对不变。然而,响应时间会随用户负载按比例增加。即如果用户负载在重负载区域中加倍,那么响应时间也加倍。在某些点上,由 C 部分(崩溃区域)表示,某个系统 组件用完。在此点上,吞吐量开始降低。例如,当 Web 服务器上的网络连接数超出网络适配器的限制时,或者请求数超出操作系统的文件句柄数限制时,系统可能进入过速区域。

    如果通过推动 CPU 利用率接近 100% 达到饱和点,那么您可以转移到下一个步骤。如果在系统利用率达到 100% 前发生 CPU 饱和,那么应用程序可能将使另一个瓶颈恶化。例如,应用程序将可能创建这样一种 Java 对象,该对象将在 Java 代码中引起过多的垃圾回收瓶颈。

    管理应用程序瓶颈有两种方法:除去 瓶颈或克隆瓶颈。管理瓶颈的最佳方法是除去它。您可以使用基于 Java 的应用程序概要分析程序,如 Rational Application Developer、Performance Trace Data Visualizer (PTDV)、Borland's Optimizeit、JProbe 或 Jinsight 检查对象利用的全部情况。

  • 当从客户机往下游移动时减少队列大小

    在吞吐量饱和点上的并发用户数表示应用程序的最大并发性。例如,如果应用程序使 WebSphere Application Server 在用户数为 50 时饱和,那么使用 48 个用户可能产生吞吐量与响应时间的最佳组合。此值称为“最大应用程序并发性”值。“最大应用程序并发性”成为调整 WebSphere Application Server 系统队列的首选值。请记住,对于大多数用户来说,容许网络中存在等待;因此,从客户机中向下游更深入浏览时,队列大小应该减小。例如,假定“最大应用程序并发性”值为 48,请使系统队列先使用下列值:Web 服务器 75,Web 容器 50,数据源 45。执行一组其他实验,将这些值稍微调高或调低以找到最佳设置。

    要帮助确定并发用户数,请查看 Tivoli Performance Viewer 中的 Servlet 引擎线程池和并发活动的线程度量值。

  • 调整队列设置以符合访问模式

    在许多情况下,仅小部分请求通过某个队列进入下一个下游队列。在具有许多静态页面的站点中,大量请求在 Web 服务器上完成,而且不会传递到 Web 容器。在这种情况下,Web 服务器队列可以比 Web 容器队列大很多。在上一个示例中,Web 服务器队列设置为 75,而不是更接近于“最大应用程序并发性”值。当不同的组件具有不同的执行时间时,您可以进行类似调整。

    例如,在将 90% 的时间用于处理复杂 Servlet 而仅花费 10% 的时间用于执行简短 JDBC 查询的应用程序中,平均有 10% 的 Servlet 在任何时间都使用数据库连接,因此数据库连接队列可以比 Web 容器队列小很多。相反,如果大多数的 Servlet 执行时间用于对数据库执行复杂查询,请考虑增大 Web 容器和数据源的队列值。请始终监视 WebSphere Application Server 和数据库服务器的 CPU 和内存利用率,以验证 CPU 或内存利用率是否未饱和。


指示主题类型的图标 参考主题



时间戳记图标 最近一次更新时间: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cprf_queuetip
文件名:cprf_queuetip.html