Measuring the Performance Overhead of OpenResty XRay When Profiling Go Applications

When you profile a live Go 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 gin (Go) application in production mode: during active sampling, maximum throughput dropped by only 1.5% and average latency rose by just 6 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 captured system metrics using the top command before starting the analyzer. As shown below, the target gin-helloworld process (a Go application) was consuming approximately 43% CPU. The system’s one-minute load average stood at 0.62, CPU idle was around 84%, and available memory was approximately 1,546 MB.

What Happens to CPU, Memory, and Load During Profiling?

To simulate a real-world diagnostic scenario, we used the OpenResty XRay console to launch a 300-second (5-minute) “High CPU usage” analysis in production mode against the target Go process (via: Guided Analysis → High CPU usage → select target process).

Choosing production mode is critical: it is specifically designed for live environments and minimizes performance impact through techniques such as low-frequency sampling. The trade-off is that analysis sessions may take longer to complete.

During the analysis run, we observed the following changes across system metrics:

• Target process CPU usage: rose to about ~47%, up approximately 4 percentage points from the baseline.
• System one-minute load average: rose to 0.63, a negligible increase from the baseline of 0.62.
• CPU idle: held steady around ~85%, essentially unchanged from the baseline of 84%.
• Available memory: rose to ~1,622 MB, up 76 MB from the baseline.

In summary, the OpenResty XRay analyzer’s impact on system-level resources — CPU, memory, and load — during active sampling is measurable but minimal, posing no meaningful risk to system stability.

How Much Does Profiling Affect Throughput and Latency?

For production services, throughput and latency are the two metrics that matter most. We tested each across three scenarios to establish a clear comparison. The table below summarizes the results across all three scenarios:

1. Maximum Throughput

We used a load testing tool to measure peak server throughput across three configurations:

• Without the OpenResty XRay Agent installed: maximum throughput was approximately 24,500 RPS.
• With the Agent installed but the analyzer idle: maximum throughput remained unchanged.
• With the analyzer actively sampling: maximum throughput was approximately 24,100 RPS — just 1.5% lower than the no-sampling baseline.

These results confirm that running the analyzer has a negligible impact on the target process’s maximum throughput.

2. Average Request Latency

We measured the impact of sampling on request latency across the same three scenarios:

• Without the OpenResty XRay Agent installed: average request latency was 406 microseconds.
• With the Agent installed but the analyzer idle: average request latency was unchanged.
• With the analyzer actively running: request latency rose to 412 microseconds — an increase of just 6 microseconds.

This demonstrates that running the analyzer has an equally negligible impact on request latency.

It is worth noting that automatic analysis on the “Insights” and “Dashboard” pages carries a similarly negligible performance overhead.

If you are troubleshooting an actual high CPU issue in a Go application, see how we traced a service that burned 36.8% of its CPU time on regex compilation: analyzing high CPU usage in Go applications. We ran the same production-mode overhead measurement on other languages as well — see the results for Rust, 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.

FAQ

How much performance overhead does OpenResty XRay add to a production Go application?

During active analysis, OpenResty XRay lowers maximum throughput by about 1.5% (from ~24,500 to ~24,100 requests per second) and adds about 6 microseconds of average latency (from 406 µs to 412 µ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 gin app?

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 gin-helloworld process, the one-minute load average rose only from 0.62 to 0.63 and target-process CPU from 43% to about 47%, so it can be deployed continuously in production.

Does OpenResty XRay slow down my Go 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 1.5% throughput impact while actively profiling.

How much CPU and memory does OpenResty XRay use while profiling a Go process?

While sampling the gin-helloworld process, target-process CPU usage rose from a baseline of 43% to about 47% (roughly 4 percentage points), CPU idle held steady at about 85% (baseline 84%), and available memory was about 1,622 MB — a minor change from the 1,546 MB baseline.

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.

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.