WebUniverse性能调节.docVIP

WebUniverse性能调节 （内部调节） 准备工作 目的 目的：了解WebUniverse的参数对性能的影响，以及WebUniverse下的应用程序自身的哪些特点对应用程序的性能影响比较大，从而得知如何调节管理的参数和程序的参数。 调节内容 本调节是针对网宇应用服务器2.0进行的。主要包括管理部分的调节和程序调节。管理调节主要是调节应用服务器，而程序调节是调节编程过程中用到的技术，包括框架、设计模式、到具体的算法和语句。 管理调节 JVM：虚拟机调节 Web容器调节 EJB容器调节 JDBC调节 程序调节 使用轻量的持久化方法如JDBC取代Entity Bean对性能的影响。 使用DTO设计模式对性能的影响。 性能指标 对各种应用来说，并没有一个统一的性能指标。可能在特定情况下，会把运行速度作为主要指标，但在另外的情况下会把系统所能支持的规模（吞吐量）作为指标。 通常应用系统可以划分为两个基本类别： 交互式的，即当终端用户与应用程序同步交互时。 批处理或后端应用程序，即当不需要直接和用户交互时。 对交互式应用程序，关键的性能属性是响应时间，这是用户所能感受得到的最直接最明显的方面。响应时间很大程度上受到并发用户数的影响。从操作员的观点来看，他们需要知道在硬件资源被耗尽前，应用程序能够处理的用户数量，这时最大用户数又变成了主要因素。 对后端应用程序，最有用的性能指标是吞吐量。表达吞吐量性能的最流行方式是每秒的事务处理（Transactions Per Second, TPS）。 吞吐量 吞吐量是每秒的事务处理（Transactions Per Second, TPS）数量。这里关键的因素是对事务的定义。在某种情况下，一个事务可能是对一次数据库查询的描述，在另一种情况下，它又可能是对一组数据库查询的描述。因此，事务总是针对特定测试案例所说的。 应该明白的是，吞吐量是一个容量（Capacity）测量，而不是一个速度测量。它不是一个像响应时间那样原始的清晰的度量标准。测试条件的小的改变可能导致吞吐量的巨大变化。同时，吞吐量并不能完整描述系统性能，比如高的吞吐量可能是在并发请求小的情况下取得的，而较差的吞吐量又可能是因为应用程序没有完全利用所有硬件资源的结果。 响应时间 在处理交互式应用程序时，响应时间定义为：客户端从发送请求的那一刻起到收到应用程序的最后一个字节所用的时间段。 服务器CPU和内存占用率 CPU和内存占用率一定程度上影响和决定了应用服务器的响应时间和吞吐量。 调节方法 调节工具 The Grinder是我们进行性能调节使用的主要工具。Grinder可用来生成负载和收集数据（服务器的最大吞吐量、平均吞吐量、响应时间、出错率、每秒响应字节数等），且这些数据可来自多个客户端，适合对J2EE应用服务器进行分布式测试，同时它可免费获取。Grinder的工作机制如图1： 图1 方法 在以上性能指标的基础上，确定合适的测试样本、调节数据、测试数据和grinder脚本程序，定义采样方法。 样本和数据 针对不同的调节，准备特定的样本和数据，保证调节的快速和有效性。 Grinder脚本 它包含了运行调节测试时一个特定请求所需要的所有信息：并发进程、线程数，思考时间（请求间隔）等。 采样方法 本测试采用“快照方法”（固定的时间点）采集数据，每个5S/2.5S采集一次数据，为保证所采集数据的稳定性，忽略一定前面一定数量的，不同测试中样本忽略和采集的时间不同。 评价和分析 对我们的测试结果，我们需要引入一个可信度的概念，来评价这个测试结果的精度。一般的J2EE API性能研究的结果是，如果在相同条件下能准确重复同一测试，我们将能够在5%的范围内再现该结果。但考虑到测试环境异常复杂，测试条件很可能不能完全重复，我们将认为在误差范围25%以内，这个测试样本是可以接受的。 针对测试数据，我们主要从吞吐量和响应时间两方面进行不同应用服务器之间的横向对比和WebUniverse内部的纵向两个对比。 其他profiler工具 在服务器端（Linux操作系统）采用vmstat和top来监控系统性能 测试环境 服务器（运行网宇应用服务器的计算机）： Server1（201）：Dell-PowerEdge2600，1G内存，36G*3硬盘，2.4GHZ Server2（208）：Dell-PowerEdge2600，1G内存，72G*3硬盘，2.4GHZ 客户机（运行Grinder的Console和work的计算机） Pc1（14.13）：512M内存、P4、2.4GHZ、Win2K、SP4 Pc2（16.26）：512M内存、P4、2.4GHZ、Win2K、SP4 Pc3：512M内存、P4、2.4GHZ、Win2K、SP4 Pc4：512M内存、Cel