
Heroku XL - zrail
https://www.heroku.com/xl
======
happywolf
A quick check on the documentation reveals instead of routing the requests to
the first available or least loaded dynos, the dyno routing algorithm now
routes requests to random dynos(Reference:
[https://devcenter.heroku.com/articles/how-heroku-
works#dyno-...](https://devcenter.heroku.com/articles/how-heroku-works#dyno-
manager))

Routing requests to random dyno is definitely not the smartest routing
algorithm because it kind of defeats the purpose of having a routing layer. If
you are not aware of the issue between Heroku and Rap Genius, I will think it
is important enough for anybody who considers Heroku to be aware of. Here is
the URL with relevant information: [http://news.rapgenius.com/James-somers-
herokus-ugly-secret-a...](http://news.rapgenius.com/James-somers-herokus-ugly-
secret-annotated)

~~~
zrail
This has been talked to death, but for the general case, for applications that
can handle concurrent requests (like Rails with a rack server just a tiny bit
smarter than Webrick), random routing works just as well as intelligent
routing with far less coupling in the routing later, making it more robust and
easier to manage and scale.

~~~
sync
Rails servers like Unicorn can still only support ~4 concurrent requests on
regular dynos (roughly 1 per virtualized core), lessening the problem but not
solving it if you have many requests per second.

~~~
jules
Actually that makes a tremendous difference. It is a bit difficult to explain
but even 2 concurrent requests per dyno is a lot better than 1. As you go up
from 2 to 3 to 4 the difference quickly becomes minimal. I'll try to explain
why, but warning: hand waving ahead!

The problem with only 1 concurrent request is that if that request takes long
to process then it can block other requests that are queued up in that dyno.
Lets say that 1% of the requests take long. If a dyno can process only 1
request concurrently then at each request there is a 0.01 chance that that
will block other requests. If however it can process 4 concurrent requests,
then the dyno will only be blocked if it gets 4 long requests at the same
time. So there is only a 0.01^4 = 0.00000001 chance that a dyno will be
blocked.

~~~
adrianpike
Not quite. If you keep routing to a blocked backend, any requests that hit
that backend will have unacceptable latencies. Since the routing is
essentially random, you'll still be fielding about 1/4 of your requests to
that backend, so one long request winds up making 1/4 of all your requests
have unacceptable latencies.

~~~
jules
I don't think that's how it works. Within a single dyno with concurrency of 4
a single request can not block block any requests. It can only block 1 thread,
but then the other requests will be processed on the other threads. Routing is
only random to dynos, within dynos it is not random.

------
grandalf
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.

~~~
mjn
> 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

~~~
shiftyrussian
Ninefold.com has a wider choice of server sizes and is paas similar to heroku

------
zrail
There's also a more informative blog post here:

[https://blog.heroku.com/archives/2014/2/3/heroku-
xl](https://blog.heroku.com/archives/2014/2/3/heroku-xl)

~~~
seanhandley
Thanks - this is a much better resource than the marketing page!

------
ROFISH
Heroku's $0.05/hr base pricing hasn't changed in a very long time, while
Amazon has both dropped price and increased power.

I love Heroku's service, but it's starting to get very expensive. This
$576/month plan proves it. :/

~~~
rplnt
And it still goes down when Amazon does (or has this changed?). Sure you get
something extra, but paying more just to add another layer that can possibly
fail? I don't know...

edit: Oh, and you are getting vendor-locked and they can go Google-App-Engine
on you.

~~~
ctide
[https://blog.heroku.com/archives/2009/4/24/commercial_launch](https://blog.heroku.com/archives/2009/4/24/commercial_launch)

It was .055 / hour when it launched in 2009. Back then, EC2 small instances
cost .10 / hour ([http://aws.amazon.com/about-aws/whats-
new/2009/10/27/announc...](http://aws.amazon.com/about-aws/whats-
new/2009/10/27/announcing-lower-amazon-ec2-instance-pricing/)).

Now? Heroku is .05 / hour, and small EC2 instances are .06 / hour. This is why
I stopped using Heroku a year or so ago for anything I plan on paying for.
They just let Amazon keep driving down their bottom line without passing any
of those savings onto their customers.

~~~
jroes
Heroku isn't just a transparent proxy to EC2. You are getting several other
services that are not easy to put together on your own - routing
infrastructure, simple git push deployment, world-class postgres tooling. To
put this kind of stuff together on your own is costly, and you will likely
make a lot of mistakes on the way (mistakes Heroku has already made and
learned from).

Another thought: When you use Basecamp, are you calculating how much they are
spending on hosting your data?

~~~
orf
This plan is $576 a month, the actual hardware you get for that is mediocre at
best. A postgres instance and git push deploy isn't worth that much and isn't
that hard to set up yourself.

sure, you could run into some issues while doing it yourself but that risk
isn't worth nearly $600 p/m IMO

~~~
jroes
How many hours do you spend a month on devops tasks? And on top of that, how
diligent are you with applying patches, testing backups, and all other sorts
of drudgery necessary to keep a production site running smoothly? Take that
number of hours, multiply it by your consulting rate, and there's a good
chance Heroku may save you money.

For most production apps, you'd need at least a part time ops person to do
things right. That's the kind of cost Heroku saves you.

------
ukd1
It's made a massive difference to us; we've gone from 10 x 1x dynos to 2 x XL
- it's done the following to our latency graph:
[http://i.imgur.com/BGKwGfp.png](http://i.imgur.com/BGKwGfp.png). Orange is
perc99.

~~~
thu
So you changed from $0.50 / hour to $1.60 / hour. Did you first try with, say,
20 x 1x dynos (that would cost $1.00 / hour)?

~~~
ukd1
Yep, but it didn't help like this did. I don't have graphs for you I'm afraid.

------
machbio
Someone explain me, why I would need a 6GB RAM machine over a dedicated server
that I could have with 10 times more machine at the same price..

~~~
adamlett
Maybe you don't have a full time sysadmin in your employ. Maybe you are a one-
man team that would rather spend your time working on user-facing features
instead of fiddling with infrastructure.

