6 ms·

Hmm, you might be out of luck, but it does bring up the question of why Heroku doesn't have load-triggered scaling, or some sort of dead-man's switch option.

• jmonegro 16y ago
  There are third-party solutions for that, like this one: http://github.com/ddollar/heroku-autoscale http://github.com/ddollar/heroku-autoscale
  • aaronbrethorst 16y ago
    Have you been able to get that to work with Rails 3? I've tried and failed miserably.
    • jmonegro 16y ago
      Not really. If/when I do I'll see if I patch it up if the owner hasn't already.
  • andrewacove 16y ago
    Having been a Heroku user for a while, and having looked into autoscaling for dynos and workers a few times (but not having really needed it yet), I really think they could do a better job of publicizing that these solutions exist. I imagine that tons of their user base (especially for small hobby sites that only occasionally, if ever, see high traffic or run background tasks) look for this, and yet there's nothing pointing to it other than old posts on the mailing list. At least put information and resources for autoscaling in the Docs section of the site. Acquiring resources only as long as you need them, and then releasing them when you're done, should be the standard service - complete user control should be the advanced feature set. They already do this for websites on a single dyno: they spin them down when they're idle for a while. But they don't do it with workers (what effect does the latency of starting a backup job up really have? it's already running in the background).
    • tfe 16y ago
      It's because they need to keep a process running all the time to poll the queue for new jobs. So basically, they keep an instance of your app booted at all times for job processing (if I understand how DJ workers work). And that's pretty much like a dyno, except it doesn't serve traffic. And there are no web requests to trigger it to spin up like there are for dynos.
      • aaronbrethorst 16y ago
        One of Heroku's employees has a fork of delayed_job that handles autoscaling workers in the background. I use it in conjunction with several hourly cron jobs and it works like a charm. http://github.com/pedro/delayed_job/tree/autoscaling http://github.com/pedro/delayed_job/tree/autoscaling
        • andrewacove 16y ago
          Yes, I was aware of this, though I haven't had the need to use it yet. But my question stands: why isn't this stuff very visible - i.e., on Heroku's DJ doc page: http://docs.heroku.com/delayed-job http://docs.heroku.com/delayed-job , or at least linked from there? Or published as an official piece of code on the Heroku github page?
          • pts101 16y ago
            Because it would decimate their bottom line if everyone stopped running extra instances.
            • andrewacove 16y ago
              Really? I would certainly hope that's not the case. Relying on customers overspending due to technical deficiency seems like a pretty poor business model. I'd certainly be happier paying more per pro-rated unit of time that I actually use than I am feeling as though I'm in an arms race to not be fleeced. Is there really that much revenue to skim off the top? Either way, they're paying Amazon out of those charges. But I'm not so cynical as to think that their success is reliant on this income.