Moving to a Service Mesh
summary
Indeed migrates Boxcar services to gRPC over Envoy and evaluates performance with a custom Hyperloop test harness instrumented by Prometheus via statsd. Tests show Boxcar peaks around 2909 ops/s vs 2671 ops/s for gRPC before tuning; after increasing client workers, event loop groups and executor threads gRPC can reach ~4200 ops/s and outperforms Boxcar at 90th/99th percentiles. Tuning knobs: event loop group sizing, optional channel pool, and executor type; observed a 1–2 ms client-side latency gap that proved acceptable.
AI-written summary · about
chapters (14)
- 0:00Start
- 6:03Hyperloop
- 8:45Event Loop Group
- 9:05Channel Pool
- 9:30Boss Event Loop Group
- 9:58Worker Event Loop Group
- 10:56Graph the Request Rates of Servers
- 12:40Latency
- 22:27How Did Boxcar and Gr Pc Compare to One another
- 24:29Did We Mix Gr Pc and Envoy in Architecture
- 27:34Traffic Monitoring and Traffic Control
- 29:30How Are We Handling Authentication and Authorization
- 30:09Distributing Distributed Tracing
- 30:48Are We Using Service Mesh in Production
related talks
50mEnabling Googley microservices with gRPC
24mNext Generation Services at Indeed Using gRPC [I]
30mgRPC & Kubernetes
21mReal World Migration from HTTP to gRPC in Ruby
22mA Case Study of Enhancing gRPC Micro-Services for Supporting High Throughput, Low Latency Trading
33mgRPC For Microservices: Service-mesh and Observability
22mUsing a Service Mesh With gRPC
33m"RPC frameworks overview"
