New Python-2.7 and Python-3.1 versions

Posted in Python by

Python-2.7.1 and Python-3.1.3 were released on Saturday and we’ve now rolled them out to all servers.

Also, in case you missed the announcement WordPress-3.0.2 was released on Tuesday and it contains some security fixes so everybody with a WordPress site should run the auto-upgrade asap.


New twitter account for status updates

Posted in General by

We now have a new twitter account for status updates:
This will be a mirror of our status blog at


A look at our Python setup

Posted in Python by

You may not know this but WebFaction started as a specialized Python hosting provider (it was even called so as you might expect we have pretty good support for Python. Let’s SSH into one of our servers and take a look:

[remi@web150 ~]$ python
Python 2.4.3 (#1, Nov 11 2010, 13:34:43)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-48)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

“What?” you say. “Only Python 2.4! My grandmother is younger than that!” (or alternatively, “Wow, this is awesome, my current host only has Python 2.2”)
Don’t worry, that’s just the default Python on Centos5. Let’s try something else:

[remi@web150 ~]$ python<hit tab>
python            python2.5-config  python2.7-config  python3.1-config
python2           python2.6         python3.0
python2.4         python2.6-config  python3.0-config
python2.5         python2.7         python3.1
[remi@web150 ~]$

That’s better… We actually have all versions from Python 2.4 to 3.1 and you can bet that we’ll add new versions as soon as they come out.
That’s just the beginning. Python comes with “batteries included” but most people need some extra modules that don’t come with Python. Let’s see what we’ve got:

[remi@web150 ~]$ rpm -qa | egrep 





[remi@web150 ~]$

That’s a pretty decent set of modules for each Python version. The “.el5.webfaction” at the end of the RPM name is our naming scheme for software we build and maintain ourselves because it’s not provided by Centos5.
But that’s not all: if you need a module which is not pre-installed we give you all the tools to install it yourself in your home directory and it’s all nicely documented at You can install them with pip, or easy_install. For example:

[remi@web150 ~]$ mkdir -p ~/lib/python2.5
[remi@web150 ~]$ easy_install-2.5 matplotlib
Searching for matplotlib
Best match: matplotlib 0.91.1
<lots of compilation messages>
[remi@web150 ~]$ python2.5
Python 2.5.4 (r254:67916, Aug  5 2009, 12:42:40)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib

Pretty cool huh?

I hope you now have a good idea of what our Python setup includes. In future blog posts we’ll look at other components of our setup.


RoundCube (our webmail app) upgraded

Posted in Email by

We’ve upgraded RoundCube (our webmail app at to the latest version.

The upgrade includes lots of bug fixes and an increased maximum attachment size (the limit is now 15MB).


Meet our new Q&A community site

Posted in Community by

Until recently we’ve been using a normal forum for public questions and answers from our community.
The forum model has two major drawbacks: it’s not easy to update information so the content can become obsolete quite soon and people can’t vote on replies so it’s sometimes hard to tell what the best answer to a question is.
This is why we’ve recently launched a new Q&A community site based on the stack-exchange model:

WebFaction Q&A community site

It has some great features like threaded comments, ability to update and vote on content and best of all it has user karma so we can see who really kicks ass (go Sean !).
This new model seems to be working much better than a simple forum so go ahead and ask any question about your hosting there and if you know some of the answers go ahead and improve your karma. You can also search previous questions and answers which can save you having to ask the question yourself in the Q&A site or in a support ticket.

As a side note the community site is an instance of the great OSQA open-source project which we’ve heavily customized by adding our logo at the top. Our old forum posts are still online but the forum is now in a read-only mode.


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/ .
vi ../conf/httpd.conf # Or another editor if you think "vi" is too simple...
    # add the following:
    LoadModule pagespeed_module modules/
    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/

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

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/
  • /usr/lib64/httpd/modules/

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/
  • 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


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/
[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

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 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]