Hacker News Reader

Comment by fomb | Hacker News Reader

So how does this resolve the Heroku routing problem for you? You have one server that internally routes efficiently - but what happens when you scale past one server?

If you're not scaling past one server, why does Heroku's routing cause you issues?

View on HN

On Heroku I was using thin that forced me to scale horizontally to handle more than one request at the same time. With this setup I can set a number of unicorn workers bigger than 1 and I'm done. I can scale vertically until I can and then set up more machines with the same methodology and use a load balancer like HAProxy to manage requests.

Why not use Unicorn on Heroku?

There is a limited amount of workers you can run with 512mb of memory (max 3 for my application) and the random routing can overload one dyno while the others are doing nothing. Basically you have to scale and pay more when with Digital Ocean I can buy a 2gb machine and run 10 workers spending 20$ per month.

He can use a 2-core VPS with plenty of memory and he will have much more headroom than a single Heroku dyno.

How many people really have to worry about scaling past a single server? To me, the issue is more about uptime so that where PaaS's get extra credit as far as I am concerned. It is great to be able to go on vacation and not much worry about admin hassles.

Using unicorn on a vps is the equivalent of many 'servers' or dynos on heroku, and unicorn is taking the place of the heroku routing here, so this does address the problem as you'd have more control over things like timeout and routing strategy, and have other options too for load balancing. If you do need several servers there is software out there to do load balancing, but with caching you can easily scale a single vps to serve a lot of users. For example HN still runs on one server I think, there's a pic of it somewhere that pg posted...

Reply on news.ycombinator.com