mod_annot editor

Annotate Section

Taking advantage of Apache 2

With Apache 2 and threaded MPMs, a wider range of altogether more efficient and scalable options present themselves. Starting from what we already have, we can list our options:

  • Classic CGI: one connection per request.
  • Classic LAMP: one persistent connection per thread.
  • Alternative LAMP: one persistent connection per process, with a mechanism for a thread to take and lock it.
  • Connection Pooling: more than one connection per process, but fewer than one per thread, with a mechanism for a thread to take and lock a connection from the pool.
  • Dynamic Connection Pooling: a variable-size connection pool, that will grow or shrink according to actual database traffic levels.

Looking at these in order, we can see the advantages and drawbacks of each option. We have already dealt with the first two.

The third dispenses with the LAMP overhead at the cost of preventing parallel accesses to the backend. It may be an efficient solution in some cases, but clearly presents its own problems with servicing concurrent requests.

The fourth and fifth present an optimal solution whose scalability is limited only by the available hardware and operating system. The number of backend connections to threads should reflect the proportion of the total traffic that requires the backend. So, in simple terms, if one in every five requests to the webserver requires the database, then a pool might have one connection per five threads. Just as Apache itself maintains a dynamic pool of threads to service incoming HTTP connections, so the optimal solution to managing backend connections is a dynamic pool whose size is driven by actual demand rather than best-guess configuration.