−25% Server Cost with Puma and malloc Tuning

TL;DR

By tuning Puma workers and threads and paying attention to allocator behavior, we cut server costs by 25% and increased throughput from 200 to 500 RPM on the same Rails monolith.

The starting point

We were running a Rails app on Puma with a conservative worker/thread setup. Latency was acceptable but the bill was growing, and we were hitting a 200 RPM ceiling before response times degraded.

What we tuned

1. Puma workers: increased to better use CPU cores without over-subscribing memory.
2. Threads per worker: reduced slightly because our workload is I/O-bound and more threads increased contention.
3. Request queue size: monitored to separate capacity issues from slow responses.
4. Allocator: collected RSS metrics and confirmed glibc malloc was holding onto memory. We planned a jemalloc migration as the next step.

The result

• 200 RPM → 500 RPM sustainable throughput.
• 25% reduction in server cost.
• Memory graphs became predictable enough to right-size instances.

What I learned

Throughput and cost are often the same problem. Before scaling horizontally, squeeze the runtime you already have. The biggest single lever was matching the worker count to the instance's cores and memory, then measuring RSS stability instead of only latency.