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大數據接口響應慢怎么排查與處理”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！