A Few Thoughts After a Major Ruby/Rails Deployment at sablog.com

A Few Thoughts After a Major Ruby/Rails Deployment

Written by Shanti A. Braford January 25th, 2007in Ruby, Ruby on Rails.

Programmers seem to be obsessed with programming language speed.

I’ve ranted before abaout Joel and his Wasabi project, for bashing Ruby.

Last night / this morning we were pushing out a major release of Mailroom.

Some of the maintenance scripts we had to run to catch up the database are/were taking an incredibly long time.

We were pushing two boxes to loads of 4.0 - 6.0. When we started MR’s receiver, we were seeing loads of 8-10. For the non-techies, that means that something like “800%” of the CPU was being used, or something like that. Basically, you don’t ever really want it that high.

But anyway.. the point is that a majority of the processing juice seemed to be going to the DB. I would guesstimate 80-90% of the cpu juice on that server was being used for the DB, not Ruby. That was really the limiting factor, it seemed, not Ruby code.

So why do coders get their panties all in a bunch about programming language speed, but not so much when it comes to database speed?

I guess because we really only have a few options in the Database game, so the DB wars are restricted to “MySQL vs PostgreSQL” or maybe throw Oracle in their if you can afford the $30k licenses.

Whereas programming language wars let you explain why you think VBScript, Wasabi, Lisp, Java, Smalltalk, Ruby, Python, Perl, PHP, etc. is better than X language.

That’s everyone’s favorite Slashdot (now Digg) thread right there.

Now, I know this totally depends on the application… but it’s true for ours. And I’ve seen it be true for many that I’ve worked on in the past:

If 90% of your application’s process is spent in the DB, how much does a 50% increase in speed in your programming language (or VM) get you, in terms of overall application performance? …

… 5%! Nothing to get too excited about, eh?

You can

bookmark this,

digg this or check the

cosmos

2 Responses to “A Few Thoughts After a Major Ruby/Rails Deployment”

RSS &

1 Gabriel on Jan 28th, 2007 at 7:18 pm

Definitely sounds like it might be time to have a SQL ninja make sure that every DB call is optimized as much as possible if you haven’t already.

One tiny example that I ran into was where I was counting the total number of entries in two tables. I was initially trying to be clever and combine the two queries into one. This ended up creating a large join of the two tables, and by splitting the queries into two separate ones I ended up getting the speedy performance that I had originally expected from such a simple query. Looking back it was probably a n00bish mistake, but sometimes it pays to revisit SQL and test different variations to acheive the result you’re looking for.

Now, if you’ve already had a DB master fine tune your queries and they’re still taking that long, well, you’re probably doing something complicated that might just be inherently complex and can’t be shortened. In which case, use your l33t Ruby skills to rework the problem into a different space. Or something…
2 Shanti A. Braford on Jan 28th, 2007 at 9:59 pm

Gabriel - you’re right. The above post was hastily dashed off after a deployment.

Of course, we didn’t have time yet to check SQL and DB indexes. When you’re at the tail end of a 12-hour workday, not all brain cylinders are hitting at 100%!

Charles and I went back and majorly tweaked the database.

Once optimized, the ratio of DB / AppServer is probably more like 60/40 or 50/50.