最近，我們與一家頭部的金融科技客戶合作，對其核心的跨境支付清算系統進行例行效能評估。該系統的入口是一個基於 OpenResty 構建的高效能 API 閘道器，每天承載數百億次呼叫，峰值 QPS 超過 500,000。在金融科技領域，系統的穩定性和延遲是業務的生命線。他們對關鍵交易路徑的 SLO (Service Level Objective) 有著近乎苛刻的要求。初看之下，系統執行得相當平穩：P50 延遲穩定在 10ms 以內，各項核心指標都處於健康狀態。

儘管平均延遲指標表現健康，但深入 P99 延遲曲線，我們發現了一個不容忽視的穩定性風險：週期性出現的尖刺將延遲推高至 300ms 級別，這已經超出了對核心交易路徑的嚴格 SLA 閾值。對於 OpenResty 作為關鍵閘道器的系統而言，這不僅是效能衰退的訊號，更是潛藏的交易超時風險。

當“地震儀”找不到震源

為客戶進行的一次例行效能健康檢查中，我們利用 OpenResty XRay 對其生產環境進行了非侵入式的深度掃描。儘管客戶現有的監控儀表盤顯示系統整體執行平穩，但 OpenResty XRay 的分析很快揭示了兩個潛藏在漂亮平均值之下的嚴重效能風險：

• 無法解釋的 P99 延遲： 我們發現，P99 延遲曲線上存在著短暫卻高達 300ms 以上的毛刺。這些訊號在客戶現有的海量監控資料中很容易被當作統計噪音而忽略，但 OpenResty XRay 卻能精準捕捉並分析其最長耗時，將其標記為高風險事件。
• 持續高企的 CPU 黑洞： 監控顯示，閘道器叢集的 CPU 利用率，尤其是在 log 階段，一直居高不下。為了保證峰值時段的穩定性，客戶團隊不得不採用超額配置的策略，這直接轉化為了高昂的基礎設施成本。

這是都曾面臨的經典難題：大概知道問題出在哪裡，大機率是 Lua 程式碼層，但你不知道具體是哪一行、哪個函式、以及在何種條件下觸發。

從經驗主義到動態觀測的價值轉化

很顯然，挑戰已不再是收集更多的監控資料，而是如何從海量資料中獲得可執行的洞察。為了走出“觀察-猜測-驗證”的低效迴圈，我們需要一個能夠安全地在生產環境進行深度勘察的工具。這正是 OpenResty XRay 發揮核心價值的地方，其非侵入式的動態追蹤能力是關鍵——無需修改任何程式碼，無需重啟任何服務，這對於金融核心系統是不可逾越的紅線。

我們在客戶一個高負載的生產 Pod 上啟動了 OpenResty XRay 的自動分析。幾分鐘後，第一批深度分析報告生成，謎題的答案開始浮現。

效能熱點鎖定

P99 毛刺的謎團首先被解開。

• 證據： OpenResty XRay 的“Regex Expressions”報告清晰地指出，一個 string.gmatch 函式呼叫，其模式為 "([^%.]+)"，在取樣週期內的“最長單次執行耗時”達到了驚人的 244.64 ms。
• 根因分析： 這就是 P99 毛刺的直接來源。我們分析後發現，客戶團隊的工程師習慣性地使用了 Lua 內建的 string.gmatch。這背後的技術原因是，它依賴的 LPeg 引擎並不支援 JIT（Just-In-Time Compilation）。當面對某些邊界或惡意構造的輸入時，其正規表示式引擎會觸發災難性的效能回溯，導致執行時間瞬間飆升。
• 解決方案建議： 我們立刻建議客戶將熱點路徑程式碼中的 string.gmatch 全部替換為 ngx.gmatch。後者基於 OpenResty 深度最佳化的 PCRE 庫，不僅效能更穩定，還支援 JIT 編譯。

深層損耗分析

解決了延遲問題，我們把目光轉向了 CPU 佔用率。

