4 ms·

Tried this, it's not really possible because Heroku deploys restart the server and make the site inaccessible for a few minutes (and often errors out requests).

Tried this, it's not really possible because Heroku deploys restart the server and make the site inaccessible for a few minutes (and often errors out requests). 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.

tomfakes 15y ago
This one point has me sitting on the fence with taking my app to production on Heroku, or using Amazon EC2 directly and eating the time to build Chef scripts to provision servers.
neilmiddleton 15y ago
Personally, I don't see this. If you spend the time making sure that your application spins up nice and fast then the only downtime is from when Heroku decommissions the old version of your application and the new one starts up. 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.
- ryanbrunner 15y ago
  It really depends on your environment. If you're using Rails, it's almost certainly 100% dependent on how many gems you're using.
- railsjedi 15y ago
  Most deployment allows for the site spin up independently before switching the load balance to it to provide a seamless experience. 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 :)
vineet 15y ago
I checked with Heroku regarding this before considering using it. It seems that you should not be seeing the above (atleast on their latest cedar stack). 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.
- ryanbrunner 15y ago
  This is true only for a very trivial definition of "get it up". The second that Heroku starts your server all requests will be pushed over to the new dynos. For a Rails app, depending on how many gems you are loading and how fast your environment can load, this might be as much as 15 seconds of request queueing.
shykes 15y ago
Shameless plug: dotCloud (http://www.dotcloud.com http://www.dotcloud.com) doesn't have downtime at deployment. It leaves your current version untouched until the new version is fully built, run, scaled and responsive. Only then is trafic switched over. If anything goes wrong on even a single node, the deployment is safely aborted. This is the case even for deployments which span dozens or hundreds of processes on several datacenters. It's a lot of work to get right. (disclaimer: I work at dotCloud)
- railsjedi 15y ago
  Awesome, thanks for the heads up. I'll definitely be trying DotCloud very soon. Glad you guys were able to really focus on the small details as its easy to glance over when trying to launch a product.
matlock 15y ago
We (Railsonfire, a continuous deployment service actually) deploy regularly to Heroku (up to several times a day) and the timeout is a few seconds max. We are on cedar stack though, which might make a difference there. 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.html 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

tomfakes 15y ago

This one point has me sitting on the fence with taking my app to production on Heroku, or using Amazon EC2 directly and eating the time to build Chef scripts to provision servers.

neilmiddleton 15y ago

Personally, I don't see this. If you spend the time making sure that your application spins up nice and fast then the only downtime is from when Heroku decommissions the old version of your application and the new one starts up. 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.

ryanbrunner 15y ago
It really depends on your environment. If you're using Rails, it's almost certainly 100% dependent on how many gems you're using.
railsjedi 15y ago
Most deployment allows for the site spin up independently before switching the load balance to it to provide a seamless experience. 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 :)

vineet 15y ago

I checked with Heroku regarding this before considering using it. It seems that you should not be seeing the above (atleast on their latest cedar stack). 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.

ryanbrunner 15y ago
This is true only for a very trivial definition of "get it up". The second that Heroku starts your server all requests will be pushed over to the new dynos. For a Rails app, depending on how many gems you are loading and how fast your environment can load, this might be as much as 15 seconds of request queueing.

shykes 15y ago

Shameless plug: dotCloud (http://www.dotcloud.com http://www.dotcloud.com) doesn't have downtime at deployment. It leaves your current version untouched until the new version is fully built, run, scaled and responsive. Only then is trafic switched over. If anything goes wrong on even a single node, the deployment is safely aborted. This is the case even for deployments which span dozens or hundreds of processes on several datacenters. It's a lot of work to get right. (disclaimer: I work at dotCloud)

railsjedi 15y ago
Awesome, thanks for the heads up. I'll definitely be trying DotCloud very soon. Glad you guys were able to really focus on the small details as its easy to glance over when trying to launch a product.

matlock 15y ago

We (Railsonfire, a continuous deployment service actually) deploy regularly to Heroku (up to several times a day) and the timeout is a few seconds max. We are on cedar stack though, which might make a difference there. 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.html 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