菜单
文档breadcrumb arrow Beylabreadcrumb arrow 性能开销
Grafana Cloud

Beyla 性能开销

Beyla 与您的应用程序并行运行，对性能影响最小。我们使用以下方法来衡量性能开销：

  • 在本地 Kubernetes 集群中使用 Kind 和 Helm chart 以单进程方式部署 Beyla
  • 部署 OpenTelemetry Demo 以展示一个真实世界应用程序，其中包含多个相互交互的服务
  • 使用 application_process 测量性能，对 Beyla 进行插桩以提取进程级指标并测量 CPU 和内存使用情况
  • 每个场景都在前一个场景的基础上添加，因此我们可以测量每个功能对性能的影响
  • 使用 Prometheus 收集指标，使用 Grafana 进行可视化

性能影响

OpenTelemetry demo 带有一个负载生成器，用于模拟对应用程序的流量。此脚本向 /api/products 端点生成每秒 20 到 60 个请求，该端点可以调用 Redis、Kafka 和内部 RPC 调用。总请求量平均为每秒 75 个请求。

下表显示了 Beyla 对 OpenTelemetry Demo 应用程序的性能影响。

场景内存使用量CPU 使用率备注
基线：Beyla 自我插桩75MB0.05%Beyla 使用 application 和 application_process 功能进行自我插桩
默认：所有 OTEL demo 应用都已插桩75MB*0.5%对所有 OpenTelemetry demo 应用程序进行插桩最初会导致峰值内存使用量达到 600MB，这是因为我们需要查找并插桩正在运行的应用程序的符号，之后会下降到正常的 75MB 水平。CPU 使用率增加了 10 倍，因为它需要处理所有应用程序的流量。
默认 + 启用应用监控85MB1.2%Beyla 带有 application_span 和 application_service_graph 功能。内存和 CPU 使用量增加，Beyla 需要为每个请求生成更多指标（指标 Span 和图形指标）。
默认 + 调试模式95MB2%Beyla 设置为 log_level: debug 和 bpf_debug: true，并将追踪打印到 stdout。内存和 CPU 使用量增加，因为 Beyla 需要生成更多日志和调试信息。
默认 + 启用网络120MB1.2%Beyla 启用了 network 功能。内存和 CPU 使用量增加，因为 Beyla 需要从网络流量中生成更多指标。
启用了 OpenTelemetry 指标105MB1.5%这与“默认 + 启用应用监控”相同，但使用了 OpenTelemetry 指标导出器。
启用了 OpenTelemetry 追踪80MB*0.4%Beyla 生成追踪而不是指标。内存使用量会突发性增加，因为它需要创建批量追踪发送到收集器。

eBPF 程序开销

eBPF 程序在内核空间运行并在应用程序上下文中执行。eBPF 程序的开销极小，因为它们轻量且高效。通过在内核中运行，它们避免了与用户空间程序相关的上下文切换开销。此外，eBPF 程序使用即时 (JIT) 编译，这进一步优化了它们的性能。

为了测量延迟，我们使用了 Beyla 的 ebpf 功能来收集 eBPF 程序的延迟。在 OpenTelemetry demo 中运行 24 小时后，Beyla 所有组合探针观察到的延迟约为 40ms。这相当于每个请求 500ns 的延迟，可以忽略不计。

原始数据

您可以访问我们在 beyla_performance_calculation.pdf 中用于分析性能的原始数据。