How I have improved the Database performance from 5 seconds to 1 millisecond
summary
Customer workload starts at multi-second latencies (examples show 5s and 200ms spikes) and target is <50ms; optimizations reduce p99 to single-digit milliseconds and often ~1ms. Key actions: use static CosmosClient singleton, prefer ReadItemAsync using id+partition key instead of cross-partition queries, choose direct connection mode and private endpoints, fix hot partitions and warm up load tests, increase worker cores, split growing documents (attendance separate from employee), store binaries in blob storage, and use autoscale for throughput.
AI-written summary · about
chapters (18)
- 0:00Start
- 5:08Features
- 5:18Global Distribution
- 7:53The Challenges
- 8:06Architecture
- 8:58Cost Factor
- 9:17Capacity Calculator
- 14:04Single Execution of Test
- 15:22Client Objects
- 16:02Thread Safety
- 20:46Connection Mode
- 21:57Code B
- 22:48Demo
- 27:36Thread Switching
- 30:51Async Performance Capture
- 33:13Data Model
- 38:25Binary Files
- 39:46The Final Result
related talks
48mPerformance tuning for Azure Cosmos DB
33mDriver for Data-Driven Change - Azure Cosmos DB Performance, Security & Cost Optimization Done Right
12mWhen each millisecond counts?
45mGetting the Most from NoSQL in the Cloud with Azure Cosmos DB
59mPlanet scale or planet fail?
32mAzure Cosmos DB Performance Tuning
01h 00mCost cutting strategies for Azure Cosmos DB
01h 02mAzure Cosmos DB - Low Latency and High Availability at Planet Scale