While deploying a new Ruby on Rails based webapp to development/QA/production clusters, I found a novel way to differentiate the environments without modifying the Rails environment.rb for each.

The first discovery was that Ruby-MemCache is generally deprecated for speed in favor of memcache-client. See the memcache-client docs for more information on its deployment.

After adding that to the metapackage deployment, it was a matter of modifying the environment.rb to use a memcache instead of file session store. HowtoChangeSessionStore covers this readily.

Then I stumbled on bin-environment for lighttpd. With it, you can set multiple environment variables for the FastCGI you are about to spawn.

Each server in a functional cluster runs in a specific RAILS_ENV mode. Likewise, each cluster has its own group of memcached servers as a makeshift distributed filesystem of sorts.

To set these indepenndently for each environment, you can define some environment variables and reference them from within environment.rb.

Here is an example lighttpd.conf snipppet that sets the environment variables:

server.modules += ( "mod_fastcgi" )
fastcgi.server    = ( ".fcgi" =>
 (( "socket" => "/tmp/fastcgi.socket",
    "bin-path" => "/var/www/public/dispatch.fcgi",
    "bin-environment" => (
     "memcache_servers" => "192.168.0.2:2222,192.168.0.3:2222",
     "RAILS_ENV" => "development"
    ),
    "max-load-per-proc" => 25,
    "min-procs" => 1,
    "max-procs" => 5,
    "idle-timeout" => 60
  ))
)
server.error-handler-404   = "/dispatch.fcgi"
index-file.names = ( "dispatch.fcgi" )
server.dir-listing = "disable"

Then you need to reference the environment variable from within environment.rb:

 # ...
 # Bootstrap the Rails environment, frameworks, and default configuration
 require File.join(File.dirname(FILE), 'boot')
 require 'memcache' if ENV['memcache_servers']
 memcache_options = {
        :compression => false,
        :debug => false,
        :namespace => "app-#{RAILS_ENV}",
        :readonly => false,
        :urlencode => false
 } if ENV['memcache_servers']

 memcache_servers = ENV['memcache_servers'].split(",") if ENV['memcache_servers']

 Rails::Initializer.run do |config|
        # ...
        config.action_controller.session_store = :mem_cache_store if ENV['memcache_servers']
        # ...
 end

 if ENV['memcache_servers']
        CACHE = MemCache.new(memcache_options)
        CACHE.servers = memcache_servers
        ActionController::CgiRequest::DEFAULT_SESSION_OPTIONS.merge!({ 'cache' => CACHE })
 end
 # ...

Pretty slick.

There are suprisingly few guides to using memcache with Rails and lighttpd, but none of them seem to cover all of this in any all encompassing detail:

• MemCached on Rails from the wiki.
• fak3r's Speed Up Ruby With Memcached blog post.

On to more fun, with Paul's new Ruby bindings for Xapian...

William Reading on the LOPSA list mentioned some useful bits about EV-DO Revision A rollout plans that seemed worth posting to the blogosphere:

Thus spake William Reading:

Well, I probably should have noted somewhere that Sprint has currently
deployed EV-DO Rev. 0. The problem with that is that you  get the nice speeds
down, but you're still limited to 1xRTT speeds (slightly worse than speeds 
you'd get with EDGE, but a lot better  than GPRS).

Supposedly Sprint is looking into deploying Rev. A in 2007-2008.  That's
supposed to get you something like 1.8Mb/s down and 3.1Mb/s  up--though I'm not
sure they have the backhaul everywhere to get  those kinds of speeds just yet
because I'm near a tower and don't hit  the maximum 2.1Mb/s possible. (But I do
get the 700-800Kbps they  promise).

Verizon doesn't seem to have announced a date for their EV-DO Rev. A.  I'm not
so sure that they're keen on deploying it just yet because  then you'd actually
be able to use it for heavy-duty VoIP  applications and all the other fancy
stuff that they prohibit in the  TOS.

While Verizon's EV-DO network rollout is older and larger than Sprint's, it sounds like Sprint may be upping the ante with revision A service sooner rather than later.

Interesting.