7.1附录1:执行性能测试基本原则
原则一：测试前，要确认系统级的关键参数已经基本配置正确(例如：数据库、WEB容器、线程池、JDBC连接池、对象池、JVM、操作系统、应用系统等配置)；
原则二：测试前，要确保测试脚本的业务功能运行正确。
原则三：测试前，清空所有应用日志、调高错误日志的输出级别(Error级)，必要时在每次测试前重启应用服务和数据库应用服务；
原则四：调整系统参数时，一次只调整一个，不要同时调整多个，并记录调整前后的系统变化。
原则五：优先测试基线案例。
7.2附录2:性能问题分析原则
原则一：把事实与推测分开，总是用实际的证据来证明你的推测；
原则二：在没有足够证据之前，不对程序进行优化；
原则三：优先验证简单的假设；
原则四：日志文件中没有错误不代表真的没有错误；
原则五：从系统到应用、从外到内进行层层剥离，缩小范围。
确认是系统级问题还是应用级问题；
确认是否外部系统问题(如密码鉴权问题、EJB问题等)；
确认是应用程序问题还是数据库问题。
原则六：范围缩小后，再分割成多个小单元，对每个小单元进行轮番压力测试，来证明或者否定是那个单元引起性能问题。
7.3附录3:常见性能问题及成因
常见性能问题的六个特征
① 持续缓慢：应用程序一直特别慢，改变负载，对整体响应时间影响很少；
② 随着时间推进越来越慢：负载不变，随着时间推进越来越慢，可能到达某个阈值，系统被锁定或出现大量错误而崩溃；
③ 随着负载增加越来越慢：每增加若干用户，系统明显变慢，用户离开系统，系统恢复原状；
④ 零星挂起或异常错误：可能是负载或某些原因，用户看到页面无法完成并挂起，无法消除；
⑤ 可预见的锁定：一旦出现挂起或错误，就加速出现，直到系统完全锁定。通常要重启系统才解决。
⑥ 突然混乱：系统一直运行正常，可能是一个小时或三天之后，系统突然出项大量错误或锁定。
常见性能问题成因
常见性能问题及成因列表：
性能问题
描述
问题特征
成因
线性内存泄漏
每单位(每事务、每用户等)泄漏造成内存随着时间或负载线性增长。这会随着时间或负载增长降低系统性能。只有重启才有可能恢复。
随着时间越来越慢
随着负载越来越慢
虽然可能有多种外部原因，但最典型的是与资源泄漏有关(例如，没有清理不能被GC回收的大对象，引起大对象不断积累)。
指数方式内存泄漏
双倍增长的内存泄漏造成系统内存消耗表现为时间的指数曲线
随着时间越来越慢
随着负载越来越慢
通常是由于向集合(Vector，HashMap) 中加入永远不删除的元素造成的。
糟糕的编码：无限循环
线程在 while(true) 语句以及类似的语句里阻塞。
可以预见的锁定
需要对循环进行大刀阔斧的删剪。
资源泄漏
JDBC 语句，CICS 事务网关连接，以及类似的东西被泄漏了，造成桥接层和后端系统的影响。
随着时间越来越慢
可以预见的锁定
突然混乱
通常情况下，这是由于遗漏了 finally 块，或者更简单点，就是忘记用 close() 关闭外部资源的对象所造成的。
外部瓶颈问题
后端或者其他外部系统(如鉴权)越来越慢，同样减缓了应用服务器和应用程序
持续缓慢
随着负载越来越慢
咨询专家(负责的第三方或者系统管理员)，获取解决外部瓶颈问题的方法。
外部系统
应用程序通过太大或太多的请求滥用后端系统。
持续缓慢
随着负载越来越慢
清除冗余的工作请求 ，批量处理相似的工作请求，把大的请求分解成若干个更小的请求，调整工作请求或后端系统(例如，公共查询关键字的索引)等。
糟糕的编码：CPU密集的组件
一些糟糕的代码进行交互处理时，就挂起了 CPU，把吞吐速度减慢到爬行的速度。
持续缓慢
随着负载越来越慢
典型的解决方案就是数据高速缓存。
中间层问题
实现得很糟糕的桥接层(如JDBC 驱动程序、数据库连接池管理)，由于对数据和请求不断的排列、解除排列，从而把所有通过它的流量减慢到爬行速度。这个毛病在早期阶段很容易与外部瓶颈混淆。
持续缓慢
随着负载越来越慢
检查桥接层和外部系统的版本兼容性。如果有可能，评估不同的桥接供应商。如果重新规划架构，有可能完全不需要桥接。
内部资源瓶颈：过度使用或分配不足
内部资源(线程池、对象池)变得稀缺。是在正确使用的情况下加大负载时出现过度使用还是因为泄漏？
随着负载越来越慢
零星的挂起或异常错误
分配不足：根据预期的最大负载提高池的最大尺寸。过度使用：请参阅外部系统的过度使用。
不停止的重试
这包括对失败请求连续的(或者在极端情况下无休止的)重试。
可以预见的锁定
突然混乱
可能是后端系统完全当机，或者网络连接中断。
线程：阻塞点
线程遇到同步阻塞，造成交通阻塞。
随着负载越来越慢
零星的挂起或异常错误
可以预见的锁定
突然混乱
可能同步是不必要的(只要重新设计)，或者比较外在的锁定策略(例如，读/写锁)也许会有帮助。
线程：死锁/活动锁
这是基本的“获得顺序”的问题。
突然混乱
“获得顺序”的算法不合理。
7.4附录4:常用监控指标
诊断性能问题，需要清楚监控的关键指标，以此辅助试验诊断，最后验证推测。
常用监控的关键指标
可见性：
Memory、CPU、DISKIO的指标可以使用操作系统提供的工具来监控。
Java堆栈：可以打开verbose：gc 开关来监控，也可以用更直观的Jprofiler监控工具。
计时：
LoadRunner工具有事务计时，组件或方法的计时可以用Jprofiler监控工具，或者应用程序加debug观察。
内部资源：
监控线程池、数据库连接池、对象池等资源分配的数量、使用的数量、等待的数量、死亡的数量、消耗的时间等等。
提示：内部资源的监控对诊断性能问题起到至关重要的作用。
WebLogic自带的监控工具，基本满足对内部资源的监控。
也可以用Jprofiler监控线程的使用，监控对象、方法动态占有内存的信息。
自编的数据库连接池或使用tomcat等的数据库连接池，需要在应用程序中加上debug观察动态使用信息。
外部资源：
例如EJB外部资源，监控对外部资源连接的数量、使用数量、等待的数量、消耗的时间等等。
WebLogic自带的监控工具，基本满足对外部部资源的监控。
可以在应用程序中加上debug观察外部资源动态使用信息。
可以用外部资源自带工具监控外部资源。
7.5附录5:如何诊断数据库的性能问题
是应用程序还是数据库？
诊断性能问题，最常见的也是较难的判断是：是应用程序还是数据库？或者两者都有？
难在那里？
是因为应用程序、数据库、WebLogic Server(Tomcat)都不是在孤立地运转的。因此脱离应用架构单独运行测试诸如SQL计时、JDBC计时、线程计时等等几乎没有作用。
关键是对相互作用的了解
要熟知系统的性能度量；
提示：系统性能度量参见附录4：常见监控指标
了解SQL的结构；
提示：SQL结构可参阅文档《OracleSQL性能优化指南.doc》
了解用户发出的请求在跨越整个系统时的端对端、点对点计时、SQL的计时等；
了解用户发出的请求后所关联的线程、JDBC连接、数据库的活动及其之间的交互关系；
典型的应用数据库问题
典型应用数据库问题的三个类型：过量的数据库调用、数据库连接池问题、SQL语句及其索引或锁定属性问题。
过量的数据库调用
问题
很常见的性能瓶颈来是自过量的数据库调用，引发这些问题不一定是SQL查询的Execute()或Update()，而是应用程序与数据库的交互有关，例如ResultSet操作，常见的问题是指定了过于精细的查询条件，然后使用ResultSet.Next()详细搜寻返回的数据,每次一行。
解决办法
从数据库中大批取得所要求的数据，避免应用程序反复回调数据库。
数据库连接池问题
问题1：连接池资源泄漏
虽然可以通过WebLogic自带工具或Jprofiler工具或自编工具检测到数据库连接池资源泄漏，但是，很难在应用程序代码本身准确定位泄漏的源头！
问题1解决办法
仔细分析程序代码，是否没有close()连接？或者遗漏了finally 块?或者尽管有close()但并没有成功？
问题2：连接池大小
连接池过小会造成新的连接不上，在日志中有错误信息，一般的做法是调大即可，可问题是，调的过大会造成资源无效损耗可能出现新的性能问题，那么调到多大较合适？
问题2解决办法
经验法则1：数据库连接池数＝线程池数X每个线程需要连接数据库平均数X1.1 (1.1的含义是加10%的峰值期负载), 通常, 每个线程需要连接数据库平均数是一个,也即:当线程池数120时, 数据库连接池数就是132。
经验法则2：设置最初池大小＝最大池大小。
SQL语句及其索引或锁定属性问题
问题：SQL语句及其索引或锁定属性不合理
可能引发DISKIO过忙(磁盘读写数据)或者CPU过忙(在内存中索引排序)，造成执行时间过长，阻塞线程的执行，最终引发系统挂起。
或者执行超时引发系统挂起：例如错误信息
oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2857) at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate
或者死锁引发系统挂起：例如错误信息
java.sql.SQLException: ORA-00060: deadlock detected while waiting for resource at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:170)
解决办法
优化SQL语句及其索引或锁定属性。
581
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
