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.