The Journey to Achieve 1000x TPS for a Real-World Core Banking Application on TiDB
summary
A real deployment on ARM64 TiDB starts at QPS 1 and reaches 1,200 after systematic fixes: fix three slow queries with a composite index and enable index-merge (QPS → 30), rework topology and double TiDB instances with NUMA binding and CPU/memory affinity (QPS → 600), fix HAProxy session limits, use LVS or client-side load balancing, correct disk and NIC placements (QPS → 880), push tombstones and scale app JVMs (QPS → 1,200). Diagnosis uses mpstat, flamegraph, perf, go trace and Grafana, and improvements rely on a higher plan cache hit ratio.
AI-written summary · about
chapters (26)
- 0:00Intro
- 0:15Abstract
- 1:08Introduction
- 2:18User Response Time
- 5:46Real-world case
- 6:05Background
- 6:59Workload analysis - Read Heavy
- 10:55Full table scan vs Index merge
- 11:43TPS up to 30
- 11:59Topology adjustment
- 12:47Where is the bottleneck?
- 15:17Duration VS Connection Idle Duration
- 18:45The impact of Numa
- 19:32New topology
- 20:23HAProxy 2000 session limit
- 21:07Proxy solution
- 21:52Env Fix
- 24:31Final result
- 25:32DB time Analysis
- 26:28Plan Cache hit ratio
- 27:35Query performance vs GoLang GC
- 29:54Plan stability challenge
- 31:29Always stale statistics
- 32:35The optimizer enhancement requests
- 33:26Key Takeways
- 34:38TiDB Evolution For Mission-Critical OLTP
related talks
47m10 Reasons Why the TiDB Database Should Power Your Next Development Project
30mStateful Superpowers: Explore High Performa...
29mDistributed SQL: How TiDB Modernized Data Management
22mIt’s all about the db - a journey to accommodate 100k events per second
26mReimagine Real-time
29mDistributed SQL How TiDB Modernized Data Management
36maccelerating the digital agenda
23mArchitecting for Performance, Scalability and Real-time Data with AWS