Hoping Heroku will fix what I consider a major bug. Until then, I've resigned to having to redeploy to heroku in the middle of the night to avoid customers getting pissed.
Hoping Heroku will fix what I consider a major bug. Until then, I've resigned to having to redeploy to heroku in the middle of the night to avoid customers getting pissed.
(disclaimer: I work at dotCloud)
Working on startup time definitely helps getting that number down, but they did a pretty good job in starting up on Heroku fast I think.
You can take a look at how we deploy your code to heroku here: http://help.railsonfire.com/deployment/Heroku-Deployment.htm...
You can deploy to staging on every build and deploy to production only when you push to a specific branch for example. So you still deploy continuously to staging, but trigger deployment to production manually.
Basically to set it up all you need to to is install our gem and run railsonfire create in your application folder.
We are going public with our Heroku Addon as soon as possible, but you can login with your GitHub account or email/password as well (and even connect all 3 of those logins into one account).
If you have any more questions send me an email to flo@railsonfire.com
I'm generally only seeing a lag of a few seconds at most, and no lost requests. I would look at your code and see what improvements you may be able to make.
Even a very simple Rails sample app will often take over a minute to spin up on heroku. I don't think it's smart to completely focus on server startup time when the real fix is available on most other deployment environments.
That said, I still like Heroku and can deal with this for a while until they fix it :)
When you make a new push to Heroku, they seem to make sure to setup the code on a different machine, get it up, and then finally redirect the incoming requests from the load balancer.