I was trying something out with this blog to speed up the loading of the pages. What I was measuring didn’t really make a large difference in the page load time, but I did notice a huge amount of time spent loading all of the social pieces of the page - Disqus, Twitter and Google Plus. Since I’m not using JQuery on this blog, I don’t have an easy $(document).ready() way to run all these pieces after the page has loaded, yet just putting the script into the page causes it to run inline and delay the page being ready for interaction.

<script>
// Google Analytics
// Disqus code
// Twitter
// Google Plus
</script>

WebPageTest reported that the page was taking between 3.5 and 4 seconds to get to the ‘loaded’ state, with 2 of those seconds being the social pieces.

With a quick rearrangement of the code to put the initialization inside a window.onload() function call, I get code that looks like this:

<script>
window.onload = function() {

  // Google Analytics
  // Disqus code
  // Twitter
  // Google Plus

}
</script>

Now the page load time is recorded as being between 1.5 and 2 seconds, with 2 seconds more work being done after that point.

Caveats

One of the features you get with JQuery’s ready() method is that you can have many of them. When you strip that away, you have to be more careful to get your entire code into a single unload() function definition. For my blog, this is really easy, because there isn’t much code to disrupt, but for an non-trivial application, this isn’t likely to be an option.

Summary

Delaying the loading of scripted pieces that are not needed for the initial rendering of the page can significantly improve the measured load time of your pages. If you aren’t using JQuery, then you have to remember how to use the old-school methods of getting things done.

I’ve recently added ETag support to this blog. There’s a post coming soon on how to use the Rails cache helpers to short-circuit the generation of dynamic content that your user’s browser already has. While I was monitoring the situation with the Heroku logs command, I saw something a little strange in the requests being processed. Here is a request from Pingdom for the home page of the blog (with the times removed to save space)

app[web.1]: Started GET "/" for 76.164.194.74 at 2012-12-20 01:00:29 +0000
app[web.1]: Processing by MainController#show as HTML
app[web.1]: Filter chain halted as :load_posts rendered or redirected
app[web.1]: Completed 304 Not Modified in 10ms (ActiveRecord: 3.0ms | Dalli: 18.2ms)

heroku[router]: at=info method=GET path=/ host=blog.craz8.com fwd=76.164.194.74 dyno=web.1 queue=0 wait=0ms connect=1ms service=41ms status=200 bytes=56586
heroku[nginx]: 76.164.194.74 - - [20/Dec/2012:01:00:29 +0000] "GET / HTTP/1.0" 200 56586 "-" "Pingdom.com_bot_version_1.4_(http://www.pingdom.com)" blog.craz8.com

The main thing to notice here is that my application code returned a 304 Not Modified response, but Heroku returned a 200 OK response to the client. Heroku doesn’t cache responses for Cedar apps, so what’s going on here?

The big clue was this data: Dalli: 18.2ms (Dalli is a memcache client library). For such a small request, why is so much time spent getting data from memcache? Perhaps it’s because the entire response actually came from memcache somewhere in the middleware stack that doesn’t log its output. Which other middleware uses memcache?

Following along with the code, I’ve discovered that the Rack::Cache middleware is doing all the work here. If you’ve marked a response with an ETag, Rack::Cache remembers this as part of the cached reponse data. If a request comes from a client without an ETag then Rack::Cache will add the ETag they just looked up and pass that up to your application. If you return a 304 Not Modified response, then they can return the response body that matches that ETag.

Summary

Rack::Cache works with ETags in your application to allow you to bypass creation of dynamic content even for clients that have never visited before. I have yet to see any documentation on this feature, but it makes the use of Rails cache helpers - stale? and fresh_when - much more useful.

If you look at the Network debug tab in most modern browsers, the waterfall display clearly shows that the browser doesn’t do any work to start rendering your page until the initial response is received from the server. The faster you can return the browser response, the sooner the user will see the content you want to display.

When I’m speeding up a Rails application, I like to work through a six step process that gets to the ultimate performance for a particular feature. Not all requests can get to the sixth level, but the more you can move your Rails application through these steps, the faster and more responsive your application will be.

