All of the zero-copy design elements of httpd are expanded on within mod_perl in an ithread context. All of those performance optimizations are lost when you bury them behind a mod_proxy gateway to your application server running prefork. Moreover, your scaling model for your application server is a disaster from a resource management perspective, because you are latency bound by all of those system calls that copy data between your servers. Typically you will run an app server with 5-10x the number of vCPU on the host, because of the context switch bottleneck you can't avoid.
mod_perl with mpm_event is designed to be tightly integrated with the rest of httpd. For example I have my outbound mod_perl filter stack loaded up with compression and SSI. I also can dynamically add Perl filters to it to do mass-multplexing when I'm interfacing over sockets with my markdown.js node service. Again full zero-copy OOTB. I don't have any context-switches to deal with once mod_perl has hooked an interpreter into my modperl response handler invocation, so I don't need all the wasted overhead involved in multitiered services. Gimme one ithread per vCPU, that's more I will ever need with an httpd worker process, and send the benchmark concurrency into the thousands just to watch your vCPUs burn through the Perl op trees.
