Web performance is a brilliant, but sometimes complex world. Concatenating and minifying files, optimizing images, setting up caching, these are all tasks that can lead to great performance wins. We know that this stuff is good for performance but actually putting these strategies into practice can sometimes be tedious. A team at Google recognized this problem and came up with the idea of creating a web server module that would take of a whole bunch of performance optimizations for you; thus mod_pagespeed was born.

In this post you’re going to learn how to set up mod_pagespeed on an Apache web server. You’ll also be learning how to configure optimization filters that are provided by the module.

Note: This post assumes a familiarity with using the command line, SSH, and basic Apache configurations.

Performance Optimizations Covered by mod_pagespeed

The PageSpeed module (mod_pagespeed) contains a number of filters that are each responsible for taking care of an optimization task. By default, filters are enabled that handle:

• Image Optimization (Compression and Resizing)
• CSS & JavaScript Concatenation, Minification, and Inlining
• Asset Caching

As well as these common optimizations there are filters available for a wide range of other tasks, including:

• Deferred Loading of JavaScript and Images
• Removal of HTML Comments and Whitespace
• Lazy-loading Images (only loaded when they become visible in the viewport)
• Google Analytics Injection
• and more…

Later in this post you’ll learn how to enable these additional filters in the PageSpeed configuration.

Installing mod_pagespeed For Apache

In this post we’re going to focussing on setting up the PageSpeed module for an Apache web server. It’s worth noting that there is also an equivalent module available for nginx.

Note: In order to install the mod_pagespeed module you will need to have SSH access to your web server. If you use a shared hosting service this may not be the case, and therefore I’d advise you to contact your hosting provider and enquire if they have support for mod_pagespeed. You can also check to see if the module is enabled using a phpinfo file.

To install the mod_pagespeed module follow these steps.

1. Open a Connection to Your Server

Start by opening up Terminal and creating a new SSH connection to your server.

ssh user@hostname  # e.g. ssh root@127.0.0.1
    

2. Download the Package

Download the appropriate package for your server environment. You can use the wget program to save this file directly to your server.

wget <package url>
    

• 32 Bit (Debian/Ubuntu): https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-stable_current_i386.deb
• 64 Bit (Debian/Ubuntu): https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-stable_current_amd64.deb
• 32 Bit (CentOS/Fedora): https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-stable_current_i386.rpm
• 64 Bit (CentOS/Fedora): https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-stable_current_x86_64.rpm

3. Install the Package

Next you need to install the package. Instructions for doing this vary depending on what type of server you are using.

For Debian/Ubuntu servers:

sudo dpkg -i mod-pagespeed-*.deb
    sudo apt-get -f install
    

For CentOS/Fedora servers:

# only if 'at' is not installed
    sudo yum install at
    
    # install the package
    sudo rpm -U mod-pagespeed-*.rpm
    

4. Restart Apache

The mod_pagespeed module should now be installed on your server. All you need to do now is restart Apache.

service apache2 restart
    

The installation process should have enabled the new module for you. You can check this by looking for the pagespeed.conf and pagespeed.load files in the /etc/apache2/mods-enabled directory. If these two files are present the module will be loaded by Apache and you’re good to go!

