Alfa Jango Blog Engineering, Software, and Entrepreneurship

In this article, we’re going to speed up our Rails application by up to 75%, simply by optimizing our Rails asset host. We’re going to serve our components (stylesheets, javascripts, images, etc.) from a combination of our app’s server and Amazon CloudFront (Option A, recommended), or entirely from CloudFront (Option B – easier).

The best option for you may depend on your specific needs, but I’ll cover both processes below. For a an in-depth analysis of why Option A is recommended over Option B, see the last article in this series, How to Combine GZip + CDN for Fastest Page Loads.

(more…)

It has become common practice to use JQuery as the javascript library of choice for Ruby on Rails applications. If you have a Rails app already using Prototype, it usually isn’t feasible to replace it in one swoop. And sometimes, you just simply need both to work at the same time. Whether you want to use both in unison (not recommended as a long-term strategy), or you want to gradually migrate from Prototype to JQuery, it’s not as scary as you may think.

The secret is that it is difficult to get Prototype to play nicely with JQuery, while it is rather trivial to get JQuery to play nicely with Prototype. This may seem like a minor distinction, but it is one that will save you a lot of headaches.

Use Prototype/Scriptaculous with JQuery

First, in our application layout, we’re going to get rid of <%=javascript_include_tag :defaults %> and include each javascript file explicitly just to make things a little less magicky and a little more straight forward.

(more…)

We recently worked on a Rails application that had page and action caching set up, only to find that it was not actually working. It occurred to me that many Rails/Passenger/Apache applications may have caching set up in a way that it appears to be caching, when it is not actually caching. Searching through the interwebs for various Passenger/Apache configurations, such as this snippet on Github or this discussion on Google Groups, I found that many did not work with the most recent version of Phusion Passenger. What’s more, these configurations give the appearance that they are working.

For an introduction to caching with Rails, check out this post: Caching With Rails: An Overview

The Appearance That Caching Works

Here is what I mean by giving the appearance that caching is working:

1. you add caches_page :index to your controller, for example
2. configure and restart your server
3. load the index page
4. check your rails cache directory on your server, and see the index.html
5. it works! (hint: this step is wrong, you’re not quite there yet)

Just because Rails is generating your cached page does not mean that your server is subsequently serving the cached .html file instead of sending the request to Rails again.

Ensure It’s Serving the Cached Page

To make sure it’s subsequently serving the cached page, the easiest method is to look at the created date on the cached file on your server, for instance:

(more…)

Phusion Passenger (aka mod_rails) allows for easy and scalable deployment of Ruby on Rails applications on Apache or Nginx servers. Part of what makes it so easy is that it comes with suitable default settings right out of the box, so that you don’t need to concern yourself with any of the details when deploying your application to production.

However, once you’ve launched your application and people start actually using it, you may find server experiencing excessive swapping once the traffic begins to pick up. Before getting too deep into scaling, caching, upgrading your server, etc., there are a few Passenger settings you can tune to wring out the best performance your existing stack. I’ll address these settings with a few rules of thumb we’ve gathered from the Passenger documentation and simple trial-and-error.

Before getting started, we highly recommend employing Munin (instructions for Munin with Passenger here) and NewRelic Performance Monitoring for your Passenger/Rails application, so that you can fine-tune your settings for the best performance.

Note: the following settings are specific for Apache, you will need to modify the syntax/file-names for Nginx.

Per-server Settings

These settings are set per-server, meaning if you have multiple applications running on the server, these should be set only once throughout all of your .conf files. If you have only one Rails/Passenger app on the server, then you may set these in that application’s .conf file. On Ubuntu, this may be found at /etc/apache2/sites-available/yourapp.conf.

(more…)

Here’s the problem: You have a Ruby on Rails application and its WordPress blog. For the sake of consistency and branding, you’d like to use the same layout in your WordPress blog as you do for your Rails app. Perhaps your blog is one of the main links or tabs in your application’s header.

Why this doesn’t work: You proceed with creating a custom theme for your WordPress blog that looks exactly like your Rails application. Then over the next couple years, you begin to realize how tedious this solution is. You have to copy over your CSS stylesheets from your Rails app, your Javascript files (if your standard layout contains any Javascript elements, like a Twitter widget in the footer or whatever), and your layout images and assets. Then, every time you change or update the layout of your Rails app, you have to copy the changes in your custom WordPress theme. And you cannot just copy the changes, because if you have any Ruby/Rails functionality in the layout, you have to translate them into PHP functionality in your WordPress layouts.

And then there’s the impossible stuff… if anything in your Rails app layout loads information from the database in your Rails app, then you cannot have those elements in your WordPress layout, unless you do something like create an XML or JSON feed in your Rails app and then import it in your WordPress layout. But this is quite tedious still if you want to change any of it!

There’s an easier way.

Include Your Rails Layout Directly In Your WordPress Layout

The solution I found turns out to be quite simple. The basic idea is to create a :partial in your Rails app layout, make it publicly accessible via your config/routes.rb, have it generate and simply return the appropriate html using your controller method, and then import that html (and CSS) in your WordPress layout.

(more…)

Munin is a great tool to monitor resources on your server, showing graphs over time, so that you can analyze resource trends to find what’s killing your server before it causes major problems. It is also very configurable and can be made to profile and graph just about anything via plugins. And with a couple tricks, you can get it to monitor your Phusion Passenger application with ease.

Update: If you have RVM installed on your server and need Munin to work with RVM’s Passenger installation, follow all of the instructions below, and then make the changes described in Monitor Passenger with Munin when using RVM.*

* These changes will still use your server’s non-RVM-installed default Ruby to run the Munin plugin, which will in turn use your RVM-installed Ruby to run the passenger-status and passenger-memory-stats commands.

If you already have Munin installed and working, and just want to know how to get the Passenger Plugins working, you can skip directly to Install Munin Passenger Plugins, Configure Munin for Passenger Stats, and be sure to read the Gotcha.

(more…)