6 ms·

You run "touch #{RAILS_ROOT}/tmp/restart.txt". That will restart the rails processes. No connections are dropped, and I've not seen any downtime.

latortuga 17y ago
To clarify, my understanding is that while rails is restarting, Passenger will queue all the requests that come in and begin processing them as soon as rails is ready. But yeah, zero downtime, it's pretty awesome.
- joevandyk 17y ago
  that is correct.
- fizx 17y ago
  Sites do tend to lag for at least several seconds after the restart though.
  - caseyf 17y ago
    Yeah. We load balance across 5 Apache/Passengers and I do rolling deploys (all in Capistrano) by removing a Passenger from load balancing, updating the app, restarting Apache, and adding it back into load balancing with a 10 second delay between each. We tried the Passenger touch restart.txt and that didn't go well at all when we were under load.
    - chadr 17y ago
      Have you tried contacting the Passenger developers about this? I won't be surprised if they come out with a fix for this.
    - boundlessdreamz 17y ago
      Can you share your setup please?
      - brett 17y ago
        He has been kind enough to share about his setup quite a lot about lately. In fact, looks like it's on the HN homepage right now: http://news.ycombinator.com/item?id=872301 http://news.ycombinator.com/item?id=872301
      - caseyf 17y ago
        I wrote a short post about our setup in March and it hasn't really changed since then: http://codemonkey.ravelry.com/2009/03/10/quick-update-ravelry-runs-on/ http://codemonkey.ravelry.com/2009/03/10/quick-update-ravelr... If you have any questions or are looking for details or something, ask away - just stick a comment on the blog post.
  - EvilTrout 17y ago
    Also, if you're using Monit to watch the memory bloat of your passenger processes, when you kill one process it tends to do the same stalling thing on all your processes until the ONE you killed is back up.

latortuga 17y ago

To clarify, my understanding is that while rails is restarting, Passenger will queue all the requests that come in and begin processing them as soon as rails is ready. But yeah, zero downtime, it's pretty awesome.

joevandyk 17y ago
that is correct.
fizx 17y ago
Sites do tend to lag for at least several seconds after the restart though.
- caseyf 17y ago
  Yeah. We load balance across 5 Apache/Passengers and I do rolling deploys (all in Capistrano) by removing a Passenger from load balancing, updating the app, restarting Apache, and adding it back into load balancing with a 10 second delay between each. We tried the Passenger touch restart.txt and that didn't go well at all when we were under load.
  - chadr 17y ago
    Have you tried contacting the Passenger developers about this? I won't be surprised if they come out with a fix for this.
  - boundlessdreamz 17y ago
    Can you share your setup please?
    - brett 17y ago
      He has been kind enough to share about his setup quite a lot about lately. In fact, looks like it's on the HN homepage right now: http://news.ycombinator.com/item?id=872301 http://news.ycombinator.com/item?id=872301
    - caseyf 17y ago
      I wrote a short post about our setup in March and it hasn't really changed since then: http://codemonkey.ravelry.com/2009/03/10/quick-update-ravelry-runs-on/ http://codemonkey.ravelry.com/2009/03/10/quick-update-ravelr... If you have any questions or are looking for details or something, ask away - just stick a comment on the blog post.
- EvilTrout 17y ago
  Also, if you're using Monit to watch the memory bloat of your passenger processes, when you kill one process it tends to do the same stalling thing on all your processes until the ONE you killed is back up.