nginx metrictag大數(shù)據(jù)接口響應(yīng)慢怎么排查與處理

這篇文章主要介紹“nginx metrictag大數(shù)據(jù)接口響應(yīng)慢怎么排查與處理”，在日常操作中，相信很多人在nginx metrictag大數(shù)據(jù)接口響應(yīng)慢怎么排查與處理問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”nginx metrictag大數(shù)據(jù)接口響應(yīng)慢怎么排查與處理”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

一、問題現(xiàn)象

platform調(diào)用 queryMetricTagRel 經(jīng)常會(huì)出現(xiàn)超時(shí)錯(cuò)誤。

注意：這個(gè)接口響應(yīng)大小是118M，這就對網(wǎng)絡(luò)性能要求很高。

二、問題排查與處理

1、確認(rèn)是否是接口本身響應(yīng)慢

通過對nginx日志的排查：

• 有兩臺(tái)wuhan機(jī)房的機(jī)器響應(yīng)平均都在30秒左右，beijing機(jī)房的兩臺(tái)機(jī)器響應(yīng)時(shí)間幾乎都在3秒左右，可見是訪問wuhan機(jī)器服務(wù)時(shí)導(dǎo)致的超時(shí)。

• 由于nginx網(wǎng)關(guān)部署在beijing機(jī)房，而beijing機(jī)房的兩臺(tái)服務(wù)訪問都很快，可見超時(shí)主要是因?yàn)閎eijing的nginx訪問wuhan的服務(wù)耗時(shí)比較大的原因。

2、解決

解決一：去除網(wǎng)絡(luò)的影響。既然wuhan到beijing網(wǎng)絡(luò)有問題，那就直接把wuhan機(jī)房的兩臺(tái)機(jī)器去掉即可（beijing能再申請兩臺(tái)機(jī)器最好，但是沒有機(jī)器了）。

但是注意：去掉wuhan的機(jī)器之后，所有的請求就都轉(zhuǎn)發(fā)到了beijing的兩臺(tái)機(jī)器了。

觀察：wuhan兩臺(tái)機(jī)器去掉之后，發(fā)現(xiàn)請求確實(shí)變快了，但是一會(huì)功夫，又有請求超時(shí)了，已經(jīng)是同區(qū)域訪問了，超時(shí)就不會(huì)是網(wǎng)絡(luò)問題了，那么還可能是什么問題？答案是機(jī)器的網(wǎng)卡！

看了下機(jī)器的網(wǎng)卡的監(jiān)控：發(fā)現(xiàn)在14點(diǎn)20左右，流量升上去了，是正常的，流量最多到了1.6G左右，但是正常應(yīng)該是1.8G左右才對，所以考慮是不是機(jī)器的網(wǎng)卡被限速了？

帶著這個(gè)疑問咨詢了設(shè)備服務(wù)提供方得知，確實(shí)對機(jī)器有限流，每臺(tái)限制1.6G，限速就會(huì)導(dǎo)致多余的請求的響應(yīng)數(shù)據(jù)不能及時(shí)傳輸出來，自然就會(huì)慢。

而且網(wǎng)卡流量達(dá)到上限，可能對入口的請求有影響，導(dǎo)致很多請求都會(huì)變慢。

解決二：升級(jí)網(wǎng)卡。針對網(wǎng)卡限流的解決，我們將網(wǎng)卡升級(jí)到了3.2G/秒。

但是發(fā)現(xiàn)有時(shí)候還是會(huì)超時(shí)，不出意外應(yīng)該還是網(wǎng)絡(luò)限制導(dǎo)致的。

解決三：壓縮。既然接口響應(yīng)內(nèi)容大會(huì)出現(xiàn)網(wǎng)卡，網(wǎng)絡(luò)等問題，可否將響應(yīng)的數(shù)據(jù)進(jìn)行壓縮呢？答案是可以的，本項(xiàng)目是spring-boot搭建，框架提供了對響應(yīng)數(shù)據(jù)進(jìn)行壓縮的機(jī)制，配置的方式：

server.compression.enabled=true  #打開壓縮機(jī)制
server.compression.mime-types=application/json #對json響應(yīng)格式進(jìn)行壓縮，壓縮為gzip

但是上面的內(nèi)容只有在客戶端指定接受gzip的方式時(shí)才會(huì)生效，即 Accept-Encoding ：gzip

經(jīng)過簡單的測試，gzip之后，壓縮后的大小是壓縮前的1/8，很可觀，大大的降低了網(wǎng)絡(luò)端的消耗

效果：壓縮前：129KB，耗時(shí)532ms

壓縮后：15KB，564ms，耗時(shí)差不多（涉及到壓縮計(jì)算和解壓計(jì)算，比較耗費(fèi)CPU），但是Size降低了將近10倍。

響應(yīng)：如下 Content-Encoding ：gzip 說明服務(wù)端經(jīng)過了gzip的壓縮方式

到此，關(guān)于“nginx metrictag大數(shù)據(jù)接口響應(yīng)慢怎么排查與處理”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！