← 返回

雙重瓶頸併發？OpenResty XRay多維分析破解效能難題

章亦春釋出於 Jul 30, 2025 更新於 Jul 30, 2025

預計閱讀 7 分鐘

閱讀次數

在高併發業務場景下，系統效能直接影響使用者體驗與業務成效。響應延遲，即使是毫秒級別，也可能對使用者留存和業務指標產生負面影響。然而，生產環境中的效能問題，特別是偶發性瓶頸，因其複雜性和難以復現的特點，定位和解決通常面臨挑戰。

本文將透過一個真實案例，介紹如何排查一個典型的生產效能問題。某客戶的線上系統在業務高峰期出現平均響應時間翻倍、CPU 使用率持續過高的情況。技術團隊採用常規方法，如分析日誌、使用通用效能剖析工具以及在測試環境復現，但未能準確定位問題根源。

為解決此問題，該團隊採用了 OpenResty XRay 這一深度觀測平臺。OpenResty XRay 專為複雜生產環境的效能問題診斷而設計，它基於動態追蹤技術（如 eBPF+ 和 Stap+），能夠對線上服務進行深度分析，而無需修改程式碼或重啟服務，且對系統效能影響極小。

本文將詳細介紹使用 OpenResty XRay 診斷該效能問題的全過程。我們將逐步展示如何透過多維度的火焰圖分析，定位到隱藏在程式碼深處的效能瓶頸。

使用 OpenResty XRay 快速透視和解決您的軟體問題

整體 CPU 使用分析

OpenResty XRay 自動生成了下面這張 C-land CPU 火焰圖：

透過分析這張火焰圖，團隊迅速發現了問題的核心：ModSecurity 模組是絕對的第一大效能瓶頸。

ModSecurity 模組 CPU 佔用：57.9%
總體 CPU 瓶頸佔比：約 60%

深入模組內部分析

進一步利用 OpenResty XRay 的細粒度追蹤能力，團隊發現了兩個主要的 CPU 消耗源：

1. PCRE DFA 正則匹配瓶頸

下面這張 C-land CPU 火焰圖向我們揭示了 PCRE 的 DFA 匹配函式在 CPU 資源消耗中的顯著地位。pcre_dfa_exec 函式在整體應用中佔據了 24.4% 的 CPU 時間。

這一發現明確指出，nginx 版 ModSecurity 模組的呼叫是導致這一高消耗的主要原因。值得注意的是，PCRE 庫的 DFA 引擎在效能上明顯遜色於其帶 JIT 編譯的回溯引擎，這為我們提供了最佳化的方向和契機。

2. HTTP 響應體 Gzip 壓縮瓶頸

OpenResty XRay 的多維度分析能力讓我們得以進一步深入探究系統效能的第二大瓶頸。透過收集多個 C 級別 CPU 火焰圖樣本，團隊系統性地分析了 HTTP 響應體壓縮對系統效能的影響：

樣本一分析：初步取樣顯示，zlib 庫的 deflate 函式在整個應用的 CPU 時間分配中佔據了 13.1%。這一資料已經明確表明 Gzip 壓縮是一個不可忽視的效能消耗點。

樣本二驗證：為確保發現的準確性，我們進行了第二輪取樣。結果更加顯著——在這個樣本中，deflate 函式的 CPU 佔用率攀升至 34.7%，進一步證實了壓縮操作對系統效能的重大影響。

壓縮策略深度分析

在確認 Gzip 壓縮是系統效能的第二大瓶頸後，OpenResty XRay 的專項分析能力被充分發揮，幫助我們深入探究壓縮策略的各個維度：

壓縮級別分析

首先，我們透過 OpenResty XRay 專門的分析器對壓縮級別進行了全面檢查，結果令人深思：

found 561 response chunks not gzip'd
gzip levels: count=2000, min=1, avg=1, max=1
value |-------------------------------------------------- count
    0 |                                                      0
    1 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 2000
    2 |                                                      0
    4 |                                                      0

這組資料揭示了兩個關鍵事實：

系統中有 2000 個響應塊使用了壓縮，全部採用級別 1，即最低壓縮級別
同時存在 561 個未壓縮的響應塊

這表明，從壓縮級別角度看，系統配置已經相當合理——級別 1 提供了最高的執行效率。然而，壓縮操作仍然消耗了大量 CPU 資源，這促使我們進一步探究：是哪些型別的內容在消耗這些資源？

MIME 型別分佈分析

為解答上述問題，我們再次啟動了 XRay 分析功能，對參與 Gzip 壓縮的 MIME 型別進行了精確統計：

found 557 response chunks not gzip'd
* gzip application/javascript: count=606
value |-------------------------------------------------- count
    0 |                                                     0
    1 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@     606
    2 |                                                     0
    4 |                                                     0
* gzip text/html: count=212
value |-------------------------------------------------- count
    0 |                                                     0
    1 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@         212
    2 |                                                     0
    4 |                                                     0
* gzip text/css: count=182
value |-------------------------------------------------- count
    0 |                                                     0
    1 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@      182
    2 |                                                     0
    4 |                                                     0

這組資料展現了更加細緻的畫面：

JavaScript 檔案（606 個例項）是最主要的壓縮物件
HTML 檔案（212 個例項）和 CSS 檔案（182 個例項）緊隨其後
這三種型別幾乎佔據了所有壓縮操作
同樣有 557 個響應塊未被壓縮

分析結論

