Why your ASP.NET Core application won't scale
summary
Practical drill-down on why ASP.NET Core apps stop scaling: concrete demos show a sync-over-async pattern causing thread-pool starvation (30 concurrent requests turn into one RPS because each request blocks five seconds), timer/disposal leaks that accumulate timers in the queue, large-object-heap and gigabyte allocations from buffering, and forgotten disposals (HttpClient, file handles) causing port and handle exhaustion. Tools used are PerfView and dotnet-dump plus Visual Studio dumps and a load tool (Bombardier). Fixes demonstrated: avoid blocking thread-pool threads, use cancellation tokens, flush/Dispose streams, and bound or size-limit caches.
AI-written summary · about
chapters (32)
- 0:00Intro
- 0:30Do you build ratifications
- 1:11What is scale
- 1:48Two kinds of scaling
- 2:31What is your app scale
- 3:47What effects skill
- 6:14Shared resources
- 8:00Async programming
- 8:57Testing before production
- 10:30The cycle
- 11:05CPU skill
- 11:19Load testing vs stress testing
- 13:07Checklist for scalability
- 15:29IO usage
- 16:08Sinking
- 17:18Sync over a sink
- 19:16Threads super high
- 20:08Demo
- 22:38Debugging
- 24:09Visual debugging
- 25:38Get a dump from a process
- 28:00Debugging a heap
- 32:12Debugging in time
- 32:48Threads
- 34:01Lock
- 35:14Concurrency
- 38:14Demonstration
- 45:48Object graph
- 47:04MVC
- 52:46Timers
- 54:21Testing
- 56:06The fix
related talks
01h 00mDiagnosing issues in ASP.NET Core Applications
57mSpeeding Up ASP.NET Core
01h 01mWhat's New In ASP.NET Core
01h 02mPatterns for application development with ASP.NET Core
48mWhy I’m Not Leaving .NET
01h 02mWriting high performance code in .NET
59mClean Architecture With ASP.NET Core
01h 02mHow to Scale .NET Apps with Distributed Caching