问题现象测试部搭建自动化的测试环境，结果界面又卡顿了

在工作过程中，我们经常会收到来自测试部门的界面跳转、卡顿等问题，尤其是在压力测试的时候。对于卡死的问题，总是需要我们大量的时间来定位问题。即使问题定位到了，我们仍然需要花费大量的时间去思考优化的方案并进行验证。如果验证失败，我们需要重新考虑新的解决方案。，等等。

最近遇到了多层嵌套导致纸箱在工作的问题。虽然很快就找到了问题的原因大循环的for循环的时间优化，但还是花了一周的时间才找到解决问题的办法。因此，将分析和解决过程记录在这里。，一方面是对自己的总结，方便后续复习，另一方面也是分享出来，希望可以作为遇到类似问题的人的参考。

问题现象

测试部门搭建自动化测试环境，在机器上创建用户，先存储图片，再将图片发送到服务器，并限制发送速度，使存储和发送的操作不断进行。由于网络速度限制，待发送界面上显示的数据会不断累积，达到数千甚至数万。当接口上要发送的队列超过4000个时，操作接口就卡住了。

分析过程

测试部报告问题后，立即前往现场获取相关信息，但根据现有信息无法找到问题原因，推测与网络有关，于是重启机器并发现问题不再卡住。用户未激活。重新激活用户后，界面又卡住了。找到解决问题的方法后，自然就找到了导致卡死的代码位置。

原来问题出在两个for循环上。vct_data向量的大小4000多，vct_image向量的大小也4000多。两个嵌套for循环的执行次数为1600万次。耗时超过8秒。

找到问题的原因后，下一步就是寻找解决方案。

解决方案

由于获取当前用户所有要发送的命令和要发送的图片的数据源是数据库，所以首先考虑的方案是创建一个视图，将两个数据库表合并，然后应用程序直接获取结果信息从视图上看，从而替换了两个嵌套的for循环。

经验验证了这种方案是可行的，但是由于需要修改数据库，修改量大，所以暂时不考虑。

然后考虑从数据结构上进行优化。由于table_image中的uid是唯一的，而table_command中的uid可能会重复，那么通过尽可能减少执行次数来优化。从下图中的处理方法可以看出，当找到匹配条件时，从vct_data中获取所有的量大循环的for循环的时间优化，然后删除vct_image中的对应项，最后执行break退出循环。

经验证，这个方案只能减少冻结的时间，但随着数量的不断增加，冻结的时间也会不断增加，所以不是最优解，不采用。

最后想到的方案是最优的，不需要修改数据库，改动量也比较小。解决的办法是修改查询数据库的方法，使用数据库的关键字IN来达到获取相关数据的目的，从而替换嵌套的for循环。将从数据库table_image获取的所有uid传入数据库的查询语句IN中。

总结

在工作过程中遇到困难时，往往需要从不同的角度进行分析，以找到问题的最优解。卡顿的问题，当然是从场景中获取必要的数据，以便尽快找到问题的根源，并且可以从三个角度着手解决，首先是直观的解决方案，第二个是数据结构，第三个是解决方案。三种查询方式。