If you can’t find thesefiles in themods-enabled` folder, execute the following commands to enable the module and restart the web server.

cd /etc/apache2/mods-enabled
    ln -s ../mods-available/pagespeed.* ./
    
    # Restart Apache
    service apache2 restart
    

Simply by installing mod_pagespeed you’ve bagged yourself a bunch of great performance wins. By default, mod_pagespeed will be enabled for all of the websites on your server.

Inline CSS with mod_pagespeed

Try visiting one of the websites on your server and take a look at the source code in the browser. You’ll see that mod_pagespeed has changed things around a bit. You may now have CSS and JavaScript assets (maybe even some small images) inline within your HTML. This reduces the number of HTTP requests that are needed to load the page, resulting in faster load times.

Configuring mod_pagespeed

The mod_pagespeed module comes with some of the most commonly used filters enabled by default. In this section you’re going to learn how to enable some of the other optimization filters that are provided.

The master configuration file for mod_pagespeed can be found at /etc/apache2/mods-available/pagespeed.conf. This defines the global configuration for mod_pagespeed and therefore any changes that you make to this file will affect all of the websites on your server. This is great if you want all of your websites to use the same filters but there may be times when this is not the case.

If you’re using virtual hosts, an ideal place to put your site-specific PageSpeed filters is within the host configuration. Depending on your setup, you may find virtual hosts declared within the files in the /etc/apache2/sites-available folder.

The snippet below shows an example VirtualHost configuration with mod_pagespeed directives.

<VirtualHost *:80>
      DocumentRoot /www/example
      ServerName www.example.come
    
      # mod_pagespeed configuration
      ModPagespeedEnableFilters lazyload_images
      ModPagespeedDisableFilters inline_css
    </VirtualHost>
    

You can also use a .htaccess file if you don’t have access to the configuration for you virtual host.

Note: By default, virtual hosts will inherit the options specified in the master pagespeed.conf file. This behaviour is controlled using the ModPagespeedInheritVHostConfig directive. Setting this to off would cause each of the virtual hosts to have a completely independent PageSpeed configuration.

Rewrite Levels

PageSpeed uses two different levels to make configuration simple. The CoreFilters level enables a default set of filters that will make your website faster. You can then enable or disable filters to modify the configuration as you wish.

Alternatively you can disable CoreFilters by setting the RewriteLevel to PassThrough. You will then need to manually enable all of the filters that you wish to use.

ModPagespeedRewriteLevel PassThrough
    

Unless you have some very specific requirements it’s often best to leave the RewriteLevel as CoreFilters and then modify the enabled filters in the host configuration.

Enabling Filters

To enable a filter you use the ModPagespeedEnableFilters directive.

ModPagespeedEnableFilters <filter_name>,<filter2_name>
    

You can find a full list of the different filters available here.

Note than some filters rely on additional configuration variables, such as the insert_ga filter which will automatically insert the Google Analytics code into your pages.

ModPagespeedEnableFilters insert_ga
    ModPagespeedAnalyticsID <Analytics ID>
    

Refer to the documentation for each of the options to find out if you need to set additional variables.

Disabling Filters

To disable a filter you use the ModPagespeedDisableFilters directive.

ModPagespeedDisableFilters <filter_name>,<filter2_name>
    

Specifying this in your host config will override the options specified in pagespeed.conf.

As well as disabling filters you can also forbid virtual hosts from using specific filters. This is done using the ModPagespeedForbidFilters directive.

ModPagespeedForbidFilters <filter_name>,<filter2_name>
    

Forbidding access to filters can be useful if you manage a server that hosts many different websites.

Disabling mod_pagespeed for a Website

You can disable the PageSpeed module completely for a specific website by setting ModPagespeed to off in your host configuration.

ModPagespeed off
    

If you only need to temporarily disable mod_pagespeed for testing purposes, you can just add the ModPagespeed=off query parameter to the URL.

http://example.com/index.html?ModPagespeed=off
    

Final Thoughts

We all know that optimizing websites for performance is a big part of web development today, but taking care of all the different optimization tasks can often become tedious. The PageSpeed module you’ve learned about here takes care of much of this headache; leaving you to do what you do best – build great websites.

I highly recommend that you take a little time to install this module on your web servers. For a minimal amount of effort you can unlock a wide range of performance gains and supercharge your websites.

Useful Links

• PageSpeed Module Homepage
• Google Code Project
• mod_pagespeed Filter Examples
• Nginx Install Instructions
• Configuring PageSpeed Filters

The post Automating Web Performance Best Practices with mod_pagespeed appeared first on Treehouse Blog.

As developers, we want the applications we build to be resilient when it comes to failure, but how do you achieve this goal? If you believe the hype, micro-services and a clever communication protocol are the answer to all your problems, or maybe automatic DNS failover. While that kind of stuff has its place and makes for an interesting conference presentation, the somewhat less glamorous truth is that making a robust application begins with your code. But, even well designed and well tested applications are often lacking a vital component of resilient code – exception handling.

I never fail to be amazed by just how under-used exception handling tends to be even within mature codebases. Let’s look at an example.

What Can Possibly Go Wrong?

Say we have a Rails app, and one of the things we can do using this app is fetch a list of the latest tweets for a user, given their handle. Our TweetsController might look like this:

class TweetsController < ApplicationController
      def show
        person = Person.find_or_create_by(handle: params[:handle])
        if person.persisted?
          @tweets = person.fetch_tweets
        else
          flash[:error] = "Unable to create person with handle: #{person.handle}"
        end
      end
    end

And the Person model that we used might be similar to the following:

class Person < ActiveRecord::Base
      def fetch_tweets
        client = Twitter::REST::Client.new do |config|
          config.consumer_key        = configatron.twitter.consumer_key
          config.consumer_secret     = configatron.twitter.consumer_secret
          config.access_token        = configatron.twitter.access_token
          config.access_token_secret = configatron.twitter.access_token_secret
        end
        client.user_timeline(handle).map{|tweet| tweet.text}
      end
    end

This code seems perfectly reasonable, there are dozens of apps that have code just like this sitting in production, but let’s look a little more closely.

• find_or_create_by is a Rails method, it’s not a ‘bang’ method, so it shouldn’t throw exceptions, but if we look at the documentation we can see that due to the way this method works, it can raise an ActiveRecord::RecordNotUnique error. This won’t happen often, but if our application has a decent amount of traffic it’s occurring more likely than you might expect (I’ve seen it happen many times).
• While we’re on the subject, any library you use can throw unexpected errors due to bugs within the library itself and Rails is no exception. Depending on our level of paranoia we might expect our find_or_create_by to throw any kind of unexpected error at any time (a healthy level of paranoia is a good thing when it comes to building robust software). If we have no global way of handling unexpected errors (we’ll discuss this below), we might want to handle these individually.
• Then there is person.fetch_tweets which instantiates a Twitter client and tries to fetch some tweets. This will be a network call and is prone to all sorts of failure. We may want to read the documentation to figure out what the possible errors we might expect are, but we know that errors are not only possible here, but quite likely (for example, the Twitter API might be down, a person with that handle might not exist etc.). Not putting some exception handling logic around network calls is asking for trouble.

Our tiny amount of code has some serious issues, let’s try and make it better.

The Right Amount of Exception Handling

We’ll wrap our find_or_create_by and push it down into the Person model:

class Person < ActiveRecord::Base
      class << self
        def find_or_create_by_handle(handle)
          begin
            Person.find_or_create_by(handle: handle)
          rescue ActiveRecord::RecordNotUnique
            Rails.logger.warn { "Encountered a non-fatal RecordNotUnique error for: #{handle}" }
            retry
          rescue => e
            Rails.logger.error { "Encountered an error when trying to find or create Person for: #{handle}, #{e.message} #{e.backtrace.join("\n")}" }
            nil
          end
        end
      end
    end

We’ve handled the ActiveRecord::RecordNotUnique according to the documentation and now we know for a fact that we’ll either get a Person object or nil if something goes wrong. This code is now solid, but what about fetching our tweets:

class Person < ActiveRecord::Base
      def fetch_tweets
        client.user_timeline(handle).map{|tweet| tweet.text}
      rescue => e
        Rails.logger.error { "Error while fetching tweets for: #{handle}, #{e.message} #{e.backtrace.join("\n")}" }
        nil
      end
    
      private
    
      def client
        @client ||= Twitter::REST::Client.new do |config|
          config.consumer_key        = configatron.twitter.consumer_key
          config.consumer_secret     = configatron.twitter.consumer_secret
          config.access_token        = configatron.twitter.access_token
          config.access_token_secret = configatron.twitter.access_token_secret
        end
      end
    end

We push instantiating the Twitter client down into its own private method and since we didn’t know what could go wrong when we fetch the tweets, we rescue everything.

You may have heard somewhere that you should always catch specific errors. This is a laudable goal, but people often misinterpret it as, “if I can’t catch something specific, I won’t catch anything”. In reality, if you can’t catch something specific you should catch everything! This way at least you have an opportunity to do something even if it’s only to log and re-raise the error.

An Aside on OO Design

In order to make our code more robust, we were forced to refactor and now our code is arguably better than it was before. You can use your desire for more resilient code to inform your design decisions.

An Aside on Testing

Every time you add some exception handling logic to a method, it’s also an extra path through that method and it needs to be tested. It’s vital you test the exceptional path, perhaps more so than testing the happy path. If something goes wrong on the happy path you now have the extra insurance of the rescue block to prevent your app from falling over. However, any logic inside the rescue block itself has no such insurance. Test your exceptional path well, so that silly things like mistyping a variable name inside the rescue block don’t cause your application to blow up (this has happened to me so many times – seriously, just test your rescue blocks).

What to Do With the Errors We Catch

I’ve seen this kind of code countless times through the years:

begin
      widgetron.create
    rescue
      # don't need to do anything
    end

We rescue an exception and don’t do anything with it. This is almost always a bad idea. When you’re debugging a production issue six months from now, trying to figure our why your ‘widgetron’ isn’t showing up in the database, you won’t remember that innocent comment and hours of frustration will follow.

Don’t swallow exceptions! At the very least you should log any exception that you catch, for example:

begin
      foo.bar
    rescue => e
      Rails.logger.error { "#{e.message} #{e.backtrace.join("\n")}" }
    end

This way we can trawl the logs and we’ll have the cause and stack trace of the error to look at.

Better yet, you may use an error monitoring service, such as Rollbar which is pretty nice. There are many advantages to this:

• Your error messages aren’t interspersed with other log messages
• You will get stats on how often the same error has happened (so you can figure out if it’s a serious issue or not)
• You can send extra information along with the error to help you diagnose the problem
• You can get notifications (via email, pagerduty etc.) when errors occur in your app
• You can track deploys to see when particular errors were introduced or fixed
• etc.

begin
      foo.bar
    rescue => e
      Rails.logger.error { "#{e.message} #{e.backtrace.join("\n")}" }
      Rollbar.report_exception(e)
    end

You can, of course, both log and use a monitoring service as above.

If your rescue block is the last thing in a method, I recommend having an explicit return:

def my_method
      begin
        foo.bar
      rescue => e
        Rails.logger.error { "#{e.message} #{e.backtrace.join("\n")}" }
        Rollbar.report_exception(e)
        nil
      end
    end

You may not always want to return nil, sometimes you might be better off with a null object or whatever else makes sense in the context of your application. Consistently using explicit return values will save everyone a lot of confusion.

You can also re-raise the same error or raise a different one inside your rescue block. One pattern that I often find useful is to wrap the existing exception in a new one and raise that one so as not to lose the original stack trace (I even wrote a gem for this since Ruby doesn’t provide this functionality out of the box). Later on in the article when we talk about external services, I will show you why this can be useful.

Handling Errors Globally

Rails lets you specify how to handle requests for resources of a certain format (HTML, XML, JSON) by using respond_to and respond_with. I rarely see apps that correctly use this functionality, after all if you don’t use a respond_to block everything works fine and Rails renders your template correctly. We hit our tweets controller via /tweets/yukihiro_matz and get an HTML page full of Matzs’ latest tweets. What people often forget is that it’s very easy to try and request a different format of the same resource e.g. /tweets/yukihiro_matz.json. At this point Rails will valiantly try to return a JSON representation of Matzs’ tweets, but it won’t go well since the view for it doesn’t exist. An ActionView::MissingTemplate error will get raised and our app blows up in a spectacular fashion. And JSON is a legitimate format, in a high traffic application you’re just as likely to get a request for /tweets/yukihiro_matz.foobar. Tuts+ gets these kinds of requests all the time (likely from bots trying to be clever).

The lesson is this, if you’re not planning to return a legitimate response for a particular format, restrict your controllers from trying to fulfill requests for those formats. In the case of our TweetsController:

class TweetsController < ApplicationController
      respond_to :html
    
      def show
        ...
        respond_to do |format|
          format.html
        end
      end
    end

Now when we get requests for spurious formats we’ll get a more relevant ActionController::UnknownFormat error. Our controllers feel somewhat tighter which is a great thing when it comes to making them more robust.

Handling Errors the Rails Way

The problem we have now, is that despite our semantically pleasing error, our application is still blowing up in our users’ face. This is where global exception handling comes in. Sometimes our application will produce errors that we want to respond to consistently, no matter where they come from (like our ActionController::UnknownFormat). There are also errors that can get raised by the framework before any of our code comes into play. A perfect example of this is ActionController::RoutingError. When someone requests a URL that doesn’t exist, like /tweets2/yukihiro_matz, there is nowhere for us to hook in to rescue this error, using traditional exception handling. This is where Rails’ exceptions_app comes in.

You can configure a Rack app in application.rb to be called when an error that we haven’t handled is produced (like our ActionController::RoutingError or ActionController::UnknownFormat). The way you will normally see this used is to configure your routes app as the exceptions_app, then define the various routes for the errors you want to handle and route them to a special errors controller that you create. So our application.rb would look like this:

...
    config.exceptions_app = self.routes
    ...

Our routes.rb will then contain the following:

...
    match '/404' => 'errors#not_found', via: :all
    match '/406' => 'errors#not_acceptable', via: :all
    match '/500' => 'errors#internal_server_error', via: :all
    ...

In this case our ActionController::RoutingError would be picked up by the 404 route and the ActionController::UnknownFormat will be picked up by the 406 route. There are many possible errors that can crop up. But as long as you handle the common ones (404, 500, 422 etc.) to start with, you can add others if and when they happen.

Within our errors controller we can now render the relevant templates for each kind of error along with our layout (if it’s not a 500) to maintain the branding. We can also log the errors and send them to our monitoring service, although most monitoring services will hook in to this process automatically so you don’t have to send the errors yourself. Now when our application blows up it does so gently, with the right status code depending on the error and a page where we can give the user some idea regarding what happened and what they can do (contact support) – an infinitely better experience. More importantly, our app will seem (and will actually be) much more solid.

Multiple Errors of the Same Type in a Controller

In any Rails controller we can define specific errors to be handled globally within that controller (no matter which action they get produced in) – we do this via rescue_from. The question is when to use rescue_from? I usually find that a good pattern is to use it for errors that can occur in multiple actions (for example, the same error in more than one action). If an error will only be produced by one action, handle it via the traditional begin...rescue...end mechanism, but if we’re likely to get the same error in multiple places and we want to handle it the same way – it’s a good candidate for a rescue_from. Let’s say our TweetsController also has a create action:

class TweetsController < ApplicationController
      respond_to :html
    
      def show
        ...
        respond_to do |format|
          format.html
        end
      end
    
      def create
        ...
      end
    end

Let’s also say that both of these actions can encounter a TwitterError and if they do we want to tell the user that something is wrong with Twitter. This is where rescue_from can be really handy:

class TweetsController < ApplicationController
      respond_to :html
    
      rescue_from TwitterError, with: twitter_error
    
      private
    
      def twitter_error
        render :twitter_error
      end
    end

Now we don’t need to worry about handling this in our actions and they will look much cleaner and we can/should – of course – log our error and/or notify our error monitoring service within the twitter_error method. If you use rescue_from correctly it can not only help you make your application more robust, but can also make your controller code cleaner. This will make it easier to maintain and test your code making your application that little bit more resilient yet again.

Using External Services in Your Application

It’s difficult to write a significant application these days without using a number of external services/APIs. In the case of our TweetsController, Twitter came into play via a Ruby gem that wraps the Twitter API. Ideally we would make all our external API calls asynchronously, but we’re not covering asynchronous processing in this article and there are plenty of applications out there that make at least some API/network calls in-process.

Making network calls is an extremely error prone task and good exception handling is a must. You can get authentication errors, configuration problems, and connectivity errors. The library you use can produce any number of code errors and then there is a matter of slow connections. I am glossing over this point, but it’s oh so crucial since you can’t deal with slow connections via exception handling. You need to appropriately configure timeouts in your network library, or if you’re using an API wrapper make sure it provides hooks to configure timeouts. There is no worse experience for a user than having to sit there waiting without your application giving any indication of what’s happening. Just about everyone forgets to configure timeouts appropriately (I know I have), so take heed.

If you’re using an external service in multiple places within your application (multiple models for example), you expose large parts of your application to the full landscape of errors that can be produced. This is not a good situation. What we want to do is limit our exposure and one way we can do this is putting all access to our external services behind a facade, rescuing all errors there and re-raising one semantically appropriate error (raise that TwitterError that we talked about if any errors occur when we try to hit the Twitter API). We can then easily use techniques like rescue_from to deal with these errors and we don’t expose large parts of our application to an unknown number of errors from external sources.

An even better idea might be to make your facade an error free API. Return all successful responses as is and return nils or null objects when you rescue any sort of error (we do still need to log/notify ourselves of the errors via some of the methods we discussed above). This way we don’t need to mix different types of control flow (exception control flow vs if…else) which may gain us significantly cleaner code. For example, let’s wrap our Twitter API access in a TwitterClient object:

class TwitterClient
      attr_reader :client
    
      def initialize
        @client = Twitter::REST::Client.new do |config|
          config.consumer_key        = configatron.twitter.consumer_key
          config.consumer_secret     = configatron.twitter.consumer_secret
          config.access_token        = configatron.twitter.access_token
          config.access_token_secret = configatron.twitter.access_token_secret
        end
      end
    
      def latest_tweets(handle)
        client.user_timeline(handle).map{|tweet| tweet.text}
      rescue => e
        Rails.logger.error { "#{e.message} #{e.backtrace.join("\n")}" }
        nil
      end
    end

We can now do this: TwitterClient.new.latest_tweets('yukihiro_matz'), anywhere in our code and we know that it will never produce an error, or rather it will never propagate the error beyond TwitterClient. We’ve isolated an external system to make sure that glitches in that system won’t bring down our main application.

But What if I Have Excellent Test Coverage?

If you do have well-tested code, I commend you on your diligence, it will take you a long way towards having a more robust application. But a good test suite can often provide a false sense of security. Good tests can help you refactor with confidence and protect you against regression. But, you can only write tests for things you expect to happen. Bugs are, by their very nature, unexpected. To use our tweets example, until we choose to write a test for our fetch_tweets method where client.user_timeline(handle) raises an error thereby forcing us to wrap a rescue block around the code, all our tests will have been green and our code would have remained failure-prone.

Writing tests, doesn’t absolve us of the responsibility of casting a critical eye over our code to figure out how this code can potentially break. On the other hand, doing this kind of evaluation can definitely help us write better, more complete test suites.

Conclusion

Resilient systems don’t spring forth fully formed from a weekend hack session. Making an application robust, is an ongoing process. You discover bugs, fix them, and write tests to make sure they don’t come back. When your application goes down due to an external system failure, you isolate that system to make sure the failure can’t snowball again. Exception handling is your best friend when it comes to doing this. Even the most failure-prone application can be turned into a robust one if you apply good exception handling practices consistently, over time.

Of course, exception handling is not the only tool in your arsenal when it comes to making applications more resilient. In subsequent articles we will talk about asynchronous processing, how and when to apply it and what it can do in terms of making your application fault tolerant. We will also look at some deployment and infrastructure tips that can have a significant impact without breaking the bank in terms of both money and time – stay tuned.