Speed-up your pages with mod_pagespeed

Posted in General by

Last week Google released two new tools to help people make their websites faster.

The first one is a Firefox extension called “Page Speed” which gives you a performance analysis of the website you’re viewing as well as lots of tips on how you can make the website faster if you’re the website owner.

The second one is an Apache module called “mod_pagespeed”. Enabling it in Apache causes Apache to analyze the resources it’s serving and optimize them on the fly before serving them. We have installed mod_pagespeed on all of our servers (except web1-web20 which run rhel4). It is disabled by default for all websites but if you are using a static app all you have to do to enable mod_pagespeed for your website is to add this line to your .htaccess file (or create a new .htaccess file if you don’t have one yet):

ModPagespeed On

If you’re using a Django app or any other app that comes with your own Apache instance you can also easily enable mod_pagespeed like this (assuming your app is called “django” and your username is “username“):

mkdir -p $HOME/mod_pagespeed/cache/ $HOME/mod_pagespeed/files
cd $HOME/webapps/django/apache2/modules
cp /usr/lib/httpd/modules/mod_pagespeed_ap24.so .
vi ../conf/httpd.conf # Or another editor if you think "vi" is too simple...
    # add the following:
    LoadModule pagespeed_module modules/mod_pagespeed_ap24.so
    ModPagespeed on
    ModPagespeedFileCachePath            "/home/username/mod_pagespeed/cache/"
    # save and exit
cd ../bin; ./restart

Note that if you’re using Apache-2.2 the module’s path is /usr/lib/httpd/modules/mod_pagespeed.so

If you’re using your own Apache instance you can also configure which filters you want to enable or disable. If you’re using a static/php/cgi or a php-based app like WordPress, Drupal or Joomla then it is not currently possible to configure which filters you want because the current version of mod_pagespeed doesn’t seem to support filter configuration per virtual hosts. For these apps you will be using the default “core filters” chosen by Google. These are:

  • add_head: adds a head to the document if it encounters a <body> tag before finding a <head> tag.
  • combine_css: replaces multiple distinct CSS files with a single CSS file, containing the contents of all of them.
  • rewrite_css: parses referenced and inline CSS and minifies them.
  • rewrite_javascript: parses referenced and inline javascript code and minifies it.
  • inline_css: reduces the number of requests made by a web page by inserting the contents of small external CSS resources directly into the HTML document.
  • inline_javascript: reduces the number of requests made by a web page by inserting the contents of small external JavaScript resources directly into the HTML document.
  • rewrite_images: rescales, and compresses images; inlines small ones.
  • insert_img_dimensions: inserts width= and height= attributes into <img> tags that lack them and sets them to the image width and height.
  • extend_cache: rewrites the URL references in the HTML page to include a hash of the resource content. Thus if the site owner changes the resource content, then the URL for the rewritten resource will also change.

For the official docs on mod_pagespeed and its filters see http://code.google.com/speed/page-speed/docs/using_mod.html

Enjoy the new mod_pagespeed and let us know if you notice any difference in the loading time for your pages.

Update: Be aware that mod_pagespeed is still in beta and therefore might have some bugs. In particular we’ve had reports saying that it can saturate the number of Apache processes available for your site and cause some requests to hang. We’ll roll-out future versions as Google release them but in the mean time if mod_pagespeed is causing problems for your particular site the best thing to do is to just not enable it for your site for now.

Update 1 August 2011: Removed deprecated ModPagespeedUrlPrefix directive.

Update 24 August 2015: mod_pagespeed is no longer on by default – you must use “ModPagespeed On” in your .htaccess to activate it (see above).

Update 16 June 2016: For CentOS 6 and CentOS 7 servers, the paths to the mod_pagespeed modules are:

  • /usr/lib64/httpd/modules/mod_pagespeed_ap24.so
  • /usr/lib64/httpd/modules/mod_pagespeed.so

Update 12 July 2017: Almost all customers have been migrated to CentOS7 and Apache 2.4, so the Django docs have been updated:

  • LoadModule pagespeed_module modules/mod_pagespeed_ap24.so
  • Removed deprecated ModPagespeedGeneratedFilePrefix option

Welcome to our shiny new blog

Posted in General by

As you might have noticed we’ve moved our blog to this shiny new WordPress-based blog.
This will be the new home for lots of exciting announcements …

PS: For the nostalgics our old posts are available at http://blog1.webfaction.com


Rails 3 has landed!

Posted in Rails by

The long-awaited release of Rails 3 has finally arrived and with it a new one-click installer on the control panel.

Rails 3 is the culmination of two years of effort and a merge of the Rails and Merb projects. This major release sports numerous improvements, such as:

  • script/rails: the rails command replaces the individual commands in the scripts directory. For example, rails console replaces script/console.
  • Javascript framework agnosticism: Rails 3 lets you use Prototype, jQuery, and other Javascript tools as you need them.
  • Improved security: cross-site scripting (XSS) protection is included by default with Rails 3.
  • Easier email: Action Mailer has been redone with improved syntax and new options.

