This document 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.
- Application: Laravel/Aimeos on PHP-FPM 8.2
- Environment: local Docker with NGINX
- Telemetry destinations: OTLP-compatible endpoints
| Variant | Avg. time per request [ms] | Overhead [ms] |
|---|---|---|
| No agent | 17.36 | 0.00 |
| Vendor-specific APM agent | 20.63 | 3.27 |
| OpenTelemetry PHP Distro | 23.08 | 5.71 |
| OpenTelemetry PHP Distro + local collector | 24.37 | 7.01 |
| Vanilla OpenTelemetry PHP + protobuf (C extension) + collector | 25.76 | 8.40 |
| Vanilla OpenTelemetry PHP pure-PHP protobuf export + collector | 49.02 | 31.66 |
| Vanilla OpenTelemetry PHP pure-PHP protobuf export | 2158.58 | 2141.22 |
- 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.
- 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.