Performance Overhead

Performance benchmark results and guidance for minimizing overhead when using OpenTelemetry PHP Distro.

This page outlines performance implications of using OpenTelemetry PHP Distro and provides guidance for minimizing overhead.

Like any instrumentation agent, the distro runs in application processes and adds runtime cost. The exact impact depends on architecture, configuration, deployment environment, and workload.

The benchmark below compares multiple PHP observability variants in a local Docker setup (PHP-FPM 8.2 + NGINX). In scenarios with a collector, the collector also runs locally and shares host CPU resources.

Benchmark setup

  • Application: Laravel/Aimeos on PHP-FPM 8.2
  • Environment: local Docker with NGINX
  • Telemetry destinations: OTLP-compatible endpoints

Results

VariantAvg. time per request [ms]Overhead [ms]
No agent17.360.00
Vendor-specific APM agent20.633.27
OpenTelemetry PHP Distro23.085.71
OpenTelemetry PHP Distro + local collector24.377.01
Vanilla OpenTelemetry PHP + protobuf (C extension) + collector25.768.40
Vanilla OpenTelemetry PHP pure-PHP protobuf export + collector49.0231.66
Vanilla OpenTelemetry PHP pure-PHP protobuf export2158.582141.22

Key findings

  • OpenTelemetry PHP Distro significantly reduces overhead compared to vanilla OpenTelemetry PHP with pure-PHP protobuf export.
  • Local collector placement can increase overhead when it contends for CPU with PHP workers.
  • Pure-PHP protobuf export in vanilla OpenTelemetry PHP introduces very high overhead under this benchmark.

Recommendations

  • Measure overhead in your own workload and infrastructure.
  • Prefer OTLP HTTP/protobuf with asynchronous transport.
  • Avoid colocating heavy collector workloads with latency-sensitive application workers.
  • Tune sampling and exporter settings to meet your SLOs.