负载测试客户机
性能测试环境的客户机端对性能测试结果有重大影响。传统的负载测试工具作为代理程序在几台客户机机器上运行。您需要不止一台客户机机器来生成有代表性的容量负载，这是因为 CPU 和内存限制了同时收集准确结果的客户机所能真实代表的用户的数量。
图 3. 负载测试客户机使容量流向服务器环境
在图 3 中，我们的三台负载测试客户机正把负载应用到性能测试环境中的服务器。请注意负载测试客户机没有驻留在应用程序服务器上。客户机应该总是位于与应用程序服务器不同的机器上。
专用的客户机
负载测试客户机机器应被完全专用于负载测试任务。竞争本地 CPU、内存和磁盘资源的其他应用程序不能共享这些机器。这种对本地资源的竞争确实会影响被测量的响应的可靠性。客户机机器应保持在相同的路由器和网络配置上并尽可能地（在网络连接的意义上）接近专用的服务器环境。
还有，负载测试客户机必须能够生成装入涉及的应用程序所需的正确类型的请求。例如，基于对 EJB 的 RMI 访问的应用程序不同于测试对 JSP 或 servlet 框架的基于 HTTP 的请求。
测试的基线和一致性
专用的负载测试机器在不同的性能测试运行之间提供了一致性。在运行于 WebSphere Application Server 的应用程序的性能测试规划的第一步中，有一步是记录一组结果的基线。仅当整个测试情景可被一致地再次产生时（也就是说，您总是可以再次运行基线并获取相同的结果。）基线才是有关的。偶然交换负载测试机器或它们的配置将增加完成“基线”任务的困难（甚至无法完成该任务），此外，这至少会使性能数据的分析含糊不清。
超时
请把客户机页面超时设置为 2 分钟或更短。这将在应用程序没有在合理的时间里作出响应时使客户机端出现错误。很少有用户能够忍受太长的响应时间。
收集和测量结果
v整个收集性能数据的练习的一部分涉及获取代表 Java 虚拟机（Java Virtual Machine，JVM）或应用程序服务器的特征的尺度。查看应用程序服务器本身的不同资源以及它们与应用程序的其余部分有关的表现情况的能力是很宝贵的。WebSphere Resource Analyzer 就是一个这样的工具，它提供基于每台服务器的时间开销和资源分配值。其他成熟的工具（例如 Wily's Introscope™ 和 IBM Tivoli® Monitoring V5.1 WebSphere PAC）提供带有补充功能的更多深度数据收集，例如把群集中的多台服务器中的数据编译成一个视图和把收集来的尺度作为历史归档保存到数据库。这些工具还通常在生产监视环境中观察许多相同的关键的应用程序性能点从而肩负双重责任。事实上，性能测试活动可指出在生产中应被监视的应用程序性能点。
图 4. 应用程序监视
在图 4 中，应用程序监视可获取指出应用程序瓶颈和／或后端资源的问题的尺度。
无论您选择什么工具，应用程序监视都是性能测试和问题确定中的一个重要因素。监视提供的能力可测量针对后端资源的应用程序 servlet、JSP 和 EJB 的响应时间，也可测量针对那些由负载测试客户机测量的东西的响应时间。这些尺度有助于识别应用程序的作用域内或作用域外需要关注的问题所在。
