nginx metrictag大数据接口响应慢怎么排查与处理

这篇文章主要介绍“nginx metrictag大数据接口响应慢怎么排查与处理”，在日常操作中，相信很多人在nginx metrictag大数据接口响应慢怎么排查与处理问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”nginx 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的压缩方式

到此，关于“nginx metrictag大数据接口响应慢怎么排查与处理”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注亿速云网站，小编会继续努力为大家带来更多实用的文章！