httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Httpd Wiki] Update of "PerformanceScalingUp" by jmcg
Date Wed, 17 Nov 2010 00:00:17 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpd Wiki" for change notification.

The "PerformanceScalingUp" page has been changed by jmcg.
The comment on this change is: Fixing typos (en_US). Weeding 1.3 references, updating in some
places to 2.3. The Windows and some of the FreeBSD references need review by someone who has
more clue. We need: better examples, reviews.
http://wiki.apache.org/httpd/PerformanceScalingUp?action=diff&rev1=4&rev2=5

--------------------------------------------------

  
  See also: http://wiki.apache.org/httpd/PerformanceScalingOut
  
- <<TableOfContents(2)>>
+ <<TableOfContents(3)>>
  
  = Acknowledgment =
  This documentation is based on the ApacheCon Presentations on
@@ -37, +37 @@

  
  Therefore, in spite of strides forward in machine speed and bandwidth allowances,
  web server performance and web application performance remain areas of concern.
- In this paper and the ApacheCon session it accompanies, several
- aspects of web server performance will be discussed.
+ In this documentation several aspects of web server performance will be discussed.
  
  == What Will and Will Not Be Discussed ==
  The session will focus on easily accessible configuration and tuning options for
- Apache 1.3 and 2 as well as monitoring tools. Monitoring tools will allow you
+ Apache httpd 2.2 and 2.3 as well as monitoring tools. Monitoring tools will allow you
  to observe your web server to gather information about its performance, or
- lack thereof. We’ll assume that you don’t have an unlimited budget for server
+ lack thereof. We'll assume that you don't have an unlimited budget for server
  hardware, so the existing infrastructure will have to do the job. You have
  no desire to compile your own Apache, or to recompile the operating system
  kernel. We do assume, though, that you have some familiarity with the Apache
- configuration file.
+ httpd configuration file.
  
  = Monitoring Your Server =
  The first task when sizing or performance-tuning your server is to find out how
@@ -58, +57 @@

  
  == Monitoring Tools ==
  === top ===
