Das Buch Wer mitmacht, hat Recht!

The usage of .htaccess files is totally overrated these days, it is often used for things it’s orginally not intended for, like complex RewriteCond and RewriteRule sets.
In this article I will show you how not to use a .htaccess, with some benchmarking and what will happen to a strong webserver when it has to process a large .htaccess file.

Read the whole story. or go straight to Part 2 – The Solution

Pros and Cons of using .htaccess:

• PRO
  • Easy customization of your Apache configuration (cool isn’t it?)
  • Easily testing mod_rewrite and other stuff ( \o/ )

• CON
  • HUGE performance impact
    • ‘initial loading lag’ with large .htaccess files (What take this page so long to load?!)
  • Limitation of configuration options ( THANK GOD )

Performance? What teh fock I do care?

Even if it’s not your server, you should care about performance.

If .htaccess is enabled the Apache will look on every access to every path if a .htaccess is existing.
If not it will proceed loading the requested file, otherwise it’s parsing and processing the .htaccess file.
Depending on the filesize of .htaccess, large files are much the worse, your Apache has to ‘cache’ the file for the access.

If you are using a ‘static’ set of RewriteRules and having access to the Apache configuration, then take the pain off your Apache and add the rules to your Apache configuration.
Otherwise, try to avoid using complex and themself repeating rulesets in your .htaccess files.

Advanced Apache Torturing Example:

A 1.6 MiB large .htaccess file, like this one, is a huge pain for your Apache.

Some details of this file, for the stat whores of you:

• Words: 46,783
• Lines: 13,562
• Characters (no spaces): 1,584,845
• Characters (with spaces): 1,672,503
• Handled Third Level Domains: 198

So, this means the poor Apache have to process about 12,000 Rules in nearly 200 Rulesets on every page request.

I don’t get it!?

Ok, I did a benchmark with the site which is using that large .htaccess, where I got the stats above from. The webserver is an Intel Xeon 3050 DualCore with 2 MiB cache and 16 GB (2×8) ECC DDR2 RAM, not that bad hardware for a modern webserver.

First I tried to benchmark it with 1000 requests and 100 concurrent connections, well it quit. Then I tried 1000 requests and 10 concurrent connections, didn’t got finished too.

It worked with 30 requests and 10 concurrent connections …. and the Apache had a (short) lockdown while the test ran and I was trying to access the site myself with a webbrowser!

ab -n 30 -c 10 http://shops.example.com/example_shop

Benchmarking shops.example.com (be patient).....done

Server Software: Apache/2.2.4
Server Hostname: shops.example.com
Server Port: 80

Document Path: /example_shop
Document Length: 16285 bytes

Concurrency Level: 10
Time taken for tests: 7.17990 seconds
Complete requests: 30
Failed requests: 29
(Connect: 0, Length: 29, Exceptions: 0)
Write errors: 0
Total transferred: 502141 bytes
HTML transferred: 491011 bytes
Requests per second: 4.27 [#/sec] (mean)
Time per request: 2339.330 [ms] (mean)
Time per request: 233.933 [ms] (mean, across all concurrent requests)
Transfer rate: 69.82 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 26 27 0.6 27 28
Processing: 1621 2110 319.3 2123 2647
Waiting: 1552 2046 316.8 2063 2553
Total: 1648 2137 319.2 2151 2674

Percentage of the requests served within a certain time (ms)
50% 2151
66% 2280
75% 2379
80% 2517
90% 2613
95% 2657
98% 2674
99% 2674
100% 2674 (longest request)

Summary

The above benchmarks clearly shows that this ‘monster’ of webserver hardware could not manage a small number of requests, because the Apache is busy with parsing the .htaccess file and the rulesets inside it.

In short words, the Apache totally got fucked up.

References:

Apache Tutorial: .htaccess files
ab – Apache HTTP server benchmarking tool

ChangeLog:

• Revised article structure
• Fixed some typos and spelling issues
• Revised Introduction

Last Update: 2008/01/30 – 01:30 p.m. (CET)