性能理论八:测试流程之常见性能问题及成因

本文探讨了性能测试中常见的六个性能问题:持续缓慢、随时间推移变慢、随负载增加变慢、零星挂起或异常、可预见的锁定以及突然混乱。这些问题可能导致系统效率低下,甚至需要重启才能恢复。

一、常见性能问题的六个特征

 

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

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

③ 随着负载增加越来越慢:每增加若干用户,系统明显变慢,用户离开系统,系统恢复原状;

④ 零星挂起或异常错误:可能是负载或某些原因,用户看到页面无法完成并挂起,无法消除;

⑤ 可预见的锁定:一旦出现挂起或错误,就加速出现,直到系统完全锁定。通常要重启系统才解决。

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

 

 

性能问题

描述

问题特征

成因

线性内存泄漏

每单位(每事务、每用户等)泄漏造成内存随着时间或负载线性增长。这会随着时间或负载增长降低系统性能。只有重启才有可能恢复。

随着时间越来越慢
随着负载越来越慢

虽然可能有多种外部原因,但最典型的是与资源泄漏有关(例如,没有清理不能被GC回收的大对象,引起大对象不断积累)。

指数方式内存泄漏

双倍增长的内存泄漏造成系统内存消耗表现为时间的指数曲线

随着时间越来越慢
随着负载越来越慢

通常是由于向集合(Vector,HashMap) 中加入永远不删除的元素造成的。

糟糕的编码:无限循环

线程在 while(true) 语句以及类似的语句里阻塞。

可以预见的锁定

需要对循环进行大刀阔斧的删剪。

资源泄漏

JDBC 语句,CICS 事务网关连接,以及类似的东西被泄漏了,造成桥接层和后端系统的影响。

随着时间越来越慢
可以预见的锁定

突然混乱

通常情况下,这是由于遗漏了 finally 块,或者更简单点,就是忘记用 close() 关闭外部资源的对象所造成的。

外部瓶颈问题

后端或者其他外部系统(如鉴权)越来越慢,同样减缓了应用服务器和应用程序

持续缓慢
随着负载越来越慢

咨询专家(负责的第三方或者系统管理员),获取解决外部瓶颈问题的方法。

外部系统

应用程序通过太大或太多的请求滥用后端系统。

持续缓慢
随着负载越来越慢

清除冗余的工作请求 ,批量处理相似的工作请求,把大的请求分解成若干个更小的请求,调整工作请求或后端系统(例如,公共查询关键字的索引)等。

糟糕的编码:CPU密集的组件

一些糟糕的代码进行交互处理时,就挂起了 CPU,把吞吐速度减慢到爬行的速度。

持续缓慢
随着负载越来越慢

典型的解决方案就是数据高速缓存。

中间层问题

实现得很糟糕的桥接层(如JDBC 驱动程序、数据库连接池管理),由于对数据和请求不断的排列、解除排列,从而把所有通过它的流量减慢到爬行速度。这个毛病在早期阶段很容易与外部瓶颈混淆。

持续缓慢
随着负载越来越慢

检查桥接层和外部系统的版本兼容性。如果有可能,评估不同的桥接供应商。如果重新规划架构,有可能完全不需要桥接。

内部资源瓶颈:过度使用或分配不足

内部资源(线程池、对象池)变得稀缺。是在正确使用的情况下加大负载时出现过度使用还是因为泄漏?

随着负载越来越慢
零星的挂起或异常错误

分配不足:根据预期的最大负载提高池的最大尺寸。过度使用:请参阅外部系统的过度使用。

不停止的重试

这包括对失败请求连续的(或者在极端情况下无休止的)重试。

可以预见的锁定
突然混乱

可能是后端系统完全当机,或者网络连接中断。

线程:阻塞点

线程遇到同步阻塞,造成交通阻塞。

随着负载越来越慢
零星的挂起或异常错误
可以预见的锁定
突然混乱

可能同步是不必要的(只要重新设计),或者比较外在的锁定策略(例如,读/写锁)也许会有帮助。

线程:死锁/活动锁

这是基本的“获得顺序”的问题。

突然混乱

“获得顺序”的算法不合理。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值