Istio performance is measured in several different ways.

1. IBM Regpatrol measures performance of a realistic application. It runs nightly in ingress-only, full-istio and mixer-disabled modes. The throughput and response times can be compared between builds to detect trends and regressions.

2. Synthetic service graph measures performance of a deeply nested synthetic micro-services application. It creates 20 services per name space and typically runs with 20 - 40 namespaces in large a cluster. Here is a v1.1 Performance dashboard and the corresponding Mesh dashboard using release-1.1-20190110-09-15 build.

3. Two pods benchmark test runs a focused benchmark for data path performance only, which is available at: https://perf.dashboard.istio.io/

sidecars - 0.75 vCPU / 1k rps @1KB response size

istio-telemetry - 0.7 vCPU / 1k rps

istio-policy - 0.002 vCPU / 1k rps @ > 95% cache hit rate

twopod test baseline: {p90 1.2ms, p99 2.1ms}, full istio: {p90 9.6ms, p99 13.8ms} Istio adds 8ms at p90 and 11ms at p99.

• Pilot: 1
• Sidecars: 1600
• Services: 800
• VirtualServices: 80
• Gateways: 44
• Namespaces: 40
• Config Change rate: 10 per minute {galley.sourceEventRate}

Namespace Isolation: On, Sidecar resource

• 1 VCPU peak

• 1.4GB Memory

• Proxy Memory: 70Mi

Namespace Isolation: off

• 5 VCPU peak
• 4GB Memory
• Proxy memory: 170Mi

When NS isolation is off

1. Pilot needs to broadcast changes to all pods and namespaces
2. Every proxy gets more configuration. All clusters and all listeners are delivered to all sidecars. That explains the difference between memory consumption.

Time to get ready. < 5s