Concurrent Server Architectures
summary
Claims that Go uses epoll/non-blocking synchronous I/O to multiplex thousands of sockets in a few threads, and that naive “one goroutine per connection” hits the kernel OOM when you spawn 1,000,000 goroutines because each needs about 2 KB goroutine stack (≈2 TB total). Notes Linux limits like select limited to 1024 fds, recommends worker pools to cap goroutine count, and cites external benchmarks showing Go runtime schedules goroutines across cores for real parallelism.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 1:14Concurrent server challenges
- 3:02Sequential server approach
- 4:26Process and thread models
- 8:46Blocking vs non-blocking I/O
- 11:18Go's non-blocking I/O
- 12:44Goroutines for concurrency
- 14:52Worker pool pattern
- 15:57Standard library limitations
- 16:42Conclusion and Q&A
related talks
47mUnbounded Concurrency in Go
58mUnbound Concurrency in Go
24mMastering Concurrency in Go: From Patterns to Production
41mDetecting and Fixing Unbound Concurrency Problems
47mQueues, Fairness, and The Go Scheduler
01h 31mHistory of Time: Asynchronous C++
54mComplex Concurrency Patterns with Go
22mTales of Go Runtime Scheduler