httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Antwort: cvs commit: httpd-docs-1.3/htdocs/manual/misc perf -tuning.html
Date Mon, 10 Mar 2003 15:32:56 GMT


  +    <h4><a name="mmap" id="mmap">mod_mmap_static</a></h4>
  +    <p>Apache comes with a module, <a
  +    href="../mod/mod_mmap_static.html">mod_mmap_static</a>, which is not
  +    enabled by default, which allows you to map files into RAM, and
  +    serve them directly from memory rather than from the disc, which
  +    should result in substantial performance improvement for
  +    frequently-requests files.

  is there any idea what "frequently used" might mean?

  I have stats about the absolute hits as well as for the hits
  percentage for each file ... which one would provide the most
  useful information in this case?

  > See the documentation for this module for more complete details.</p>

  My interpretation of the "Use Unix the way it was meant to be used."
  formulation in there would be: "poor admin, if you don't even
  understand sed then you don't deserve to experience the per-
  formance benefits of a highly tuned web server", which seems
  a little out of fashion now that Windows is an accepted and
  supported platform for the Apache HTTP Server as well.

  So I would indeed consider some "mmap this directory tree"
  directive a way to give more users access to this feature,
  let them play around with it, don't force them to update
  their Apache configuration just because they changed their
  file tree (one thing more you can forget to remember and be
  sorry about it later - having the script doesn't mean I actu-
  ally invoke it when I need to, and the people who change our
  file tree don't normally do the Apache configuration as well;
  and what happens if the file tree changes and I am running
  mod_mmap with some outdated mapping directives? Error 404?).
  IMHO this would be one step away from the "experimental" stage
  of mod_mmap towards a usable and comfortable module.
  It might even be the one thing that prevents me from using it
  in our production environment.

  Anyway, I have a number of detail questions about mod_mmap
  (when it comes to performance tuning) that don't seem to be
  covered by the docs as of now:

  1. How should I imagine the implementation of the feature?
     [=> Performance Guide]
  Am I right to believe that the files' content will be mapped
  into the address space of _each_ httpd child process - or is
  there any common memory pool they all attach to so that these
  files will eat up the corresponding memory only once?
  I am asking because the chapter about calculating the memory
  size to prevent swapping sounded so reasonable to me, and I
  would want to understand in which way an extensive use of
  mod_mmap would modify my RAM calculation model. Of course I
  can try it out, but I would prefer to understand it first ...

  2. Is it reasonable to have a large number (hundreds, maybe
     thousands) of files in mod_mmap?
     [=> mod_mmap description]
  More specifically: Is the internal mod_mmap data structure
  a) a list (would be awfully slow then) or
  b) a tree (logarithmic access, i. e. robust against high
     numbers of files)?

  3. What about the overhead of each entry inside mod_mmap?
     [=> Performance Guide]
  Is the file content size a reasonable estimation value for
  the amount of RAM being used, or should I take some known
  overhead into calculation - especially when I am holding
  small files (lots of tiny GIF images) in memory?

  And finally, the section

  > Be careful with the filename arguments: They have to literally
  > match the filesystem path Apache's URL-to-filename translation
  > handlers create. We cannot compare inodes or other stuff to match
  > paths through symbolic links etc.  because that again would cost
  > extra stat() system calls which is not acceptable.
  has left me rather confused. I am extensively using symbolic
  links (because we have a family of generic but customizable
  web sites as virtual hosts, adapted to the corporate identity
  of certain customers, thus sharing parts of their document
  tree but not all of if), so can't I use mod_mmap at all or
  (And no, I cannot replace the symbolic links by "Alias"
  directives as this would destroy transparency of the semantic
  relations between these document trees for their maintainers.)

  I am surprised that performance is used as a reason for this
  warning, as this directory parsing would only have to take
  place once during the Apache startup phase ... right?
  And I don't really care how long the Apache startup will take
  as this will surely happen outside our production time window.

Regards, Michael

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message