Here’s the call graph for #strip_tags (as profiled in an application I’m working on). As you can see, it tokenizes the entire string, and then iterates the tokens, likely pushing and popping sections onto and off of a stack as tags are opened and closed.

This is a lot more than a quick little regex to strip out tags; it’s actually parsing the full HTML document. Fortunately, there are already tools to do that, and they have their slow parts written as C extensions. Nokogiri is my weapon of choice in this regard – it’s battle-tested and generally rocks at parsing markup, even when it’s poorly-formed.

So, let’s benchmark a “strip all the markup out of a string” use case with #strip_tags and nokogiri.

require 'rubygems'
require 'action_view'
require 'nokogiri'

include ActionView::Helpers::SanitizeHelper

f = open("news").read

LOOPS = 1000
Benchmark.bmbm do |x|
  x.report("strip_tags") { LOOPS.times { strip_tags f }}
  x.report("nokogiri") { LOOPS.times { Nokogiri::HTML(f).text }}
end

The data file in this case is a snapshot of the current page of Hacker News. It’s a 23kb HTML file. Nothing too huge, but certainly not small, either. Let’s run it through the benchmark:

[chris@luna projects]$ ruby strip.rb
Rehearsal ----------------------------------------------
strip_tags  33.070000   0.010000  33.080000 ( 33.092638)
nokogiri     3.220000   0.020000   3.240000 (  3.241090)
------------------------------------ total: 36.320000sec

                 user     system      total        real
strip_tags  33.010000   0.010000  33.020000 ( 33.056551)
nokogiri     3.190000   0.000000   3.190000 (  3.200680)

Yikes. It’s not just slower, it’s ~10x slower.

Don’t use strip_tags. Also, profile your code. But just because it’s convenient doesn’t mean you should use it.

Fortunately, Ruby is deeply entangled with another more portable serialization format: YAML.

Rails manages its session cookies through the MessageVerifier. Easy enough – we can just write our own MessageVerifier that uses YAML rather than Marshal.

module ActiveSupport
  class YamlMessageVerifier < MessageVerifier
    def verify(signed_message)
      raise InvalidSignature if signed_message.blank?

      data, digest = signed_message.split("--")
      if data.present? && digest.present? && secure_compare(digest, generate_digest(data))
        str = ActiveSupport::Base64.decode64(data)
        if str[0..2] == '---'
          YAML::load str
        else # Handle old Marshal.dump'd session
          Marshal.load(str)
        end
      else
        raise InvalidSignature
      end
    end

    def generate(value)
      data = ActiveSupport::Base64.encode64s(YAML::dump value)
      "#{data}--#{generate_digest(data)}"
    end
  end
end

You’ll notice that verify() can accept a Marshaled session as well; this lets you transparently transition existing cookies to the new format without any kind of session breakage. Nice.

Now, to use the verifier, we monkeypatch CookieStore:

module ActionController
  module Session
    class CookieStore
      def verifier_for(secret, digest)
        key = secret.respond_to?(:call) ? secret.call : secret
        ActiveSupport::YamlMessageVerifier.new(key, digest)
      end
    end
  end
end

Now, this will work…at least at first glance, until you try to use the flash. This is a particularly nasty little problem, and it stems from the fact that Ruby’s YAML implementation serializes Hash objects without their instance variables, and FlashHash inherits from Hash, and thus inherits its serialization/deserialization strategy. I worked for a while to monkeypatch those strategies, but I didn’t like the result, and it felt a little hacky. Instead, I just took advantage of the YAML load lifecycle to make sure the FlashHash initializes properly:

module ActionController
  module Flash
    class FlashHash
      def update_with_initializer(h)
        @used ||= {}
        update_without_initializer(h)
      end
      alias_method_chain :update, :initializer
    end
  end
end

The core problem is that YAML::load calls Hash#update, and FlashHash presumes that the @used instance variable is present and initialized to an empty hash. To fix that, I just aliased in an initializer to make sure that variable is set.

Note that if you are storing other Hash subclasses with instance variables that rely on those variables being persisted across sessions, they will break. However, you should only be storing primitive/array/hash data in the session if possible. FlashHash is sort of a nasty violation of this principle.

At this point, your session should be serializing to and from YAML. We’ll want to read it from PHP, naturally. I’m using SPYC in the PHP project, which gets us Close Enough(TM). It doesn’t handle symbol keys, but we’ll handle those in the PHP itself.

