> So, this model might work if you have a Rails[1] app that doesn't use up a lot of memory. I can confirm that. In my previous company, we had a lot of H12 (re

> So, this model might work if you have a Rails[1] app that doesn't use up a lot of memory. I can confirm that. In my previous company, we had a lot of H12 (request timeout) on heroku. We thought this should be our codebase fault, without being able to isolate why some usually fast requests were sometime so long to complete. As a workaround, we decided to temporary switch to unicorn to add more concurrency to our dynos. H12 went down, but we were flooded by R14 (memory exceeded). Even with two workers, it was too much. Granted, our app was eating too much memory and we were refactoring it to split it into several distinct apps. We also had the problem that heroku router seemed to send requests to dyno while master unicorn process was starting (and thus, could not process it yet), which was a major problem since we used hirefire, which keep starting new dynos(and thus, new unicorn masters).