Re: Experience running mod_perl2 with mpm_event on Solaris 11
I have a v4.0.0 beta for sealed.pm that I expect will be fully operational with mod_perl+ithreads now, but I will let it soak for a week to see what happens in prod. On Fri, Aug 26, 2022 at 3:30 PM Joe Schaefer wrote: > You're welcome. Pardon my rudeness, but you will understand when I tell > you that I developed sealed.pm after proving ithreads are solid on > Solaris over 2 years ago, and communicated with the Perl5 community on FB > and LI about the same thing I did here last week. There is considerable > racism and dysfunction around the whole ithread effort involving p5p, and > that is plainly evident that those prejudices impact this project’s user > base, which is a real shame to see compared with the interest and > excitement around our work 20y ago. > > On Fri, Aug 26, 2022 at 3:23 PM Edward J. Sabol > wrote: > >> On Aug 26, 2022, at 1:16 PM, Joe Schaefer wrote: >> > AFAICT you guys are just too lazy to look. >> >> That came across as rude, Joe. Not all of us are experts at Perl >> internals or track the latest changes to Perl's ithread support and/or >> glibc, and it's generally been accepted in the mod_perl community for years >> that mod_perl only works reliably with mpm_prefork. To the best of my >> recollection, there haven't been any reports of mod_perl working under >> mpm_event prior to your messages about using it on Solaris a couple weeks >> ago. But thank you for sharing your knowledge and experiences. It does seem >> well worth exploring. >> >> Regards, >> Ed >> >> -- > Joe Schaefer, Ph.D. > We only build what you need built. > > 954.253.3732 > > > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: Experience running mod_perl2 with mpm_event on Solaris 11
You're welcome. Pardon my rudeness, but you will understand when I tell you that I developed sealed.pm after proving ithreads are solid on Solaris over 2 years ago, and communicated with the Perl5 community on FB and LI about the same thing I did here last week. There is considerable racism and dysfunction around the whole ithread effort involving p5p, and that is plainly evident that those prejudices impact this project’s user base, which is a real shame to see compared with the interest and excitement around our work 20y ago. On Fri, Aug 26, 2022 at 3:23 PM Edward J. Sabol wrote: > On Aug 26, 2022, at 1:16 PM, Joe Schaefer wrote: > > AFAICT you guys are just too lazy to look. > > That came across as rude, Joe. Not all of us are experts at Perl internals > or track the latest changes to Perl's ithread support and/or glibc, and > it's generally been accepted in the mod_perl community for years that > mod_perl only works reliably with mpm_prefork. To the best of my > recollection, there haven't been any reports of mod_perl working under > mpm_event prior to your messages about using it on Solaris a couple weeks > ago. But thank you for sharing your knowledge and experiences. It does seem > well worth exploring. > > Regards, > Ed > > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: Experience running mod_perl2 with mpm_event on Solaris 11
On Aug 26, 2022, at 1:16 PM, Joe Schaefer wrote: > AFAICT you guys are just too lazy to look. That came across as rude, Joe. Not all of us are experts at Perl internals or track the latest changes to Perl's ithread support and/or glibc, and it's generally been accepted in the mod_perl community for years that mod_perl only works reliably with mpm_prefork. To the best of my recollection, there haven't been any reports of mod_perl working under mpm_event prior to your messages about using it on Solaris a couple weeks ago. But thank you for sharing your knowledge and experiences. It does seem well worth exploring. Regards, Ed
Re: Experience running mod_perl2 with mpm_event on Solaris 11
LOL IF YOU THINK THE WAIT FOR ITHREAD SUPPORT WAS A LONG TIME COMING. https://github.com/majorz/apache2-rs/tree/master/src On Fri, Aug 26, 2022 at 2:36 PM John D Groenveld wrote: > In message < > cafqgv+yb4bo3k4_hryccyj7ljsnejrh9hwyjw+9172ybc+q...@mail.gmail.com> > , Joe Schaefer writes: > >The entire collective engineering effort for mod_perl and mod_apreq was to > >ensure our code was thread-safe, both from an httpd context and a Perl > one. > >We achieved that twenty years ago, but have been stuck dealing with the > >fact that ithread engineering within Perl5 itself had a ways to go. > > My WAG is that new application development that requires instrumenting > the Apache httpd request phases is now being coded in Rust. > > John > groenv...@acm.org > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: Experience running mod_perl2 with mpm_event on Solaris 11
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.
Re: Experience running mod_perl2 with mpm_event on Solaris 11
In message , Joe Schaefer writes: >The entire collective engineering effort for mod_perl and mod_apreq was to >ensure our code was thread-safe, both from an httpd context and a Perl one. >We achieved that twenty years ago, but have been stuck dealing with the >fact that ithread engineering within Perl5 itself had a ways to go. My WAG is that new application development that requires instrumenting the Apache httpd request phases is now being coded in Rust. John groenv...@acm.org
Re: Experience running mod_perl2 with mpm_event on Solaris 11
The entire collective engineering effort for mod_perl and mod_apreq was to ensure our code was thread-safe, both from an httpd context and a Perl one. We achieved that twenty years ago, but have been stuck dealing with the fact that ithread engineering within Perl5 itself had a ways to go. What I'm telling this list now is that Perl5 has finally caught up, and we can confidently tell you to familiarize yourself with the entire universe of tooling around ithread pools that is unique to mod_perl, and will blow you away once you are fully versed in how it can be tuned for maximum effect with minimal memory footprint. On Fri, Aug 26, 2022 at 1:49 PM Joe Schaefer wrote: > Why are you still paying attention to mod_perl development, if you don't > even care to use it to full effect? > Running a 2-tiered webserver architecture is anathema to mod_perl. It's > not distinguishable from any other fastcgi thingy out there. > > > On Fri, Aug 26, 2022 at 1:46 PM John D Groenveld > wrote: > >> In message > zhwww5d7fcmmcgpdmxs...@mail.gmail.com> >> , Joe Schaefer writes: >> >Lazy enough never to support HTTP/2? >> >> If HTTP/2 becomes necessary, my lazy first answer is to enable it in my >> mod_proxy front end. >> >> John >> groenv...@acm.org >> > > > -- > Joe Schaefer, Ph.D. > We only build what you need built. > > 954.253.3732 > > > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: Experience running mod_perl2 with mpm_event on Solaris 11
Why are you still paying attention to mod_perl development, if you don't even care to use it to full effect? Running a 2-tiered webserver architecture is anathema to mod_perl. It's not distinguishable from any other fastcgi thingy out there. On Fri, Aug 26, 2022 at 1:46 PM John D Groenveld wrote: > In message zhwww5d7fcmmcgpdmxs...@mail.gmail.com> > , Joe Schaefer writes: > >Lazy enough never to support HTTP/2? > > If HTTP/2 becomes necessary, my lazy first answer is to enable it in my > mod_proxy front end. > > John > groenv...@acm.org > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: Experience running mod_perl2 with mpm_event on Solaris 11
In message , Joe Schaefer writes: >Lazy enough never to support HTTP/2? If HTTP/2 becomes necessary, my lazy first answer is to enable it in my mod_proxy front end. John groenv...@acm.org
Re: Experience running mod_perl2 with mpm_event on Solaris 11
There isn't anything else on the market that will ever touch mod_perl + mpm_event in terms of HTTP/2 performance. And you don't need to ever spin up more ithreads than you have vCPU cores. On Fri, Aug 26, 2022 at 1:36 PM Joe Schaefer wrote: > Lazy enough never to support HTTP/2? > > On Fri, Aug 26, 2022 at 1:32 PM John D Groenveld > wrote: > >> In message < >> cafqgv+btwpyvvup2ewzfn7ruv4sfgdihadh48cm3n8qxpwb...@mail.gmail.com> >> , Joe Schaefer writes: >> >AFAICT you guys are just too lazy to look. Running latest on CPAN with an >> >> Correct. >> mod_perl's make test mostly passes and does not core with mpm_event under >> OmniOS/illumos, FreeBSD, and Void Linux with Musl, but I haven't tested >> my applications because I am lazy and mpm_prefork just works. >> >> John >> groenv...@acm.org >> > > > -- > Joe Schaefer, Ph.D. > We only build what you need built. > > 954.253.3732 > > > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: Experience running mod_perl2 with mpm_event on Solaris 11
Lazy enough never to support HTTP/2? On Fri, Aug 26, 2022 at 1:32 PM John D Groenveld wrote: > In message < > cafqgv+btwpyvvup2ewzfn7ruv4sfgdihadh48cm3n8qxpwb...@mail.gmail.com> > , Joe Schaefer writes: > >AFAICT you guys are just too lazy to look. Running latest on CPAN with an > > Correct. > mod_perl's make test mostly passes and does not core with mpm_event under > OmniOS/illumos, FreeBSD, and Void Linux with Musl, but I haven't tested > my applications because I am lazy and mpm_prefork just works. > > John > groenv...@acm.org > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
Re: Experience running mod_perl2 with mpm_event on Solaris 11
In message , Joe Schaefer writes: >AFAICT you guys are just too lazy to look. Running latest on CPAN with an Correct. mod_perl's make test mostly passes and does not core with mpm_event under OmniOS/illumos, FreeBSD, and Void Linux with Musl, but I haven't tested my applications because I am lazy and mpm_prefork just works. John groenv...@acm.org
Re: Experience running mod_perl2 with mpm_event on Solaris 11
AFAICT you guys are just too lazy to look. Running latest on CPAN with an Ubuntu 22.04 stock httpd and the thing just cranks out the hits. (Not with sealed.pm tho, it will leak scalars and cause crashes with mod_perl and mpm_event). If anybody is to thank for this, thank SawyerX for his Pumpking work on the 5.22+ line. On Wed, Aug 24, 2022 at 11:08 PM Joe Schaefer wrote: > Has anybody actually tried running bleadperl with modperl and mpm_event on > Linux? I wouldn’t be surprised if it works without coring in malloc() at > this point, or at least can be tuned to work. > > On Sat, Aug 20, 2022 at 11:31 AM Joe Schaefer wrote: > >> Solaris libc malloc() is also tunable (% man mallopt again), but I can >> tell you that I've yet to have a reason to bother, because it simply >> doesn't dump core on my mod_perl applications. >> >> >> >> On Sat, Aug 20, 2022 at 10:37 AM Joe Schaefer wrote: >> >>> >>> >>> -- Forwarded message - >>> From: Joe Schaefer >>> Date: Fri, Aug 19, 2022 at 10:37 PM >>> Subject: Re: Experience running mod_perl2 with mpm_event on Solaris 11 >>> To: pengyh >>> >>> >>> Seriously it’s always been a quality of implementation issue in open >>> source libc implementations (FreeBSD libc isn’t any better than glibc for >>> modperl and event_mpm). >>> >>> I papered over a third player in the memory management regimes in play. >>> The real problem for modperl isn’t apr pool allocations, it’s the bucket >>> brigades in the filter stacks. That stuff is hitting malloc/free multiple >>> times every time you deliver content to the browser. Combine that with a >>> lot of concurrent ithreads and things fall apart on non Solaris libc >>> implementations. >>> >>> >>> On Fri, Aug 19, 2022 at 10:17 PM Joe Schaefer >>> wrote: >>> Lower case t on technology On Fri, Aug 19, 2022 at 10:17 PM Joe Schaefer wrote: > https://sunstarsys.com/CMS/Technology > > On Fri, Aug 19, 2022 at 10:15 PM pengyh wrote: > >> i am not a programming expert. but I hear that most scripts like >> perl/python/ruby support threads not that well. is it? >> >> >> Joe Schaefer wrote: >> > Yes, with per Interpreter Threads. Everything else uses a Global >> > Interpreter Lock, which makes it single threaded on the actual op >> tree >> > walk (running your script logic, instead of system calls). >> > -- > Joe Schaefer, Ph.D. > We only build what you need built. > > 954.253.3732 > > > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732 -- >>> Joe Schaefer, Ph.D. >>> We only build what you need built. >>> >>> 954.253.3732 >>> >>> >>> >>> >>> -- >>> Joe Schaefer, Ph.D. >>> We only build what you need built. >>> >>> 954.253.3732 >>> >>> >>> >> >> -- >> Joe Schaefer, Ph.D. >> We only build what you need built. >> >> 954.253.3732 >> >> >> -- > Joe Schaefer, Ph.D. > We only build what you need built. > > 954.253.3732 > > > -- Joe Schaefer, Ph.D. We only build what you need built. 954.253.3732
