JVM调优；

Server调优； JDBC调优；

WEB、JMS、EJB调优。

数据库调优

核心参数调优；

数据库连接池调优； SQL与索引调优。

应用程序调优 通用代码调优； JDBC代码调优； WEB代码调优； JMS代码调优； EJB代码调优。

操作系统调优

操作系统影响应用程序运行性能的因素主要有：

硬件的配置(CPU、内存、硬盘等)、核心参数、TCP/IP参数以及补丁的情况等。这

里对操作系统的配置,除了更新最新的补丁程序以保证应用程序正常运行之外,就是调整TCP/IP参数、文件描述符,对于个别操作系统还有其它特别的参数调整。

6.5. 性能回归测试

由于性能优化对原有系统进行了相应的修改，所以必须进行相应的回归测试，以检查修改的正确性和有效性。

功能回归测试：测试相应功能的正确； 性能回归测试：测试相应性能的改善。

6.6. 测试报告

测试报告：

对测试进行总结，记录已改进的问题及相关改进的修改，制定未解决问题的对策，提出系统运行、维护和改进建议。

软件性能测试与调优指南 Page 17 of 36

7 附录

7.1附录1:执行性能测试基本原则

原则一：测试前，要确认系统级的关键参数已经基本配置正确（例如：数据库、WEB容器、线程池、JDBC连接池、对象池、JVM、操作系统、应用系统等配置）； 原则二：测试前，要确保测试脚本的业务功能运行正确。

原则三：测试前，清空所有应用日志、调高错误日志的输出级别（Error级），必要时在每次测试前重启应用服务和数据库应用服务；

原则四：调整系统参数时，一次只调整一个，不要同时调整多个，并记录调整前后的系统变化。 原则五：优先测试基线案例。

7.2附录2:性能问题分析原则

原则一：把事实与推测分开，总是用实际的证据来证明你的推测； 原则二：在没有足够证据之前，不对程序进行优化； 原则三：优先验证简单的假设；

原则四：日志文件中没有错误不代表真的没有错误；

原则五：从系统到应用、从外到内进行层层剥离，缩小范围。

确认是系统级问题还是应用级问题；

确认是否外部系统问题（如密码鉴权问题、EJB问题等）； 确认是应用程序问题还是数据库问题。

原则六：范围缩小后，再分割成多个小单元，对每个小单元进行轮番压力测试，来证明或者否

定是那个单元引起性能问题。

7.3附录3:常见性能问题及成因

常见性能问题的六个特征

① 持续缓慢：应用程序一直特别慢，改变负载，对整体响应时间影响很少；

② 随着时间推进越来越慢：负载不变，随着时间推进越来越慢，可能到达某个阈值，系统被锁定或出现大量错误而崩溃；

③ 随着负载增加越来越慢：每增加若干用户，系统明显变慢，用户离开系统，系统恢复原状； ④ 零星挂起或异常错误：可能是负载或某些原因，用户看到页面无法完成并挂起，无法消除； ⑤ 可预见的锁定：一旦出现挂起或错误，就加速出现，直到系统完全锁定。通常要重启系统才解决。

软件性能测试与调优指南 Page 18 of 36

⑥ 突然混乱：系统一直运行正常，可能是一个小时或三天之后，系统突然出项大量错误或锁定。

常见性能问题成因 常见性能问题及成因列表：

