Most of this discussion revolves around the technical merits of Tornado; whether other platforms are quicker, or whether it’s too limited.  Whilst interesting, I think that many of these discussions are rather missing the point.

What I find interesting about FriendFeed is that it was built primarily because of the requirements of the way the FriendFeed site works.  To give an overview without getting too much into the technical details, the difference is in the way real-time data is updated.
The way pretty much every other website works with regards to updating data is to poll for updates at regular intervals.  FriendFeed works differently; they create a connection to the server, and sit there waiting for an update.  When an update does happen, it displays immediately, because there’s no need to wait for a polling update to run.
A website that works like this, with every user having a connection open waiting for an update, isn’t feasible to create when using a mainstream web server (Apache, Nginx, IIS), because they are designed with the older ‘open a connection, send the data, close the connection’ way of working in mind.

I expect that as desktop software dies out and everything moves to a web-based ’software-as-a-service’ approach it will become increasingly common that parts of the site will run on custom-written software.  The days of the dominance of Apache are over, not because another better webserver daemon has come along, but because with increasingly complex webapps one size no longer fits all.

You have a website you need to move to a new web server on a new IP address. You intend to keep the domain and all URLs the same.

By utilising the Apache module mod_proxy we can make sure that all requests are sent to the correct server, despite any cached DNS entries which are pointing to the old IP. Whilst this isn’t too much of a problem for static web-sites, for modern, database driven sites it is vital that all data is written to the correct location. One particular benefit feature of this approach is that you can move just a single VirtualHost, where other approaches expect you to be moving everything hosted on that server.

Pre-requisites:

• Apache and mod_proxy on the server you are moving from
• Access to the Apache configuration files on the server you are moving from
• Control over the DNS for your domain

The Science Bit

Essentially, what we’re going to do is make the old server into a ‘reverse proxy’, so it will forward all requests on to the new server, then return the reply to the client. One thing to watch out for is scripts that do checking based on the remote IP address, as this will be seen as the old server’s IP for proxied connections.

The Procedure

Testing on the new server

First, I’d recommend taking a copy of your website and putting it up on the new server to test that everything is OK. You can view the website on the new server by making an entry in your ‘hosts’ file on your local machine(/etc/hosts on Linux/Mac OS X, c:\windows\system32\drivers\etc on Windows). An example entry is below:

  # Temporary entry for www.example.com on the new server

  192.168.0.5   www.example.com

Once you’ve ascertained that everything is working correctly on the new server, we can begin the process of moving the website.

Disable updates

Firstly, we need to stop any modifications to the site/database, so you might want to put up an ‘under maintenance’ page. Many applications (Wordpress comes to mind) already include this feature, so it could be as simple as ticking a box and hitting save. An important thing to remember here is that just putting up a page on the front of your site isn’t going to be enough – people will be following deep links and/or already using the site.

Copy the site across

Take a copy of the site, move it to the new server and disable the ‘under maintenance’ page on the server you’re moving to. You might want to double-check everything is OK on the new server at this point, as pretty soon we’re going to hit the point of no (easy) return.

Edit the hosts file on the server

Next, add the hosts entry you made on your local machine to the hosts file on the server you’re moving from. You need this because we’re going to be proxying to the new server by hostname – if the old server still thinks it’s hosting the domain, we’re going to get ourselves in an infinite loop.

Alter the Apache Config

Now here’s where the actual proxying part comes in. In the VirtualHost declaration for the website you want to move, replace the existing config with the following:

  ServerName www.example.com  ProxyRequests Off

<Proxy *>

    Order deny,allow

    Allow from all

  </Proxy>

ProxyPass / http://www.example.com/

  ProxyPassReverse / http://www.example.com/

It’s also probably a good idea to leave your log statements intact – this way you can see how many hits to the old IP you’re getting.

Now run a config check (apachectl configtest), and reload the Apache configuration.

Remove the entry you made in your local hosts file earlier, and verify that the proxy is indeed working. If all is well, you should see an entry in your Apache log on your old server, and an entry in the Apache log on the new server showing the IP of the old server a
s the client.

Move DNS

Now the proxying is set up and we’ve verified it all as working, it’s time to switch the DNS across to the new IP address. From now on you’ll gradually get more and more connections directly to the new server.

After a week or two it should be safe to remove the configuration from the old server – I’d suggest checking the logs to ascertain when the last connection was received to the previous server. If it’s been more than a week, you’re probably safe.