一则性能测试问题分析案例

目录

前言:

1 线程堆栈

2 问题现象

3 问题分析

4 最后小结


前言:

性能测试是软件开发过程中非常重要的一环,可以帮助我们发现和解决性能瓶颈问题。

1 线程堆栈

线程堆栈也称作线程调用堆栈。Java 线程堆栈是虚拟机中线程(包括锁)状态的一个瞬间快照,即系统在某个时刻所有线程的运行状态,包括每一个线程的调用堆栈,锁的持有情况等信息,从线程堆栈中可以得到以下信息:

线程的名字,ID,线程的数量等;

线程的运行状态,锁的状态(锁被那个线程持有,哪个线程在等待锁等);

函数间的调用关系,包括完整类名,所执行的方法,源代码的行数等;

2 问题现象

在测试一个场景时,发现响应时间很长,日志也无报错现象,根据调用链逐级定位,发现 80% 的时间都是消耗在 DAO 层的方法上,这时首先考虑的是 sql 会不会有问题?于是找 DBA 同学帮忙抓 sql 看下,但 DBA 同学反映 sql 执行很快,执行计划也没有问题,那问题出现在哪里呢,找不到原因就看下线程堆栈,系统在 dao 层方法后做了什么?

此时就 jstack 就派上用场了。

jstack 使用,一般来说执行 jstack -l pid > test.txt,然后查看 test.txt 文件即可观察对比线程堆栈。

jstack 线程堆栈如下:


"DubboServerHandler-10.165.184.51:20881-thread-200" daemon prio=10 tid=0x00007f2fd6208800 nid=0x504b waiting on condition [0x00007f2fc0280000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x000000078172f2c0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
at com.alibaba.druid.pool.DruidDataSource.pollLast(DruidDataSource.java:1487)
at com.alibaba.druid.pool.DruidDataSource.getConnectionInternal(DruidDataSource.java:1086)
at com.alibaba.druid.pool.DruidDataSource.getConnectionDirect(DruidDataSource.java:953)
at com.alibaba.druid.filter.FilterChainImpl.dataSource_connect(FilterChainImpl.java:4544)
at com.alibaba.druid.filter.logging.LogFilter.dataSource_getConnection(LogFilter.java:827)
at com.alibaba.druid.filter.FilterChainImpl.dataSource_connect(FilterChainImpl.java:4540)
at com.alibaba.druid.pool.DruidDataSource.getConnection(DruidDataSource.java:931)
at com.alibaba.druid.pool.DruidDataSource.getConnection(DruidDataSource.java:923)
at com.alibaba.druid.pool.DruidDataSource.getConnection(DruidDataSource.java:100)
at org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:111)
at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:77)
at org.mybatis.spring.transaction.SpringManagedTransaction.openConnection(SpringManagedTransaction.java:81)
at org.mybatis.spring.transaction.SpringManagedTransaction.getConnection(SpringManagedTransaction.java:67)
at org.apache.ibatis.executor.BaseExecutor.getConnection(BaseExecutor.java:279)
at org.apache.ibatis.executor.SimpleExecutor.prepareStatement(SimpleExecutor.java:72)
at org.apache.ibatis.executor.SimpleExecutor.doQuery(SimpleExecutor.java:59)
...

3 问题分析

先关注线程状态,发现堆栈信息里大量的 dubbo 线程处于 TIMED_WAITING 状态,从 “waiting on condition” 可以看出系统在等待一个条件发生,这时的线程处于 sleep 状态,一般会有超时时间唤醒,一般出现 TIMED_WAITING 很正常,一些等待 IO 都会出现这种状态,但是大量的 TIMED_WAITING 就要找原因了,观察线程堆栈发现处于 TIMED_WAITING 状态的线程都在等待 druid 获取连接池的连接,这种现象很像连接池不够用了,于是增加数据库连接池的连接数,TPS 直接提升了 3 倍。

4 最后小结

在遇到一些系统挂起无响应,系统 CPU 较高,系统运行的响应时间长,线程死锁等现象的时候,可以利用 jstack 多执行对比几次线程堆栈情况,看看到底哪里出问题。

  作为一位过来人也是希望大家少走一些弯路

在这里我给大家分享一些自动化测试前进之路的必须品,希望能对你带来帮助。

(软件测试相关资料,自动化测试相关资料,技术问题答疑等等)

相信能使你更好的进步!

点击下方小卡片

【自动化测试交流】:574737577(备注ccc)http://qm.qq.com/cgi-bin/qm/qr?_wv=1027&k=1awhv601XkPBTWLDugKsKxC-TiEUo8Em&authKey=yynS50gXtxeVb%2BhznGONzzFQQ3e9RHhTfKLNTfk87rZ4ZTkqT22rKw0Fi4kHaL3V&noverify=0&group_code=574737577

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值