KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 15
you have a real performance penalty, since after completing the processing for each request, the process will wait for KeepAliveTimeout seconds before closing the connection and will therefore not be serving other requests during this time. With this configuration you will need many more concurrent processes on a server with high traffic.
If you use the mod_status or Apache::VMonitor server status reporting tools, you will see a process in K state when it's in KeepAlive state.
You will probably want to switch this feature off:
The other two directives don't matter if KeepAlive is Off.
However, you might consider enabling KeepAlive if the client's browser needs to request more than one object from your mod_perl server for a single HTML page. If this is the situation, by setting KeepAlive On, for every object rendered in the HTML page on the client's browser you save the HTTP connection overhead for all requests but the first one.
For example, if the only thing your mod_perl server does is process ads, and each of your pages has 10 or more banner ads (which is not uncommon today), your server will work more efficiently if a single process serves them all during a single connection. However, your client will see a slightly slower response, since the banners will be brought one at a time and not concurrently, as is the case if each <img> tag opens a separate connection.
SSL connections benefit the most from KeepAlive if you don't configure the server to cache session IDs. See the mod_ssl documentation for how to do this.
You have probably followed our advice to send all the requests for static objects to a plain Apache (proxy/accelerator) server. Since most pages include more than one unique static image, you should keep the default KeepAlive setting of the non-mod_perl server (i.e., keep it On). It will probably also be a good idea to reduce the KeepAliveTimeout to 1 or 2 seconds—a client is going to send a new request on the KeepAlive connection immediately, and the first bits of the request should reach the server within this limit, so wait only for the maximum latency of a modem connection plus a little bit more.
Another option is for the proxy/accelerator to keep the connection open to the client but make individual connections to the server, read the responses, buffer them for sending to the client, and close the server connection. Obviously, you would make new connections to the server as required by the client's requests.