性能测试：一个bug引发的白夜追凶

问题简述

写了一个性能测试脚本，用于从A到B平台并发同步数据的。同步完成后，发现有些数据同步不完整：

如上图，并发40个同步，发现有4个同步不完全。什么原因造成的呢？

等待

考虑到同步需要一些时间，因此我也不急于去排查问题，等个半小时看看情况。

嗯，这是个漫长的等待…

之后，就确认了，这真是个问题。

问题排查

1、现象

如上，我们从B平台前端得到的信息相当有限。

2、查询数据库
根据“label_edge_yeqinfang00000_20200910175329”查询mongodb数据库：

如图，这是通过查询语句查询到的数据，发现transfercount为2，正常应改为3，明显丢包了。

那到底是B平台本身的问题，还是A没传递过来呢？

3、通过关联字段在A平台查询数据库

上图的synctaskid就是A平台传递过来的任务id，查询A平台的数据库：

如图，A平台同步数据包有3个，而B平台少了1个。

4、查看A平台的打包情况

根据数据库的字段“1599731665732”来查看打包情况：

如上图，在存储位置是可以找到该文件的，说明文件已经打包成功，那么，有没有传给B平台呢？

5、查看A平台的发送日志：

如上，打包成功并且已发送。

真相只有一个

通过上述排查，我们已经知道问题出在B平台。很可能是B平台在处理数据的过程中，出现了丢包情况。会不会是没有队列机制导致的？

我们来看看B平台的日志：

将一天的日志输出到桌面，再去查看：

从日志信息看，B平台也没有报错，而且是已经处理了的。

说明什么？处理得可能有问题。也就是处理过程中出现问题了。