Hacker News Reader

When it comes down to it for rails deployment your going to maximize the number of workers you have based on the amount of available memory. I'd like to see a test where they set the number of workers equal to the amount that fit within 512MB's of ram or something similar. I'd say using passenger + ree you'd be able to double or triple the number of workers for the same amount of memory and blow the rest of the stacks out of the water.

View on HN

Forgive me if I'm just out of date here, but last time I checked, REE offered something like a 30% memory savings per forked worker. By my math (Workers_ree = Workers_mri / 0.7) that gives you something like a 1.4X increase in number of available workers.

Now, a 40% boost in running threads within the same memory is nothing to sneeze at. It's just a far cry from a 200% increase in the same metric.

Furthermore, for many deployments running on bare hardware (or even virtualized in a private datacenter), RAM isn't really the most precious resource. An modern app server can easily be packing 16-32GB of RAM, at which point CPU and I/O throughput can easily challenge memory for "most precious resource".

You are assuming that the processes are memory bound. While this is a frequent situation for Rails apps deployed on VPS machines, they are just as frequently CPU bound when under load.

Reply on news.ycombinator.com