Reading from PHP

Reading the data back out is surprisingly simple. We have to verify the authenticity of the data, of course, by checking the hash, but then you just base64 decode the data, load it with spyc, and perform some simple transformation to turn symbols into strings. If you wanted to make it even easier, you could monkeypatch the cookie store to call #stringify_keys! on your session hash before serializing it (and then call #with_indifferent_access on the hash when you deserialize it. Be aware of the speed impact of such a decision before you do it.)

function explode_symbols($arr) {
  $result = array();
  foreach($arr as $key => $val) {
    if(is_numeric($key) && $val[0] == ":") {
      $bits = explode(":", $val, 3);
      $result[trim($bits[1])] = trim($bits[2]);
    } elseif (is_array($val)) {
      $result[$key] = explode_symbols($val);
    } else {
      $result[$key] = $val;
    }
  }
  return $result;
}

function deserialize_session($session_key, $secret) {
  list($session64, $hash) = explode("--", $_COOKIE[$session_key], 2);
  if(hash_hmac("SHA1", $session64, $secret) == $hash) {
    $session = base64_decode($session64);
    return explode_symbols(spyc_load($session));
  } else {
    throw new Exception("Invalid session signature");
  }
}

$rails_session = deserialize_session("your_session_cookie_name", $your_session_cookie_secret);

Caveats

• Be aware that YAML is slower than Marshal
• Be aware that storing Hash subclasses in the session is likely going to Not Work.

And that’s all there is to it. You can now share data between the two apps via the session cookie.

In practice, I’ve found that this costs about 1ms per 1000 records in your counted result set. This is really bad in concert with will_paginate, which Plucky (which is used by MongoMapper) exposes an interface to. It naively takes your query, performs a count() on it, and then performs the query again with limiters to get the records for the current page. This is a standard and quickly-accepted way to do this sort of thing.

NewRelic is a great tool to help profile your applications, and in this case, it’s making the problem abundantly clear:

You see that purple? That’s how long it takes to run those count() operations. What a big fat pile of suck.

I don’t have a good solution to this yet, but in the meantime, I’ve mokneypatched Plucky to cache counts for large result sets. This means that my total counts for a large collection might desync over the course of an hour, but in my use cases, I only need ballpark numbers, so it works out well. This has a very noticeable effect on page times, effectively halving the amount of time I spend in the database for a given index page. Additionally, I can manually specify a count. So, for example, if I know a collection will have over 10k results, I can just pass 10k, and stop paginating after 10k results, drastically reducing my DB load at the expense of exposing older or long-tail content (which may be perfectly, appropriate, depending on the application context).

What I’m doing is caching any counts over some arbitrary limit (I chose 10k, at which point the counts would take ~10ms) for an hour via the Rails cache (memcached, in my case, leveraging the expires_in parameter). I brought the issue up in the #mongodb IRC channel, and the advice I was given was basically “cache your counts”, which is all well and good for simple data sets, but when I’m building pages per-user based on their preferences and myriad inputs (all indexed, mind you), it just doesn’t work, so I’ve resorted to this. It’s a hack, but it’s gotten my page times down substantially.

module Plucky
  class Query
    BIG_RESULT_SET = 10000

    def paginate(opts={})
      page          = opts.delete(:page)
      limit         = opts.delete(:per_page) || per_page
      query         = clone.update(opts)
      cache_key     = "count-cache-#{criteria.source.hash}"
      total         = opts.delete(:total) || Rails.cache.read(cache_key)
      if total.nil?
        total       = query.count
        if total > BIG_RESULT_SET
          Rails.cache.write(cache_key, total, :expires_in => 1.hour)
        end
      end
      paginator     = Pagination::Paginator.new(total, page, limit)
      query[:limit] = paginator.limit
      query[:skip]  = paginator.skip
      query.all.tap do |docs|
        docs.extend(Pagination::Decorator)
        docs.paginator(paginator)
      end
    end
  end
end

I’m not entirely happy with this solution, and would love input on ways to fix it.

I couldn’t find a quick and easy answer to this with some Googling, but it turns out that the answer is fortunately rather simple.

In your test_helper.rb:

 def setup
    Resque.redis.select 1
  end

  def teardown
    Resque.redis.keys("queue:*").each {|key| Resque.redis.del key }
  end