1. Server Creates Entire Response and Sends It

This is the worst case scenario, and sadly, it’s the default scenario for a lot of web applications. Every time the browser requests a page, the Rails application looks up some data, renders the results and sends the content back to the browser. This is hard to fix for the very first request of a dynamic application, but we can do much better. Rails 3.x applications automatically use the next level, so are always a little better than the worst case.

2. Server Creates Entire Response but Sends a ‘Nothing Changed’ response

In Rails 3.x, the default middleware stack includes Rack::ETag that allows the middleware to signal to the browser that the content it has hasn’t changed since the last time it was requested. This reduces the bandwidth used by your application, but doesn’t reduce the amount of work done by your application server process. The good news is that you get this improvement for free with Rails 3.x - you do not need to make any code changes to take advantage of this feature.

3. Server Creates Response from Cached Fragments and Sends It

The server code loads up enough of the data needed by the page to use to find the fragments of the page that are cached and uses those fragments to build the response rather than running all of the rendering code. Depending on how you decide where to perform caching, a lot of the pieces of the page can be shared between users, and can be cached for a very long time. The longer the fragments are cached, the lower the total cost of rendering over the lifetime of your application.

If you have enough fragments on a page, the cost of finding those fragments may become the slowest part of the page. There is a recently released gem to allow many fragments to be retrieved simultaneously to increase the overall speed of these pages.

In addition, the Rack::ETag middleware mechanism will be used to reduce bandwidth if the user has seen this exact page before

4. Server Sends Response but Does No Work

In Rails, this is done with Action Caching. The entire response is saved in a cache store and used to respond to future requests without doing any work to generate the output. Action Caching does run all the before_filter code for an action, so authentication can be performed (which can be construed as doing work, but its often hard to skip this step).

Action Caching can be hard to achieve. There are often pieces of the page that are customized for a particular user, and caching every possible version of a page is usually the wrong way to improve performance. Expiring complex pages can be very error prone.

The Rack::ETag middleware mechanism will be used to reduce bandwidth if the user has seen this exact page before.

5. Server Does Nothing when asked

Rails 3.x added support for Conditional GET support inside actions. This allows you to write specific code to detect when the browser already has the current page and short circuit the page generation process.

If you can use the ETag information to avoid performing some or all of the database lookups needed to render the page, then you will increase the speed of displaying the page to your user.

This mechanism doesn’t work for the first view of a page by a user, but for often visited pages, this technique is almost the fastest way to display a page to your user for views after the first one

6. Server Does Nothing

The holy grail of making your web application fast is to avoid requests altogether! There are a number of techniques available to do this. A common way is to combine things together so instead of 10 requests, you have just one. CSS and Javascript files are easy ones to perform this trick on with Rails 3.1+, as the Asset Pipeline does all of the heavy lifting to precompile your files into a single one of each.

Image Sprites is a technique that works on images to reduce the number of requests and improve your application performance.

For all of these static files, and with the Rails Asset Pipeline set to generate and use digests, you can also set HTTP cache headers on these files to allow browsers to not even request these files for a long time in the future, yet be assured that if you make changes to your application, these changes will be picked up when you deploy your new code.

As an extreme example, I recently worked with an application that had a mouse over effect that performed a server request to render some data and display a small box with that data. It occurred to me that the page in question already had all of that data displayed on it, so all of those requests were actually not needed. I made a small change to pre-render that data into the page and update the mouseover code to use the local data instead.

For this page, with appropriate caching, the initial display maybe 50ms slower, but the mouseover effects are each 300-500ms faster than before and no ‘waiting’ graphic is needed whilst the user is waiting for the popup to appear.

Summary

To get the ultimate performance from your Rails application, you have to think clearly about what data you need to get to your user and how best to do that in an efficient way. With the above techniques, you can improve upon what Rails 3 gives you out of the box and make your users happier. Happier customers are better customers!

Rails Fragment Cache is one of the best ways to increase performance of your application. The render code hunts for the pieces it needs and gathers them from, typically, a memcache server to build your page piece by piece. It would be much faster if you could batch these up in some way to reduce the overhead of gathering data from memcache a single piece at a time.

