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

平均指標再健康，也掩蓋不住偶爾飆升的延遲尖刺。我們發現了一個不容忽視的穩定性風險：週期性出現的尖刺將延遲推高至 300 毫秒級別，這已經超出了對核心交易路徑的嚴格 SLA 閾值。對於 OpenResty 作為關鍵閘道器的系統而言，這不僅是效能衰退的訊號，更是潛藏的交易超時風險。

當“地震儀”找不到震源

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

• 平均值掩蓋下的隱患： 我們發現，在絕大多數請求都正常響應時，仍然有極少數請求（即最慢的那 1%）會出現短暫卻高達 300 毫秒以上的嚴重延遲。這些訊號在客戶現有的海量監控資料中很容易被當作統計噪音而忽略，但 OpenResty XRay 卻能精準捕捉並分析其最長耗時，將其標記為高風險事件。
• 持續高企的 CPU 黑洞： 監控顯示，閘道器叢集的 CPU 利用率，尤其是在 log 階段，一直居高不下。為了保證峰值時段的穩定性，客戶團隊不得不採用超額配置的策略，這直接轉化為了高昂的基礎設施成本。

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

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

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

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

效能熱點鎖定

在對客戶的高效能閘道器叢集進行深度分析時，我們首先著手解決的是一個棘手的延遲毛刺問題。

• 資料指引： 透過對生產環境的瞬時取樣分析，我們將高延遲現象與一個特定的字串處理函式關聯起來。資料顯示，在處理某些特定模式的輸入時，該函式的單次執行耗時可達 244.64 毫秒，這足以解釋觀察到的延遲毛刺。
• 證據： 進一步分析表明，該函式所依賴的底層引擎在設計上未對 JIT（即時編譯）進行最佳化。當遇到某些邊界情況的輸入時，其模式匹配演算法會退化為一種低效的回溯模式，導致執行時間出現指數級增長。

基於此發現，我們建議將熱點路徑中的該函式替換為框架內一個更現代、且為高併發場景設計的 JIT 友好型替代方案。實施後，系統的延遲毛刺現象得到有效解決，服務可用性指標恢復穩定。

深層損耗分析

在解決了延遲問題後，我們注意到系統的整體 CPU 使用率仍然高於預期基線，這表明存在進一步的最佳化空間。

• XRay 證據： On-CPU 火焰圖提供了一個清晰的方向，一個通常被認為是低開銷的日誌記錄（log）階段，意外地佔用了 26.5% 的 CPU 時間，成為一個不成比例的 CPU 消耗點。
• 歸因分析： 對該函式棧的下鑽分析揭示了問題的核心：在日誌處理邏輯中，一個用於格式化和脫敏的正規表示式，在每次請求處理時都被重新編譯。這種在迴圈中執行的昂貴編譯操作，是導致 CPU 開銷過高的直接原因。

我們建議在相關的正規表示式呼叫中啟用“編譯快取”選項，確保其“一次編譯，多次執行”。這一調整大幅降低了客戶日誌模組的 CPU 佔用，將這部分計算資源釋放出來，從而提升了伺服器處理核心業務邏輯的容量。

被遺忘的 PCRE JIT 開關

前兩項最佳化解決了應用層面的具體問題，但 OpenResty XRay 的“Lua-Land”報告揭示了一個更深層次、更系統性的問題。

• 系統性發現： 分析報告顯示，即使在應用了快取最佳化之後，系統核心的 PCRE（Perl Compatible Regular Expressions）引擎的 JIT 加速功能，在整個生產環境中也並未被啟用。
• 根源追溯： 這個問題並非源於程式碼邏輯，而是來自更上游的構建環節。我們確認，客戶用於部署的基礎容器映象，在編譯其核心應用閘道器時，遺漏了啟用 PCRE JIT 支援的關鍵編譯引數（--with-pcre-jit）。
• 戰略性修正： 這意味著整個叢集從未利用到這一重要的效能增強特性。我們向客戶團隊提出了修正其CI/CD流程、重構基礎映象的建議。此舉從根本上啟用了平臺的一項核心效能特性，徹底釋放 OpenResty 的潛力。系統性地提升了所有相關服務的效能基線，展現了我們貫穿應用程式碼、執行時環境到基礎設施構建全鏈路的分析能力。

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

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

1. 延遲毛刺徹底消除： 最佳化後，延遲曲線變得平滑如鏡，從超過 300 毫秒降至穩定水平。
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. 公司的 部落格網站 。也歡迎掃碼關注我們的微信公眾號：

翻譯

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