Ruby already has many tools for gathering telemetry data, but most of them haven’t put the performance as their first concern.
Ruby has several instrumentation tools: NewRelic Ruby Agent [1], Datadog Tracing Ruby Client [2], and OpenTelemetry Ruby [3]. However, their drawbacks are obvious: they offer limited observability, introduce unnecessary delays in applications, and are tightly coupled with the target’s implementation. Datadog offers Continuous Profiler [4] and Dynamic Instrumentation [5] to address some of these limitations, but they require manual setup, whereas SDB provides these benefits without manual effort.
Ruby also has several profiling tools, such as rbspy [6], stackprof [7], ruby-prof [8], pf2 [9], and vernier [10]. With the exception of rbspy, all of these tools increase application delay; ruby-prof, for example, nearly doubles it. This increase is primarily due to their use of signals to trigger stack scanning, which blocks application threads and performs symbolization synchronously. rbspy uses ptrace to scan stacks and gather symbolizations, but it consumes excessive CPU when the scan interval is short. SDB is also a stack profiling tool but operates fully asynchronously—it doesn’t execute code in application threads or acquire the Ruby GVL. Additionally, it decouples symbolization from function creation and offline analysis. These design choices allow it to outperform existing profiling tools.
Relative Work
Ruby already has many tools for gathering telemetry data, but most of them haven’t put the performance as their first concern.
Ruby has several instrumentation tools: NewRelic Ruby Agent [1], Datadog Tracing Ruby Client [2], and OpenTelemetry Ruby [3]. However, their drawbacks are obvious: they offer limited observability, introduce unnecessary delays in applications, and are tightly coupled with the target’s implementation. Datadog offers Continuous Profiler [4] and Dynamic Instrumentation [5] to address some of these limitations, but they require manual setup, whereas SDB provides these benefits without manual effort.
Ruby also has several profiling tools, such as rbspy [6], stackprof [7], ruby-prof [8], pf2 [9], and vernier [10]. With the exception of rbspy, all of these tools increase application delay; ruby-prof, for example, nearly doubles it. This increase is primarily due to their use of signals to trigger stack scanning, which blocks application threads and performs symbolization synchronously. rbspy uses ptrace to scan stacks and gather symbolizations, but it consumes excessive CPU when the scan interval is short. SDB is also a stack profiling tool but operates fully asynchronously—it doesn’t execute code in application threads or acquire the Ruby GVL. Additionally, it decouples symbolization from function creation and offline analysis. These design choices allow it to outperform existing profiling tools.
References