But that’s merely a small taste of what’s changed in the latest version of Rails. Check out the complete release notes for details on everything that’s changed since Rails 2.

When you’re ready, give the new one-click installer a try and join us in the forum to share what you think of this latest generation of Rails.


Introducing Passenger

Posted in Ruby by

Recently, we quietly added an important pair of new apps to our complement of one-click installers based on Phusion Passenger. Passenger’s also known as mod_rails ormod_rack, but in the time I’ve spent playing with it, I’ve come to call it nifty.

Passenger is a module which works with nginx to make it easy to setup and run a wide variety of web applications, but Passenger shines while running Ruby and Ruby on Rails applications. But as you’re about to find out, it’s capable of a lot more.

In the control panel you’ll find two new application types available for installation:

  • Passenger 2.2.8 (nginx 0.7.64/Ruby Enterprise Edition 1.8.7)
  • Rails 2.3.5 (nginx 0.7.64/Passenger 2.2.8/Ruby Enterprise Edition 1.8.7)

The Rails application is a new (and, in many respects, improved) way of setting up your Rails applications; the Passenger application is a more generalized tool for deploying other kinds of applications.

Gems, Rack, and You

One of the great things about both new applications is how easy it is to install Ruby Gems. For example, here’s how I installed Sinatra, a light-weight web application framework:

[ddbeck@web100 ~]$ cd webapps/passenger_app/
[ddbeck@web100 passenger_app]$ export GEM_HOME=$PWD/gems
[ddbeck@web100 passenger_app]$ export PATH=$PWD/bin:$PATH
[ddbeck@web100 passenger_app]$ gem install sinatra
Successfully installed sinatra-0.9.4
1 gem installed
Installing ri documentation for sinatra-0.9.4...
Installing RDoc documentation for sinatra-0.9.4...

Another great feature of Passenger is that it supports the Rack interface which allows Ruby and Ruby frameworks to easily work with web servers. For example, I can use the Sinatra framework I just installed to create a simple web application:

[ddbeck@web100 passenger_app]$ mkdir frank
[ddbeck@web100 passenger_app]$ mkdir frank/public
[ddbeck@web100 passenger_app]$ mkdir frank/tmp
[ddbeck@web100 passenger_app]$ touch frank/config.ru
[ddbeck@web100 passenger_app]$ touch frank/myapp.rb 

Then I paste the following code (from Sinatra’s Getting Started guide) into myapp.rb:

require 'rubygems' require 'sinatra' get '/' do 'Hello WebFactioneers!' end 

Next, I put these lines into my config.ru:

require 'rubygems' require 'sinatra' require 'myapp' run Sinatra.application 

Finally, I update this line in ~/webapps/passenger_app/nginx/conf/nginx.conf:

root /home/ddbeck/webapps/passenger_app/hello_world/public; 


root /home/ddbeck/webapps/passenger_app/frank/public; 

and reboot my application with ./bin/restart and voila!

[ddbeck@web100 passenger_app]$ curl ddbeck.webfactional.com Hello, WebFactioneers! 

With the flexibility and other improvements that Passenger provides, we invite you to give the new apps a try. We can’t wait to see what uses you find.


A little holiday present: 10,000 reqs/sec with Nginx!

Posted in Server setup by

Updated Dec 19 at 05:15 CDT (first posted Dec 18 at 06:01 CDT) by Remi

A few weeks ago we quietly started to configure our new machines with Nginx as the front web server instead of Apache (we still run Apache behind Nginx for people who need all the features from Apache).

Here is a little benchmark that I did to compare Nginx versus Apache (with the worker-MPM) for serving a small static file:

nginx vs Apache requests per second

This benchmark is not representative of a real-world application because in my benchmark the web servers were only serving a small static file from localhost (in real life your files would get served to remote machines and some of your requests would be dynamic) but the results are impressive nonetheless. Both servers are capable of serving a huge number of requests per second, but Apache’s performance start decreasing as you add more concurrent connections whereas Nginx’s performance almost doesn’t drop!

But here comes the best bit: because Nginx is event-based it doesn’t need to spawn new processes or threads for each request, so its memory usage is very low. Throughout my benchmark it just sat at 2.5MB of memory while Apache was using a lot more:

nginx vs Apache memory usage

To take advantage of the lightning speed of Nginx we have added two new types of applications to our control panel: the “static only” app and the“symlink to static-only” app. They just work like a normal “static/cgi/php” and “symlink to static/cgi/php” app, except that they can only serve purely static content (no .htaccess support) and they are served directly by the front Nginx server.

Even if your site is not static you can still serve all your static data (CSS, javascript, images, …) directly from Nginx and enjoy the speed gain.

Nginx is only available on Web57 and over. If you’re on an older server and would like to use Nginx open a ticket and we’ll give you an extra plan on a new Nginx server and a free week to transfer your data.

Nginx FTW!

[Updated December 19th, 2008 to clarify the fact that we still run Apache behind Nginx for people who need all the Apache features]