Pound makes lighty and Mongrel play nice

With the rocket rise of Mongrel, we’ve seen a growing number of folks jump ship from lighttpd to Apache 2.2 because of mod_proxy_balancer. It’s great to see that Mongrel is putting Apache back on the map as a premiere Rails web server, but unless you desire Apache for other reasons, you certainly don’t have to jump ship.

The trouble with lighttpd is the state of its mod_proxy implementation, which leaves a lot to be desired when used as a balancer between multiple Mongrel backends. But because the whole Rails deployment stack is going straight HTTP, it’s surprisingly easy to rectify. All you need is to add a more capable load balancer to the mix and you’re golden.

One such balancer that has seen a lot of play lately is Pound (OS X install notes). It’s light, fast, and proven on mega sites. So here’s what you do if want to stay with lighttpd and still use Mongrel:

  • Setup lighttpd on port 80 with mod_proxy to point at one back-end server (see the Mongrel lighty docs, but just only use one backend instead of four).
  • Setup Pound on a high port, like 7999, and make it point to any number of Mongrel processes (see the Mongrel Pound docs).
  • Start n number of Mongrels, from say port 8000 through 8002, using either mongrel_cluster or the soon-to-be-committed Mongrel-compatible script/process/spawner

And bingo, you should now have a production-ready stack ready to take on the world. This is a pretty good outline of how we at 37signals intend to use Mongrel in production shortly.

You can also take pleasure in the fact that Jan Knesche is busy at work making the Pound crutch unnecessary. Over the Summer, he has promised to elevate mod_proxy to be on par with the competition, and this three-way stack should again become a two-way one.

Learning more about Active Resource

Active Resource was announced at RailsConf and the first tiny pieces of code has already been checked in, but what is it exactly? Ryan’s Scraps tries to answer that with a summary of the stuff that’s already working and the ideas for how to implement the rest of the interface.

Rails 1.1.4: Security fix without breakage

The security fix from Rails 1.1.3 might have closed the hole, but it also caused breakage for people with controllers in modules. We’ve fixed that now, so Rails 1.1.4 should work for any application that also ran under 1.1.2. We apologize for the problem with 1.1.3 and encourage everyone running 1.1.x to upgrade as soon as possible to this release.

Note: Edge Rails was never affected by this security issue as it includes a rewritten routes module. So if you’re running on the latest edge, you don’t need to worry about upgrading.

European RailsConf talk proposals

Talk proposals are now being accepted for the European Rails
Conference
, to be held September 14-15 in London. Accepted speakers
will get free admission to the conference. Join a line up that already includes the creator of Rails, David Heinemeier Hansson, Pragmatic Programmer Dave Thomas, best-selling author and passion maven Kathy Sierra, Rails core developers Jamis Buck, Marcel Molina, Jr., and Thomas Fuchs, Rails authors and trainers David Alan Black, and Chad Fowler, and Rake author Jim Weirich.

Proposal suggestions span a variety of Rails topics, including:

  • case-studies in interesting Rails applications
  • Rails add-ons and adapations (including experimental ones)
  • analyses and critiques of specific aspects of the framework
  • the use of Ruby in/for/with Rails development
  • comparative analysis of Rails and other frameworks
  • testing, coding, deployment, and all the rest!

The deadline for proposals is July 21. You are asked to submit a title, a short abstract, and a slightly longer
description (400 words or so). You don’t have to have the whole talk
written, just a reasonably detailed overview.

Send in your talk proposal.

You can write to David A. Black (dblack at wobblini.net) if you have questions about the proposal
process.

Keep an eye on the conference website feed for updates.

Rails 1.1.3: Security fix and minor fixes

We’ve found and fixed a security issue with routing that could cause excess CPU usage in Rails processes when triggered by certain URLs. We strongly encourage anyone running 1.1.x to upgrade to the latest version. It’s fully backwards compatible and should serve as a small drop-in fix.

If you’re running the latest Edge Rails, though, there’s no need to update. We’ve rewritten the routes functionality on edge and the new version doesn’t have this problem.

To upgrade, you as always can just do: gem install rails --include-dependencies

Note: This release doesn’t include any of the new CRUD/resource-based features. All of the new features we’ve been working on over the last couple of months will become available in 1.2.0, which is scheduled for “soonish”. This 1.1.3 release is purely to address the security issue and another few minor fixes that were available on the STABLE branch as well.

The Power of the Marginal

Paul Graham delivered one of the keynotes to an audience of about 550 people this weekend at RailsConf. The text of his talk, The Power of the Marginal, is now online. Hold tight for full video of almost all the keynotes in weeks to come. They will be made available for free to download.

For now, relive the weekend or catch up to what went down with a bunch of pictures and commentary.

New Rails app: MOG.com

You may have seen MOG mentioned on BoingBoing or elsewhere earlier this week. It’s the new social networking site that lets music lovers connect based on what they’re into, keep a blog about their musical discoveries, and find new things to appreciate based on their friends’ recommendations. It even has this MOG-O-MATIC plugin for iTunes so that it can figure out what you listen to without you having to tell it. Even if you don’t have your music tagged.

That’s all pretty cool, but for the readers of this blog, the really cool part is that MOG is written entirely in Ruby on Rails. The MOG software is the creation of Lucas Carlson, Dave Fayram, and Joshua Sierles. It’s a nice piece of work, serving up 1.5M requests per day using Pound, Mongrel and memcached, and they are still tuning it for performance. The app also includes an XML-RPC interface used by the plugin (though Dave says now he thinks REST might have been a better way to go).

So tune your internet dial to mog.com and take a listen…

Tips on how to improve application efficiency

Rails performance specialist Stefan Kaes, who writes extensively about optimizing Rails over at Rails Express has a lengthy article at the new InfoQ site called A Look at Common Performance Problems in Rails.

Kaes identifies various development practices that will slow down your Rails applications, such as repeating computations that only need to be run once and then cached. If you’ve located some slowness in your application, Kaes may have already identified some of the likely culprits.