Re: Does "AllowOverride All" damage Apache performance?

["Steve Swift" <steve.j.swift@xxxxxxxxx>]

On many systems the htaccess files will tend to stay in cache - if not the systems's memory cache then the disk subsystem's cache. The busier the server gets, the more likely this is to be true, because it uses the one htaccess file for references to all other files in the directory. So there is very little overhead in reading them. However, I come from the era when you avoided machine intructions that took more than two CPU cycles... so I avoid htaccess files :-)

On 22/02/07, Joshua Slive <joshua@xxxxxxxx> wrote:

On 2/22/07, thomas Armstrong <tarmstrong@xxxxxxxxx> wrote:
> Hi.
>
> One colleague claims that if we set "AllowOverride All" within our
> httpd.conf , the performance of Apache (we use 2.0.59) is damaged.
>
> Is this true? Any suggestion is welcome.

As discussed here:
http://httpd.apache.org/docs/2.2/misc/perf-tuning.html#runtime
if AllowOverride is set to anything other than "none", then there will
be a performance penalty as apache looks for .htaccess files.

This would only be noticeable on a site that was stretching its
performance to the limits.  For example, apache.org runs with
AllowOverride enabled and easily transfers hundreds of gigabytes and
hundreds of millions of requests per day.  And if you are running any
kind of dynamic content like php, the processing time for those
scripts will overwhelm any time spent looking for .htaccess files.

In other words, the performance hit from enabling .htaccess is
irrelevant to most sites.  But if you are running a site that needs
the maximum throughput for requests for small static files, you might
consider disabling it and testing the result.

Joshua.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
   "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx

-- 
Steve Swift
http://www.swiftys.org.uk