A few months ago, I wrote some code that used Rails Fragment Caching heavily to increase page rendering speed. At the time, I wrote some quick and dirty code that batched all the Fragment Cache calls together and used the Rails cache multi_read method to get them all in a single call from my memcache server. The code worked, and it was fast, but I sure didn’t want to show it to anyone else.

A few days ago, Nathan Kontny introduced a new Rails Gem (multi_fetch_fragments) that takes what I was doing and packaged it together in a really clean implementation that he talks about in a blog post about Rails faster partial rendering and caching. The source code can be seen on github

I immediately tried it out on a big app I’m working on, and it’s going to help a lot for that app when I can extract the per-user parts of the partials.

Today, I added this code to my blog’s index page rendering. The single fragment cache code looks like this, simplified:

index.html.erb

<%= render :partial => 'post', :collection => @posts %>

_post.html.erb

<% cache post do %>
  <div class="article">
     <!-- other post rendering code -->
  </div>
<% end %>

To make this multi fragment cached, the code changes to this:

index.html.erb

<%= render :partial => 'post', :collection => @posts, :cache => true %>

_post.html.erb

  <div class="article">
     <!-- other post rendering code -->
  </div>

Running this test on Heroku, here are the render times for this blog’s home page

And this is just for a difference in how cached objects are retrieved for 10 items!

An interesting point to note is that there’s a bunch of variability in the response times. The multi fragment cache code, since there are much fewer calls to the memcache server, there is less opportunity for someone else’s network traffic to interfere with my page rendering speed.

This is such a simple change, and you get such a speedup of rendering lists of partials, that you should probably add this to your current apps as soon as is possible.

When you start a new web application, there’s likely to be very little data in your system. Hopefully, over time your users will find your application useful and add data. At some point, loading index pages will become slower and slower due to this extra data. It’s time for pagination.

The math is pretty simple. If you have 500 items on a page, and you can reduce that to, for instance, 50 items, the time to display those items is likely to be 10 times faster. Now, there are some constants here with header/footer/sidebar pieces that are the same no matter how many items you have, but the difference between 500 and 50 items will be very obvious to your users.

There are two different paginates available for Rails. I’ve been using will_paginate for several years, but there is a new kid on the block called kaminari. Which one you use may just be a matter of taste. Try one and switch if you don’t like it!

For the published posts for this blog, I ran some tests. My index page post retrieval code looks like this:

@posts = Post.published.order("published_at desc")

On a test system, my blog page with all posts renders in about 600ms.

When I add pagination to the system and repeat the test with a page size of 10

@posts = Post.published.order("published_at desc").paginate(:page => params[:page], :per_page => 10)

Now the page renders in under 100ms.

Make sure to keep track of your new applications and add pagination to keep page performance up as the amount of data grows.

I recently wrote about using the same codebase to run multiple Heroku apps. There are some situations where it may be better to run multiple applications in a single Heroku app. The whole CRAZ8 domain is running as a single Heroku application, frankly because there’s not much at the root portion, and the Blog code isn’t very taxing with the number of users I have.

Rails 3.1 added some routing goodness to make this fairly easy to do. The typical use of sub-domains in a Rails application is to provide different users or accounts with a different url. For a low-traffic site like this, we can use this feature to host completely different systems under sub-domains, but all under a single codebase.

I have a root domain, craz8.com, a blog subdomain, and, if anyone uses ‘www.craz8.com’, I want to redirect them back to the root domain.

Here is a summary of my routes.rb file:

MyApplication::Application.routes.draw do
  constraints :subdomain => '' do
    root :to => 'site#root'

    # Other main site routes
  end

  constraints :subdomain => 'blog' do
    root :to => 'blog#show'

    # Other blog routes
  end

  constraints :subdomain => 'www' do
    match "/" => redirect("http://craz8.com/")
    match "/*other" => redirect { |params, req| "http://craz8.com#{params[:other]}" }
  end
end

You then need to tell Heroku about the sub-domains so that they send requests to your configured application:

heroku domains:add blog.craz8.com
heroku domains:add www.craz8.com
heroku domains:add crazy.com

