Re: Experience running mod_perl2 with mpm_event on Solaris 11

Joe Schaefer <[email protected]> Fri, 26 Aug 2022 14:41:36 -0400
Newsgroups gmane.comp.apache.mod-perl
Message-ID <CAFQGv+a9a5urQXZykAEx2agd4G_s5qYeV6fc1x58bktf6qX-WA@mail.gmail.com>
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.