Apologies for the delay in posting about this. I was enjoying the fantastic Ajax Experience and jQuery Camp out in Boston, where I got a chance to hang with my jQuery compatriots as the huge Microsoft and Nokia announcement broke.
Now that I'm back, I want to talk about the cool new features we've been adding to Merb's server. Let's take a look at them one at a time:
- When a Merb server boots up and tries to bind to existing ports, it doesn't crash. Instead, it waits for each port to become available and binds when they do. As a result, you can start up a new merb, and then gracefully kill the old one. This should make restarting clusters of merbs significantly less painful, and with almost no downtime.
- Merb's clusters have been rewritten to take advantage of Ruby Enterprise Edition, which makes it much easier to share memory between workers in a Merb cluster. Using Ruby Enterprise with Merb 1.0 should yield around the same 30% memory improvement that Phusion Passenger yields.
- Merb clusters are now controlled by a master process, which can be told to gracefully kill all of its children, or reload the application code (but not init.rb or gems).
- Sending an INT to the master process (directly or via merb -K all) tells each of the worker processes to gracefully die.
- Sending a HUP to the master process tells each of the worker processes to gracefully die, but to start up a new cluster with reloaded code. This bypasses reloading Merb, gems, and init.rb, so the restart is much quicker than doing a full reload. This is also the same internal code used by development mode code-reloading, which has now been made 100% foolproof.
- Killing a worker process (either via INT, which is graceful, or KILL, which isn't) will cause a new process to be respawned instantly. We're talking basically no time at all, since no code needs to be reloaded (the spawner process forks right before binding to a port)
The most important thing to keep in mind is that Merb has been significantly tuned for Ruby Enterprise, and with regular Ruby, there is a bit of overhead for the master processes. All of the features above will work correctly with standard Ruby, but you'll get them for free (memory-wise), as well as quite a bit of improved memory overall in a cluster by using Ruby Enterprise.
Please please please check it out.