Blog

Archive for October, 2008

MerbCamp Keynote and Introducing Nanite

By | October 11th, 2008 at 5:10PM

Just a quick post to share some news. I just finished giving my keynote at MerbCamp about past and present merb and the core tenets of merb development.

I also introduced Nanite: self assembling cluster of ruby processes.

You can watch the full video of my talk here: Keynote Video.

And you can see my slides on slideshare below.

Merb Nanite

View SlideShare presentation or Upload your own. (tags: merb nanite)

Thanks to all the merbcamp organizers, the venue is awesome and I have never spoken at a ruby conference that streamed all of the talks live. Very cool setup here.

I will follow up with some more posts on nanite and the what why and how of it shortly. But you can get a pretty good overview of it by watching my talk.

Popularity: 1% |

Merb Master Process

By | October 3rd, 2008 at 5:10PM

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)

All of these improvements are just harbingers of even more improvements, making Merb’s master process even more powerful and smart.

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.

Popularity: 1% |

Attention DC Rubyists!

By | October 3rd, 2008 at 5:10PM

Do you live in or around the Washington DC area? Free next weekend, or looking to take a trip?

If you’re not already registered to attend Ruby DCamp, perhaps we can be of assistance…

Ruby DCamp is an experimental Ruby BarCamp-style event, organized by local DC Rubyists. We can get you in, but only if you can answer the following super challenging question ;)

The legendary Matz: what’s his full name? Spelled correctly, that is. The first two folks to email giveaways@engineyard.com, Subject: RubyDCamp Passes, get in.

Good luck!

Popularity: 1% |