WebSphere Application Server 环境的基本配置

WebSphere Application Server 环境的一些基本配置常常被误解或被错误地配置。

分层的“门”
        一种配置是限制从因特网到 WebSphere Application Server 并最终到后端资源的请求。限制请求的原因是针对应用程序的最佳性能特征来配置它。负载曲线中有一点表示响应时间的增加的直接原因是应用程序处理的请求的数量。当您使用这里描述的规划来确定了这一点后，您就可以“限制”应用程序处理的请求的数量。结果，在应用程序能够处理下一个请求前，在 HTTP 服务器中应使进入的请求排队。您可以通过配置基础结构中三个不同的点来实现限制，这些点可控制流向下一层的请求的流动和容量。

图 2. 限制请求

        图 2 显示了基础结构中的主要组件，从左边开始，请求从因特网进入 HTTP 服务器。然后，请求被发送到 WebSphere Application Server，在这里，应用程序连接到后端资源（例如数据库）。在图中的每一个箭头（共三个）中有一个配置点，这个点可限制进入应用程序并接着进入后端资源的入站请求。限制进入环境的请求可以对最大工作负载调优并提供良好的用户体验。

限制规划 
        这里描述的限制规划是基于推荐的 WebSphere Application Server 最佳实践、摘自红皮书且被编排过的信息和在大容量客户位置所获得的经验。

        根据基础结构中的三个配置点，这个规划有三个步骤：

1. HTTP 服务器并发请求的最大个数

        WebSphere Application Server 支持的 Web 服务器都提供定义可接受的并发请求（而不是并发用户）的最大个数的功能。在这里用户与请求的区别被指出，因为包括几个图像的一个 HTML 页面将导致来自一个用户的多个请求。

        在 Apache 的世界中，最大的并发请求“门”完全由 MaxClients 设置来控制。（在 iPlanet 上相应的设置是 ThrottleRequests。）对本地的静态内容的请求由 Web 服务器来处理，对应用程序的请求被转发给 WebSphere 插件，WebSphere 插件再把请求向外发送给应用程序。

        Web 服务器既处理对本地的静态内容的请求，也处理对应用程序的请求。为了确定 MaxClients 的值，您需要分析发送给浏览器的内容和应用程序服务器中 servlet 引擎线程的最大个数。对于任何使用一台 Web 服务器和一台应用程序服务器的应用程序，用于设置初始值的一般原则是：

maxClient = imageContentPerPage*maxServletEngineThreads

        其中 imageContentPerPage 表示 HTML 响应中图像的平均（或最大）的个数，maxServletEngineThreads 表示为应用程序服务器定义的 servlet 引擎线程的最大个数。

        这个公式的外推法是基于 WebSphere Application Server 的环境。例如，请考虑有三台 Web 服务器为两台应用程序服务器（它们可以是相同的 ServerGroup 中的克隆）提供输入的情景。那么，公式将变成：

maxClient = imageContentPerPage*maxServletEngineThreads*numberApplicationClones/numWebServers

        如果 maxClient 的值太小，那么负载测试客户机将遇到连接错误，这是因为 Web 服务器上的可用的侦听器太少。在这种情况下应使 maxClient 的值变大。

2. servlet 引擎线程的最大个数

        您可以通过分析性能测试结果来确定 servlet 引擎线程的最大个数。不存在用于设置这个最大个数的有效的“通用”值，在通常情况下，缺省值 25 对于大容量的应用程序来说太小了。

        在设置 servlet 引擎线程个数的最大值时请记住最大 JVM 堆大小设置的数量。每个 servlet 引擎线程被分配给它自己的堆栈，该堆栈将消耗 JVM 中的内存。由于每个 servlet 线程在负载条件下处理请求，您还需考虑在该活动期间创建的对象的个数。请确保 JVM 最大堆大小的设置足够的大以支持增大的 servlet 引擎线程个数并避免内存不足的条件。另外，别忘了您很可能需要启用生成的垃圾收集（请参阅 WebSphere Application Server InfoCenter Performance Tuning Guide中的定义）。

        您实际使用的最大值应完全由负载和强度测试期间的应用程序监视结果来确定。请使用应用程序监视器来确定是否所有的 servlet 引擎线程被建立，然后相应地调整最大值并再次运行测试。请记住如果您更改了 servlet 引擎线程的最大个数，那么您还应对 Web 服务器上的 MaxClients 参数作相应的更改。

3. 最大的连接池大小

        链中的最后一个“门”是应用程序访问的数据源的连接池的大小。有关连接池的文档（请参阅 参考资料）指出应用程序在执行它们的事务时应该短暂地维持数据库连接。这将使几个数据库连接的高效管理和共享成为可能。广泛接受的数据源连接的最大值是 40，即使在大容量的安装中也是 40，典型的应用程序在 10 至 20 之间。

        在这里，您实际使用的最大值完全由负载和强度测试期间的应用程序监视结果来确定。应用程序监视应确定池中被利用的数据源连接的个数。如果最大值的设置是 20 且所有 20 个数据源连接在负载下被完全利用，那么请把最大值的设置增加到 30。请再次运行测试、再次分析扩大的连接池的利用情况并再次确定连接池是否被完全利用。请根据需要再次调整最大值。

        为了发现所需的连接的真正的最大个数，作实验是必要的。当打开的连接存在时，形式为影响应用程序性能的内存使用和网络利用的关联开销也存在。虽然确定所需的连接的个数不是准确的科学，但是通过反复实验和应用程序监视，您可以找到可能找到的最佳值。

使期望的测试结果相关

        测试结果应该显示负载测试客户机端所看到的数字与应用程序服务器上的数字之间有某些相关性。例如，如果一台应用程序服务器的三个克隆被配置成每台服务器 25 个 servlet 引擎线程并且注意到 servlet 的响应时间小于一秒，那么您应期望看到至少每秒 75 或更多个请求通过应用程序服务器。您还应期望在客户机端看不到 8 秒的响应时间。结果必须同时考虑用于静态数据的 HTTP 连接的数量。请确保测试结果与您在应用程序服务器的配置中看到的东西相匹配。如果结果不匹配，请确保负载测试客户机没有在运行时发出太多的热量（100% CPU）、出现内存不够或遇到某些网络瓶颈。