← 返回

生產環境實測：追蹤 Python 應用時 OpenResty XRay 對系統效能的影響

章亦春釋出於 Nov 27, 2023 更新於 Nov 27, 2023

預計閱讀 6 分鐘

閱讀次數

在生產環境分析一個實時執行的 Python 應用，最大的顧慮往往不是能不能定位問題，而是分析工具本身會不會拖垮線上服務。我們在一個實時執行的 gunicorn（WSGI）應用上、以生產模式實測了 OpenResty XRay 的開銷：取樣期間最大吞吐量僅下降 3.4%、平均延時僅增加 0.16 毫秒，而 Agent 空閒時效能開銷嚴格為零。之所以能做到這一點，是因為它與常駐式 APM Agent 不同，不對目標程序做任何程式碼注入或修改，只在使用者主動發起分析時才低頻採集資料；下文用一組逐項實測資料，還原它對 CPU、記憶體、負載，以及吞吐量和延時的真實影響；完整的實測與操作過程，可觀看本文上方的影片版本。

測試環境與效能基線

為建立對比基準，在分析器執行前，我們透過 top 命令捕獲了系統效能基線。如下圖所示，目標 gunicorn 程序（Python 編寫的應用）的 CPU 佔用約為 46.5%，整個系統過去一分鐘的平均負載值為 0.7，當前 CPU 空閒率約為 87.2%，可用記憶體約 2632 MB。

分析期間對 CPU、記憶體和負載有何影響?

為模擬真實診斷場景，我們透過 OpenResty XRay 控制檯，在生產模式下，針對該 Python 程序發起了一次持續 300 秒（5 分鐘）的 “High CPU usage” 場景分析（路徑：Guided Analysis → High CPU usage → 選擇目標程序）。

選擇“生產模式”至關重要，因為它專為線上環境設計，透過低頻取樣等最佳化，旨在將效能影響降至最低。不過這也意味著分析時間可能會更長。

在分析器執行期間，我們觀察到系統各項指標的細微變化：

目標程序 CPU 佔用率：上升至 ~48%，相比基線增加約 1.5 個百分點。
整個系統過去一分鐘的平均負載值：上升至 0.84，比之前的 0.7 增加了 0.14。
CPU 空閒率：下降至 ~86.7%，與基線 87.2% 相差無幾。
系統可用記憶體：維持在 ~2631 MB，僅降低約 1 MB，無明顯變化。

結論是，OpenResty XRay 分析器在取樣期間對系統級資源（CPU、記憶體、負載）的影響是存在的，但幅度輕微，並未對系統穩定性構成壓力。

分析對吞吐量與延時的影響有多大?

對於線上服務而言，吞吐量和延時是衡量效能的生命線。我們對這兩項核心指標進行了三輪對比測試。下表彙總了三種狀態下的結果:

狀態	最大吞吐量	平均延時
未安裝 OpenResty XRay 的 Agent	約 2300 RPS	4.32 毫秒
已安裝 Agent、分析器空閒	約 2300 RPS(不變)	4.32 毫秒(不變)
分析器正在取樣	約 2220 RPS(−3.4%)	4.48 毫秒(+0.16 毫秒)

1. 最大吞吐量

我們使用壓測工具，測量了不同狀態下伺服器的最大吞吐量。

沒有安裝 OpenResty XRay 的 Agent 時，最大吞吐量約為每秒 2300 個請求。
當 Agent 已安裝但未執行分析器時，最大吞吐量保持不變。
當分析器正在取樣時，最大吞吐量約為 2220 RPS，僅比不進行取樣時低 3.4%。

結果顯示，當分析器正在取樣時，最大吞吐量約為每秒 2220 個請求，僅比不取樣時低 3.4%。

2. 平均請求延時

我們測量了取樣過程中，對請求延時的影響。

沒有安裝 OpenResty XRay 的 Agent 時，平均請求延時為 4.32 毫秒。
當 Agent 已安裝但分析器未執行時，平均請求延時沒有變化。
當分析器正在執行時，請求延時變為 4.48 毫秒。僅僅增加了 0.16 毫秒。

總結

透過對系統資源、應用吞吐量和請求延時的全面測量，可以得出結論：OpenResty XRay 的動態追蹤架構，使其在對生產環境 Python 應用進行實時診斷時，效能開銷可量化、可預期，且對核心業務指標的影響極小。這證明了它是一款可以安全、放心地在生產環境中常態化使用的效能分析工具。

在 Insights 和 Dashboard 頁面進行自動分析的開銷也同樣極低。

如果你的 Python 程序 CPU 佔用很低、吞吐卻上不去，可參考用 off-CPU 分析定位阻塞的 subprocess.run 呼叫的實戰：Python 應用 off-CPU 分析。同樣的生產模式開銷實測我們也在其他語言上做過，可檢視 Go、Rust、PHP、Perl 應用的實測結果。

OpenResty XRay 與常駐式 APM Agent 的對比

開銷之所以能維持在如此低的水平，根源在於架構差異。傳統 APM Agent 會向目標程序注入程式碼並持續採集資料，因此無論是否有人在觀察，都會始終帶來執行時開銷。OpenResty XRay 採取相反的思路:非侵入式,且僅按需取樣。

	傳統常駐式 APM Agent	OpenResty XRay
資料採集	持續、始終開啟	按需,僅在使用者發起分析時
目標程序	程式碼注入 / 插樁	非侵入,不修改程式碼
空閒時開銷	持續存在	嚴格為零
取樣時開銷	持續存在	約 3.4% 吞吐、+0.16 毫秒延時

常見問題

OpenResty XRay 對生產環境的 Python 應用會帶來多大的效能開銷?

在分析進行期間,OpenResty XRay 使最大吞吐量下降約 3.4%(從約 2300 降至約 2220 每秒請求數),平均延時增加約 0.16 毫秒(從 4.32 毫秒到 4.48 毫秒)。當 Agent 已安裝但未在取樣時,吞吐量和延時均無變化;當其空閒時,效能開銷嚴格為零。

在生產環境的 gunicorn 或 Django 應用上執行 OpenResty XRay 安全嗎?

安全。OpenResty XRay 的 Agent 是非侵入式的——它不對目標程序做任何程式碼注入或修改,只在你主動發起分析時才低頻採集資料。在對一個實時執行的 gunicorn 程序做 300 秒生產模式分析期間,系統過去一分鐘的平均負載僅從 0.7 升至 0.84,目標程序 CPU 僅從 46.5% 升至約 48%,因此可以在生產環境中常態化部署。

OpenResty XRay 在未執行分析時會拖慢我的 Python 應用嗎?

不會。Agent 只在使用者發起的分析執行期間採集資料。當其已安裝但處於空閒狀態時,最大吞吐量和請求延時與完全沒有安裝 Agent 時完全一致——效能開銷嚴格為零。

OpenResty XRay 的開銷與傳統常駐式 APM Agent 相比如何?

傳統 APM Agent 向目標程序注入程式碼並持續執行,始終帶來開銷。OpenResty XRay 則按需、低頻取樣,因此空閒時開銷為零,取樣時也僅有約 3.4% 的吞吐影響。

OpenResty XRay 在分析 Python 程序時佔用多少 CPU 和記憶體?

在對 gunicorn 程序取樣期間,目標程序 CPU 佔用從基線 46.5% 升至約 48%(約 1.5 個百分點),CPU 空閒率僅從 87.2% 降至 86.7%,可用記憶體穩定在約 2631 MB——變化約 1 MB。

關於 OpenResty XRay

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

立即申請 OpenResty XRay 試用

關於作者

章亦春是開源 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 多個開源軟體庫。