adamarc, I have certainly not found your assertions in post #2 to be at all correct.   (DBCS, persistence, or heavy refactoring).   Indeed, I have successfully replaced mod_perl with Plack and found the process to be both quite straightforward and more efficient and versatile on today’s typical hardware configs.   Although some sites are guilty of “voodoo mod_perl coding” in an effort to squeeze the hardware a little harder, I have found that most conversions were almost “drop-in replacement.”

Today, the biggest problem with mod_perl, IMHO, is precisely the result of how it was designed:   to embed the Perl interpreter that is running the web site, directly into the Apache service process that received the request.   Many companies do not want the web-server that is “out there on the front line” to actually be the one that’s doing the work:   they want there to be a FastCGI server somewhere else that, through a very tight firewall, VPN, etc., is actually responsible for evaluating the inputs and generating the response.   Load balancers and so-forth can distribute the workload, even distributing different requests to different FastCGI server-banks depending, say, on a portion of the URL.   The number of FastCGI providers might not equal the number of Apache processes.

FastCGI service-processes do remain persistent (until they periodically commit hari-kiri), and therefore can and usually do maintain persistent database connections.   They become what you think of as being “the service providers,” while the (continually light-weight) Apache service processes are “the front-end interface providers.”   The FastCGI servers are more-trusted; the Apache servers, not much at all.

In today’s environments of blade-servers arranged in “defense in depth,” I suggest that FastCGI / Plack is a better approach now, and I also suggest that the amount of work that you will actually incur to convert most applications is quite manageable.