Apache 2.1 docs: Notes/questions/typos on "perf-tuning.xml"

[Mi...@telekurs.de]

At several locations "Apache 2.0" is mentioned
explicitly; this should be "Apache 2.1" now.

Others mention "Apache 2.x", thus it might be
worth checking which of the "Apache 2.0" strings
should rather be "Apache 2.x" now (a thing I
didn't do this time).

> However, there are compile-time and run-time configuration choices
> that can significantly affect performance.

The English original doesn't make that very explicit,
but IMHO the main idea of this line would be that
_on_top_ of the enhancements which are active by
default there are _further_ enhancements that require
explicit activation, which may include configuration
as well as recompiling the source code with "tuned"
options.

I try to reformulate this line so that it would be
that explicit:
"Furthermore, some additional enhancements that can
significantly affect performance have to be activated
explicitly by the administrator; some of these are
available via configuration directives while others
(even) require (re)compiling the source code, using
specific compiler options."
(Meaning: "The more performance tuning you want, the
more you have to do & understand about your Apache.")

> Beyond that the rest is mundane: get a fast enough CPU,
> a fast enough network card, and fast enough disks,

The _number_ of hard disks might be relevant as well.
This line could be a little more precise about that,
as more hard disks _and_ a proper distribution of
accessed data on these disks might improve the degree
of parallel access and reduce disk head positioning.
(Maybe mentioning RAID systems would be a good idea; I
am not deep enough into this stuff to make a proposal
for the text though.)

> Wherever in your URL-space you do not have an Options
> FollowSymLinks, or you do have an Options SymLinksIfOwnerMatch
> Apache will have to issue extra system calls to check up
> on symlinks.

The English version is very short about why this is so
(and consequently Jobst Giesecke overlooked the "not"
in the first line - I would like to see this word marked
up as "important", maybe <em>...</em>).

Actually there are three possible scenarios:
a) symlinks are allowed. In this case Apache has nothing
   to check (this is the "fast but insecure" choice that
   would provide the best performance).
b) symlinks are forbidden. In this case Apache has to check
   each component of a file path whether it is a symlink.
c) only certain types of symlink are allowed, i. e. those
   where the owner of the symlink is the same as the owner
   of the target of the symlink. In this case Apache has to
   check for symlinks like in case b), but if symlinks
   _have_ been used then Apache has to do an additional
   check whether these symlinks are 'valid' as specified.
   This is the 'slowest' scenario, combining the comfort of
   symlinks with the security goal of not (inadvertently?)
   making 'foreign' files visible within the URL space -
   but if you want this you have to pay the price for it.
Maybe the above lines (or some equivalent of these) could
make it into the document?

> Wherever in your URL-space you allow overrides
> (typically .htaccess files) Apache will attempt to open
> .htaccess for each filename component. For example,

Questions:
1. Is "overrides" self-explaining enough?
2. Is there any other way besides .htaccess files?
(I know the name is configurable, I am just on semantics here)

If the second answer were "no" then I would reformulate this line to:
"Whereever in your URL-space you allow the overriding of
configuration directives (through the mechanism of .htaccess
files) Apache will attempt...".

> Negotiation
> If at all possible, avoid content-negotiation if you're really interested
> in every last ounce of performance.

I doubt that I can unconditionally agree to this line.

Serving compressed content SHOULD be done via negotiation
("Accept-Encoding"), and it should be considered a per-
formance issue (not only regarding response time for the
client but even regarding output volume for the server
itself).
Serving statically precompressed files would likely reduce
the load of the server, and most definitely the bandwidth
required.
Dynamic compression might cost CPU load, but when _not_
using the highest compression level (this is configurable
in mod_deflate; mod_gzip chose level 6 as a good compromise
between CPU load and compression effect) it might even pay
off for the server load. (Benchmarks, anyone?)
I suggest mentioning mod_deflate in the performance guide
in some way or another, as well as negotiating statically
precompressed files; combined with the use of mod_cache
this might provide good results.

Some other note here:
Even mod_expires should be a candidate for this document,
as the fastest (and least load intensive) responses will
always be those to requests that haven't even ben sent in
the first place, i. e. access to a browser (or proxy) cache.
I am aware that this comes close to "tuning the application"
instead of "tuning the Apache server providing the HTTP
interface of the application", yet it can be done within
Apache's range, and with Apache knowledge, even for closed
source applications.

> In situations where Apache 2.0 can ignore the contents of the file
> to be delivered -- for example, when serving static file content --
> it normally uses the kernel sendfile support the file
> if the OS supports the sendfile(2) operation.

I am not sure how to read the last two lines of this
sentence.
Isn't there a word missing or something like that?
(Perhaps insert "for" after the first "support", and then
replace "the" by "this"?)

> attempt to eliminate modules that youare not actually using.

Typo: A whitespace seems to be missing after "you".

(I am not yet finished with the translation review, thus
more questions/notes may follow.)

Regards, Michael


---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org