Puma Tuning + Concurrency

A misconfigured Puma is the most common Rails performance issue after N+1. Defaults are conservative; the right tuning depends on workload (I/O-bound vs CPU-bound), memory budget, and Ruby version. This skill encodes the formulas.

The opinion

Workers = CPU cores × 1.5 (I/O-bound) or = CPU cores (CPU-bound). Threads per worker = 3-5. preload_app! + fork-safe initializers (re-establish DB connections after fork). MALLOC_ARENA_MAX=2 + jemalloc. YJIT on for Ruby 3.3+. Plan for ~300-500MB per worker after warm-up.

Counter-position: Falcon and Iodine offer event-loop concurrency that beats Puma on pure I/O workloads. For 95% of Rails apps, Puma is the right answer.

The formulas

WORKERS  = max(2, CPU_cores × 1.5)         # I/O bound (most Rails apps)
WORKERS  = CPU_cores                        # CPU bound (heavy serialization, image processing)
THREADS  = 5                                # safe default; tune up to 10 for I/O-heavy
TOTAL    = WORKERS × THREADS                # concurrent requests handled
MEMORY   = WORKERS × 400MB                  # rough budget after warm-up