一.背景说明
这次代码新增了入参解密,出参加密,然后压测过不了,接口响应时间超过公司规定了,遂排查之,然后做个记录。
二.排查过程
方式一:
打印耗时日志
1.怀疑是加解密算法太耗时,我们是采用RSA+AES的方式;所以先补日志,在代码前后打印耗时。
2.最终看日志发现在将流转换为String耗时比较多,应该是普通io的操作是阻塞的,io的read和write需要阻塞读或者写,在高并发的情况下, 响应不过来。
这种方式比较反锁,而且在修改比较多的情况,需要补大量日志,不是很方便,建议采用第二种方式。
方式二:
1.使用top命令查看cpu,内存使用情况,我们机器是6C6G,可以发现CPU没满,但是load average非常高,说明排队的进程很多,具体情况可参考:
load average是CPU的Load,它所包含的信息不是CPU的使用率状况,而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息,也就是CPU使用队列的长度的统计信息
讲解了cpu和load average
2.所以需要打印出线程信息来分析,使用
jstack -l pid > jstack.log 如jstack -l 14 > jstack.log
3.然后使用
top -Hp pid 查出最占cpu的线程 如top -Hp 14
4