这篇文章主要介绍“nginx metrictag大数据接口响应慢怎么排查与处理”，在日常操作中，相信很多人在nginx metrictag大数据接口响应慢怎么排查与处理问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”nginx metrictag大数据接口响应慢怎么排查与处理”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
platform调用 queryMetricTagRel 经常会出现超时错误。
注意：这个接口响应大小是118M，这就对网络性能要求很高。
通过对nginx日志的排查：
有两台wuhan机房的机器响应平均都在30秒左右，beijing机房的两台机器响应时间几乎都在3秒左右，可见是访问wuhan机器服务时导致的超时。
由于nginx网关部署在beijing机房，而beijing机房的两台服务访问都很快，可见超时主要是因为beijing的nginx访问wuhan的服务耗时比较大的原因。
解决一：去除网络的影响。既然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大数据接口响应慢怎么排查与处理”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注亿速云网站，小编会继续努力为大家带来更多实用的文章！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