Then configure your DNS provider to send all sub-domains to Heroku and deploy your app in the usual way.

Just by building your application with Ruby on Rails 3.1+, there are a number of performance features that you get just by following the Rails conventions. These are features that make your application faster to your users, and faster applications have been shown to have happier users.

And you get them all for Free!

ETags for All Content

Rails adds Rack Middleware for ETag (Rack::ETag) and ConditionalGet (Rack:ConditionalGet) that, together, help to reduce the amount of data that is sent to the client, without you having to do anything (although you can add code to make this work even more to your advantage, which is something I’ll write about later).

Every action that is executed that returns content, and is not marked as ‘no-cache’, will have an ETag generated for it. If a browser requests the same action, and the same content is generated - making the ETags match - then the ConditionalGet middleware will throw away the response you generated and send a Not Modified response instead, as the browser already has that content.

The obvious improvement here is that if you can detect that the content will be the same before you do all the work to generate it, then you can respond to the browser raven sooner! Rails provides a number of ways to do this that I’ll write about later

The Asset Pipeline

One of the best things you can do to improve the performance of your web application is to reduce the number of individual files that the browser has to download. Since Rails 3.1 Rails the Asset Pipeline reduces the number of CSS and JS files downloaded by combining them all into a single file of each type for production, but allowing you to keep functionality in separate files during development.

Unique Asset File Names

The Asset Pipeline system in Rails allows you to automatically add unique identifiers during the Precompile phase (called digests), and then the built-in helpers reference these unique names at runtime without you having to write any special code, other than using the provided helpers.

Why would you do this and not refer to images and other assets directly?

The main reason is that you can now set the caching of these files to be a really long time, since the names of the files will change if you change the content of the files. Typically, this cache setting will be done in Apache or Nginx configuration, but if you’re using Heroku, you should read my recent post on Heroku Configuration for Performance Rails Apps

The longer you can cache images and other assets, the fewer requests a browser needs to make to display your page to your user, and the happier your users will be.

As an extra benefit, the use of a Content Delivery Network to host your assets becomes much easier than with a regular web application if you don’t have to worry about cleaning up cached files when you update them.

Summary

Rails 3.1+ provides automatic performance features that you get for free as an application developer

1. ETags to get Not Modified to reduce data returned
2. The Asset Pipeline to reduce the number of requests per page
3. Unique Asset names to allow long cache times and enable CDN usage

If you want to provide the best experience to the users of your Rails application, you should serve all of your static content using a Content Delivery Network, or CDN. There are many CDN providers, but one of the easiest to sign up for and configure is Amazon’s CloudFront service.

Here’s how I configured my Rails blog to use CloudFront to serve all the static assets.

In the AWS Console

• Select the CloudFront option
• Click the Create Distribution button
• Set these options
  • Download
  • Your current domain name (for my blog, this is blog.craz8.com)
  • Origin ID: assets.domain-name (e.g. assets.blog.craz8.com)
  • Select which Price Class you want to be in - I used the default
  • use the defaults for all others
• Click the Create Distribution button at the bottom
• From the Distributions list, copy the Domain Name for the distribution you just created. Mine is d1za39ny3bo0r4.cloudfront.net
• Wait for your new distribution status to change to Deployed (up to 15 minutes)

Now you have to edit a configuration option in your Rails code. In the production.rb configuration file, make this change to use the host name you just created:

  config.asset_host = 'http://d1za39ny3bo0r4.cloudfront.net'

Then deploy your application and enjoy!

The Heroku Platform as a Service is a great way to deploy your Rails apps quickly, but there are a few differences in running a Rails app on their platform.

Serve Static Assets

In a typical Rails application, you want to have your web server, using configuration in Apache or Nginx, deliver static files to the browser. This avoids running any Rails code for the simple case of sending bytes to the network. Heroku doesn’t work this way. As your Rails app is deployed, Heroku injects the Rack::Static middleware into your middleware stack to serve static files from your /public directory. This includes your pre-compiled assets.

This is equivalent to the following entry in your production.rb file

  config.serve_static_assets = true

