austin entrepreneur

clientperf v0.1.6 Released

Posted in Uncategorized by efalcao on June 29, 2008

Spent a few minutes getting some bugfixes into clientperf today.

How to upgrade:

gem install clientperf
clientperf /path/to/rails/app
rake db:migrate

What is fixed:

  • Don’t choke on SafeERB
  • Added indexes (indices? can you say indexes when you’re talking about databases?)
  • Graphs don’t choke when there is no data.


Tagged with: , ,

Slides From My Austin on Rails Talk

Posted in Uncategorized by efalcao on June 25, 2008

Here are the slides from my talk last night:

Announcing Clientperf: Simple Client-Side Rails Performance

Posted in Uncategorized by efalcao on June 21, 2008

I’m giving a talk at Austin on Rails next Tuesday on applying the 14 rules of high-performance websites in the typical rails mongrel/nginx stack, the main idea being to focus on some of the important implementation details when it comes to client-side performance optimization.

As I was planning, I realized that there was no simple as in the we’re-all-spoiled-with-rails simple way to measure client download times in production. Now, there is clientperf. It’s just a start, but decent enough to benchmark the actual client performance impact of any optimizations you make:

How it works

It injects javascript into the page that takes a timestamp at the top of the page and at the bottom of the page. Once the browser is done downloading, evaluating and rendering all assets, clientperf makes one last image request to your server with the start time, end time and the URL. Piece of cake.

How to install

gem install clientperf
clientperf /path/to/rails/app
rake db:migrate

and that’s it!



Thanks to Howard Rauscher for the javascript. Thanks to FiveRuns dev team for helping me learn neat things.

Enjoy and please let me know about bugs.

Turning off RJS debugging on a per controller/action basis

Posted in Uncategorized by efalcao on June 10, 2008

FiveRuns TuneUp is a neat profiling tool for developers. Developing this tool also has brought up some interesting challenges. Here is one that I encountered today:

TuneUp injects into the head of the page and does an AJAX call to fill up the actual run data. We noticed that it was running slow and one of the reasons is that in development mode rails wraps RJS in a javascript try/catch block that produces an alert message with the RJS if there is an exception. On a random run, AJAX response size without RJS debug: 82k, with debug: 386k. That’s quite a bit of overhead.

We can’t tell all TuneUp users to manually turn off RJS debugging, so here is how we disable it solely for our one heavy AJAX action in rails version 2 or greater:

def action_name
  debug_rjs = response.template.debug_rjs
  response.template.debug_rjs = false
  response.template.debug_rjs = debug_rjs

It’s trivial, but it took a little bit of digging through the rails source to find out how to get to this from inside the controller, so I hope it’ll save others some time