总结：metrictag大数据接口响应慢问题排查与处理

一、问题现象

platform调用 queryMetricTagRel 经常会出现超时错误。

注意：这个接口响应大小是118M，这就对网络性能要求很高。

二、问题排查与处理

1、确认是否是接口本身响应慢

通过对nginx日志的排查：

• 有两台wuhan机房的机器响应平均都在30秒左右，beijing机房的两台机器响应时间几乎都在3秒左右，可见是访问wuhan机器服务时导致的超时。
• 由于nginx网关部署在beijing机房，而beijing机房的两台服务访问都很快，可见超时主要是因为beijing的nginx访问wuhan的服务耗时比较大的原因。

2、解决

解决一：去除网络的影响。既然wuhan到beijing网络有问题，那就直接把wuhan机房的两台机器去掉即可（beijing能再申请两台机器最好，但是没有机器了）。

但是注意：去掉wuhan的机器之后，所有的请求就都转发到了beijing的两台机器了。

观察：wuhan两台机器去掉之后，发现请求确实变快了，但是一会功夫，又有请求超时了，已经是同区域访问了，超时就不会是网络问题了，那么还可能是什么问题？答案是机器的网卡！

看了下机器的网卡的监控：发现在14点20左右，流量升上去了，是正常的，流量最多到了1.6G左右，但是正常应该是1.8G左右才对，所以考虑是不是机器的网卡被限速了？

带着这个疑问咨询了设备服务提供方得知，确实对机器有限流，每台限制1.6G，限速就会导致多余的请求的响应数据不能及时传输出来，自然就会慢。

而且网卡流量达到上限，可能对入口的请求有影响，导致很多请求都会变慢。

解决二：升级网卡。针对网卡限流的解决，我们将网卡升级到了3.2G/秒。

但是发现有时候还是会超时，不出意外应该还是网络限制导致的。

解决三：压缩。既然接口响应内容大会出现网卡，网络等问题，可否将响应的数据进行压缩呢？答案是可以的，本项目是spring-boot搭建，框架提供了对响应数据进行压缩的机制，配置的方式：

server.compression.enabled=true  #打开压缩机制
server.compression.mime-types=application/json #对json响应格式进行压缩，压缩为gzip

但是上面的内容只有在客户端指定接受gzip的方式时才会生效，即 Accept-Encoding ：gzip

经过简单的测试，gzip之后，压缩后的大小是压缩前的1/8，很可观，大大的降低了网络端的消耗

效果：压缩前：129KB，耗时532ms

压缩后：15KB，564ms，耗时差不多（涉及到压缩计算和解压计算，比较耗费CPU），但是Size降低了将近10倍。

响应：如下 Content-Encoding ：gzip 说明服务端经过了gzip的压缩方式

三、总结

1、对于接口响应数据比较大的，应该首先考虑到内容压缩。

2、但是考虑到客户端可能不支持gzip压缩，服务端发现客户端不支持gizp压缩的时候，及时服务端配置了压缩，也不会生效，所以当客户端不支持的时候应该考虑升级网卡，解决网络问题（如将服务器和网关放到一个机房）