Service Mesh Overhead Calculator
Calculate the latency and CPU overhead a service mesh's sidecar proxies add to a request path, based on proxy hop count.
Inputs
Number of sidecar proxy hops in the request path (typically 2 per service-to-service call: client-side + server-side sidecar).
Added latency contributed by each proxy hop (mTLS handshake amortized, routing, telemetry).
Request latency without the mesh's sidecars in the path, for comparison.
Additional CPU consumed by one sidecar relative to the application container's own CPU usage.
Number of distinct sidecars whose CPU overhead should be summed for this request path.
Latency Added by Mesh
3.00ms
Latency Overhead
7.5%
Total Request Latency
43.00ms
Total CPU Overhead
16.0%
Step by step
Latency added: proxy hops × per-hop latency
2 × 1.5ms
= 3.00ms
Total latency: baseline + added
40 + 3.00
= 43.00ms
Total CPU overhead: sidecars × per-sidecar overhead
2 × 8%
= 16.0%
How it works
Every hop through a sidecar proxy adds a small, roughly constant amount of latency for TLS, routing decisions and telemetry collection: latency_added_ms = proxy_hops × per_hop_ms. A typical service-to-service call in a mesh traverses two hops — the caller's outbound sidecar and the callee's inbound sidecar — and each active sidecar also consumes CPU proportional to the traffic it proxies, which should be budgeted alongside the application container's own resource requests.
Formula
overhead_percent = (latency_with_mesh - latency_without_mesh) / latency_without_mesh × 100
- latency_with_mesh
- Request latency through the mesh (ms)
- latency_without_mesh
- Direct request latency without mesh (ms)
Frequently Asked Questions
How many proxy hops does a typical mesh request have?
Most service mesh architectures (Istio, Linkerd) add 2 hops per service-to-service call — the client's outbound sidecar and the server's inbound sidecar — though calls through an ingress gateway or additional intermediate services add more.
Is 1-2ms per hop realistic?
For modern high-performance proxies like Envoy or Linkerd's Rust-based proxy under moderate load, 0.5-2ms per hop for p50 latency is typical; p99 tail latency can be considerably higher under resource contention or with expensive per-request policies (e.g. complex authorization checks).
Does mTLS significantly increase per-hop latency?
The TLS handshake cost is amortized across a connection's lifetime via session reuse and connection pooling, so per-request overhead from mTLS is typically small once connections are warm — see the dedicated mTLS performance calculator for a detailed breakdown.
How should I budget CPU for the mesh across a whole cluster?
Multiply the per-sidecar CPU overhead percentage by your application containers' baseline CPU requests, then add that as extra CPU request/limit for each sidecar container — this mesh 'tax' should be included in overall cluster capacity planning.
You might also need
- mTLS Performance CalculatorCommonly used together
- Service Mesh Health Score CalculatorCommonly used together
- Timeout Configuration CalculatorCommonly used together
- Traffic Split CalculatorCommonly used together
- Envoy Proxy Capacity CalculatorCommonly used together
- Istio Sidecar CPU CalculatorCommonly used together