Skip to content

Coroot — Benchmarks

Performance overhead, resource consumption, and scale limits for Coroot's eBPF-based observability.

eBPF Agent Overhead

Test Conditions

Parameter Value
Workload Go HTTP server (baseline)
Load 10,000 requests per second (RPS)
Agent coroot-node-agent (eBPF)
Methodology Latency comparison: baseline (no agent) vs agent enabled

Results

Metric Without Agent With Agent Impact
Request latency Baseline Within margin of error Negligible
CPU consumption ~200 millicores ~20% of 1 CPU core
Latency impact Within measurement error

Key finding: At 10,000 RPS, the latency difference with the coroot-node-agent enabled vs baseline falls within the margin of measurement error. The eBPF programs are verified by the kernel for finite complexity, guaranteeing they cannot disrupt kernel operations.

CPU Profiler Overhead

Component Overhead Notes
eBPF CPU profiler 1–3% Based on Grafana Pyroscope implementation
JVM with -XX:+PreserveFramePointer 1–3% Required for accurate JVM stack traces

Resource Consumption at Scale

Coroot Server

Cluster Size Recommended CPU Recommended RAM Notes
< 50 services 1 vCPU 2 GB Single-node sufficient
50–200 services 2 vCPU 4 GB Inspection engine overhead
200+ services 4+ vCPU 8+ GB Service map complexity

Node Agent

Per Node CPU RAM
Base overhead ~50 millicores ~50 MB
Under load (10K RPS) ~200 millicores ~100 MB
Heavy profiling ~300 millicores ~150 MB

Scale Limits

Dimension Practical Limit Bottleneck
Services per cluster 500+ Server CPU for service map
Nodes per cluster 200+ Node agent DaemonSet scaling
Multi-cluster 10+ clusters Network bandwidth to central server
Metrics cardinality Backend dependent Prometheus/VM limits apply
Trace throughput Backend dependent ClickHouse write capacity

Storage Backend Requirements

Backend Scenario Resources
Prometheus < 1M series 2 CPU, 8 GB RAM, 100 GB SSD
VictoriaMetrics 1–10M series 2 CPU, 4 GB RAM, 200 GB SSD
ClickHouse 100 GB/day logs + traces 4 CPU, 16 GB RAM, 500 GB SSD

Caveats

  • Benchmarks are from vendor-provided testing. Users with specialized workloads should conduct their own validation.
  • eBPF overhead can vary based on kernel version, workload characteristics, and enabled collection features.
  • Disabling span capture while maintaining eBPF metrics can further reduce resource consumption in extremely high-load environments.

Sources