You are probably familiar with the N+1 query and cache counter problems, so let’s look how Bullet will detect these by monitoring the database queries.

The N+1 query problem

Suppose we have our application with accounts having many rate plans:

class RatePlan < ActiveRecord::Base
  belongs_to :account
end

If we iterate over the rate plans, accessing rate plans attributes, like:

RatePlan.all.each {
  |post| puts "#{rate_plan.name}, by #{rate_plan.account.name}"
}

Will be using N+1 queries:

• one query to get all the rate plans
• then, for each rate plan, one query to get the corresponding account.

(This means that if we have 1000 posts, we’ll be doing 1000+1 queries)

By using the :include option, we can retrieve the rate plans and their corresponding accounts on the same query:

RatePlan.find(:all, :include => :account).each {
   |post| puts "#{rate_plan.name}, by #{rate_plan.account.name}"
}

By detecting if we forgot to use eager loading or a counter cache, Bullet can save time looking for problems on the fly.
For example, Bullet will show this message:

We have to be careful not to abuse the :include option. If the rate_plans table is big enough, it could take too much server memory. Also, we could end up with big, slow requests, or getting from the server a lot of data that won’t be used. Bullet will show a message if it detects an unused eager loading.

Cache counters

Cache counters is another improvement in a one-to-many relationship. Because the _has_many_ relationship defines an attribute that is a collection, if we use the size property on this attribute, it will trigger a select count(*) on the child table. This is generally acceptable, except when we are using frequently count and we end up going to the database unnecessarily.
In order to avoid that, we can use counter caching: Active Record will maintain for a parent table the number of child references. Bullet also shows a message if it finds a cache counter is needed.

Configuration

You have to first install the gem, by adding it to the Gemfile, or by installing manually:

sudo gem install bullet --pre

The next thing is to add some configuration to the development environment. Bullet won’t do anything unless you configure it explicitly, and also note that it’s not a good idea to configure it on the production environment, because on that case your users would also receive those N+1 query alerts.

Configuration allows Growl notifications, and sending messages by XMPP (Jabber), but since the default JavaScript alerts are good enough for me, I configured it like this:

config.after_initialize do
  Bullet.enable = true
  Bullet.alert = true
  Bullet.bullet_logger = true
  Bullet.console = true
  Bullet.growl = false
  Bullet.rails_logger = true
  Bullet.disable_browser_cache = true
end

Note the last option, because disabling browser cache can save you some trouble on some configurations. In any case, if Bullet is not working, try first disabling browser cache.

With this configuration, it will show a JavaScript alert, the same message on the console, and the detail and stack trace on the bullet.log.

Actually has been made improvements on this topic, specially in the new Ruby implementation (Ruby 1.9) based on the YARV virtual machine.

JRuby (Ruby over JVM implementation) has been focused in its performance from its lastest releases. Here at moove-it we are exploring the posibility of use Rails over JRuby in some JEE application servers, so we need some facts about JRuby performance (and other topics like gems compatibility, etc)

The Ruby community has put a set of benchmarks at ruby1.9 trunk: http://svn.ruby-lang.org/repos/ruby/trunk/benchmark/

So, we test with these benchmarks and here are the results!.

The code that run the benchmarks is like that:

block_to_benchmark = lambda { load BENCHMARKS_DIR + '/' + filename}
Benchmark.measure &block_to_benchmark

(yes, we are using the benchmark module bundled with the ruby standard lib)

.

A looser conclusion may be that Ruby 1.9 is 95% faster than Ruby1.8, and JRuby 1.3.0 is 10% faster than 1.8, in general the new implementations are faster than Ruby1.8,  especially 1.9 (twice as faster).

The benchmarks were under WindowsXP  SP3, 4GB RAM, and a Intel Core 2 duo 2.0GHz. Happy hacking!

There are many techniques that allow us to reduce the amount of requests that are made on a page, among them are: the sprites, put the stylesheets on top of the page, javascripts compress, among others.

But what’s offered by Rails to improve the performance of our web application?

It offers a great plugin called bundle_fu (http://code.google.com/p/bundle-fu/)
It allows us with a single request obtain all the javascripts and with another request all the stylesheets  (it also offers the possibility of compress javascripts).
Using this plugin is really easy but it’s very powerfull

<% bundle do -%>
  <%= javascript_include_tag :default -%>
  <%= javascript_include_tag "javascript1" -%>
  <%= javascript_include_tag "javascript2" -%>
  <%= javascript_include_tag "javascript3" -%>
  <%= stylesheet_link_tag "style1" -%>
  <%= stylesheet_link_tag "style2" -%>
  <%= stylesheet_link_tag "style3" -%>
  ...
<% end %>

All these javascripts and stylesheets are converted in only two files when the request is processed.