- The top tool ships with Linux and FreeBSD, and can be downloaded for Solaris.
+ The top tool ships with Linux and FreeBSD. Solaris offers `prstat'.
  It collects a number of statistics for the system and for each running
  process, then displays them interactively on your terminal. The data displayed
  is refreshed every second and varies by platform, but typically includes system
@@ -66, +65 @@

  time spent executing user and system code, and the state of the virtual memory
  system. The data displayed for each process is typically configurable and
  includes its process name and ID, priority and nice values, memory footprint,
- and percentage CPU usage. An example top display is shown in Figure 1.
+ and percentage CPU usage. The following example shows multiple httpd processes
+ (with MPM worker and event) running on an Linux (Xen) system:
+ {{{
+ top - 23:10:58 up 71 days,  6:14,  4 users,  load average: 0.25, 0.53, 0.47
+ Tasks: 163 total,   1 running, 162 sleeping,   0 stopped,   0 zombie
+ Cpu(s): 11.6%us,  0.7%sy,  0.0%ni, 87.3%id,  0.4%wa,  0.0%hi,  0.0%si,  0.0%st
+ Mem:   2621656k total,  2178684k used,   442972k free,   100500k buffers
+ Swap:  4194296k total,   860584k used,  3333712k free,  1157552k cached
+ 
+   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
+ 16687 example_  20   0 1200m 547m 179m S   45 21.4   1:09.59 httpd-worker
+ 15195 www       20   0  441m  33m 2468 S    0  1.3   0:41.41 httpd-worker
+     1 root      20   0 10312  328  308 S    0  0.0   0:33.17 init
+     2 root      15  -5     0    0    0 S    0  0.0   0:00.00 kthreadd
+     3 root      RT  -5     0    0    0 S    0  0.0   0:00.14 migration/0
+     4 root      15  -5     0    0    0 S    0  0.0   0:04.58 ksoftirqd/0
+     5 root      RT  -5     0    0    0 S    0  0.0   4:45.89 watchdog/0
+     6 root      15  -5     0    0    0 S    0  0.0   1:42.52 events/0
+     7 root      15  -5     0    0    0 S    0  0.0   0:00.00 khelper
+    19 root      15  -5     0    0    0 S    0  0.0   0:00.00 xenwatch
+    20 root      15  -5     0    0    0 S    0  0.0   0:00.00 xenbus
+    28 root      RT  -5     0    0    0 S    0  0.0   0:00.14 migration/1
+    29 root      15  -5     0    0    0 S    0  0.0   0:00.20 ksoftirqd/1
+    30 root      RT  -5     0    0    0 S    0  0.0   0:05.96 watchdog/1
+    31 root      15  -5     0    0    0 S    0  0.0   1:18.35 events/1
+    32 root      RT  -5     0    0    0 S    0  0.0   0:00.08 migration/2
+    33 root      15  -5     0    0    0 S    0  0.0   0:00.18 ksoftirqd/2
+    34 root      RT  -5     0    0    0 S    0  0.0   0:06.00 watchdog/2
+    35 root      15  -5     0    0    0 S    0  0.0   1:08.39 events/2
+    36 root      RT  -5     0    0    0 S    0  0.0   0:00.10 migration/3
+    37 root      15  -5     0    0    0 S    0  0.0   0:00.16 ksoftirqd/3
+    38 root      RT  -5     0    0    0 S    0  0.0   0:06.08 watchdog/3
+    39 root      15  -5     0    0    0 S    0  0.0   1:22.81 events/3
+    68 root      15  -5     0    0    0 S    0  0.0   0:06.28 kblockd/0
+    69 root      15  -5     0    0    0 S    0  0.0   0:00.04 kblockd/1
+    70 root      15  -5     0    0    0 S    0  0.0   0:00.04 kblockd/2
+ }}}
  
  Top is a wonderful tool even though it’s slightly resource intensive (when
  running, its own process is usually in the top ten CPU gluttons). It is indispensable
@@ -80, +115 @@

  space is in use. Linux allocates unused memory as file system cache. The free
  command shows usage both with and without this cache. The free command
  can be used to find out how much memory the operating system is using, as
- described in the paragraph ‘Sizing MaxClients’ on page 10. The output of free
+ described in the paragraph ‘Sizing MaxClients’. The output of free
  looks like this:
  
  {{{
@@ -147, +182 @@

  to bring to market a multiplatform monitoring tool built on the same principles
  as SE Toolkit, written in Java.
  
+ === DTrace ===
+ Given that DTrace is available for Solaris, FreeBSD and OS X, it might be
+ worth exploring it. There's also mod_dtrace available for httpd.
+ 
  === mod_status ===
  The mod status module gives an overview of the server performance at a given
  moment. It generates an HTML page with, among others, the number of Apache
  processes running and how many bytes each has served, and the CPU load
- caused by Apache and the rest of the system. The Apache Software Foundation
+ caused by httpd and the rest of the system. The Apache Software Foundation
- uses mod status on its own web site5 . If you put the ExtendedStatus On directive
+ uses mod status on its own [[http://apache.org/server-status|web site]].
+ If you put the ExtendedStatus On directive
  in your httpd.conf, the mod status page will give you more information at
  the cost of a little extra work per request.
  
  == Web Server Log Files ==
- Monitoring and anaylizing the log files Apache writes is one of the most effective
+ Monitoring and analyzing the log files httpd writes is one of the most effective
  ways to keep track of your server health and performance. Monitoring the error
  log allows you to detect error conditions, discover attacks and find performance
- issues. Analysing the access logs tells you how busy your server is, which resources
+ issues. Analyzing the access logs tells you how busy your server is, which resources
  are the most popular and where your users come from. Historical log
  file data can give you invaluable insight into trends in access to your server,
  which allows you to predict when your performance needs will overtake your
@@ -171, +211 @@

  number of active processes or the maximum number of concurrently open files.
  The error log also reflects when processes are being spawned at a higher-than-usual
  rate in response to a sudden increase in load. When the server starts, the
- stderr file descriptor is redirected to the error logfiel, so any error encountered
+ stderr file descriptor is redirected to the error logfile, so any error encountered
- by Apache after it opens its logfiles will appear in this log. This makes it good
+ by httpd after it opens its logfiles will appear in this log. This makes it good
  practice to review the error log frequently.
  
- Before Apache opens its logfiles, any errors will be written to the stderr
+ Before Apache httpd opens its logfiles, any errors will be written to the stderr
- stream. If you start Apache manually, this error information will appear on your
+ stream. If you start httpd manually, this error information will appear on your
- terminal and you can use it directly to troubleshoot your server. If your Apache
+ terminal and you can use it directly to troubleshoot your server. If your httpd
  is started by a startup script, the destination of early error messages depends
  on their design. The /var/log/messages file is usually a good bet. On Windows,
  early error messages are written to the Applications Event Log, which can be
  viewed through the Event Viewer in Administrative Tools.
+ 
+ The Error Log is configured through the `ErrorLog` and `LogLevel` configuration
+ directives. The error log of httpd’s main server configuration receives
+ the log messages that pertain to the entire server: startup, shutdown, crashes,
+ excessive process spawns, etc. The `ErrorLog` directive can also be used in virtual
+ host containers. The error log of a virtual host receives only log messages
+ specific to that virtual host, such as authentication failures and 'File not Found'
+ errors.
+ 
+ On a server that is visible to the Internet, expect to see a lot of exploit
+ attempt and worm attacks in the error log. A lot of these will be targeted
+ at other server platforms instead of Apache, but the current state of affairs is
+ that attack scripts just throw everything they have at any open port, regardless
+ of which server is actually running or what applications might be installed.
+ You could block these attempts using a firewall or [[http://www.modsecurity.org/|mod_security]],
+ but this falls outside the scope of this discussion.
+ 
+ The `LogLevel` directive determines the level of detail included in the logs.
+ There are eight log levels as described here:
  
  || '''Level''' ||  '''Description''' ||
  || emerg || Emergencies - system is unusable. ||
@@ -193, +252 @@

  || info || Informational. ||
  || debug || Debug-level messages ||
  
+ The default log level is warn. A production server should not be run on
+ debug, but increasing the level of detail in the error log can be useful
+ during troubleshooting. Startint 2.3.8 LogLevel can be specified on a
+ per module basis:
+ {{{
+ LogLevel debug mod_ssl:warn
+ }}}
+ This puts all of the server in debug mode, except for `mod_ssl`, which we
+ tends to be very noisy.
- 
- The Error Log is configured through the `ErrorLog` and `LogLevel` configuration
- directives. The error log of Apache’s main server configuration receives
- the log messages that pertain to the entire server: startup, shutdown, crashes,
- excessive process spawns, etc. The `ErrorLog` directive can also be used in virtual
- host containers. The error log of a virtual host receives only log messages
- specific to that virtual host, such as authentication failures and ‘File not Found’
- errors.
- 
- On a server that is visible to the Internet, expect to see a lot of exploit
- attempt and worm attacks in the error log. A lot of these will be targeted
- at other server platforms instead of Apache, but the current state of affairs is
- that attack scripts just throw everything they have at any open port, regardless
- of which server is actually running or what applications might be installed.
- You could block these attempts using a firewall or mod security6 , but this falls
- outside the scope of this discussion.
- 
- The `LogLevel` directive determines the level of detail included in the logs.
- There are eight log levels, described in Table 1. The default log level is warn. A
- production server should not be run on debug, but increasing the level of detail
- in the error log can be useful during troubleshooting.
  
  === Access Log ===
- Apache keeps track of every request it services in its access log file. In addition
+ Apache httpd keeps track of every request it services in its access log file. In addition
- to the time and nature of a request, Apache can log the client IP address, date
+ to the time and nature of a request, httpd can log the client IP address, date
  and time of the request, the result and a host of other information. The various
- logging format features are documented in the Apache manual7 . This file exists
+ logging format features are documented in the [[http://httpd.apache.org/docs/current/mod/core.html#loglevel|manual]].
- by default for the main server and can be configured per virtual host by using
+ This file exists by default for the main server and can be configured per virtual host by
using
  the `TransferLog` or `CustomLog` configuration directive.
  
  The access logs can be analyzed with any of several free and commercially
- available programs. Popular free analysis packages include Analog8 and We-
+ available programs. Popular free analysis packages include Analog and Webalizer.
- balizer9 . Log analysis should be done offline so the web server machine is not
+ Log analysis should be done offline so the web server machine is not
  burdened by processing the log files. Most log analysis packages understand the
- Common Log Format. The fields in the log lines are explained in Table 2.
+ Common Log Format. The fields in the log lines are explained in in the following:
  
  {{{
  195.54.228.42 - - [24/Mar/2007:23:05:11 -0400] "GET /sander/feed/ HTTP/1.1" 200 9747
@@ -249, +296 @@

  || Content Bytes || 9747 ||  Bytes transferred w/o headers ||
  
  === Rotating Log Files ===
- There are several reasons to rotate logfiles. Firstly, they simply become too
- large to handle over time. Some operating systems have a hard file size limit of
+ There are several reasons to rotate logfiles. Even though almost no operating
+ systems out there have a hard file size limit of two Gigabytes anymore, log files simply
become
- two Gigabytes. Secondly, any periodic log file analysis should not be performed
+ too large to handle over time. Additionally, any periodic log file analysis should not be
performed
  on files to which the server is actively writing. Periodic logfile rotation helps
  keep the analysis job manageable, and allows you to keep a closer eye on usage
  trends.
@@ -259, +306 @@

  On unix systems, you can simply rotate logfiles by giving the old file a new
  name using mv. The server will keep writing to the open file even though it has
  a new name. When you send a graceful restart signal to the server, it will open
- a new logfile with the configured name. For example, you could run script from
+ a new logfile with the configured name. For example, you could run a script from
  cron like this:
  
  {{{
@@ -301, +348 @@

  gathered from the logs is so valuable that under normal circumstances
  logging should not be turned off. For optimal performance, you should put
  your disk-based site content on a different physical disk than the server log
- files: the access patterns are very different. Retrieving content is from disk is
+ files: the access patterns are very different. Retrieving content from disk is
  a read operation in a fairly random pattern, and log files are written to disk
  sequentially.
  
@@ -315, +362 @@

  separate access logfile. This makes it easier to analyze the logfile later. However,
  if your server has many virtual hosts, all the open logfiles put a resource burden
  on your system, and it may be preferable to log to a single file. Use the `%v`
- format character at the start of your `CustomLog` format to make Apache print
+ format character at the start of your LogFormat and starting 2.3.8 of your `ErrorLogFormat`
- the hostname of the virtual host that received the request at the beginning of
+ to make httpd print the hostname of the virtual host that received the request or the error
- each log line. A simple Perl script can split out the log file after it rotates: one
+ at the beginning of each log line. A simple Perl script can split out the log file after
it rotates: one
  is included with the Apache source under `support/split-logfile`.
  
  You can use the `BufferedLogs` directive to have Apache collect several log
@@ -345, +392 @@

   * Finally, JMeter13 , a Jakarta subproject, is an all-Java load-testing tool.
   While early versions of this application were slow and difficult to use, the
   current version 2.1.1 seems to be versatile and useful.
+ 
+  * ASF external projects, that have proven to be quite good: grinder, httperf, tsung, FunkLoad
+ 
-  When you load-test your web server, please keep in mind that if that server
+ When you load-test your web server, please keep in mind that if that server
- 
  is in production, the test load may negatively affect the server’s response. Also,
  any data traffic you generate may be charged against your monthly traffic allowance.
  
  = Configuring for Performance =
  == Apache Configuration ==
- The Apache 1.3 httpd is a pre-forking web server. When the server starts, the
+ The Apache 2.2 httpd is by default a pre-forking web server. When the server starts, the
  parent process spawns a number of child processes that do the actual work of
- servicing requests. Apache 2 introduced the concept of the Multi-Processing
+ servicing requests. But Apache httpd 2.0 introduced the concept of the Multi-Processing
  Module (MPM). Developers can write MPMs to suit the process- or threadingarchitecture
  of their specific operating system. Apache 2 comes with special
  MPMs for Windows, OS/2, Netware and BeOS. On unix-like platforms, the
  two most popular MPMs are Prefork and Worker. The Prefork MPM offers
  the same pre-forking process model that Apache 1.3 uses. The Worker MPM
  runs a smaller number of child processes, and spawns multiple request handling
- threads within each child process.
+ threads within each child process. In 2.3+ MPMs are no longer hard-wired.
+ They too can be exchanged via LoadModule. The default MPM in 2.3 is the event mpm.
  
  The maximum number of workers, be they pre-forked child processes or
  threads within a process, is an indication of how many requests your server
  can manage concurrently. It is merely a rough estimate because the kernel can
  queue connection attempts for your web server. When your site becomes busy
- and the maximum number of workers is running, the machine doesn’t hit a hard
+ and the maximum number of workers is running, the machine doesn't hit a hard
  limit beyond which clients will be denied access. However, once requests start
  backing up, system performance is likely to degrade.
  
@@ -376, +426 @@

  maximum number of workers your server can create. It has two related directives,
  `MinSpareServers` and `MaxSpareServers`, which specify the number of
  workers Apache keeps waiting in the wings ready to serve requests. The absolute
+ maximum number of processes is configurable through the `ServerLimit` directive.
- maximum number of processes is hard coded into Apache 1.3 as the parameter
- HARD_SERVER_LIMIT: in order to change it you’d have to recompile the
- server. Fortunately, most distributors have raised this limit well beyond the
- default of 256. In Apache 2.0, this limit is configurable through the `ServerLimit`
- directive.
  
  === Spinning Threads ===
- For Apache 1.3, or the prefork MPM of Apache 2.0, the above directives are
+ For the prefork MPM of the above directives are
  all there is to determining the process limit. However, if you are running a
  threaded MPM the situation is a little more complicated. Threaded MPMs
- support the `ThreadsPerChild` directive14 . Apache requires that `MaxClients` is
+ support the `ThreadsPerChild` directive1 . Apache requires that `MaxClients` is
  evenly divisible by `ThreadsPerChild`. If you set either directive to a number
  that doesn’t meet this requirement, Apache will send a message of complaint
  to the error log and adjust the `ThreadsPerChild` value downwards until it is an
@@ -404, +450 @@

                              RAM per httpd process
  }}}
  
-     The various amounts of memory allocated for the OS, external programs
+ The various amounts of memory allocated for the OS, external programs
  and the httpd processes is best determined by observation: use the top and
  free commands described above to determine the memory footprint of the OS
  without the web server running. You can also determine the footprint of a
@@ -413, +459 @@

  
  The difference between these two is the amount of memory per-process. The
  shared segment really exists only once and is used for the code and libraries
- loaded and the dynamic inter-process tally, or ‘scoreboard,’ that Apache keeps.
+ loaded and the dynamic inter-process tally, or 'scoreboard,' that Apache keeps.
  How much memory each process takes for itself depends heavily on the number
  and kind of modules you use. The best approach to use in determining this
  need is to generate a typical test load against your web site and see how large
@@ -427, +473 @@

  in doubt, be conservative and use a low `MaxClients` value. The Linux kernel
  will put extra memory to good use for caching disk access. On Solaris you need
  enough available real RAM memory to create any process. If no real memory is
- available, Apache will start writing ‘No space left on device’ messages to the error
+ available, httpd will start writing ‘No space left on device’ messages to the error
  log and be unable to fork additional child processes, so a higher `MaxClients`
  value may actually be a disadvantage.
  
@@ -445, +491 @@

  For instance, should a child process of a preforked MPM crash, at most one client
  connection is affected. However, if a threaded child crashes, all the threads in
  that process disappear, which means all the clients currently being served by
- that process will see their connection aborted. Additionally, there may be socalled
+ that process will see their connection aborted. Additionally, there may be so-called
  "thread-safety" issues, especially with third-party libraries. In threaded
- applications, threads may access the same variables indiscriminantly, not know-
+ applications, threads may access the same variables indiscriminantly, not knowing
- ing whether a variable may have been changed by another thread.
+ whether a variable may have been changed by another thread.
  
- This has been a sore point within the PHP community1 . The PHP processor
+ This has been a sore point within the PHP community. The PHP processor
  heavily relies on third-party libraries and cannot guarantee that all of these are
  thread-safe. The good news is that if you are running Apache on Linux, you can
  run PHP in the preforked MPM without fear of losing too much performance
@@ -460, +506 @@

  Apache maintains an inter-process lock around its network listener. For all
  practical purposes, this means that only one httpd child process can receive
  a request at any given time. The other processes are either servicing requests
- already received or are ‘camping out’ on the lock, waiting for the network listener
+ already received or are 'camping out' on the lock, waiting for the network listener
  to become available. This process is best visualized as a revolving door, with
  only one process allowed in the door at any time. On a heavily loaded web
  server with requests arriving constantly, the door spins quickly and requests are
  accepted at a steady rate. On a lightly loaded web server, the process that
- currently “holds” the lock may have to stay in the door for a while, during
+ currently "holds" the lock may have to stay in the door for a while, during
  which all the other processes sit idle, waiting to acquire the lock. At this
  time, the parent process may decide to terminate some children based on its
  `MaxSpareServers` directive.
  
- === 3.1.6   The Thundering Herd ===
+ === The Thundering Herd ===
- The function of the ‘accept mutex’ (as this inter-process lock is called) is to keep
+ The function of the 'accept mutex' (as this inter-process lock is called) is to keep
  request reception moving along in an orderly fashion. If the lock is absent, the
  server may exhibit the Thundering Herd syndrome.
  
- Consider an American Football team1 poised on the line of scrimmage. If
+ Consider an American Football team poised on the line of scrimmage. If
  the football players were Apache processes all team members would go for the
  ball simultaneously at the snap. One process would get it, and all the others
  would have to lumber back to the line for the next snap. In this metaphor, the
@@ -493, +539 @@

  avoid internal conflicts.
  
  You can manipulate the accept mutex with the `AcceptMutex` directive. Be-
- sides turning the accept mutex off, you can select the locking mechanism. Com-
+ sides turning the accept mutex off, you can select the locking mechanism. Common
- mon locking mechanisms include fcntl, System V Semaphores and pthread lock-
+ locking mechanisms include fcntl, System V Semaphores and pthread locking.
- ing. Not all are available on every platform, and their availability also depends
+ Not all are available on every platform, and their availability also depends
  on compile-time settings. The various locking mechanisms may place specific
  demands on system resources: manipulate them with care.
  
- There is no compelling reason to disable the accept mutex. Apache auto-
+ There is no compelling reason to disable the accept mutex. Apache automatically
- matically recognizes the single listener situation described above and knows if
+ recognizes the single listener situation described above and knows if
  it is safe to run without mutex on your platform.
  
  == Tuning the Operating System ==
- People often look for the ‘magic tune-up’ that will make their system perform
+ People often look for the 'magic tune-up' that will make their system perform
  four times as fast by tweaking just one little setting. The truth is, present-day
  UNIX derivatives are pretty well adjusted straight out of the box and there is
  not a lot that needs to be done to make them perform optimally. However,
  there are a few things that an administrator can do to improve performance.
  
  === RAM and Swap Space ==
- The usual mantra regarding RAM is “more is better”. As discussed above, unused
+ The usual mantra regarding RAM is "more is better". As discussed above, unused
  RAM is put to good use as file system cache. The Apache processes get
  bigger if you load more modules, especially if you use modules that generate
  dynamic page content within the processes, like PHP and mod perl. A large
- configuration file–with many virtual hosts–also tends to inflate the process footprint.
+ configuration file-with many virtual hosts-also tends to inflate the process footprint.
- Finally, Apache 2.0 processes tend to have larger footprints than those
- of Apache 1.3. Having ample RAM allows you to run Apache with more child
+ Having ample RAM allows you to run Apache with more child
  processes, which allows the server to process more concurrent requests.
  
  While the various platforms treat their virtual memory in different ways, it
@@ -607, +652 @@

  {{{
  sysdef -i | grep maximum
  }}}
- but it is not recommanded to change them.
+ but it is not recommended to change them.
  
  
  === Turn Off Unused Services and Modules ===
@@ -621, +666 @@

  and disable them respectively.
  
  In a similar fashion, cast a critical eye on the Apache modules you load. Most
- binary distributions of Apache, and pre-installed versions that come with Linux
+ binary distributions of Apache httpd, and pre-installed versions that come with Linux
  distributions, have their modules enabled through the `LoadModule` directive.
  
- A notable exception is the Apache httpd on Cobalt Raq servers, which has
- mod_perl compiled statically to run the GUI–despite the fact that the GUI
- Apache is running as an entirely different process from the one doing the actual
- serving. You cannot disable this instance of mod_perl. Other modules,
- however, may be culled: if you don’t use their functionality and configuration
+ Unused modules may be culled: if you don't rely on their functionality and configuration
  directives, you can turn them off by commenting out the corresponding `LoadModule`
- lines. Read the documentation18 on each module’s functionality before
+ lines. Read the documentation on each module’s functionality before
  deciding whether to keep it enabled. While the performance overhead of an
  unused module is small, it's also unnecessary.
  
  = Caching Content =
  Requests for dynamically generated content usually take significantly more resources
  than requests for static content. Static content consists of simple filespages,
- images, etc.–on disk that are very efficiently served. On platforms that
+ images, etc.-on disk that are very efficiently served. Many operating systems also
- support it, Apache uses the `sendfile(2)` system call to instruct the operating
- system kernel to transfer the contents of requested files directly to network
- sockets. The server does not need to read or inspect the contents of the files
- which makes this a very efficient operation. Many operating systems also auto-
- matically cache the contents of frequently accessed files in memory.
+ automatically cache the contents of frequently accessed files in memory.
  
  Processing dynamic requests, on the contrary, can be much more involved.
  Running CGI scripts, handing off requests to an external application server and
@@ -663, +700 @@

  substitutions.
  
  === Example: A Statically Rendered Blog ===
+ 
+ ''''we should provide a more useful example here. One showing how to make
+ Wordpress or Drupal suck less.''''
+ 
- Blosxom19 is a lightweight web log package that runs as a CGI. It is written in
+ Blosxom is a lightweight web log package that runs as a CGI. It is written in
  Perl and uses plain text files for entry input. Besides running as CGI, Blosxom
  can be run from the command line to pre-render blog pages. Pre-rendering
  pages to static HTML can yield a significant performance boost in the event
@@ -731, +772 @@

  content requirements that are part of the HTTP specification. The mod cache
  module caches URL response content. If content sent to the client is considered
  cacheable, it is saved to disk. Subsequent requests for that URL will be served
- directly from the cache. The provider module for mod cache, mod mem cache or
+ directly from the cache. The provider module for mod_cache, mod_disk_cache,
- mod disk cache, determines whether the cached content is stored on disk or in
- memory. Most server systems will have more disk available than memory, and
- it's good to note that some operating system kernels cache frequently accessed
- disk content transparently in memory.
+ determines how the cached content is stored on disk. Most server systems will
+ have more disk available than memory, and it's good to note that some operating
+ system kernels cache frequently accessed disk content transparently in memory,
+ so replicating this in the server is not very useful.
  
  To enable efficient content caching and avoid presenting the user with stale
  or invalid content, the application that generates the actual content has to send
- the correct response headers. Without headers like Etag:, Last-Modified: or
+ the correct response headers. Without headers like `Etag:`, `Last-Modified:` or
- Expires:, mod cache can not make the right decision on whether to cache the
+ `Expires:`, mod_cache can not make the right decision on whether to cache the
  content, serve it from cache or leave it alone. When testing content caching,
  you may find that you need to modify your application or, if this is impossible,
  selectively disable caching for URLs that cause problems. The mod cache
  modules are not compiled by default, but can be enabled by passing the option
  `--enable-cache[=shared]` to the configure script. If you use a binary distribution
- of Apache, or it came with your port or package collection, it may have
+ of Apache httpd, or it came with your port or package collection, it may have
- mod cache already included.
+ mod_cache already included.
  
  === Example: wiki.apache.org ===
+ 
+ ''''Is this still the case? Maybe we should give a better example here too.'''
+ 
  The Apache Software Foundation Wiki is served by MoinMoin. MoinMoin
  is written in Python and runs as a CGI. To date, any attempts to run it under
  mod_python has been unsuccessful. The CGI proved to place an untenably
  high load on the server machine, especially when the Wiki was being indexed
  by search engines like Google. To lighten the load on the server machine, the
- Apache Infrastructure team turned to mod cache. It turned out MoinMoin
+ Apache Infrastructure team turned to mod_cache. It turned out MoinMoin
- needed a small patch to ensure proper behaviour behind the caching server:
+ needed a small patch to ensure proper behavior behind the caching server:
  certain requests can never be cached and the corresponding Python modules
  were patched to send the proper HTTP response headers. After this modification,
  the cache in front of the Wiki was enabled with the following configuration
@@ -774, +818 @@

  
  This configuration will try to cache any and all content within its virtual
  host. It will never cache content for more than six hours (the `CacheMaxExpire`
- directive). If no Expires: header is present in the response, mod cache will
+ directive). If no `Expires:` header is present in the response, mod_cache will
- compute an expiration period from the Last-Modified header. The computation
+ compute an expiration period from the `Last-Modified:` header. The computation
  using `CacheLastModifiedFactor` is based on the assumption that if a
  page was recently modified, it is likely to change again in the near future and
- will have to be re-cached. Please see the mod cache documentation for more
+ will have to be re-cached. Please see the mod_cache documentation for more
  information on using this module.
  

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


Mime
View raw message