puma-tuning-and-concurrency

What problem does it solve?

Misconfigured Puma is the most common Rails performance issue after N+1 queries. Default Puma settings are overly conservative, leading to wasted memory, poor concurrency, and missed throughput gains for production Rails applications.

Core Features & Use Cases

• Workload-aware sizing formulas: Calculates optimal worker count (CPU cores × 1.5 for I/O-bound, ×1 for CPU-bound) and thread count per worker (3-5 default, up to 10 for I/O-heavy workloads) based on your server specs and app type.
• Memory optimization integration: Guides setup of jemalloc, MALLOC_ARENA_MAX=2, and YJIT for Ruby 3.3+ to cut memory usage by 20-40% and boost throughput by 10-25%.
• Production-safe configuration: Provides copy-on-write compatible Puma config with preload_app!, fork-safe on_worker_boot hooks for DB/cache reconnection, and PumaWorkerKiller setup to bound memory bloat from leaks.
• Use Case: A team running a 4-CPU I/O-bound Rails 8 monolith uses this skill to configure 6 Puma workers with 5 threads each, enabling 30 concurrent requests with a ~2.4GB total memory budget, avoiding overprovisioning and underutilization.

Quick Start

Use the puma-tuning-and-concurrency skill to calculate the optimal Puma worker count, thread count, and memory settings for your production Rails 8 deployment on a 4-CPU I/O-bound server.