90%开发都会忽略的性能调优点：针对返回大数据量的接口，10分钟内找到提升带宽瓶颈的突破口

01 问题现象

前几天小编居家远程办公，在测试环境访问某返回3.4M数据的接口，响应速度远不如预期。一开始怀疑是用远程用vpn连接访问导致的。但回到公司之后，我再次通过内网多次访问该接口，响应时间依然不理想，在600～700ms左右，最快也需要500ms多。但办公室带宽100M，打满带宽所需耗时为 3.4MB / (100MBit/s / 8) = 272ms，这里面存在至少200多ms的时间缺口，是什么原因导致的？又该如何调优？

02 常见但易被忽略的类似场景

我们可能从来没有注意到一个事情：在实际生产环境访问大数据量的接口时，我们自然而然地认为响应速度相对慢些是正常的，但真的完全是因为返回报文太大的缘故吗？现在的带宽大都是百兆，服务器之间的带宽更是上千兆，而往往查询十几M的数据也要几秒钟，这里面还有没有可调优的缺口？

我们突然意识到，如果能排查出该慢请求背后的根因，找到调优方法，这可能会对众多开发者提升生产环境接口的性能产生很大的价值和参考意义。

03 初步排查

我们用程序摄像头Trace Profiling捕捉了该慢请求，trace的span信息如下：

我们发现该接口真正处理