Tuesday, June 10, 2008
I will be speaking at the
Lone Star Ruby Conference in September about how we use Ruby to deploy, monitor, and manage a cluster of servers running in the
Amazon Web Services virtual cloud. Below is a summary of what I'll be talking about.
In OtherInbox, almost every system administration task imaginable is carried out using Ruby, meaning we as developers can enjoy all of Ruby's expressive benefits and spend less time scripting the shell, writing cron tasks, or using other languages. Because we make fewer context switches from thinking in Ruby to thinking in other languages, we also reap a big productivity benefit.
Using Ruby throughout our cloud also means that porting the application to run in different production environments is a trivial task, because Ruby is the glue connecting the Ruby components together, thus all we require is a Ruby interpreter to deploy.
Two key Ruby technologies have matured in the previous 18 months which make it ideal for almost every layer of managing a cluster of servers:
- god.rb allows fine-grained process monitoring and daemon control (a la monit)
- rufus-scheduler enables Ruby-based scheduling (replacing cron, and providing a great facility for running daemons that must be executed on a recurring basis)
When combined with these Ruby workhorses, developers today can spend much more of their time writing Ruby code, and less time struggling with the vagaries of their production environment:
The talk will also include a discussion of using several different
AWS gems to make
cloud computing simple, by illustrating the use of Amazon's
S3 and
SQS services to distribute asychnronous work and handle communication between servers.
Labels: conferences, deployment, god.rb, lone star ruby conference, otherinbox, ruby
Monday, June 2, 2008
I wrote up a few articles on the
OtherInbox blog about my experiences at RailsConf 2008:
The best blow-by-blow coverage so far is from
Drew Blas. Of the ones I attended or heard the best feedback about, I most strongly recommend looking at the slides for these:
Labels: otherinbox, rails, railsconf
Wednesday, May 21, 2008
I spent some time today optimizing
OtherInbox. As our private beta expands, we are starting to see heavier usage, and so it's time to revisit some of my beloved SQL queries.
I use the
MySQL slow query log to find out which queries were taking the most time -- that's been a wonderful tool that I plan to blog about later. I will note that the output is much easier to make sense of if you parse it first with
this script. (It's really old, so I had to modify it to look at Query_time instead of Time)
Using the
EXPLAIN command for each of the slow queries identified in the above log, I found one that was especially disturbing. According to EXPLAIN's "extra" column, MySQL was resolving these queries with two fairly expensive operations:
Using where; Using temporary; Using filesort
Fixing the "Using temporary" required some nimble manipulation of indices, but filesort was really perplexing me. I wasn't using an ORDER BY clause, so as I read
the docs, there was no reason to be doing a filesort. But then I remembered that MySQL automatically does ordering based on GROUP BY clauses. All I had to do was add "ORDER BY null" to the end of my query, and that did the trick:
Using where; Using temporary
If only all optimizations were so simple.
Labels: databases, mysql, optimization, otherinbox
Thursday, May 1, 2008
For the past seven months I've been building a cool new consumer web app with some folks in Austin, TX,
otherinbox.com/, and we're looking for experienced Ruby On Rails developers. We're a small agile team led by Steven Smith, founder of
FiveRuns.
The whole site is Rails-based and makes extensive use of Amazon Web Services (EC2, S3, and SQS) and there's a new awesome challenge every day. More info on our
jobs page.
Labels: otherinbox, rails
