The .htaccess performance hit

If .htaccess files are allowed (through the AllowOverride directive) then apache will look for .htaccess files on every request. In addition apache has to look up the directory tree to see if there are further .htaccess files in locations above the location the file is requested from so that it can tell which directives have precedence. For example: if you request a file from /foo/bar, apache has to look for /foo/bar/.htaccess, /foo/.htaccess and /.htaccess and that’s even if there are no .htaccess files present in any of those locations! Once a .htaccess file is found it has to be parsed and don’t forget all of this has to happen for every request!!

As there’s nothing in a .htaccess file that can’t be achieved in your httpd.conf (or files included by httpd.conf) it makes sense to move existing .htaccess rules into your apache conf using a Directory or Location directive as appropriate.

Restarting apache without dropping users

One other reason why .htaccess are seen as a convenience is that they don’t require apache to be restarted after configuration changes. However if you restart apache with “apachectl graceful” you only force the parent process to re-read the apache configuration files and the children to restart when they’re not doing anything and as a result no end users are suddenly dropped.

Finding all of the .htaccess files on your system

Simply drop on to your terminal and change directory to where you site files are located and run: find . -name *.htaccess -print. This should provide output that shows the location of all of the .htaccess files so you can go through one by one and move them to into httpd.conf or a file included by httpd.conf.

At the same time as updating the site I took the opportunity to upgrade to WordPress 2.1. Aside from needing to change the blogroll categories and update the function in the template all went fairly well.

The blogroll has been merged with the other categories so if you were referencing your blogrolls and link list via id it’s likely that your ids will have changed. The easiest way to find out what’s going on is to go and look at the blogroll maintainence screens and look at the category links have changed to.

The other issue for me is that the wp_get_links function seems to have changed causing the links to be output with a load of brs etc. To fix this I looked at the code and found that the function get_links() did what I wanted. Thus I changed from this:

<?php wp_get_links(4); ?>

to:

<?php get_links(37,'<li>','</li>','',false,'name',false,false); ?>

The difference being I am now specifying the markup before and after the links and whether to display the descriptions or not.

Currently I’m on a dedicated server and the problem with that is that should the server experience some kind of major software or hardware failure then it’s up to me to either fix it or restore it which is fine but you will have inevitable downtime.

As my server is up for renewal very soon I am wondering, should I try the Grid Server or look at the Virtual Dedicated service. The specs of the Grid server are obviously tempting, but since launch it would seem they’ve had a few problems with their service. I’ve noticed at least two blogs that are hosted on the Grid Server but have been unavailable due to MySQL problems.

The only other issue I have is that I am seriously evaluating Django and as yet there is no support for Django on the Grid Server, though hopefully at some point this would be added.

So what are your views, is the Grid Server too good to be true or the best thing to ever happen to web hosting?

12-02-07: Fixed mistake in the directory comparison line.

If you want to be able to redirect blah.domain.com to domain.com/blah/ so that blah.domain.com is shown in the address bar here’s a quick and dirty how to:

First off if you want any subdomain to be able to be redirected first you need to set-up your DNS correctly. In my case this was as simple as going to the people that host my domain and adding an A record with the wildcard * that pointed to my server’s ip address. Bear in mind your DNS settings may take a while to work so be patient. Before you proceed you should check that anything.domain.com resolves to the ip address of your server. You can check this by running:

ping iloveapache.domain.com

This should respond with something like this:

[root@cheekymonkey conf]# ping iloveapache.domain.com
PING iloveapache.domain.com (62.193.xxx.xxx) 56(84) bytes of data.
64 bytes from my.serverhostame.com (62.193.xxx.xxx): icmp_seq=0 ttl=64 time=0.058 ms
64 bytes from my.serverhostame.com (62.193.xxx.xxx): icmp_seq=1 ttl=64 time=0.040 ms
64 bytes from my.serverhostame.com (62.193.xxx.xxx): icmp_seq=2 ttl=64 time=0.071 ms
64 bytes from my.serverhostame.com (62.193.xxx.xxx): icmp_seq=3 ttl=64 time=0.028 ms

The next step is to set-up the virtual host to respond to the wildcard subdomains. In the case of plesk you have to set-up a vhost.conf file but on any other apache installation you can just edit httpd.conf and look for the <VirtualHost> that corresponds to your site. If you are using Plesk you will need to ssh in to your server and create a vhost.conf file if it doesn’t already exist here where <domain.com> is your domain:

/var/www/vhosts/<domain.com>/conf/vhost.conf

Open that file with the command line editor of your choice and add the following directives:

ServerAlias *.domain.com
RewriteEngine on
RewriteCond %{HTTP_HOST} !^www.* [NC]
RewriteCond %{HTTP_HOST} ^([^\.]+)\.domain\.com
RewriteCond /var/www/vhosts/domain.com/httpdocs/%1 -d
RewriteRule ^(.*) /%1/$1 [L]

Substitute domain.com for your domain. Now here’s a quick walkthrough how these rules work. The first line ServerAlias *.domain.com tells apache to accept anysubdomain.domain.com.

Next the rewrite rules work as follows:

1. The first line of mod_rewrite !^www.* only matches urls that don’t begin with www. You don’t want to redirect www.domain.com to www.domain.com/www/ do you? Note: you could add additional lines like these to prevent re-writing other subdomains like secure.domain.com if that should not be redirected to domain.com/secure/
2. The second line ^([^\.]+)\.*$ captures into a backreference anything that doesn’t have a period e.g. the subdomain. The plus makes sure that there is at least one character that matches.
3. The next condition checked is that the directory captured into the backreference does actually exist hence the -d.
4. This last line ^(.*) /%1/$1 [L] takes the requested path and dumps it into a back reference and then rewrites it to point to the a directory (the subdomain backreference captured in the Rewrite conditions above) . In other words %1 is the subdomain backreference and $1 is the path backreference (that captured by .*). The important thing to rember is you can refer to backreferences in rewriteCond lines with % and backreferences in rewriteRules with $. Lastly the [L] (last) means doen’t further rewrite this URL. Note: You might want to leave this out if you are doing any subsequent rewrites, be sure to test what you have set-up thoroughly!!!

Now once you have made those changes if you are running plesk you will need to apply your vhost.conf changes with the following command:

/usr/local/psa/admin/sbin/websrvmng --reconfigure-vhost --vhost-name=<domain.com>

And then whether are using Plesk or not you need to restart apache e.g:

service httpd restart

Now you should find that if you set-up a directory called “meegan” with a valid index.html file in it. meegan.domain.com should find that file. The job’s a good’un.