That’s all there is to it. The setup causes Resque to write to database #1 (#0 is default, and is what your development environment is likely using), and the teardown just deletes all your queues (which are really just lists of jobs to run). Test all you want and you won’t have to worry about tens of thousands of jobs junking up your redis DB.

After continually slimming down the code, I realized that even though it’s tiny, it’s danged useful to be able to just drop this into a Rails app and go. Thus, I’d like to present Tarot, my Rails configuration solution.

Tarot’s current form is heavily inspired by the Rails I18n usage, and is very quick and easy to use in your app. The generator installs a sample yaml file at config/tarot.yml, as well as an initializer to bootstrap your configuration and provide a handy helper method for quick access to those config values.

Assuming you have a config file like so:

---
base: &base
  foo: bar
  nested:
    tree: value
  array:
    - value 1
    - value 2

development: &development
  <<: *base

test: &test
  <<: *base

production: &production
  <<: *base
  foo: baz

You’ll notice that all the environments inherit from your base environment; this gives you an easy way to define common settings once, then override them per environment. Handy!

You could can access values by key, or by dot-delimited path:

config('foo') => 'bar'
config('nested.tree') => value

Default values are similarly easy.

config('foo.missing', 42) => 42

Finally, while Tarot will read your current application environment’s config, if you want to reach into another environment, that’s likewise easy:

config('foo', nil, 'production') => 'baz'

As of 0.1.2, Tarot also supports method_missing invocation:

Config = Tarot::Config.new('settings.yml', Rails.env)
Config.foo.bar.baz => "bin"

It also supports default values:

# Assuming foo has no subkey bar
Config.foo.bar("default") => "default"

But it’ll fail if you try to invoke method_missing on a non-leaf node

# Assuming that there is no `blaze` tree
Config.blaze.blarg => NameError

That’s about all there is to it — config isn’t (or shouldn’t be) a hard problem, so there’s not a whole lot to it, but it should get you up and running with easily-configured Rails apps in seconds.

Unfortunately, there have been a number of performance regressions introduced into Haml recently, and that sucks, because Rails spends a lot of time building views, and I’d really like those numbers to be smaller.

Over the past couple of weeks, I’ve been on-and-off profiling Haml and working on various performance patches. I mentioned one of them in my previous post – avoiding exceptions as flow control. There are a couple more we need to watch out for, though.

Problem #1: Lots and lots of extra string parsing

There’s a utility method that lets Haml compare the current version of Ruby with some arbitrary string, to find out if certain features are supported. You can look at the implementation of version_gt, if you’d like, but it’s relatively complex, and we’re invoking it a lot in any given template.

In Haml::Util

    def version_geq(v1, v2)
      version_gt(v1, v2) || !version_gt(v2, v1)
    end

Memoizing these values results in significantly less string parsing and much faster templates.

    def version_geq(v1, v2)
      @@version_comparison_cache ||= {}
      k = "#{v1}#{v2}"
      return @@version_comparison_cache[k] unless @@version_comparison_cache[k].nil?
      @@version_comparison_cache[k] = ( version_gt(v1, v2) || !version_gt(v2, v1) )
    end

Problem #2: Extraneous block creation

Haml::Compiler#compile is what compiles your Haml soup down into HTML. It also creates a bunch of extra closures – one for every leaf tag in your document.

    def compile(node)
      parent, @node = @node, node
      block = proc {node.children.each {|c| compile c}}
      send("compile_#{node.type}", &(block unless node.children.empty?))
    ensure
      @node = parent
    end

Let’s just change that so that the block is only created and passed if there are children to iterate:

    def compile(node)
      parent, @node = @node, node
      if node.children.empty?
        send("compile_#{node.type}")
      else
        send("compile_#{node.type}",  &proc {node.children.each {|c| compile c}} )
      end
    ensure
      @node = parent
    end

It’s worth noting that I tried a compacted single-line send, but it seems faster to just check #empty? than to conditionally create the block and pass &(block if block).

Problem #3: Exceptions as flow control

Haml::Helpers has a couple of instances where it checks for the presence of _hamlout in a block binding by just eval’ing _hamlout and catching NameError to discover that it doesn’t exist. I’ve refactored that to use more idiomatic constructs.

@@ -337,7 +337,7 @@ MESSAGE
     # @yield [args] A block of Haml code that will be converted to a string
     # @yieldparam args [Array] `args`
     def capture_haml(*args, &block)