Since you are using the config.assets.digest = true option for your pre-compiled assets, you can afford to set these static assets to be cached by browsers for as long as you need. Add this to your production.rb file

  config.static_cache_control = "public, max-age=31536000"

GZip All The Bytes

One of the easiest ways to improve your web site load times is to make sure you serve compressed data to all the browsers that accept compressed content. Pre-compiling your assets creates a set of GZipped files that you can use in other deployments, but Heroku doesn’t serve these files at all.

The simplest way to serve compressed content is to use the Rack::Deflater middleware to handle all compression duties. If you configure it correctly, you can use this to compress all of the static content you have to serve up, as well as the HTML you generate from your Rails code.

Add this to your production.rb

  config.middleware.insert_before('ActionDispatch::Static', Rack::Deflater)

Since Heroku isn’t using your .gz files from the pre-compile stage, you can disable compression to speed up deployment:

  config.assets.compress = false

Fixing The Deflater

There is a bug in the Rack::Deflater code that needs to be patched. This fix is in the current Rack gihtub repository, but not in the latest version of the Rack Gem. The patch ensures that the @body.close code is always executed.

I patch code by adding a config/initializer script, in this case I call it rack_deflater.rb

require 'rack/deflater'

module Rack
  class Deflater
    class GzipStream
      def each(&block)
        @writer = block
        gzip  =::Zlib::GzipWriter.new(self)
        gzip.mtime = @mtime
        @body.each { |part|
          gzip.write(part)
          gzip.flush
        }
      ensure
        @body.close if @body.respond_to?(:close)
        gzip.close if gzip && !gzip.closed?
        @writer = nil
      end
    end
  end
end

Summary

For Heroku, the regular production Rails configuration needs to be different to get the best performance for your Rails application

• Your app needs to serve static assets, so make sure that browsers cache them
• Compress all compressible content
• Patch the Rack compression code to fix a bug

I am currently working on a Ruby on Rails application that has a very lightweight user facing component, and a much heavier Admin system that involves more UI and more complex processing to display system statistics.

To improve the scalability of the user facing site, I decided to split the Admin interface out to a separate web application and run it as a separate application.  To avoid actually creating two different Rails applications, and to re-use my application models between applications, I am running both of these applications from the same codebase, configured at runtime to be either the User or Admin apps.

Here’s how I did this.

Application Configuration

Create an initialization file config/initializes/admin_app.rb with the following contents

if Rails.env.production?
  Appname::Application.config.user_app = ENV["APPNAME_ADMIN"] != 'true'
  Appname::Application.config.admin_app = ENV["APPNAME_ADMIN"] == 'true'
else
  Appname::Application.config.user_app = true
  Appname::Application.config.admin_app = true
end

Note that, except for the production environment, both the User and Admin modes are enabled in the app at the same time

In the config/routes.rb file, make updates to partition the routes for each app type:

if Appname::Application.config.user_app
  resources :foo
  resources :bar
end

if Appname::Application.config.admin_app
  namespace :admin do
    resources :users
    resources :other
  end
end

Heroku Configuration

To setup the User application, the regular heroku command is used

heroku apps:create appname

You can then configure the database, memcache, redis and other add-ons that you require.  All of these add-ons place environment variables into the Heroku application configuration to be used during app initialization.

Now we setup the Admin part of the application

heroku app:create appname-admin --remote admin

Get a list of the environment variables from the User app:

heroku config --app appname

Transfer to the Admin app all the configuration that refers to add-ons you want to share, e.g.

heroku config:set DATABASE_URL=<url from appname> --app appname-admin

Also add the APPNAME_ADMIN variable we use inside the app

heroku config:set APPNAME_ADMIN=true --app appname-admin

Now you deploy both apps:

git push heroku
git push admin

You can access the User app via http://appname.herokuapp.com and the Admin app via http://appname-admin.herokuapp.com.  

Summary

With this system in place, you can now provide different configurations for your User and Admin apps.  In my particular app, I change the number of worker processes used in my Unicorn configuration file, and I remove the Admin user verification system from the User application completely.  When I start to get lots of users to this application, the User application can be scaled without needing to scale up due to needing to run the Admin code on every Heroku dyno.