[articles] [home]
Title:Apache module mod_accel
Author:Igor Sysoev
Date:Jan 27, 2002
Version:1.0.11
Translation:Danil Pismenny

Apache module mod_accel

Content:

Description
Installation
Dynamic loading
How does it work
When is the response retrieved from the cache?
Busy Locks
Limiting request numbers
Basic load balancing and failover
How is being response cached???
Notes that used to module control
How to work with cokies
What can be written to log
Cache clearing
Directives
AccelAddVia directive
AccelAddXForwardedFor directive
AccelBkRcvBuffSize directive
AccelBkRcvSockBuffSize directive
AccelBusyLock directive
AccelCacheCookie directive
AccelCacheRoot directive
AccelCacheSendSize directive
AccelClean directive
AccelCleanLastAccessed directive
AccelContentTail directive
AccelDefaultExpire directive
AccelIgnoreAuth directive
AccelIgnoreExpires directive
AccelIgnoreNoCache directive
AccelInvalidate directive
AccelLastModifiedFactor directive
AccelMaxStale directive
AccelNoCache directive
AccelNoPass directive
AccelPass directive
AccelPassCookie directive
AccelRequestBuffSize directive
AccelRevalidateUser directive
AccelReverse directive
AccelSendSize directive
AccelSetXHost directive
AccelSetXRealIP directive
AccelSetXURL directive
AccelTimeout directive
AccelUnlinkNoCached directive
AccelWaitBeforeBodyRead directive
Bugs and features
Cache manager
Module mod_randban
RandomBanner directive
Module mod_quoted
RecodeQuoted directive
Co-operation with mod_rewrite module
Performance Tuning
How does mod_proxy interact with backend
[articles] [home]
Title:Apache module mod_accel
Author:Igor Sysoev
Date:Jan 27, 2002
Version:1.0.11
Translation:Danil Pismenny

Apache module mod_accel

Content:

Description
Installation
Dynamic loading
How does it work
When is the response retrieved from the cache?
Busy Locks
Limiting request numbers
Basic load balancing and failover
How is being response cached???
Notes that used to module control
How to work with cokies
What can be written to log
Cache clearing
Directives
AccelAddVia directive
AccelAddXForwardedFor directive
AccelBkRcvBuffSize directive
AccelBkRcvSockBuffSize directive
AccelBusyLock directive
AccelCacheCookie directive
AccelCacheRoot directive
AccelCacheSendSize directive
AccelClean directive
AccelCleanLastAccessed directive
AccelContentTail directive
AccelDefaultExpire directive
AccelIgnoreAuth directive
AccelIgnoreExpires directive
AccelIgnoreNoCache directive
AccelInvalidate directive
AccelLastModifiedFactor directive
AccelMaxStale directive
AccelNoCache directive
AccelNoPass directive
AccelPass directive
AccelPassCookie directive
AccelRequestBuffSize directive
AccelRevalidateUser directive
AccelReverse directive
AccelSendSize directive
AccelSetXHost directive
AccelSetXRealIP directive
AccelSetXURL directive
AccelTimeout directive
AccelUnlinkNoCached directive
AccelWaitBeforeBodyRead directive
Bugs and features
Cache manager
Module mod_randban
RandomBanner directive
Module mod_quoted
RecodeQuoted directive
Co-operation with mod_rewrite module
Performance Tuning
How does mod_proxy interact with backend

Description

The mod_accel module provides an accelerator for an Apache server by using a second Apache server to cache responses from the first. Danil: I thought we said it could be a different server? -- Ged. I'm confused. I get this sentence from our ”orrespondence -- Danil. That is to say it provides a ProxyPass functional similar to the mod_proxy module. Unlike mod_proxy, it interacts with the backend server correctly (see below), it takes cookies into account when caching, it uses busy locks and limits the number of connections to the backend. It can log the results of its work. Its responses can be recoded by Russian Apache and they can be compressed by the mod_deflate module.

