Systemic bottlenecks
This course covers performance problems that come from shared, finite resources in a Rails application. It separates a slow path, which is slow at any load, from a plateau, which appears when concurrency reaches a limit. Lessons work through Puma workers and threads, four logical databases on one Postgres server, connection pool arithmetic, and Solid Queue running inside Puma. They also cover skipping unneeded work, measuring with warm runs and medians, and knowing when to stop. A final challenge models a pipeline and finds its bottleneck stage.
What you'll learn
- ✓How to tell a slow path from a plateau, and why throughput is concurrency divided by latency
- ✓Why four logical databases on one Postgres server share every ceiling and a polling floor
- ✓How the connection pool multiplies per process and per database, and what ConnectionTimeoutError points to
- ✓What running Solid Queue inside Puma costs, and how named queues separate slow jobs
- ✓How to skip unneeded work, measure with warm runs and medians, and recognize when to stop
A plateau is not a slow query
There are two very different performance problems. They look the same from outside, and most wasted optimization comes from treating one as the other.
Read the full lesson free →Curriculum
7 lessonsA plateau is not a slow query
Distinguishes a slow path from a plateau and shows that throughput equals concurrency divided by latency.
Everything is one database
Shows how primary, cache, queue and cable share one Postgres server, along with every ceiling and a polling floor.
The connection pool
Explains why pool size counts per process and per database, and what ConnectionTimeoutError usually means.
When jobs and requests share a box
Covers Solid Queue inside Puma, shared CPU and memory, named queues, and the polling interval as a trade.
The cheapest work is skipped work
Walks through the roadmap page, where collection caching and one select call cut request time and queries.
Measuring without fooling yourself
Covers warm runs and medians, separating database, view and framework time, and recognizing when to stop optimizing.
Putting it together
Reviews the course and sets a challenge: find a pipeline's throughput, bottleneck stage and per-stage utilization.