什么，项目“生病了”？我来看！

性能测试工程师可以比作为医生，看病象，定位病因。下面分享几个实际项目中的性能分析案例。

一: 某项目组件同步锁导致tomcat线程大量阻塞

现象：100并发，某个提交事务响应时间很长(7秒左右)，其他事务响应时间正常。且存在偶尔报错(因日志配置有问题，后台看不到错误日志)。LR报错显示：

 Error -26612: HTTP Status-Code=500 (Internal Server Error) for…

定位：

1. 服务器内存，cpu,IO 都正常，也排除数据库的原因。

2.用jstack查看线程信息，发现有大量tomcat线程阻塞，阻塞信息截图如下：

3. 根据提示信息找到对应组件ark-workflow-1.0 jar(可从部署的服务器获取jar包)，进行反编译查看WorkflowUtils代码，发现一个synchronized代码块。如下：

 

4. 结合前面的线程堆栈信息应该这里同步锁导致线程阻塞。

 

二：某项目测试脚本关联不到位导致请求响应慢(自己埋的坑…)

现象：20并发，某个审核事务响应时间很长，9s左右，其他事务响应时间正常。

定位：

1. 一开始以为跟问题一的提交事务相似原因，但查看线程快照正常。

2. 导出AWR报告，发现有大量enq: TX - row lock contention事件。

PFMC_PLAN_GROUP行锁很严重

3. 查资料看了下导致enq: TX - row lock contention的原因：

第一种情况，是真正的业务逻辑上的行锁冲突，一条记录被多个人同时操作如同时更新。这种锁对应的请求模式是6。

第二种情况，是唯一键冲突，就是如主键字段相同的多条记录同时插入。这种锁对应的请求模式是4。这也是应用逻辑问题。

第三种情况，是bitmap索引块上更新冲突，就是多个会话同时更新bitmap索引上同一个数据块.

4. 另外发现有条sql执行特别慢，是update PFMC_PLAN_GROUP表的,where条件就是唯一索引id。按测试场景来说这种情况不应该出现，猜测自己脚本有问题。

5. 看了下审核请求的post请求参数，果然group id是个固定值，未做关联(请求参数太多，看花了眼…)

6. 修改后重新压了下，问题解决。

三：某项目附件上传rest接口并发问题

现象: 该接口在并发时，请求返回正常，但 rest服务后台报异常，错误日志如下：

问题定位：

1. 查看上传的图片格式是否正确，结果是正确。（日志里有显示“Not a JPEG file ”）;

2. 查看接口代码，找到相关代码，看到下面有图片的代码，猜测是删图片导致的，然后看到上面给图片名变量赋的值是固定的，确定是并发时删同名图片文件引起的。

 

3. 上面猜测验证：基准测试重新跑一遍，查看后台日志(接口结果不能体现错误)，发现一切正常，无报错。再并发5路跑一遍，后台日志报以上错误。说明这个问题只会在并发的时候出现。