httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: Let's get rid of .htaccess files :-)
Date Thu, 18 Jul 1996 16:56:02 GMT
  The obvious optimistation to make first would be to parse them all
  at startup and hold them in an internal structure and then do a stat
  on the file at each access rather than a full parse.

Another thing which could be done along these lines (without even
caching the .htaccess contents) is to record the *absence* of a .htaccess
file in a particular directory, along with the *directory's* last-mod time,
and then check for a .htaccess file again only if the directory has changed.
(NB for either directories *or* .htaccess files, you've got to check dev/ino
as well as the last-mod date --- if someone moves an older version of the
file back into place, you want the server to notice).

It's worth remembering here that there are performance costs to the .htaccess
mechanism which (by and large) exceed the cost of parsing the files themselves;
specifically, the filesystem lookups in the stat()s for .htaccess files that,
generally, don't exist.  Depending on exactly how the filesystem in question
works, the cost of looking for a file which does *not* exist can be much
higher than the cost of looking for a file or directory which does --- 
in particular, information on files which are present is frequently cached,
but information on files which are absent sometimes isn't.  (This makes the
cost of supporting the .htaccess mechanism very high on AFS, for example).

As to caching .htaccess contents --- the toughest thing about implementing
such a mechanism, it seems to me, is memory management.  The easiest choice
would be to give each .htaccess file its own pool (so that resources asso-
ciated with config information in *that* *file* could be released when it
is reread, without tossing the entire contents of the cache).  However,
that would require tying down a fairly substantial chunk of memory for
each .htaccess file (BLOCK_MINFREE is 8K).  

(Just reducing BLOCK_MINFREE is probably not a good idea --- for the most
common case, which is allocation in per-request pools, we don't want the
palloc() and pcalloc() routines having to call getblock() very often.
However, for the particular case of .htaccess pools, which are allocated
in rarely and then kept for a while, the tradeoff may go the other way,
in favor of reducing space consumption at the expense of extra allocation
overhead.  So, just allowing a pool to be allocated with a different
effective value of BLOCK_MINFREE, and making the minor adjustments in
alloc.c which would be required, might be the way to go...).

rst

Mime
View raw message