Apache doesn't cache htaccess configs |
February 5th, 2013 |
| tech |
.htaccess files by caching them and then
watching for changes with inotify, Chris wrote:
just invalidate its cacheThis is very sensible, except Apache doesn't actually cache
.htaccess files
between requests.
Apache checks .htaccess files in a monster function, ap_directory_walk.
It's called on every request, and if AllowOverride is set it will call
ap_parse_htaccess on every directory from the root out to the leaf. In
ap_parse_htaccess you can see that it does have a per-request cache for parsed
.htaccess files:
/* firstly, search cache */
for (cache = r->htaccess; cache != NULL; cache = cache->next) {
if (cache->override == override && strcmp(cache->dir, d) == 0) {
*result = cache->htaccess;
return OK;
}
}
... more sanity and safety checks ...
dc = ap_create_per_dir_config(r->pool);
... load and parse the htaccess file into dc ...
/* cache it */
new = apr_palloc(r->pool, sizeof(struct htaccess_result));
new->dir = parms.path;
new->override = override;
new->override_opts = override_opts;
new->htaccess = dc;
/* add to head of list */
new->next = r->htaccess;
r->htaccess = new;
return OK;
Now it may be that the overhead of parsing .htaccess files just isn't that big
and that in many cases a cache would just be a waste of memory. While I doubt that, this
is testable. To get a best-case for caching we could test just something like:
/var/www/foo.html /var/www/.htaccessComparing this to the version that has the configuration options in a
<Directory> block should tell us the maximum we could expect to gain from
caching.
Update 2013-02-08: I ran some tests on the above configuration
with ab,
but the variance was so extreme (some runs of 10k requests averaged
4k/s while others averaged 500/s) that I think something else is
wrong. I tried running longer tests with more requests but
ab consistently died with apr_socket_recv: Operation
timed out (60) before finishing the test.
Comment via: google plus, facebook, substack