
Heroku 2X Dynos in Public Beta - craigkerstiens
https://blog.heroku.com/archives/2013/4/5/2x-dynos-beta
======
aroman
"Do single 2X dyno apps idle? Yes. Idling affects single 1X and 2X dyno apps
alike."

I genuinely do not understand this. I'm still paying for it. I run a node.js
app for my school that gets decent traffic, but not enough to warrant adding
another dyno (and moreover I only wrote it to work on one process). Yet I
_still_ deal with the idling problem.

I would gladly pay Heroku the money for a 2X dyno if it meant I would stop
getting idled (which is extremely annoying and disruptive), or even just some
express per-month fee to disable idling.

I feel like I'm being punished because my app is performant and doesn't need
two or more dynos...

Am I crazy here, or does this really bug anyone else?

~~~
tzaman
There's an easy solution to that. Just install the free version of New Relic
add-on. In there, you'll find an option to periodically check availability.
That will trigger a request to the URL you provide every 30 seconds, keeping
the dyno alive at all times.

~~~
aroman
While that's true, I just really don't understand why I have to resort to
sucks hacks to simply eliminate idling. I am a paying Heroku customer with a
CC on file... I just want to give them money to do something properly which I
could hack around legitimately.

The fact that this has clearly been brought to their attention before and they
have offered no real answers (I'm literally suggesting a checkbox for $10 a
month or something that simply keeps my app un-idled) frankly gets me thinking
about ulterior motives. I love Heroku, and find their services very valuable,
but some of their decisions make very little sense to me, like this, or more
recently how they've handled the RapGenius accusations.

~~~
adamwiggins
I totally agree that hacks to avoid idling when are willing and able to pay is
lame. We've actually been working on something very similar to what you
describe. Send me an email at adam at heroku dot com and I can give you early
access.

------
scottshea
Keep in mind with more Unicorn workers per box you will need fewer dynos
overall so it does not necessarily mean you will have to pay double in the
long run. At 1x Dynos we could only have 2 workers going but at 2x we could
squeeze five workers in so we use half of the dynos we did before.

~~~
tolas
Same here. We were struggling to fit 2 unicorn workers on a 1x dyno but can
easily get 4 on a 2x. We're paying the same amount for twice the concurrency.
The 2x dynos with unicorn have pretty much solved the queuing issues for us.

~~~
rickyc091
Wait up... I'm a bit confused here. How is it that you were struggling with 2
unicorns on a 1x (512mb) dyno, but 4 unicorns works on a 2x (1024mb) dyno?

~~~
jordanthoms
Unicorn instances fork after loading rails, so they share memory. (This will
work better on ruby 2.0 with the copy on write friendly GC)

------
instakill
The commenter called dude is spot on with his comment about Heroku's marketing
copy on their homepage:

"Get up and running in minutes, and deploy instantly with git. Focus 100% on
your code, and never think about servers, instances, or VMs again."

This is not the case anymore.

~~~
adamwiggins
I agree that thinking about memory use steps a bit closer to the world of
server administration, which doesn't thrill me. We've actually had 2X dynos in
alpha for close to a year, but we never pushed forward with a public release
precisely for this reason.

However, the demand from customers — especially apps on the JVM — has been
overwhelming. There's no way around it: once you start doing heavy background
processing (e.g. geospacial or image processing) or web concurrency with a
memory-intensive language like Ruby, then you care about memory. It would be
very head-in-the-sand for us to not serve this need.

I'd love to imagine that there's some design that allows us to abstract away
memory, but despite a lot of attempts, we haven't seen one. Further, memory is
generally the most expensive part of server-side computing resources these
days, so decoupling memory use from price isn't very feasible.

------
thu
I'm not sure I understand the pricing. I get you got twice the amount of
memory compared to a 1X dyno. But still the rest of the resources is the same.
For instance they will share a single queue (which is the point, no problem
here), so they don't have really any added complexity or new resources. But
the price is doubled.

~~~
masonhensley
Correction- from the comments:

"2X dynos contain twice the capacity. Memory and CPU shares. It's a new option
to experiment with vertical scaling: you may get better performance from one
2X dyno than two 1X's. In that case you'll get more value. As explained in the
post whether or not that's the case depends on the app. If you find that
scaling 1X dynos works better, you are free to keep these instead."

------
evanjacobs
One point that I haven't seen raised yet is that a reduction in the # of dynos
required to operate a service would provide the benefit of being able to run
certain addons that are priced on a per dyno basis more cheaply (e.g.
NewRelic).

~~~
dkuebric
I've been told they're encouraging add-ons to move away from a per-dyno price.
(Looked like New Relic is the only one right now).

The guys I talked to cited both the future (now present) "dyno is not a unit"
problem, as well as reporting user dissatisfaction with non-flat-rate billing.

------
JiPi
I guess there would be some serious benefits for uses with Puma too!

~~~
scottshea
Totally. Given the smaller footprint of Puma there is a win available there
too as long as you can use JRuby or Rubinius

~~~
JiPi
There is a win with MRI too, though there is a much bigger win with JRuby or
Rubinius :)

------
nthitz
Neat! I wonder if it would be possible for them to do 1/2x dynos at 256MB for
lower end uses?

~~~
whalesalad
Your first dyno is free. Under what circumstances would 1/2 size dyno's be
helpful?

~~~
mdasen
The first dyno is free, but it doesn't stay booted. After a period of
inactivity, Heroku shuts it down if you don't have any paid dynos. When a new
request comes in, it take a few seconds for the dyno to boot back up. For
users that have little traffic, the dynos get shut down and your requests are
very slow when they happen.

Heroku has good reason for this. The number of test apps that people create to
try the system and then never shut down is probably quite high. They don't
want to be running 10,000x512MB worth of apps that aren't serving any traffic.
However, that also means that if you have a low-traffic (but real app) running
on their system, the dyno is likely to get shut down during the times where
you have no traffic.

A 1/2 size dyno would allow people to have a cheaper dyno that wouldn't be
shut down.

~~~
beambot
At one point in time, you could add the free version of NewRelic along with a
scheduler task to keep your free dyno active: <https://coderwall.com/p/u0x3nw>
I haven't tested that... so things might be different now.

