Tested in Production: The Performance Impact of OpenResty XRay When Tracing Rust Applications
When you profile a live Rust application in production, the biggest worry is usually not whether you can pinpoint the problem, but whether the profiling tool itself will drag down your production service. We measured the overhead of OpenResty XRay on a live rocket-server (written in Rust) application in production mode: during active sampling, maximum throughput dropped by only 2.2% and average latency rose by just 1.12 microseconds, while the Agent’s overhead is exactly zero when idle. This is possible because, unlike always-on APM agents, it performs no code injection or modification on the target process and only collects data — at low frequency — when a user explicitly starts an analysis; the sections below use point-by-point benchmark data to show its real impact on CPU, memory, and load, as well as on throughput and latency. For the full walkthrough, see the video version at the top of this article.
Test Environment and Performance Baseline
To establish a baseline for comparison, we recorded the system’s performance metrics using the top command before starting the profiler. As shown below, the target rocket-server process (a Rust application) was consuming approximately 73% CPU. The system’s 1-minute load average was 0.86, the CPU idle percentage was approximately 74.3%, and available memory was approximately 1,566 MB.
What Happens to CPU, Memory, and Load During Profiling?
To replicate a real-world diagnostic scenario, we used the OpenResty XRay console to launch a 300-second (5-minute) “High CPU usage” analysis session against the Rust process in production mode (path: Guided Analysis → High CPU usage → select target process).
Selecting “production mode” is critical, as it is specifically designed for live environments and minimizes performance impact via optimizations such as low-frequency sampling. The trade-off is that analysis sessions may take longer to complete.
During the profiler run, we observed the following subtle changes across system metrics:
- Target process CPU usage: increased to ~74%, less than 1 percentage point above the baseline.
- System 1-minute load average: rose to 0.92, up 0.06 from the baseline of 0.86.
- CPU idle percentage: held steady at ~74.5%, nearly identical to the baseline of 74.3%.
- Available memory: dropped to ~1,564 MB, a decrease of only ~2 MB — effectively unchanged.
In summary, while the OpenResty XRay profiler does introduce some overhead on system-level resources (CPU, memory, and load) during sampling, the impact is minimal and poses no threat to system stability.
How Much Does Profiling Affect Throughput and Latency?
For production services, throughput and latency are the defining measures of performance. We ran a three-part comparative benchmark covering both of these critical metrics. The table below summarizes the results across all three scenarios:
| Scenario | Max throughput | Avg latency |
|---|---|---|
| OpenResty XRay Agent not installed | ~56,600 RPS | 37.79 µs |
| Agent installed, profiler idle | ~56,600 RPS (unchanged) | 37.79 µs (unchanged) |
| Profiler actively sampling | ~55,300 RPS (−2.2%) | 38.91 µs (+1.12 µs) |
1. Maximum Throughput
We used a load testing tool to measure the server’s maximum throughput across three different conditions.
- Without the OpenResty XRay Agent installed, the maximum throughput was approximately 56,600 requests per second.
- With the Agent installed but the profiler not running, the maximum throughput remained unchanged.
- With the profiler actively sampling, the maximum throughput was approximately 55,300 RPS — only 2.2% lower than the baseline without sampling.
These results demonstrate that running the profiler has a negligible effect on the target process’s maximum throughput.
2. Average Request Latency
We measured the impact on request latency while the profiler was sampling.
- Without the OpenResty XRay Agent installed, the average request latency was 37.79 microseconds.
- With the Agent installed but the profiler not running, the average request latency remained unchanged.
- With the profiler running, the request latency rose to 38.91 microseconds — an increase of just 1.12 microseconds.
This confirms that running the profiler also has a negligible effect on the target process’s request latency.
Conclusion
Through comprehensive measurement of system resources, application throughput, and request latency, we can conclude that OpenResty XRay’s dynamic tracing architecture ensures that the performance overhead of real-time diagnostics on production Rust applications is both quantifiable and predictable, with a negligible impact on core business metrics. This makes it a profiling tool that can be safely and confidently deployed in production environments on an ongoing basis. To see how OpenResty XRay delivers this non-intrusively across any language stack, read what OpenResty XRay is.
The overhead of automatic analysis on the Insights and Dashboard pages is equally minimal.
If you are chasing an actual CPU problem in a Rust application, see how we found the hottest code paths in the sled database: Rust CPU profiling with OpenResty XRay. We ran the same production-mode overhead measurement on other languages as well — see the results for Go, PHP, Python, and Perl applications.
OpenResty XRay vs. Always-On APM Agents
The reason the overhead stays this low is architectural. Traditional APM agents inject code into the target process and collect data continuously, so they impose runtime overhead at all times — whether or not anyone is looking. OpenResty XRay takes the opposite approach: it is non-intrusive and samples only on demand.
| Traditional always-on APM agent | OpenResty XRay | |
|---|---|---|
| Data collection | Continuous, always on | On demand, only during a user-initiated analysis |
| Target process | Code injection / instrumentation | Non-intrusive, no code modification |
| Overhead when idle | Persistent | Exactly zero |
| Overhead while sampling | Persistent | ~2.2% throughput, +1.12 µs latency |
FAQ
How much performance overhead does OpenResty XRay add to a production Rust application?
During active analysis, OpenResty XRay lowers maximum throughput by about 2.2% (from ~56,600 to ~55,300 requests per second) and adds about 1.12 microseconds of average latency (from 37.79 µs to 38.91 µs). When the Agent is installed but not actively sampling, throughput and latency are unchanged, and when it is idle the overhead is exactly zero.
Is OpenResty XRay safe to run on a production Rust application?
Yes. The OpenResty XRay Agent is non-intrusive — it performs no code injection or modification on the target process and only collects data when you explicitly start an analysis, at a low sampling frequency. During a 300-second production-mode analysis of a live rocket-server process, the one-minute load average rose only from 0.86 to 0.92 and target-process CPU from about 73% to about 74%, so it can be deployed continuously in production.
Does OpenResty XRay slow down my Rust app when it is not actively analyzing?
No. The Agent only collects data while a user-initiated analysis is running. When it is installed but idle, maximum throughput and request latency are identical to having no Agent at all — the performance overhead is exactly zero.
How does OpenResty XRay’s overhead compare to a traditional always-on APM agent?
Traditional APM agents inject code into the target process and run continuously, imposing overhead at all times. OpenResty XRay instead samples on demand at a low frequency, so it adds zero overhead when idle and only about 2.2% throughput impact while actively profiling.
How much CPU and memory does OpenResty XRay use while profiling a Rust process?
While sampling the rocket-server process, target-process CPU usage rose from a baseline of about 73% to about 74% (less than 1 percentage point), CPU idle held steady at about 74.5% (baseline 74.3%), and available memory was about 1,564 MB — a decrease of only ~2 MB.
What is OpenResty XRay
OpenResty XRay is a dynamic-tracing product that automatically analyzes your running applications to troubleshoot performance problems, behavioral issues, and security vulnerabilities with actionable suggestions. Under the hood, OpenResty XRay is powered by our Y language targeting various runtimes like Stap+, eBPF+, GDB, and ODB, depending on the contexts.
If you like this tutorial, please subscribe to this blog site and/or our YouTube channel. Thank you!
About The Author
Yichun Zhang (Github handle: agentzh), is the original creator of the OpenResty® open-source project and the CEO of OpenResty Inc..
Yichun is one of the earliest advocates and leaders of “open-source technology”. He worked at many internationally renowned tech companies, such as Cloudflare, Yahoo!. He is a pioneer of “edge computing”, “dynamic tracing” and “machine coding”, with over 22 years of programming and 16 years of open source experience. Yichun is well-known in the open-source space as the project leader of OpenResty®, adopted by more than 40 million global website domains.
OpenResty Inc., the enterprise software start-up founded by Yichun in 2017, has customers from some of the biggest companies in the world. Its flagship product, OpenResty XRay, is a non-invasive profiling and troubleshooting tool that significantly enhances and utilizes dynamic tracing technology. And its OpenResty Edge product is a powerful distributed traffic management and private CDN software product.
As an avid open-source contributor, Yichun has contributed more than a million lines of code to numerous open-source projects, including Linux kernel, Nginx, LuaJIT, GDB, SystemTap, LLVM, Perl, etc. He has also authored more than 60 open-source software libraries.
























