搜索
基于WebSphereApplicationServer的应用程序的性能测试规划本文内容包括：引言性能测试环境设置性能期望测试规划记录并评估结果结束语参考资料在本文中，AlexandrePolozoff提供对基于WebSphereApplicationServer的应用程序进行性能测试的规划，其中有关于规划、建立性能环境、进行实际的测试和测量应用程序的特征的信息。性能测试是确定应用程序在各种负载情景中的（JVM、连接池等）最佳设置的唯一方式。每个应用程序是不同的且在不同的条件下的行为也不同，这意味着所有应用程序在生产环境中被实现前必须经历性能测试活动。引言protocol（规划）一词被定义为“科学的或医学的实验、处理或过程的详细规划”。本文提供对基于WebSphere®ApplicationServer的应用程序进行性能测试的规划，其中有关于规划、建立性能环境、进行实际的测试和测量应用程序的特征的信息。性能测试是确定应用程序在各种负载情景中的（JVM、连接池等）最佳设置的唯一方式。每个应用程序是不同的且在不同的条件下的行为也不同，这意味着所有应用程序在生产环境中被实现前必须经历性能测试活动。性能测试环境在理想的情况下，性能测试环境应在每个细节（从服务器防火墙和后端资源的数量到网络电缆的规格）上完全模仿生产环境。然而，由于大容量生产环境的大小和规模，这是不实际的。包括最少两台或三台在物理上分离的WebSphereApplicationServer机器的更小的环境是更典型的性能测试的基本配置。图1.基本的性能环境如图1所示，分布式空间中的基本的性能环境有两台连接到远程数据库并由一台远程HTTP服务器驱动的在物理上分离的WebSphereApplicationServer。如果HTTP服务器在应用程序的生产环境中是远程的，那么最好使性能环境中的HTTP服务器也是远程的。每台WebSphereApplicationServer在自己的节点上独立运行。运行与测试无关的其他应用程序将引入针对本地CPU、内存和磁盘资源的竞争。这不仅会影响测试的结果，而且这些应用程序与环境的资源的交互是难以估量的。这两台WebSphereApplicationServer至少应该有相同的机器和OS级别的配置。常见的错误包括一台或另一台应用程序服务器使用不同的OS补丁或修订包级别或不同的内存配置，这将导致不一致的结果和／或行为。作为题外话，请您一定要确保每台服务器的TCP/IP堆栈设置完全相同，尤其是NIC卡的双工设置。在理想的情况下，虽然应用程序数据不必驻留在与管理资源库相同的数据库服务器上，但是管理资源库的所有应用程序数据和数据库将驻留在一台远程的机器上。如果启用了HTTP会话持久性，请确保会话表与其他数据库分离且被标记为VOLATILE。这并不是说把完全不同的配置用于性能环境是完全不可接受的。在当今的商业环境中，HTTP服务器常常驻留在每个本地的WebSphereApplicationServer节点上。然而，其中一台WebSphereApplicationServer还作为管理资源库的数据库从而肩负双重责任是不太合乎需要的。这些配置特征和其他配置特征违反了“应用程序不应该参与本地资源的竞争”的约束。性能环境中的这些不平衡可能使最终结果不准确，在许多时候确实如此。然而，虽然折衷的性能测试环境肯定不是更好的选择，但是拥有几乎任何类型的性能测试环境都要比没有环境好。专用的服务器环境显然，测试环境应尽可能地与生产环境相似，因为任何差异（任何方面的差异）将引入不确定性。如果您缩小测试环境，那么您必须扩大结果以取得生产环境中的近似数字。类似地，如果HTTP服务器在生产中是独立的，但在测试中被包括在应用程序服务器节点上，那么取得的性能结果也不能准确地反映生产中的结果。配置测试环境是作出选择和让步以获取可能取得的最精确的数据的过程。理想的性能测试环境由专用的服务器机器与连接它们的专用网络组成。如果基于WebSphereApplicationServer的应用程序的服务器也作为其他无关的应用程序或配置的服务器在运行，那么进行性能测试是困难的。您应该将对本地CPU、内存和磁盘资源的竞争减少到最小，这一点至关重要。也许最大的困难是把后端资源专用于性能测试。由于在有些安装的操作策略和复制成本，专用的服务器环境并不总是可能的。这一点可以解释为什么人们常常在“夜晚”（此时的后端资源处在轻（或更轻的）负载条件下）运行性能测试。然而，因特网的世界正在不断地使后端资源的利用率达到极限，与此同时跨国公司正向24/7运营的方向发展。缺乏专用的服务器环境可能使性能测试陷于困境。非专用服务器环境中的一些有问题的情景包括：共享的网络资源：该组织的内部网共享性能环境。这可能造成时有时无的性能结果，这与测试时网络的利用率直接有关。例如，如果有人开始大量利用网络的网络备份，那么这将增加响应时间甚至完全拒绝性能环境中的组件的网络连接。在这种情况下网络嗅探器可被用来帮助了解网络带宽的利用率并确定什么时候的负面响应时间不是由于应用程序造成的。如果您在这种环境中进行性能测试，那么您将遇到很多挫折，这种环境的效率也很低。共享的后端资源：多个应用程序试图访问相同或相关的数据。这也可能导致比正常情况更慢的响应时间，而且如果在测试中没有直接监视后端资源的工具的帮助来了解利用图，这是难以识别的情况。此外，其他应用程序可能在更改后端资源上的数据，这将增加重复测试的困难，甚至不可能进行。运行多个被测试的应用程序的WebSphereApplicationServer意味着应用程序和HTTP服务器都受到多个测试的额外压力。这是一个完全合理的可运行的情景，因为它进行了多个应用程序的性能系统集成测试。WebSphereApplicationServer环境的基本配置WebSphereApplicationServer环境的一些基本配置常常被误解或被错误地配置。分层的“门”一种配置是限制从因特网到WebSphereApplicationServer并最终到后端资源的请求。限制请求的原因是针对应用程序的最佳性能特征来配置它。负载曲线中有一点表示响应时间的增加的直接原因是应用程序处理的请求的数量。当您使用这里描述的规划来确定了这一点后，您就可以“限制”应用程序处理的请求的数量。结果，在应用程序能够处理下一个请求前，在HTTP服务器中应使进入的请求排队。您可以通过配置基础结构中三个不同的点来实现限制，这些点可控制流向下一层的请求的流动和容量。图2.限制请求图2显示了基础结构中的主要组件，从左边开始，请求从因特网进入HTTP服务器，然后请求被发送到WebSphereApplicationServer，在这里，应用程序连接到后端资源（例如数据库）。在图中的每一个箭头（共三个）中有一个配置点，这个点可限制进入应用程序并接着进入后端资源的入站请求。限制进入环境的请求可以对最大工作负载调优并提供良好的用户体验。限制规划这里描述的限制规划是基于推荐的WebSphereApplicationServer最佳实践、摘自红皮书且被编排过的信息和在大容量客户位置所获得的经验。根据基础结构中的三个配置点，这个规划有三个步骤：1.HTTP服务器并发请求的最大个数WebSphereApplicationServer支持的Web服务器都提供定义可接受的并发请求（而不是并发用户）的最大个数的功能。在这里用户与请求的区别被指出，因为包括几个图像的一个HTML页面将导致来自一个用户的多个请求。在Apache的世界中，最大的并发请求“门”完全由MaxClients设置来控制。（在iPlanet上相应的设置是ThrottleRequests。）对本地的静态内容的请求由Web服务器来处理，对应用程序的请求被转发给WebSphere插件，WebSphere插件再把请求向外发送给应用程序。Web服务器既处理对本地的静态内容的请求，也处理对应用程序的请求。为了确定MaxClients的值，您需要分析发送给浏览器的内容和应用程序服务器中servlet引擎线程的最大个数。对于任何使用一台Web服务器和一台应用程序服务器的应用程序，用于设置初始值的一般原则是：maxClients=imageContentPerPage*maxServletEngineThreads其中imageContentPerPage表示HTML响应中图像的平均（或最大）的个数，maxServletEngineThreads表示为应用程序服务器定义的servlet引擎线程的最大个数。这个公式的外推法是基于WebSphereApplicationServer的环境。例如，请考虑有三台Web服务器为两台应用程序服务器（它们可以是相同的ServerGroup中的克隆）提供输入的情景。那么，公式将变成：maxClients=imageContentPerPage*maxServletEngineThreads*numberApplicationClones/numWebServers如果maxClients的值太小，那么负载测试客户机将遇到连接错误，这是因为Web服务器上的可用的侦听器太少。在这种情况下应使maxClients的值变大。2.servlet引擎线程的最大个数您可以通过分析性能测试结果来确定servlet引擎线程的最大个数。不存在用于设置这个最大个数的有效的“通用”值，在通常情况下，缺省值25对于大容量的应用程序来说太小了。在设置servlet引擎线程个数的最大值时请记住最大JVM堆大小设置的数量。每个servlet引擎线程被分配给它自己的堆栈，该堆栈将消耗JVM中的内存。由于每个servlet线程在负载条件下处理请求，您还需考虑在该活动期间创建的对象的个数。请确保JVM最大堆大小的设置足够的大以支持增大的servlet引擎线程个数并避免内存不足的条件。另外，别忘了您很可能需要启用生成的垃圾收集（请参阅WebSphereApplicationServerInfoCenterPerformanceTuningGuide中的定义）。您实际使用的最大值应完全由负载和强度测试期间的应用程序监视结果来确定。请使用应用程序监视器来确定是否所有的servlet引擎线程被建立，然后相应地调整最大值并再次运行测试。请记住如果您更改了servlet引擎线程的最大个数，那么您还应对Web服务器上的MaxClients参数作相应的更改。3.最大的连接池大小链中的最后一个“门”是应用程序访问的数据源的连接池的大小。有关连接池的文档（请参阅参考资料）指出应用程序在执行它们的事务时应该短暂地维持数据库连接。这将使几个数据库连接的高效管理和共享成为可能。广泛接受的数据源连接的最大值是40，即使在大容量的安装中也是40，典型的应用程序在10至20之间。在这里，您实际使用的最大值完全由负载和强度测试期间的应用程序监视结果来确定。应用程序监视应确定池中被利用的数据源连接的个数。如果最大值的设置是20且所有20个数据源连接在负载下被完全利用，那么请把最大值的设置增加到30。请再次运行测试、再次分析扩大的连接池的利用情况并再次确定连接池是否被完全利用。请根据需要再次调整最大值。为了发现所需的连接的真正的最大个数，作实验是必要的。当打开的连接存在时，形式为影响应用程序性能的内存使用和网络利用的关联开销也存在。虽然确定所需的连接的个数不是准确的科学，但是通过反复实验和应用程序监视，您可以找到可能找到的最佳值。使期望的测试结果相关测试结果应该显示负载测试客户机端所看到的数字与应用程序服务器上的数字之间有某些相关性。例如，如果一台应用程序服务器的三个克隆被配置成每台服务器25个servlet引擎线程并且注意到servlet的响应时间小于一秒，那么您应期望看到至少每秒75或更多个请求通过应用程序服务器。您还应期望在客户机端看不到8秒的响应时间。结果必须同时考虑用于处理静态数据的HTTPSERVER连接的数量。请确保测试结果与您在应