-      buffer = eval('_hamlout', block.binding) rescue haml_buffer
+      buffer = eval('if defined? _hamlout then _hamlout else nil end', block.binding) || haml_buffer
       with_haml_buffer(buffer) do
         position = haml_buffer.buffer.length

...	...
@@ -540,10 +540,7 @@ MESSAGE
     # @param block [Proc] A Ruby block
     # @return [Boolean] Whether or not `block` is defined directly in a Haml template
     def block_is_haml?(block)
-      eval('_hamlout', block.binding)
-      true
-    rescue
-      false
+      eval('!!defined?(_hamlout)', block.binding)
     end

Results

To test, I have my branch in ./haml and the current origin master in ./haml-upstream. I’ve also got a 900-line Haml template with no inline ruby (just a html2haml converted webpage) that I’m parsing to test with.

To test, I just include the appropriate library and run the benchmark.

require 'haml/lib/haml'
#require 'haml-upstream/lib/haml'
require 'benchmark'

TIMES = 100
source = open("formatted_email.haml").read

Benchmark.bmbm do |x|
    x.report("Render time") do
        TIMES.times do
            engine = Haml::Engine.new source
            engine.render :ugly => true
        end
    end
end

REE-1.8.7-2011.03

Upstream:

[chris@luna repos]$ ruby haml-bench.rb
Rehearsal -----------------------------------------------
Render time   7.010000   0.770000   7.780000 (  7.777076)
-------------------------------------- total: 7.780000sec

                  user     system      total        real
Render time   6.990000   0.710000   7.700000 (  7.721977)

And my branch:

[chris@luna repos]$ ruby haml-bench.rb
Rehearsal -----------------------------------------------
Render time   5.180000   0.460000   5.640000 (  5.703304)
-------------------------------------- total: 5.640000sec

                  user     system      total        real
Render time   5.170000   0.450000   5.620000 (  5.621875)

Improvement: +27% speedup

JRuby 1.6.0

Upstream:

[chris@luna repos]$ jruby --server haml-bench.rb
Rehearsal -----------------------------------------------
Render time  13.254000   0.000000  13.254000 ( 13.254000)
------------------------------------- total: 13.254000sec

                  user     system      total        real
Render time   6.183000   0.000000   6.183000 (  6.183000)

My branch:

[chris@luna repos]$ jruby --server haml-bench.rb
Rehearsal -----------------------------------------------
Render time  11.726000   0.000000  11.726000 ( 11.726000)
------------------------------------- total: 11.726000sec

                  user     system      total        real
Render time   4.856000   0.000000   4.856000 (  4.856000)

Improvement: +21.5% speedup

Ruby MRI 1.9.2

Upstream:

[chris@luna repos]$ ruby haml-bench.rb
Rehearsal -----------------------------------------------
Render time   6.990000   0.610000   7.600000 (  7.599568)
-------------------------------------- total: 7.600000sec

                  user     system      total        real
Render time   6.920000   0.660000   7.580000 (  7.577772)

My branch:

[chris@luna repos]$ ruby haml-bench.rb
Rehearsal -----------------------------------------------
Render time   5.110000   0.470000   5.580000 (  5.573496)
-------------------------------------- total: 5.580000sec

                  user     system      total        real
Render time   5.150000   0.440000   5.590000 (  5.577480)

Improvement: +26.3% speedup

Final Words

I’ve got an open pull request, but it’s been ignored thus far. Make some noise and get this pulled into master, so we can make Rails apps everywhere faster!

Exception to the rule

I hopped into #jruby and was fortunate enough to get to talk to headius directly. He pointed me towards problems with older versions of the i18n gem, which got me thinking – perhaps there were other abuses of exceptions as flow control in my app. After using jconsole to measure my exceptions-per-request, I found that I was generating several hundred exceptions per request, which was imposing a significant slowdown on my requests. After a quick discussion, headius committed a change to add logging switches for exceptions. I was able to fire up my trinidad instance with logging switches:

jruby -Xlog.exceptions=true -Xlog.backtraces=true -Xlog.callers=true -S trinidad 2>&1 | grep "Backtrace generated" -A4

and I instantly had data at my disposal. The ugly areas became clear very quickly – CarrierWave, MongoMapper, and surprisingly, Haml were my top offenders.

