簡單一招竟把nginx服務器性能提升50倍

需求背景

接到重點業務需求要分輪次展示數據，預估最高承接 9w 的 QPS，作為后端工程師下意識的就是把接口寫好，分級緩存、機器擴容、線程拉滿等等一系列連招準備，再因為數據更新頻次兩只手都數得過來，我們采取了最穩妥的處理方式，直接生成靜態文件拿 CDN 抗量

架構流程大致如下所示：

數據更新后會重新生成新一輪次的文件，刷新 CDN 的時候會觸發大量回源請求，應用服務器極端情況得 hold 住這 9w 的 QPS

第一次壓測

雙機房一共 40 臺 4C 的機器，25KB 數據文件，5w 的 QPS 直接把 CPU 打到 90%

這明顯不符合業務需求啊，咋辦？先無腦加機器試試唄

就在這時測試同學反饋壓測的數據不對，最后一輪文件最大會有 125KB，雪上加霜

于是乎文件替換，機器數量整體翻一倍擴到 80 臺，服務端 CPU 依然是瓶頸，QPS 加不上去了

到底是哪里在消耗 CPU 資源呢，整體架構已經簡單到不能再簡單了

這時候我們注意到為了節省網絡帶寬 nginx 開啟了 gzip 壓縮，是不是這小子搞的鬼

server
{
      listen 80;
      
      gzip on;
      gzip_disable "msie6";
      gzip_vary on;
      gzip_proxied any;
      gzip_comp_level 6;
      gzip_buffers 16 8k;
      gzip_http_version 1.1;
      gzip_types text/plain application/css text/css application/xml text/javascript application/javascript application/x-javascript;

......
}

第二次壓測

為了驗證這個猜想，我們把 nginx 中的 gzip 壓縮率從 6 調成 2，以減少 CPU 的計算量

gzip_comp_level 2;

這輪壓下來 CPU 還是很快被打滿，但 QPS 勉強能達到 9w，坐實了確實是 gzip 在耗 CPU

nginx 作為家喻戶曉的 web 服務器，以高性能高并發著稱，區區一個靜態數據文件就把應用服務器壓的這么高，一定是哪里不對

第三次壓測

明確了 gzip 在耗 CPU 之后我們潛下心來查閱了相關資料，發現了一絲進展

html/css/js 等靜態文件通常包含大量空格、標簽等重復字符，重復出現的部分使用「距離加長度」表達可以減少字符數，進而大幅降低帶寬，這就是 gzip 無損壓縮的基本原理

作為一種端到端的壓縮技術，gzip 約定文件在服務端壓縮完成，傳輸中保持不變，直到抵達客戶端。這不妥妥的理論依據嘛～

nginx 中的 gzip 壓縮分為動態壓縮和靜態壓縮兩種

服務器給客戶端返回響應時，消耗自身的資源進行實時壓縮，保證客戶端拿到 gzip 格式的文件

這個模塊是默認編譯的，詳情可以查看 https://nginx.org/en/docs/http/ngx_http_gzip_module.html

直接將預先壓縮過的 .gz 文件返回給客戶端，不再實時壓縮文件，如果找不到 .gz 文件，會使用對應的原始文件

這個模塊需要單獨編譯，詳情可以查看 https://nginx.org/en/docs/http/ngx_http_gzip_static_module.html

如果開啟了 gzip_static always，而且客戶端不支持 gzip，還可以在服務端加裝 gunzip 來幫助客戶端解壓，這里我們就不需要了

查了一下 jdos 自帶的 nginx 已經編譯了 ngx_http_gzip_static_module，省去了重新編譯的麻煩事

接下來通過 GZIPOutputStream 在本地額外生成一個 .gz 的文件，nginx 配置上靜態壓縮再來一次

gzip_static on;

面對 9w 的QPS，40 臺機器只用了 7% 的 CPU 使用率完美扛下

為了探底繼續加壓，應用服務器 CPU 增長緩慢，直到網絡流出速率被拉到了 89MB/s，擔心影響宿主機其他容器停止壓力，此時 QPS 已經來到 27w

qps 5w->27w 提升 5 倍，CPU 90%->7% 降低 10 倍，整體性能翻了 50 倍不止，這回舒服了～

寫在最后

經過一連串的分析實踐，似乎靜態壓縮存在“壓倒性”優勢，那什么場景適合動態壓縮，什么場景適合靜態壓縮呢？一番探討后得出以下結論

純靜態不會變化的文件適合靜態壓縮，提前使用gzip壓縮好避免CPU和帶寬的浪費。動態壓縮適合API接口返回給前端數據這種動態的場景，數據會發生變化，這時候就需要nginx根據返回內容動態壓縮，以節省服務器帶寬

作為一名后端工程師，nginx 是我們的老相識了，抬頭不見低頭見。日常工作中配一配轉發規則，查一查 header 設置，基本都是把 nginx 作為反向代理使用。這次是直接訪問靜態資源，調整過程的一系列優化加深了我們對 gzip 的動態壓縮和靜態壓縮的基本認識，這在 NG 老炮兒眼里顯得微不足道，但對于我們來說卻是一次難得的技能拓展機會

在之前的職業生涯里，我們一直聚焦于業務架構設計與開發，對性能的優化似乎已經形成思維慣性。面對大數據量長事務請求，減少循環變批量，增大并發，增加緩存，實在不行走異步任務解決，一般瓶頸都出現在 I/O 層面，畢竟磁盤慢嘛，減少與數據庫的交互次數往往就有效果，其他大概率不是問題。這回有點兒不一樣，CPU 被打起來的原因就是出現了大量數據計算，在高并發請求前，任何一個環節都可能產生性能問題

作者：京東零售 閆創

來源：京東云開發者社區 轉載請注明來源