Calculate the request throughput capacity of an Envoy proxy instance.
Envoy's memory footprint combines a fixed base cost with two dynamic components that scale with load: memory = base_memory + connections × per_conn_memory + routes × per_route_memory. Connection state (buffers, TLS session data, HTTP/2 stream state) usually dominates for high-throughput proxies, while very large route tables (thousands of virtual hosts) can make route memory a significant factor in API gateway or ingress deployments.
max_rps = (cpu_cores × 1000) / cpu_per_request_millicores
TLS termination, HTTP/2 multiplexing, and large request/response buffering all increase per-connection memory significantly compared to simple plaintext TCP proxying — profile your actual Envoy instances under representative load rather than relying on generic defaults.
Reducing the mesh-wide route/cluster configuration pushed to each sidecar (e.g. via Istio Sidecar resource scoping to relevant namespaces) is the most effective lever, since every sidecar otherwise receives the full mesh's route table by default.
Yes — reusing upstream connections instead of opening a new one per request reduces the total concurrent connection count Envoy must track, directly lowering connection-related memory overhead.
A minimal Envoy sidecar with default stats and admin interface typically starts around 30-80MB before any dynamic connection or route load is applied, though this varies by build and enabled filters.