Is the .htaccess performance loss acceptable when it eases maintenance?

The documentation on .htaccess says in summary that one should not use .htaccess files when one has access to httpd.conf because of the performance implications (and security, but that's not a factor in this situation).

However, what about ease of maintenance and logical site assembly?

Isn't .htaccess easier to maintain on a server with hundreds of folders and subfolders? It seems logical to keep your Apache directives that are related to the content in that folder with the folder itself, just like you'd keep the images, config files, data files (no database), stylesheets, etc for that content in that folder.

Isn't this the same situation as using a server-side scripting language to include the same content on multiple pages? This "templating" reduces the server's performance but eases site maintenance, so it's widely accepted practice.

Couldn't it be said that using .htaccess has the same benefits as templating?

This situation relates to a large site (currently several hundred directories and 20,000+ files) on a dedicated server.

Hi Jeremy,

I do think per-directory config files are easier to manage.

However, I'm not sure how much slower we're talking - I've *never* seen a benchmark of this (but every tuning discussion I've seen mentions this), and a quick google didn't turn anything up. I'm guessing it depends on the level of nesting ( i.e. you have one filesystem seek'n'read for each htaccess file for each dir of the path ).

If I get some time this weekend I might have a go at benchmarking it (although this might be quite hard ).

Hmm... what about keeping .htaccess files in the dirs, turning off Override, and writing a perl/python script to find all .htaccess'es and merge them into the httpd.conf file?

--Simon

It would be interesting to see some benchmark results. If you don't get to them this weekend, I may end up doing them down the road before I make this decision.

I'm in the preliminary stages of redesigning a very large website that will only get larger. I'll need to be able to make adjustments and changes to various existing directories and possibly immediately as I make new directories. Throwing open an .htaccess file, making the modification, and being done sounds much, much easier than having to go through the steps of making the change on the server by wading through one very large config file or many smaller ones and having to restart the server to have it take effect.

I would think the efficiency loss would be almost equivalent to that of using an include in terms of disk I/O, so if it eases maintenance in the same way as an include does, it only seems logical to use .htaccess.

Ok, so I've had a go at benchmarking, and the httpd.conf can handle ~3 requests/second more. I'll do a few more tests and see if this averages out and then write up a full post of what I've done.

Edit: right, 2.4% difference in number of requests served / second when htaccess is turned off, but this is with a heavily nested dir. structure (10 subdirs ). Full details are here.

--Simon

That doesn't seem like a significant difference to me, especially if you offset the loss elsewhere: faster disks, a raid array (although, this could reduce efficiency, too), some kind of caching like mod_mem_cache, reducing the directory depth, using static HTML files, etc.

yeah - it's definitely on the trivial side of things ( & in this case Apache is checking 10 dirs, this is probably a worst case scenario ).