性能测试之文件上传的瓶颈分析调优

问题反馈

这是一个给第三方压测之后，第三方反馈的性能问题。
大致描述如下：并发上传 10 个文件的时候，接口完全没有响应，通过看服务器日志发现，请求根本没有到服务端，直接被某个地方拦截了。

按道理来说，10 个并发数量不是很大，jmeter 不会卡住的，于是让他们排查线程池队列，nginx 队列，mysql 队列，都没有发现问题

唯一的问题是这十个文件都比较大，大约是 14 兆左右的 pdf 文件。同时上传可能会对网络有影响。于是排查一下网络环境，看看有没有丢包，监听了一会，发现根本没有网络流量，所以不存在丢包坏包等现象。

纠结了一会，一筹莫展，连运维都一起拉进来研究这个问题

正在没头绪的时候，突然想到看一下日志，于是实时打印了一下设备日志，发现了一条奇怪的日志

watch "dmesg | tail -20"

感觉是 gro 导致的 tcp 异常，看到 GRO，就突然想起了一个熟悉的词mtu。这两个有什么关联？

mtu

mtu 是最大传输单元
如果 I P 层有一个数据包要发送，而且数据的长度比 M T U 值还大，那么 I P 层就需要对数据进行切片，把数据包分成若干片，这样每一片都小于 M T U 值

GRO

现在网卡都有 LRO/GRO 功能。网卡收包时将小包合并成大包，然后交给内核协议栈。LVS 内核模块在处理>MTU 的数据包时，会主动丢弃。
因此，如果我们用 LVS 来传输大文件的时候传输速度会极其慢。
/sbin/ethtool -k eth0 |grep offload 查看 gro 是否打开，发现果然是打开的。