RubyKaigi 2009 wrap up

Andre Lewis on August 17, 2009

James Gray's July 19th talk at RubyKaigi 2009 focused on best practices for long-running Ruby daemon processes.

What types of questions did the audience ask? What did they seem most interested in?

In general, users always want to know about our RRD usage, extracting the daemon functionality from Scout's agent, and the agent's memory usage. It was the same at RubyKaigi. The questions reminded me of how much current Ruby RRD solutions suck and that it's time we did something about that. It also reminded me that I need to get around to extracting our daemon code, which I've always intended to do.

Any surprises?

I was impressed at how totally wonderful the Japanese are as hosts. They invite us over to visit, help translate our slides, translate questions as they are asked, and tell us how much we are appreciated. I didn't do anything 1/10th as hard as they did for me.

Leonard Chin especially deserves a medal for keeping track of all the international Rubyists. He is tirelessly gracious.

Anything Scout-related at the conference that would be of interest to readers?

Well, Koichi caught me practicing my speech at one point early in the conference. He latched onto the words I had on screen, "Exit is the Ultimate GC." We talked a little about that with him relating to me his current research on supporting multiple virtual machines in a single Ruby process.

We will need to wait and see how that all turns out, but something like that could hold a lot of potential for programs like Scout if they can get the virtual machine costs low enough. It may be possible to run Scout's instrumentation code in a separate virtual machine of the Rails process to really avoid impacting the application in any way (not that we do much now). It may also unlock new options for how to redesign our agent daemon to live in a single process, but still be as safe as it is now.