性能测试：通过一个案例（等待锁超时）告诉你，性能到底要不要熟悉业务逻辑？

前几天，分享了《一篇文章告诉你怎么做性能测试》一文，收到一些朋友的反馈；

有些朋友说，做性能，不需要了解业务逻辑，直接按接口文档，或者抓包写压测接口的脚本，然后压测、监控、分析、调优、回归；

我觉得这样的回答，可能是他们没吃过不熟悉业务逻辑的亏；

最近压测的时候，遇到一个等待锁超时的问题，就是因为不熟悉业务逻辑造成设计的脚本不合理，下面和大家分享一下：

由于是临时任务、时间紧迫、对应的开发又出差了，他远程信誓旦旦给我说直接压，根本不给我熟悉业务逻辑的机会，赶鸭子上架一样；

请求参数用户名是变化的，做了参数化，由于各种客观因素，参数数据只准备了100个，参数取值策略是唯一、用完后循环；

当压一会儿后，就会出现下面的错：等待锁超时

 

 

经过分析定位（过程暂时略过，本文重点是说明熟悉业务逻辑的重要性），问题的原因是如果相同用户反复请求，会出现等待锁超时，因为相同用户从第二次请求开始，都是update操作，会锁行数据，其余更新相同数据的请求就等待，最终出现超时，经和开发沟通，确实如此，且这种场景的概率是很低的，随后协调资源，重新调整了压测脚本的参数数据量，相同用户只发送一次请求，重新压测，未出现此问题；

所以，压测前熟悉业务逻辑是非常有必要的，除了可以设计合理的性能脚本，还可以在分析定位的时候，方便我们定位代码逻辑问题。