4 ms·
Heroku made the bold decision to design its routing technology to be optimized for things like Node and Go rather than Ruby. So if you are using Ruby on Rails
by grandalf 13y ago
Heroku made the bold decision to design its routing technology to be optimized for things like Node and Go rather than Ruby. So if you are using Ruby on Rails (like RapGenius) Heroku's platform will simply fall short, both in terms of efficiency and flexibility.
XL Dynos let you throw money at the random routing problem which helps routing efficiency at the expense of spend efficiency (b/c they are a lot more expensive and scaling down to 1 XL dyno is still pretty expensive).
In my opinion, if you're using anything other than 1X dynos on Heroku you are compensating for some other part of your stack being broken.
We're probably months away from Heroku having some serious competition in the super easy PAAS space. Heroku's high prices have summoned competitors en masse, and by some stroke of luck Amazon has not really made a serious effort to encroach on Heroku's profits.
- zrail 13y agoRunning modern Rails on a threading server like Puma, especially on JRuby or Rubinius, would probably get an application within the same ballpark of concurrency. At the very least it'd be better than Unicorn or Webrick or whatever the heck Rapgenius was using to serve their app.
- programminggeek 13y agoRunning rails on JRuby and Torquebox (especially the upcoming version 4) would provide MUCH better performance.
- mwcampbell 13y agoAm I correct in assuming that the relevant characteristic of Node and Go is high concurrency? If I'm not mistaken, Ruby can have that too, if you use something like Puma or Thin rather than Unicorn. Python may be on the wrong side of this, though, as long as Gunicorn is the de-facto standard WSGI server for Python apps on Heroku.
- grandalf 13y agoNot just concurrency but also boot time.
- thinkbohemian 13y agoOn my Production Rails app `time rails s` takes about 0m2.273s for me (Rails 4, Ruby 2.1.0). Not an insanely fast boot time, but nothing to lose sleep over.
- grandalf 13y agoRoughly how many models and controllers are in the app?
- bgentry 13y agoIn my opinion, if you're using anything other than 1X dynos on Heroku you are compensating for some other part of your stack being broken. You may want to read this section: https://blog.heroku.com/archives/2014/2/3/heroku-xl#understanding-perc99-and-tail-latencies https://blog.heroku.com/archives/2014/2/3/heroku-xl#understa... Performance dynos give you much higher performance and much better consistency, resulting in dramatically reduced tail latencies over 1X and 2X dynos. Choosing performance dynos for a high-traffic or performance-sensitive app is definitely not "compensating for some other part of your stack being broken"; in fact it's a very smart choice.
- mark_l_watson 13y agoI tend to agree with you. For some large interconnected systems, long tail latencies have a high complexity cost because you need to code around the 1% cases when (for example) web service calls take much longer than normal to return results. Client code becomes more complex.
- mjn 13y ago> Amazon has not really made a serious effort to encroach on Heroku's profits Amazon hasn't, but there are a reasonable number of simple PaaS competitors these days: Microsoft's Azure (http://www.windowsazure.com/en-us/pricing/details/web-sites/ http://www.windowsazure.com/en-us/pricing/details/web-sites/): ASP.NET, PHP, Node.js, Python Red Hat's OpenShift (https://www.openshift.com/ https://www.openshift.com/): Java, Ruby, PHP, Node.js, Python and Perl Nodejitsu (https://www.nodejitsu.com/ https://www.nodejitsu.com/): Node.js
- riffraff 13y agoamazon has elastic beanstalk, but it's still not as easy as heroku.
- shiftyrussian 13y agoNinefold.com has a wider choice of server sizes and is paas similar to heroku
- deleted 13y ago[deleted]
- oillio 13y agoIt seems to me this move is to compensate for the well understood issues in their routing layer. You can call these issues "bold decisions." In my opinion, it reads more like, "We don't know how to fix the problem. If you really want to pay for it, we will let you skip our routing layer and solve the problem yourself." It is a bit disappointing. However, I've never had to write a routing layer to handle 60,000 requests a second, so I can't really fault them.
- AJ72 13y agoDyno Sleeping: Another interesting fact that hasn't been called out is that even with the Heroku XL Dyno, which costs ($580/mo), it will be spun down if not used for an hour. I don't understand how that matches the promise of 'performance' https://devcenter.heroku.com/articles/dynos#dyno-sleeping https://devcenter.heroku.com/articles/dynos#dyno-sleeping