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.