透過這一系列漸進式分析，我們得出了幾個關鍵結論：

系統已經採用了執行效率最高的壓縮級別：級別 1
壓縮操作主要集中在靜態資源 JS、CSS 和動態內容 HTML 上
儘管壓縮級別已最佳化，但壓縮操作仍然是系統效能的重要瓶頸

這些發現為我們指明瞭最佳化方向：不是簡單調整壓縮級別，而是需要重新思考整體壓縮策略，特別是針對不同型別資源採取差異化的處理方案。

最佳化解決方案

針對本案例中發現的兩大效能瓶頸，我們提供了相應的最佳化解決方案：

1. 壓縮效能最佳化：zstd 私有模組

針對 Gzip 壓縮瓶頸，我們提供了 zstd 私有模組作為高效能替代方案。該模組基於 Facebook 開源的 Zstandard 壓縮演算法，效能最高可達 zlib 的 5倍，能夠顯著降低本案例中發現的 34.7% CPU 壓縮開銷。作為我們的私有庫服務業務，zstd 模組特別針對高併發場景進行了深度最佳化，為使用者提供更高效的壓縮解決方案。

2. WAF 效能最佳化：OpenResty Edge

針對 ModSecurity 模組的效能瓶頸，我們的 OpenResty Edge 提供了更高效能的 WAF 解決方案。

很多場景下，OpenResty Edge 的 WAF 效能比 ModSecurity 高一個數量級，能夠有效解決本案例中 ModSecurity 佔用 60% CPU 的問題，為使用者提供更強大的安全防護能力和更優異的效能表現。

這兩個解決方案均可供使用者根據實際業務需求進行參考和選擇，幫助使用者在保障系統安全的同時，獲得更優異的效能體驗。

從“救火”到“防火”：OpenResty XRay 的核心價值

本次案例是現代效能最佳化的一個縮影。問題根源並非簡單的程式碼 Bug，而是深藏於系統內部的配置、庫函式與處理策略之間的複雜博弈。傳統工具僅能看到“煙”，而 OpenResty XRay 憑藉其深度洞察力，則能直指“火源”。

透過這個真實案例，OpenResty XRay 的核心價值得以清晰展現：

精準洞察，拒絕猜測：XRay 將一個模糊的“CPU 佔用率高”問題，轉化為清晰、可執行的最佳化目標。火焰圖不僅告訴我們系統變慢了，更是直接鎖定了 ModSecurity 模組和 pcre_dfa_exec 函式，讓效能最佳化從“猜”變成有的放矢的“做”。
資料驅動，輔助決策：面對 Gzip 瓶頸，第一反應往往是“降級”。但 XRay 對壓縮級別和 MIME 型別的精細化分析，用資料證明了當前配置已是“最優解”，從而避免了無效調整，將最佳化方向引向“動靜資源分離處理”的更高維度策略。這正是普通調優與架構最佳化的分野。
無侵入式，生產就緒：所有深度分析都在生產環境實時完成，無需修改程式碼，更無需重啟服務。這對任何嚴肅的企業級應用而言，都是保障業務連續性的生命線，真正做到了“無感”診斷。

這一切能力的背後，是 OpenResty XRay 的立身之本。它的核心基於我們自主改進的動態追蹤技術，如 eBPF+ 和 Stap+。這些先進的技術使得 XRay 能夠在保持極低系統開銷的同時，提供遠超傳統工具的深度與精度。更值得一提的是，OpenResty XRay 同時支援 RHEL/CentOS 7 的 3.10 老核心和 6.x 新核心，為使用者的各類系統環境提供了廣泛的相容性與保障。

在今天的商業競爭中，效能不再僅僅是技術指標，更是核心的商業資產。OpenResty XRay 賦予技術團隊的，正是從被動“救火”到主動“防火”的底氣，是保障系統長治久安、創造極致使用者體驗的強大武器。

立即申請 OpenResty XRay 試用

關於 OpenResty XRay

OpenResty XRay 是一款動態追蹤產品，它可以自動分析執行中的應用，以解決效能問題、行為問題和安全漏洞，並提供可行的建議。在底層實現上，OpenResty XRay 由我們的 Y 語言驅動，可以在不同環境下支援多種不同的執行時，如 Stap+、eBPF+、GDB 和 ODB。

關於作者

章亦春是開源 OpenResty^® 專案創始人兼 OpenResty Inc. 公司 CEO 和創始人。

章亦春（Github ID: agentzh），生於中國江蘇，現定居美國灣區。他是中國早期開源技術和文化的倡導者和領軍人物，曾供職於多家國際知名的高科技企業，如 Cloudflare、雅虎、阿里巴巴, 是 “邊緣計算“、”動態追蹤 “和 “機器程式設計 “的先驅，擁有超過 22 年的程式設計及 16 年的開源經驗。作為擁有超過 4000 萬全球域名使用者的開源專案的領導者。他基於其 OpenResty^® 開源專案打造的高科技企業 OpenResty Inc. 位於美國矽谷中心。其主打的兩個產品 OpenResty XRay（利用動態追蹤技術的非侵入式的故障剖析和排除工具）和 OpenResty Edge（最適合微服務和分散式流量的全能型閘道器軟體），廣受全球眾多上市及大型企業青睞。在 OpenResty 以外，章亦春為多個開源專案貢獻了累計超過百萬行程式碼，其中包括，Linux 核心、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl 等，並編寫過 60 多個開源軟體庫。