← 返回

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

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

預計閱讀 6 分鐘

閱讀次數

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

測試環境與效能基線

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

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

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

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

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

目標程序 CPU 佔用率：上升至 ~74%，相比基線增加不到 1 個百分點。
整個系統過去一分鐘的平均負載值：上升至 0.92，比之前的 0.86 增加了 0.06。
CPU 空閒率：維持在 ~74.5%，與基線 74.3% 相差無幾。
系統可用記憶體：下降至 ~1564 MB，僅降低約 2 MB，無明顯變化。

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

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

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

狀態	最大吞吐量	平均延時
未安裝 OpenResty XRay 的 Agent	約 56600 RPS	37.79 微秒
已安裝 Agent、分析器空閒	約 56600 RPS(不變)	37.79 微秒(不變)
分析器正在取樣	約 55300 RPS(−2.2%)	38.91 微秒(+1.12 微秒)

1. 最大吞吐量

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

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

結果顯示，執行分析器對目標程序的最大吞吐量影響極小。

2. 平均請求延時

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

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

這證明了執行分析器對目標程序的請求延時影響也極小。

總結

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

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

如果你正在排查 Rust 應用的實際 CPU 問題，可參考我們找出 Sled 庫中最熱程式碼路徑的實戰：Rust CPU 剖析實戰。同樣的生產模式開銷實測我們也在其他語言上做過，可檢視 Go、PHP、Python、Perl 應用的實測結果。

OpenResty XRay 與常駐式 APM Agent 的對比

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

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

常見問題

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

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

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

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

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

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

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

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

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

在對 rocket-server 程序取樣期間,目標程序 CPU 佔用從基線約 73% 升至約 74%(不到 1 個百分點),CPU 空閒率穩定在約 74.5%(基線 74.3%),可用記憶體約 1564 MB——僅降低約 2 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 多個開源軟體庫。