More on Ruby Performance
Saturday, 2 September 2006
Posted by austin in: Ruby, trackback
After yesterday's post, Vidar of edgeio (a classified advertising site) posted to ruby-talk his experience with using Ruby in a high-performance environment. He previously had a simple messaging middleware that he had written in C++ and replaced it with a 700-line Ruby middleware that had more features that took less time to write. (Granted, some of the less time to write is because the second time you implement something, you know what you’re doing and know what shortcuts you can take.) The interesting bits from his article, though, suggest he’s done some serious profiling:
We hardly ever max out [CPUs]. … The messaging middleware app handles millions of messages per day and rarely takes up 10% of a single CPU on the servers it runs on.
Most of the CPU time used by our Ruby apps is spend waiting for IO. … about 80% of the time [for the middleware] is spent in the kernel in
read()orwrite()syscalls.…
Ruby doesn’t have to be the absolute fastest at everything. Until you’ve tried it or not, though, you won’t even know if it’s fast enough for your problem. It might be—or it might not be. I’ve got some code that I’ve been hacking at work for our build process. I should have just made the programs (a collection of shell scripts) involved with Ruby. It would have taken me less time, left me something more manageable overall, and be more capable in the future. The downside? I would have had to make sure that Ruby is installed on all of my machines, which isn’t necessarily easy (I have some AIX boxes in the mix). Unfortunately, by time I really reached that conclusion, I had already spent enough time to make it non-economical to switch for at least another year (the programs don’t need to be maintained that often). I guarantee you, though, that the Ruby code would have performed just fine and it would have been easier for people to add features to than the shell scripts that I have.
Comments
Sorry, comments are closed for this entry