背景

某港口集疏港系统近期出现故障，在凌晨3-5点时段无法上传疫情通勤卡，对港口货物运输带来影响。

该港口已部署NetInside全流量回溯系统，针对本次故障，进行故障定位和原因分析。

分析简介

  操作时间：2022年9月8日星期四，凌晨3点40左右

  操作内容：在集梳港小程序疫情通勤卡，上传一张7M左右的图片

  动机：分析整个操作过程的延时分布情况，视图发现异常

  上传环境：普通100M共享家庭网络

  报告提交时间：2022年9月8日星期四

分析结论

本次上传操作成功。

通勤卡上传动作由2部分组成，图片上传 + 图片回显。

对于一张7M左右的图片：图片上传时间为6.85秒，图片回显时间为4.51秒，图片上传完成到图片回显之间的时间长度为160.27秒（超过2分钟），即空闲等待时间长为160秒，整个操作完成时间约为171.6秒。

由上看到，图片上传时长约3分钟，时间最长的地方在中间等待时段，约160秒左右。

特征发现，图片上传时，每一个报文最大传输大小为协商一致的1412（数据包长度为1466字节）；图片回显时，出现成对的1347和219字节长度报文传输行为，传输效率低下。

详细分析过程

本次分析依据为抓包文件sample6-bigerthan7Mpic-timelong-20220908am3.43-filter.pcapng。

图片上传时间分析

图片上传从frame 28开始。数据包最大长度为1466字节。

图片上传到frame 11591结束，时长共计6.85秒。

图片上传完成与回显之间的延时分析

图片上传完成后，从frame 11593之后，到图片回显期间，都是小程序自动维护信息传输的信息。

这里视为空闲时间，或等待时间。

空闲等待时间，到frame 11625，共计时长160.27秒。

从应用程序操作来看，在上传图片时，显示“上传中…”字样的等待界面时间，主要是这一部分时间。

图片回显时间分析

图片回显数据包传输从frame 11625开始。

图片回显数据传输到frame 22942结束，共计时长4.5秒。

报文传输长度1347+219字节成对模式出现。

解决方案建议

本次访问结果正常，但发现了明显的问题，针对发现的问题，做出如下建议。

关于等待时间

从分析看到，在图片上传完成到图片回显之间，存在明显的等待时长，该占据了整个操作的时间分析93%以上的时间。

建议研发部门梳理图片上传完成到图片回显之间的业务流程，优化并虽短两者之间的等待时间，可大大加速防疫通勤卡的上传时间，提高工作效率。

关于图片回显优化

从图片回显的网络层数据传输看到，目前的传输方式并非最优选择，但图片回显时长可以接受，暂时可不做优化。

如果后期该业务并发访问量较大时，建议优化，以最大网络传输单元传输数据，可明显提高图片回显效率。