• XRay 證據： On-CPU 火焰圖給出了最直觀的線索，ngx_http_log_request 函式棧佔用了高達 26.5% 的 CPU 時間。一個本應輕量的 log 階段，成為了 CPU 消耗大戶。
• 根因分析： 我們下鑽火焰圖的堆疊，發現對 ngx_http_lua_ffi_compile_regex 的海量呼叫。這意味著，在 log 階段用於日誌脫敏和格式化的 Lua 程式碼，正在為每一個請求反覆編譯同一個正規表示式。這是一個典型但極易被忽略的效能陷阱。
• 解決方案建議： 根因在於 ngx.re.match 呼叫時缺少了 'o' (compile-once) 選項。我們建議在所有熱點路徑（尤其是 log 階段）的 ngx.re.* 呼叫中新增 'o' 選項，確保正規表示式“一次編譯，無限次執行”。

被遺忘的 PCRE JIT 開關

前兩個發現已經帶來了巨大價值，但 OpenResty XRay 的“Lua-Land”報告揭示了一個更深層次、更系統性的問題。

• 證據： 報告顯示，客戶系統中 所有 的 ngx.re.* 呼叫，JIT 編譯選項都處於關閉狀態：即使是我們剛剛建議修復的那些呼叫。
• 根因分析： 經過排查，我們發現了一個許多團隊都可能犯的錯誤：客戶用於構建閘道器的基礎 Docker 映象，在編譯 OpenResty 時，忘記了新增 --with-pcre-jit 這個關鍵的編譯引數。
• 解決方案建議： 這意味著整個叢集從未享受到 PCRE JIT 帶來的巨大效能紅利。我們立即建議客戶團隊重新編譯其基礎映象，並在所有 ngx.re.* 呼叫中統一啟用 'j' (JIT) 選項，徹底釋放 OpenResty 的潛力。

可量化的工程效率與資源最佳化指標

基於 OpenResty XRay 的洞察，客戶團隊實施了一系列最佳化。效果是立竿見影且可量化的：

1. P99 延遲毛刺徹底消除： 最佳化後，P99 延遲曲線變得平滑如鏡，從超過 300ms 降至穩定水平。
2. CPU 成本節約 30%： 修復了正則快取問題並全域性啟用 JIT 後，閘道器叢集的整體 CPU 利用率下降了約 30%，節約大量雲基礎設施成本。
3. MTTR（平均解決時間）大幅縮短： 效能問題的診斷時間從過去“幾周的猜測和會議”，縮短到了“幾分鐘的精確定位”。

構建持續效能觀測能力

修復這兩處效能瓶頸的直接價值是顯而易見的。但更深層的洞察在於，它再次印證了一個工程哲學：在高併發、低延遲的 OpenResty 環境中，效能問題往往隱藏在構建系統、執行時配置和底層細節的魔鬼之中。

當問題根源超越應用程式碼邏輯時，傳統的觀測手段將面臨效率瓶頸。缺乏動態、非侵入式的底層追蹤能力，即使是經驗最豐富的工程師，在面對這些隱蔽的效能回歸時，定位成本也會顯著提高。

基於這次經歷，客戶工程團隊正審慎地規劃下一階段的工程體系最佳化。他們計劃將 OpenResty XRay 的持續效能分析能力前置，整合到 CI/CD 流程的基準測試環節。在任何可能導致效能退化的程式碼或配置被合併到主幹之前，就能透過自動化的基準測試報告，可靠地捕獲環境、配置或編譯引起的效能異常。這一舉措標誌著一種從“被動響應”到“主動防禦”的思維轉變。

希望這次對 OpenResty 環境中兩個典型效能盲區的深度剖析，能夠為同樣奮戰在一線、致力於提升系統穩定性和效率的你，提供一個可借鑑的視角和思路。

關於 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 多個開源軟體庫。

關注我們

如果您喜歡本文，歡迎關注我們 OpenResty Inc. 公司的 部落格網站 。也歡迎掃碼關注我們的微信公眾號：

翻譯

我們提供了 英文版 原文和中譯版（本文）。我們也歡迎讀者提供其他語言的翻譯版本，只要是全文翻譯不帶省略，我們都將會考慮採用，非常感謝！