前言：有些朋友说，做性能，不需要了解业务逻辑，直接按接口文档，或者抓包写压测接口的脚本，然后压测、监控、分析、调优、回归；
我觉得这样的回答，可能是他们没吃过不熟悉业务逻辑的亏；
最近压测的时候，遇到一个等待锁超时的问题，就是因为不熟悉业务逻辑造成设计的脚本不合理，下面和大家分享一下！
由于是临时任务、时间紧迫、对应的开发又出差了，他远程信誓旦旦给我说直接压，根本不给我熟悉业务逻辑的机会，赶鸭子上架一样；
请求参数用户名是变化的，做了参数化，由于各种客观因素，参数数据只准备了100个，参数取值策略是唯一、用完后循环；
当压一会儿后，就会出现下面的错：等待锁超时。
经过分析定位，问题的原因是如果相同用户反复请求，会出现等待锁超时，因为相同用户从第二次请求开始，都是update操作，会锁行数据，其余更新相同数据的请求就等待，最终出现超时，经和开发沟通，确实如此，且这种场景的概率是很低的，随后协调资源，重新调整了压测脚本的参数数据量，相同用户只发送一次请求，重新压测，未出现此问题；
所以，压测前熟悉业务逻辑是非常有必要的，除了可以设计合理的性能脚本，还可以在分析定位的时候，方便我们定位代码逻辑问题。