Haml:          117 exceptions
CarrierWave:   162 exceptions
MongoMapper:   114 exceptions

The stack traces themselves are easy to interpret, too:

Backtrace generated:
NameError: undefined local variable or method `_hamlout' for #<ActionView::Base:0x1af81d1c>
               eval at org/jruby/RubyKernel.java:1088
     block_is_haml? at /usr/local/rvm/gems/jruby-head/gems/haml-3.1.2/lib/haml/helpers.rb:543
  capture_with_haml at /usr/local/rvm/gems/jruby-head/gems/haml-3.1.2/lib/haml/helpers/action_view_mods.rb:90
1

This gave me an easy target:

1

What's happening here is the block is evaluated with just <code>_hamlout</code>, which throws a NameError if the variable doesn't exist in the block's binding context, and then the proper boolean is returned. However, this is a perfect example of exceptions as flow control - the question is "Does _hamlout exist in the block context?", and that's not best answered by a NameError. Ruby gives us <code>defined?</code> to check that sort of thing trivially, and more importantly, idiomatically. So, I can just rewrite that helper as:

1

This is both far more correct, and far faster.

<h2>Lies, Damn Lies, and Benchmarks</h2>

Let's try a quick benchmark to test the effects of each method:

1

And results:

1
[chris@luna repos]$ rvm use ree
Using /usr/local/rvm/gems/ree-1.8.7
[chris@luna repos]$ ruby test.rb
Rehearsal --------------------------------------------
Rescue     0.070000   0.010000   0.080000 (  0.082649)
defined?   0.020000   0.000000   0.020000 (  0.022991)
----------------------------------- total: 0.100000sec

               user     system      total        real
Rescue     0.080000   0.000000   0.080000 (  0.082292)
defined?   0.030000   0.000000   0.030000 (  0.022384)

Avoiding extraneous exceptions is clearly better on MRI (3.6x faster using defined? rather than NameError), but 100k exception raises only imposes an extra 0.6 seconds of runtime on the test. Probably not worth fretting over to too great a degree, at least until other optimizations have been made.

Let’s try JRuby:

[chris@luna repos]$ rvm use jruby-head
Using /usr/local/rvm/gems/jruby-head
[chris@luna repos]$ jruby --server --fast test.rb
Rehearsal --------------------------------------------
Rescue    11.145000   0.000000  11.145000 ( 11.097000)
defined?   0.599000   0.000000   0.599000 (  0.599000)
---------------------------------- total: 11.744000sec

               user     system      total        real
Rescue     9.758000   0.000000   9.758000 (  9.758000)
defined?   0.357000   0.000000   0.357000 (  0.357000)

Holy crap, now we’re in interesting territory. Using defined? rather than letting exception handling do our dirty work for us is 27.3x faster. As Headius explains:

In JRuby 1.6, we moved to using JVM-level facilities for generating exception backtraces. These facilities are considerably more expensive than the artificial backtraces we had been maintaining before…not incredibly expensive, but not free or as cheap as they used to be by any means. If applications and libraries use exceptions for exceptional error cases, it’s not a big deal.

The message here is pretty clear – use exceptions for things that are exceptional, not for flow control of the normal program operation. It’s worth noting that in the benchmark, there isn’t a big stack trace to generate; in a Rails app, each exception is going to generate a stack trace scores of entries deep, further exacerbating the problem. This is a simple test, and a simple case, but it illustrates the point fairly clearly.

By using the new exception logging switch, I was able to, in about an hour, monkeypatch several of the libraries we were using to reduce my exceptions-per-request from 400 to 8. This had an extremely noticable impact on my page times, reducing my test action runtimes significantly. If you’d like to take a look at all the pieces I patched, check this quick pastie. I’m working on patches to submit to each of these projects; besides avoiding punching JRuby in the tenders, it also improves runtimes in MRI and REE Ruby VMs.

In all three libraries, exceptions were being used as flow control to answer “does this variable or method exist?”, and in all three cases, the libraries are doing it wrong; Ruby gives us defined? and respond_to?, and if you mean “Is this variable defined?”, why not ask “defined? variable” rather than “try to use this and hit the eject button if it doesn’t work”?

Exceptions are for things like “The remote service returned a bad response”, or “That string didn’t parse as valid JSON”, or “That file which you’re trying to parse as an image isn’t actually an image” – exceptional circumstances. Things that you don’t expect. If you’re using exceptions to answer a question, or as a poor-man’s GOTO, you may want to reevaluate how you’re using them.

JRuby as an exceptions-as-flow-control detector

It’s worth noting as a quick side item here that the commit to JRuby tonight makes JRuby a fantastic tool for locating libraries that use the exceptions-as-flow-control antipattern in your Rails apps. I tried a number of approaches to monkeypatching Exception before Headius committed the change, none of which worked very well, but once I built jruby-head, I had every exeception trace in my application laid out before me. You might consider taking a crack at this on your own apps – you might like what you find.

Getting running is as easy as:

rvm install jruby-head --branch jruby-1_6
rvm use jruby-head
gem install bundler trinidad
bundle install
jruby -Xlog.exceptions=true -Xlog.backtraces=true -Xlog.callers=true -S trinidad 2>&1 | grep "Backtrace generated" -A4

In a matter if minutes, you’ll have an abundance of stack traces to chew on at your leisure. Or, if you’re lucky, you won’t have much of anything at all. Good hunting!

To sum up:

This is flow control:

This is exception handling:

Make sure you’re pressing the right button.

It’s been broken for some time now, and not really in much of a state to be used by anyone, but I needed it, so I fixed it up. You can get my source on github, but I’ve done one easier and made it a gem. Major changes are:

• Bad assumptions fixed. Actually works now.
• Reorganized the whole thing and repackaged it as a gem. Doesn’t work as a Rails plugin anymore, but that’s okay. Just add it to to your environment or Gemfile and you’re good to go.
• Added tests!
• Fixed documentation, and normalized rake tasks names.

To get it, you can just gem install mongrations and you’re off to the races.

This is primarily going to be useful for MongoMapper people, who are likely still on Rails 2.3.x. If you’re using mongoid, check out mongoid_rails_migrations instead.

• Varnish is easy to use, if your app isn’t setting session cookies until you actually need them. The presence of a session cookie usually means that content shouldn’t be cacheable.
• Hitting any page with a form results in Rails generating a CSRF token and sticking it in the session, generating a session cookie and effectively locking the rest of the session out of being cacheable (even if it should be).
• Just *breathing* the method session in your app initializes your session.
• The Rails cookie session middleware assumes you always want to write a session cookie.

Fortunately, since so much of this is in Rack middleware, we can fix its mistakes with a middleware of our own. In a nutshell, I’m going to:

• Avoid writing CSRF tokens until we actually need them
• Check and see if we have an “empty” session (ie, no interesting data, just the session ID)
• Prevent session cookies from being sent to the browser unless there’s actually useful data in them.

Let’s get started. There’s a lot to this, and it’s a delicate collection of hacks, but it works nicely.

The care and feeding of CSRF tokens

To get started, I disabled CSRF functionality based on user state. In your application_controller.rb:

  protect_from_forgery :if => :user?
  skip_before_filter :verify_authenticity_token, :unless => :user?

protected

  def form_authenticity_token
    if user?
      session[:_csrf_token] ||= ActiveSupport::SecureRandom.base64(32)
    end
  end

In this case, user? is a method from my authentication framework that lets me check if I have an active session. The astute reader will note that this check performs the aforementioned breathing-on (and thereby initializing) the session, so it’s unfortunately not quite as simple as this. However, this will prevent authenticity checks for unauthenticated sessions. There’s no real point to them if you aren’t performing privileged operations anyhow, so we’ll just save the overhead.

Stuffing your cookies back into the jar

Next, we need to deal with the session cookie itself. We have two options when invalidating cookies – either strip them from the already-written headers, or just add another Set-Cookie line to instantly invalidate them. Since we’re dealing with Varnish, we want option 1 – ideally, we won’t be passing the Set-Cookie header, since Varnish (by default) won’t cache any response that attempts to set a cookie.

Session cookie management happens in ActionController::Session::CookieStore, and it’s really high up in the middleware stack. rake middleware will dump your stack – you’ll find it’s usually in position 2 or 3. So, in order to tweak it, we’ll need to inject a new middleware into your stack to mess with your cookie headers after the cookie handler itself blindly writes them out.

Scroll down if you want the code, but the gist of it is this:

• Check for a special “cookie.logout” environment parameter. If this is present, we’re going to just flat-out nuke the session cookie. More on this later.
• Otherwise, check to see if the session has any interesting keys. If it doesn’t, remove it from the Set-Cookie header

The code itself. Drop this in lib/strip_empty_sessions.rb.

class StripEmptySessions
  ENV_SESSION_KEY = "rack.session".freeze
  HTTP_SET_COOKIE = "Set-Cookie".freeze
  BOGUS_KEYS = [:session_id, :_csrf_token]

  def initialize(app, options = {})
    @app = app
    @options = options
  end

  def call(env)
    status, headers, body = @app.call(env)

    session_data = env[ENV_SESSION_KEY]
    sc = headers[HTTP_SET_COOKIE]
    if env["cookie.logout"]
      value = Hash.new
      value[:value] = "x"
      value[:expires] = Time.now - 1.year
      cookie = build_cookie(@options[:key], value.merge(@options))

      if sc.nil?
        headers[HTTP_SET_COOKIE] = cookie if env["cookie.logout"]
      elsif sc.is_a? Array
        sc << cookie if env["cookie.logout"]
      elsif sc.is_a? String
        headers[HTTP_SET_COOKIE] << "\n#{cookie}" if env["cookie.logout"]
      end
    elsif (session_data.keys - BOGUS_KEYS).empty?
      if sc.is_a? Array
        sc.reject! {|c| c.match(/^\n?#{@options[:key]}=/)}
      elsif sc.is_a? String
        headers[HTTP_SET_COOKIE].gsub!( /(^|\n)#{@options[:key]}=.*?(\n|$)/, "" )
      end
    end

    [status, headers, body]
  end

  private

  # Copied from the cookie session middleware.
  def build_cookie(key, value)
    case value
    when Hash
      domain  = "; domain="  + value[:domain] if value[:domain]
      path    = "; path="    + value[:path]   if value[:path]
      # According to RFC 2109, we need dashes here.
      # N.B.: cgi.rb uses spaces...
      expires = "; expires=" + value[:expires].clone.gmtime.
        strftime("%a, %d-%b-%Y %H:%M:%S GMT") if value[:expires]
      secure = "; secure" if value[:secure]
      httponly = "; HttpOnly" if value[:httponly]
      value = value[:value]
    end
    value = [value] unless Array === value
    Rack::Utils.escape(key) + "=" +
      value.map { |v| Rack::Utils.escape(v) }.join("&") +
      "#{domain}#{path}#{expires}#{secure}#{httponly}"
  end
end

Next, you’ll need to add this to your middleware stack. In your environment.rb:

config.middleware.insert_before "ActionController::Session::CookieStore", "StripEmptySessions", :key => "your_session_key", :path => "/", :httponly => true

The :key and :path parameters should match your session cookie settings.

What this will do is let this middleware run on the way back up the stack, right after the session handler gets a crack at things. If there is nothing interesting in the session, it’ll remove that line from the Set-Cookie header, so if you aren’t setting any other cookies, the header should end up being empty and should get thrown away. If you triggered a logout, will invalidate the client cookies (rather than just writing a cookie with no data in it back to them).

To do that, you’ll need to modify your logout method:

def logout
  request.env["cookie.logout"] = true
end

That should be it. You should now:

1. Not be setting session cookies for empty sessions
2. Not be setting CSRF tokens for anonymous sessions
3. Not be leaving “empty” session cookies laying around on client machines after a logout.

The net result is that you should be cookieless for anonymous sessions, resulting in trivial caching with Varnish. This can vastly improve the performance of your site – especially if you’re catching high-traffic pages from web crawlers and the like with Varnish, so they never touch your Rails stack.

Cookie image (C) scubadive67, used under Creative Commons license

It’s not too hard to set up fixtures to be inserted once per test suite run –

In your test_helper.rb, above the class ActiveSupport::TestCase definition, add the following:

Fixtures.reset_cache
fixtures_folder = File.join(RAILS_ROOT, 'test', 'fixtures')
fixtures = Dir[File.join(fixtures_folder, '*.yml')].map {|f| File.basename(f, '.yml') }
Fixtures.create_fixtures(fixtures_folder, fixtures)
Fixtures.reset_cache

Next, turn off transactional fixtures and comment out the fixtures macro:

self.use_transactional_fixtures = false
# fixtures :all

That’s all there is to it. Your fixtures will be inserted into your test database once when test_helper is included for the first time, and then not again for the rest of the test suite run. This should speed your tests up substantially.