The mod_accel module doesn't work in the usual proxy-server mode like mod_proxy. Used in that way there is no reason to prefer Apache over Squid or Oops. Apache has advantages over Squid or Oops when used in acceleration mode. The main reason is that Apache can handle non-proxied content while Squid and Oops can proxy only. However, when configuring mod_proxy for accelerator mode users often set 'ProxyRequests on' when it is not necessary. This mistake allows standard proxying and opens a new public proxy-server to abuse, which is probably not what was intended.

Mod_accel uses the Apache EAPI and a set of patches for Apache, mod_proxy, mod_rewrite, mod_ssl and mod_charset modules (for the Russian Apache). The distribution contains two modules that modify the body of the response which is passed - mod_randban and mod_quoted. The first one changes a random URL`s value for banner execution and the second one decodes Russian symbols in constructions like <a href="/show?%80%81%82">

Installation

Expand the package, go to its directory and run ./configure, specifying the path of the Apache and EAPI source trees. Run make to build:

tar zxf mode_accel-x.x.x.tar.gz
cd mod_accel-x.x.x
./configure
    --with-apache=<apache_dir>
    --with-eapi=<eapi_dir>
make
EAPI sources are available in the mod_ssl distribution. It is not necessary to install mod_ssl.
./configure
    --with-apache=../apache_1.3.20
    --with-eapi=../mode_ssl-2.8.4-1.3.20/pkg.eapi
You should not specify the --with-eapi parameter if you want to build Apache with mod_ssl because mod_ssl itself does that.

If you have to use the mod_charset and mod_ssl modules, make sure that they have already been installed before you configure mod_accel because they must be patched by the mod_accel installation. It is recomended to install mod_ssl in the manner described in section "The flexible APACI-only way [FOR REAL HACKERS]" of the INSTALL file from the mod_ssl distribution.

You can use a few other parameters for configuring:

  • --with-mod_randban - install the source of mod_randban to the directory <apache_dir>/src/modules/extra/;
  • --with-mod_quoted - install the source of mod_quoted to the directory <apache_dir>/src/modules/extra/;
  • --without-mod_rewrite - don't patch mod_rewrite;
  • --without-cachemgr - don't build cachemgr. Since version 1.0.2;
  • --with-patch=<path_to_patch> - use the specified program instead of patch. The parameter has appearanced in 1.0.7 version.

Parameters --without-mod_charset and --without-mod_ssl are not supported since version 1.0.7.

make patches the Apache sources and the mod_proxy, mod_rewrite, mod_charset and mod_ssl modules, it will install Apache EAPI if it is necessary and copies mod_accel's sources to the directory <apache_dir>/src/modules/accel/. Moreover, if the additional modules mod_randban or mod_quoted are selected, they will be copied to the directory <apache_dir>/src/modules/extra/.

If you want to use busy locks and limit the numbers of connections and waiting process, you must install the mm library (it is available at http://www.engelschall.com/sw/mm/):

tar zxf mm-1.1.3.tar.gz
cd mm-1.1.3
./configure --disable-shared
make
Use parameter --disable-shared to build static library. If you want to build it shared, you should install it by make install

If you use the mm library, it is necessary to activate modules EAPI and EAPI_MM during the Apache configuration.:

cd <apache_dir>
EAPI_MM=<mm_dir>
./configure
    ...
    --enable-rule=EAPI
    --activate-module=src/modules/extra/mod_randban.o
    --activate-module=src/modules/extra/mod_quoted.o
    --activate-module=src/modules/accel/libaccel.a
    ...
If you use version 1.0.7 or later of mod_accel the order of modules activation is not important. Before version 1.0.7 the mod_accel module must be activated after the mod_quoted and mod_randban modules. If the mm library is built shared, the variable EAPI_MM will have this value:
EAPI_MM=SYSTEM

You should create the directory which will contain the cache and temporary files when Apache is installed. The user who starts Apache must have read and write permissions for this directory. This directory is specified by the AccelCacheRoot, for example:

AccelCacheRoot  cache

Dynamic loading

You can build mod_perl to use the Dynamic Shared Object (DSO) mechanism, which allows Apache to load modules on-demand at run-time. Since version 1.0.7 of mod_accel the order of loading doesn't matter.

Before version 1.0.7, as in the case of a static build, the mod_accel module must be selected after mod_quoted and mod_randban modules:

LoadModule  randban_module  modules/mod_randban.so
LoadModule  quoted_module   modules/mod_quoted.so
LoadModule  accel_module    modules/libaccel.so
If mod_ssl is loaded by DSO too, before version 1.0.7 it must be loaded before mod_accel. (It doesn't matter after version 1.0.7):
LoadModule  ssl_module      modules/libssl.so
LoadModule  accel_module    modules/libaccel.so

How does it work

In the URI translation phase mod_accel compares the URI head and prefixes specified by the directivies list AccelPass. If it is the same, it will look at the list of directivies AccelNoPass. If this list doesn't contain a prefix or regexp corresponding to the current URI then accel-handler will be used as the handler for this request which will redirect it to another server. For example, this directive

AccelPass      /test/       http://backend/test/
will translate the URI http://frontend/test/one.cgi?test=1 to http://backend/test/one.cgi?test=1.

If the request's result can be cached, mod_accel looks for a cached one. The key used for caching is the result of an md5 hash function which gets the transformed URL as an argument. It is "http://backend/test/one.cgi?test=1" in our example. If the result is found in the cache, it is loaded by blocks, the size of which is specified by the AccelCacheSendSize directive, and is sent to the client.

If there is no result in the chache, or the result is expired, or it is not cachable, the request will be passed to the backend. If the request has a body (for example, method POST), it is written to a buffer, the size of which is specified by the AccelRequestBuffSize directive. If the body size is larger than the buffer size, it will be saved to a temporary file. mod_accel checks busy locks, the number of connections and the number of waiting process before connecting to the backend (or some of them), it passes on the request and loads the reply header. The backends and clients sockets are moved to unblockable mode and the reply header is sent to the client. Then mod_accel sends the reply body to the reply receive buffer, which is sized by the AccelBkRcvBuffSize directive. It will create a temporary file and write the buffer contents to it if the buffer is filled. The reply is sent to the client in blocks, the size of which is specified by the AccelSendSize directive.

While a relpy is transfered to the client it can be modified by a module chain, for example by the modules mod_randban and mod_quoted.

When the backend's response has been received completely, the backend's socket is closed but the client's socket is moved to blockable mode. Then the response can be cached and used by other Apache processes.

When is the response retrieved from the cache?

Before a request is passed to the backend, mod_accel looks for a cached one. It works in this way:

  • If the AccelNoCache directive is active or the request method is not GET or HEAD then it is passed to the backend and the accel_st note is set to PASS.
  • If the accel_nocache note is set then request is passed to the backend and the accel_st note is set to NTNC.
  • Next it checks the Authorization header. If the AccelIgnoreAuth and AccelRevalidateUser directives are not active then a request with Authorization header is sent to the backend. mod_accel's note accel_st is set to AUTH in this stage.

If the previous tests are passed then the request's response can be cached.

  • Further, if the AccelInvalidate directive is active then the URL's tail is checked for the string specified by the AccelInvalidate directive. If found then any cached response for that request is considered to be invalid, so the request is passed to the backend and accel_st is set to INVL.
  • If the AccelIgnoreNoCache directive is not active and there is one of Pragma: no-cache, Cache-Control: no-cache and Cache-Control: max-age=0 in the header then request is passed to the backend and accel_st is set to PGNC.
  • Then the cache is searched for a response. If it is not found, mod_accel checks for busy locks and the number of backend connection and waiting processes. If the response is not processed by another process, and the connections and the number of waiting processes has not reach maximum, then the request is passed to the backend and the accel_st note is set to MISS.
  • If the response is found in the cache and the AccelIgnoreNoCache directive is not active then it checks the headers line "Cache-Control: max-age=<number>", which limits the time of life in the cache. If the response has reached this limit then after it checks for busy locks, backend connections and waiting processes the request is passed to the backend and accel_st is set to AGED.
  • If the AccelRevalidateUser directive is active, the request is passed to the backend and accel_st is set to RVUS.
  • If a cached response is expired, then it checks busy locks, backend connections and waiting processes, the request is passed to the backend and accel_st is set to EXPR.
  • If you have expired content in the cache but the backend is busy (the are too many connections to it) mod_accel returns the expired cached content and the accel_st note is set to HIT.

If a cached request's response exists, but it is expired, then the header line If-Modified-Since is added to the backend request. If the backend returns 304 (HTTP_NOT_MODIFIED), the cache content is reborn in confirmity with response headers and the cached response is sent to client.

If the response to the client's request could not be completed by the proxy, for example the request's header contains If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match or the request is for a byte-range response; and if also there is no cached response (but a response can be cached) then these headers are deleted from the request to the backend so that mod_accel may receive a complete response and cache it. Danil: I am not sure I understood this sentence. -- Ged. Try this. -- Danil. The client receives requested byte-range or the 304 (HTTP_NOT_MODIFIED) response in the case the request contains If-Modified-Since header and the response is not changed.

This concerns HEAD requests too. If there is no cached response and it is cachable, mod_accel does a GET request to the backend for a complete response and, perhaps, caches it. The client receives the response header only.

Busy Locks

Before a request is passed to the backend, mod_accel checks for busy locks, the number of backend connections and the number of waiting processes. A busy lock won't allow a cachable request to be passed to the backend if exactly same request is already being processed by the backend. A busy lock is set by the AccelBusyLock directive and ensures that, for the specified time after the request to the backend was initiated, only one Apache process will send this request. If there is a cached but expired response and it has been expired for a time less than value set by the AccelMaxStale directive then all other processes send this expired response from the cache. Otherwise all other processes running the same request wait for the response requested by the first process, or wait for this process's busy lock time to elapse. The AccelBusyLock directive accepts three values. The first value is used if either there is no cached response or it has expired by a time greater than the value of the AccelMaxStale directive. The second value is used if a cached response has expired by less than the value of the previous directive. It is recommended to set this value greater than the first. The third value is the maximum time a process can live with a busy lock, since the process could be forced to wait for several successive busy locks.

Let us assume a set of parameters:

AccelBusyLock   10 15
AccelMaxStale   60
The following illustrates the logic for it:

  • 00:00. The request is received and the cashe doesn't contain a response for it. Since there is no process that has processed the same request it is passed to the backend and its busy lock is set to 00:10 (this is the first argument of AccelBusyLock).
  • 00:04. The second request is received. Since the first request is being processed, the process that received the second request waits for the busy lock to be unlocked or for a cached response to appear.
  • 00:07. The third request is received. Since the first request is being processed, the process that received the third request waits for the busy lock to be unlocked or for a cached response to appear, as the second process.
  • 00:10. Since the busy lock of the first process is elapsed, a process, let's assume that it is the third one, sets another busy lock and passes the request to the backend. The second process waits as before for the new busy lock to be unlocked or for a cached respone to appear. It's important to note that one waiting process only can set yet another busy lock since the busy lock is elapsed.
  • 00:12. The first process receives the response and stores it to the cache. The request's accel note will be set to MISS/-/0/- 200/CTL/300 12 .... This means that there is now a response in the cache and it has been received from the backend without waiting in the busy lock state. The code of the backend's response is 200 (HTTP_OK), the response is cachable, the time for caching is specified in the Cache-Control header and it is 300 seconds (CTL/300), the backend was processing the request for 12 seconds. The second process will see the response in the cache within one second of the receipt of the response. The accel note of the second request will be HIT/-/8/- HIT/-/-- .... This means that the process received the response from the cache after waiting for 8 seconds (00:04-00:12) in the busy lock state.
  • 00:23. The third process received and recached the response. The accel note will be MISS/-/3/- 200/CTL/300 13 .... This means that the process was waiting for 3 seconds, then it passed the request to the backend, the response of the backend is 200 (HTTP_OK), the response it cachable, the time of caching is specified in the Cache-Control header and it is 300 seconds, the backend was processing the request for 13 seconds. It is important to note that the cached response can be transfered and stored to the cache by a number of processes at the same time. Igor, please, compare it to russian version. I think it is not good for russian too.
  • 03:10. A fourth request is received. So far as the response isn't obsolete, so it is sent from the cache. The accel note will be HIT/-/-/- HIT/-/-- .... This means that the response was retreived from the cache.
  • 06:16. A fifth request is received. Since the request was expired at 05:23 and no other process is processing same request, then the process sets a busy lock and passes the request to the backend
  • 06:20. A sixth request arrives. The response is expired, but it is not very old (AccelMaxStale is 60 seconds, that is to say the response will be totally expired at 06:23). Therefore, because the same request is being processed and its busy lock will elapse at 06:31 (the second value of AccelBusyLock is 15 seconds), then the response is retrieved from the cacne and the accel note is set to HIT/57/0/U HIT/-/-- .... This means that although the response is expired for 57 seconds (05:23-06:20), but as the request is being processed at this moment ("U") the response is retrieved from the cache without waiting in the busy lock state.
  • 06:24. A seventh request is arrived. The response is totally expired, but the same request is being processed and the busy lock for the seventh request will be up at 06:26 (for the responses that are expired more than the time set by the AccelMaxStale directive, the first value of the AccelBusyLock'Ń directive is used. It is 10 seconds in our case), then the process waits for the busy lock to be unlocked or for a cached response to appear.
  • 06:25. The process that processes the fifth request receives the response from the backend and caches it. The accel note is set to EXPR/53/0/- 200/CTL/300 13 .... It means that the response is expired for 53 seconds (05:23-06:16) and the response has been received from the backend without waiting in the busy lock state, the code of the backend's response is 200 (HTTP_OK), the response is cachable, caching time is set in the Cache-Control header and it is 300 seconds, the backend was processing the request for 13 seconds. The process that processes the seventh request will see a cached response and will begin to send the response to the client within one second from this moment. The accel note is set to HIT/61/1/N HIT/-/-- .... It means that the response is expired for 61 seconds (05:23-06:24), the process was waiting for one second (06:24-06:25) in the busy lock state and the process gave the renewed response from the cache.

Limiting request numbers

Busy locks are used to reduce the loading of the backend. There are possible situations when the backend is processing the requests, other requests are coming, but the backend doen't have time to process them. In this case the processes of the frontend that are processing new requests either wait for the response from the backend, or try to connect to the backend, or wait in the busy lock state. The number of frontend process can then reach the maximum (MaxClients), and if the frontend must serve requests besides proxying then these requests will not be served. In this way an overloaded backend can cause some other resource to be not available. To avoid this situation you can set the flags MC and MW to the AccelPass directive, which allows you to limit the number of connections to the backend and the number of proceses waiting for busy locks. If the maximum is reached and the cache contains the response to the request then the cached response is sent irrespective of expiration. If the cache doesn't contain the response then the reponse 503 (HTTP_SERVICE_UNAVAILABLE) is returned. I don't understand this sentence -- Ged. How about this? -- Danil. Besides, such flags can be used in the RewriteRule directive of the mod_rewrite module, if the mod_accel module is not configured with the --without-mod_rewrite parameter.

Basic load balancing and failover

Basic load balancing and failover can be realiased with the DNS when the symbolic name is mapped to several IP addresses. Note that setting alternative IP addresses in the /etc/hosts file is not effective - the hosts file isn't used by the DNS server and is used for local name resolution only. In addition the AccelPass directive must have the NR flag set to forbid definition of the IP-address of the backend. In this case the frontend must resolve an IP-address of the backend on every connection, and then connect to one of them. I don't understand this sentence. -- Ged. Ohh. This is hardest sentence I have seen here. Next attempt. -- Danil. To generate hash key, mod_accel uses URL that (URL) have the local prefix I don't know what it is replaced to the proxied without resolution of IP-address. That is why mod_accel think that the responses of the different backends to the same requests are identical. If the response from the one server is cached then it is sent to the client until it is not expired. The busy locks and the limits of connection work this way too. That is to say the backends group is consider as one backend.

The end of translation!!!

How is being response cached???

  • Expires = (Date - LastModified) * AccelLastModifiedFactor / 100
    

Notes that used to module control

How to work with cokies

What can be written to log

Cache clearing

Directives

AccelAddVia directive

syntax: AccelAddVia on|off
default: AccelAddVia off
context: server config, virtual host, location, files

AccelAddXForwardedFor directive

syntax: AccelAddXForwardedFor on|off
default: AccelAddXForwardedFor off
context: server config, virtual host, location, files

AccelBkRcvBuffSize directive

syntax: AccelBkRcvBuffSize size
default: AccelBkRcvBuffSize 16
context: server config, virtual host, location, files

AccelBkRcvSockBuffSize directive

syntax: AccelBkRcvSockBuffSize size
default: AccelBkRcvSockBuffSize 0
context: server config, virtual host, location, files

AccelBusyLock directive

syntax: AccelBusyLock "time" ["time" ["time"]]
default: AccelBusyLock 0 0 AccelTimeout
context: server config, virtual host, location, files

AccelCacheCookie directive

syntax: AccelCacheCookie off|all|[!]string|[!]~[*]regexp
default: AccelCacheCookie off
context: server config, virtual host, location, files
compatibility: mod_accel 1.0.2 and above

AccelCacheRoot directive

syntax: AccelCacheRoot path [1|2 [1|2 [1|2]]] [noauto]
default: AccelCacheRoot none 1 2
context: server config

Directive sets directory with cache and temporary files. Whole cache must be resided on single disk partition because temporary files is moved to cache by link() operation. If path is not absolute then it is assumed to be relative to the ServerRoot. NOT READY For example

AccelCacheRoot /var/cache 1 1 noauto
sets cache in /var/cache directory, number of levels to 2, both level subdirectories would be named 0 .. f and these directories is not needed to make automatically.

AccelCacheSendSize directive

syntax: AccelCacheSendSize size
default: AccelCacheSendSize 8
context: server config, virtual host, location, files

AccelClean directive

syntax: AccelClean "[@] time"
default: AccelClean "1 hour"
context: server config

AccelCleanLastAccessed directive

syntax: AccelCleanLastAccessed "time"
default: AccelCleanLastAccessed "24 hours"
context: server config

AccelContentTail directive

syntax: AccelContentTail length
default: AccelContentTail 32
context: server config

AccelDefaultExpire directive

syntax: AccelDefaultExpire "time"
default: AccelDefaultExpire 0
context: server config, virtual host, location, files

AccelIgnoreAuth directive

syntax: AccelIgnoreAuth on|off
default: AccelIgnoreAuth off
context: server config, virtual host, location, files
compatibility: mod_accel 1.0.5 and above

AccelIgnoreExpires directive

syntax: AccelIgnoreExpires on|off
default: AccelIgnoreExpires off
context: server config, virtual host, location, files

AccelIgnoreNoCache directive

syntax: AccelIgnoreNoCache on|off
default: AccelIgnoreNoCache off
context: server config, virtual host, location, files

AccelInvalidate directive

syntax: AccelInvalidate string|off
default: AccelInvalidate off
context: server config, virtual host, location, files

AccelLastModifiedFactor directive

syntax: AccelLastModifiedFactor number
default: AccelLastModifiedFactor 0
context: server config, virtual host, location, files

AccelMaxStale directive

syntax: AccelMaxStale "time"
default: AccelMaxStale 0
context: server config, virtual host, location, files

AccelNoCache directive

syntax: AccelNoCache on|off
default: AccelNoCache off
context: server config, virtual host, location, files

AccelNoPass directive

syntax: AccelNoPass prefix|~[*]regexp
default: none
context: server config, virtual host

AccelPass directive

syntax: AccelPass prefix url [flags]
default: none
context: server config, virtual host

AccelPassCookie directive

syntax: AccelPassCookie on|off
default: AccelPassCookie off
context: server config, virtual host, location, files

Directive allows or prevents cookie passing to backend if its answer can be cachable. Answers to request with the same URLs can be differ depended on cookie so such answers should not be cached. Hence if

AccelRequestBuffSize directive

syntax: AccelRequestBuffSize
default: AccelRequestBuffSize 8
context: server config, virtual host, location, files

AccelRevalidateUser directive

syntax: AccelRevalidateUser on|off
default: AccelRevalidateUser off
context: server config, virtual host, location, files

AccelReverse directive

syntax: AccelReverse prefix url
default: none
context: server config, virtual host
compatibility: mod_accel 1.0.10 and above

AccelSendSize directive

syntax: AccelSendSize size
default: AccelSendSize 8
context: server config, virtual host, location, files

AccelSetXHost directive

syntax: AccelSetXHost on|off
default: AccelSetXHost off
context: server config, virtual host, location, files

AccelSetXRealIP directive

syntax: AccelSetXRealIP on|off
default: AccelSetXRealIP off
context: server config, virtual host, location, files

AccelSetXURL directive

syntax: AccelSetXURL on|off
default: AccelSetXURL off
context: server config, virtual host, location, files

AccelTimeout directive

syntax: AccelTimeout "time" ["time"]
default: AccelTimeout Timeout Timeout
context: server config, virtual host, location, files

AccelUnlinkNoCached directive

syntax: AccelUnlinkNoCached on|off
default: AccelUnlinkNoCached off
context: server config, virtual host, location, files

AccelWaitBeforeBodyRead directive

syntax: AccelWaitBeforeBodyRead time in milliseconds
default: AccelWaitBeforeBodyRead 0
context: server config, virtual host, location, files

Bugs and features

Cache manager

Module mod_randban

mod_randban module provides for random number generation in answers of mod_accel module.

RandomBanner directive

syntax: RandomBanner on|off|string length
default: none
context: server config, virtual host, location, files
<a href="http://host/path0?place=1&random=rb00000">
<img src="http://host/path1?place=1&random=rb00000">
</a>

<a href="http://host/path0?place=1&key=1234">
<img src="http://host/path1?place=1&key=1234&rand=11111">
</a>

<a href="http://host/path0?place=1&random=rb00000">
<img src="http://host/path1?place=1&random=rb00000">
</a>
<a href="http://host/path0?place=1&random=rb42943">
<img src="http://host/path1?place=1&random=rb42943">
</a>

<a href="http://host/path0?place=1&key=1234">
<img src="http://host/path1?place=1&key=1234&rand=31520">
</a>

<a href="http://host/path0?place=1&random=rb06172">
<img src="http://host/path1?place=1&random=rb06172">
</a>

Module mod_quoted

RecodeQuoted directive

syntax: RecodeQuoted on|off
default: off
context: server config, virtual host, location, files

Co-operation with mod_rewrite module

Performance Tuning

How does mod_proxy interact with backend