9月16日晚，小王正美滋滋地等着周董的《說好不哭》上線，但是公司的oncall電話進來，說是現在公司活動頁面加載越來越慢。接完電話，小王立馬打開了電腦排查問題，不然自己真的要哭了。
小王利索地登上了公司的線上監控平臺，發現慢請求越來越多。機智的小王立馬想到，系統響應突然變慢，無外乎CPU佔用過高或者Full GC次數過多這些原因。可是通過監控查看了當前的CPU和系統內存後，發現一切正常。
這下可把小王難住了，這到底是爲什麼呢？
還好小王機智，從監控大盤上看到，當前的下行帶寬基本被打滿了，或許這就是問題所在了。
通過監控日誌，首先梳理了當前訪問頻次top 10的請求和返回體大小top 10的請求，通過對比這兩個結果集，小王意外發現，有多個請求重合。小王立馬拿出了紙，記下來了重合的請求，並將請求按發送方區分爲由native或h5發出的請求。小王又在監控平臺上對比了上週同時段這些請求的訪問頻次，發現當前頻次大大地增加了，大約增加了幾倍，再加上這些請求返回體大小較大，小王便懷疑是這些請求佔滿了帶寬。
小王立馬着手計算這些請求所佔的帶寬，計算方式如下：
1、拿到這些請求一分鐘內的請求數量N。
2、將N除以60得到每秒請求數M。
3、將M乘以該請求的返回體大小(a kb)再除以1024得到每秒該請求的所佔的大小b (兆)
4、將b乘以8得到該請求所佔的實際帶寬。
N/60*a/1024*8
通過以上算法，計算出這幾個請求所佔帶寬並求和，發現已經佔了總帶寬的60%，問題應該就出在這裏了。
小王第一反應就是看下這些請求是否是有人惡意刷單，但是排查後沒有發現異常，那就無法通過限流攔截的方式降低頻次。
那隻能選擇減少返回體大小了。常用的方法有兩個，一個是請求走cdn，另一個是對返回體壓縮。因爲native發版需要提交應用市場，不能及時生效，這種方式只能排除，只能走以下兩個方法了。
1、將H5頁面靜態化，請求走CDN
2、在nginx層開啓gzip，對這幾個特定的請求的返回體進行壓縮
小王立馬拿起手機聯繫了前端H5負責人，確認了相關接口的H5頁面可以靜態化，並請求對方立即響應發版。H5接口的問題解決了，剩下就是native發出的接口了。
小王接着研究了Nginx的配置。ngnix自身有如下參數：
開啓和關閉gzip模式 gzip on|off; gizp壓縮起點，文件大於1k才進行壓縮 gzip_min_length 1k; gzip 壓縮級別，1-9，數字越大壓縮的越好，也越佔用CPU時間 gzip_comp_level 1; 進行壓縮的文件類型。 gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript ; nginx對於靜態文件的處理模塊，開啓後會尋找以.gz結尾的文件，直接返回，不會佔用cpu進行壓縮，如果找不到則不進行壓縮 gzip_static on|off 是否在http header中添加Vary: Accept-Encoding，建議開啓 gzip_vary on; 設置壓縮所需要的緩衝區大小，以4k爲單位，如果文件爲7k則申請2*4k的緩衝區 gzip_buffers 2 4k; 設置gzip壓縮針對的HTTP協議版本 gzip_http_version 1.1;
通過gzip的開關，壓縮文件的類型、gzip的壓縮起點，再配合nginx的location使用，就可以達到對指定請求的指定返回體大小進行壓縮了。
小王立馬又打電話給了運維小馬，小馬立馬按照對應的要求進行了ngnix的配置。
配置完一會兒以後，小王從監控上看到，帶寬逐漸回落，在H5發佈上線後，下行帶寬回到了正常水平，而且相關頁面加載也恢復正常了。小王長舒了一口氣，擡頭一看，正好趕上了周董的新歌上線。
但是想花3塊錢怎麼這麼難呢？某播放平臺進不去了……
更多文章，請關注公衆號測試架構師養成記