性能问题 线性内存泄漏 描述 问题特征 成因 虽然可能有多种外部原因，但最典型的是与资源泄漏有关(例如，没有清理不能被GC回收的大对象，引起大对象不断积累)。 通常是由于向集合(Vector，HashMap) 中加入永远不删除的元素造成的。 糟糕的编码：无限线程在 while(true) 语句以及类可以预见的锁定 循环 资源泄漏 似的语句里阻塞。 JDBC 语句，CICS 事务网关连接，以随着时间越来越慢 及类似的东西被泄漏了，造成桥接层可以预见的锁定 和后端系统的影响。 突然混乱 通常情况下，这是由于遗漏了 finally 块，或者更简单点，就是忘记用 close() 关闭外部资源的对象所造成的。 外部瓶颈问题 后端或者其他外部系统（如鉴权）越持续缓慢 来越慢，同样减缓了应用服务器和应随着负载越来越慢 用程序 外部系统 应用程序通过太大或太多的请求滥用持续缓慢 后端系统。 随着负载越来越慢 咨询专家（负责的第三方或者系统管理员），获取解决外部瓶颈问题的方法。 清除冗余的工作请求 ，批量处理相似的工作请求，把大的请求分解成若干个更小的请求，调整工作请求或后端系统(例如，公共查询关键字的索引)等。 糟糕的编码：CPU一些糟糕的代码进行交互处理时，就持续缓慢 密集的组件 挂起了 CPU，把吞吐速度减慢到爬行随着负载越来越慢 的速度。 中间层问题 实现得很糟糕的桥接层(如JDBC 驱持续缓慢 动程序、数据库连接池管理)，由于对随着负载越来越慢 数据和请求不断的排列、解除排列，从而把所有通过它的流量减慢到爬行速度。这个毛病在早期阶段很容易与外部瓶颈混淆。 内部资源瓶颈：过内部资源(线程池、对象池)变得稀缺。随着负载越来越慢 分配不足：根据预期的最大负载提高检查桥接层和外部系统的版本兼容性。如果有可能，评估不同的桥接供应商。如果重新规划架构，有可能完全不需要桥接。 典型的解决方案就是数据高速缓存。 需要对循环进行大刀阔斧的删剪。 每单位(每事务、每用户等)泄漏造成随着时间越来越慢 内存随着时间或负载线性增长。这会随着负载越来越慢 随着时间或负载增长降低系统性能。只有重启才有可能恢复。 指数方式内存泄双倍增长的内存泄漏造成系统内存消随着时间越来越慢 漏 耗表现为时间的指数曲线 随着负载越来越慢 度使用或分配不是在正确使用的情况下加大负载时出零星的挂起或异常错误 池的最大尺寸。过度使用：请参阅外软件性能测试与调优指南 Page 19 of 36

足 不停止的重试 现过度使用还是因为泄漏？ 这包括对失败请求连续的(或者在极可以预见的锁定 端情况下无休止的)重试。 突然混乱 部系统的过度使用。 可能是后端系统完全当机，或者网络连接中断。 可能同步是不必要的(只要重新设线程：阻塞点 线程遇到同步阻塞，造成交通阻塞。 随着负载越来越慢 零星的挂起或异常错误 计)，或者比较外在的锁定策略(例如，可以预见的锁定 突然混乱 线程：死锁/活动这是基本的“获得顺序”的问题。 锁 突然混乱 “获得顺序”的算法不合理。 读/写锁)也许会有帮助。

7.4附录4:常用监控指标

诊断性能问题，需要清楚监控的关键指标，以此辅助试验诊断，最后验证推测。

常用监控的关键指标

可见性：

Memory、CPU、DISKIO的指标可以使用操作系统提供的工具来监控。

Java堆栈：可以打开verbose：gc 开关来监控，也可以用更直观的Jprofiler监控工具。

计时：

LoadRunner工具有事务计时，组件或方法的计时可以用Jprofiler监控工具，或者应用程序加debug观察。 内部资源：

监控线程池、数据库连接池、对象池等资源分配的数量、使用的数量、等待的数量、死亡的数量、消耗的时间等等。

提示：内部资源的监控对诊断性能问题起到至关重要的作用。

WebLogic自带的监控工具，基本满足对内部资源的监控。

也可以用Jprofiler监控线程的使用，监控对象、方法动态占有内存的信息。 自编的数据库连接池或使用tomcat等的数据库连接池，需要在应用程序中加上debug观察动态使用信息。

外部资源：

例如EJB外部资源，监控对外部资源连接的数量、使用数量、等待的数量、消耗的时间等等。

WebLogic自带的监控工具，基本满足对外部部资源的监控。 可以在应用程序中加上debug观察外部资源动态使用信息。 可以用外部资源自带工具监控外部资源。

软件性能测试与调优指南 Page 20 of 36