Mailing List Archive

The build system for the CMS is on GitHub here: https://github.com/SunStarSys/cms. Full site builds clock in at around 500 MB/s on modern hardware (NVMe + 8 cores). But the real beauty is the Incremental Build Support in the product itself, so you only build what you changed.



From: Joe Schaefer <joe@sunstarsys.com>
Sent: Tuesday, August 16, 2022 12:08 AM
To: modperl@perl.apache.org
Subject: Experience running mod_perl2 with mpm_event on Solaris 11



You can read about it in the URL below, but I’ve had it running for over two years as the linchpin of a Perl-based CMS that The ASF used to use itself (under prefork).



It screams under HTTP2.



See

https://sunstarsys.com/CMS/

--

Joe Schaefer, Ph.D.

<https://ci3.googleusercontent.com/mail-sig/AIorK4xJ9wGYA7VWN-zW0DcpKll4IC6JxLGTMmDkmdn4h4eHliQhOGGu1nAHJcSkYVnw1jXF8E--UGA>

<joe@sunstarsys.com <mailto:joe@sunstarsys.com> >

954.253.3732 <tel://954.253.3732>

To the best of my knowledge, the underlying problem with mod_perl+ithread is that it requires a reentrant malloc in libc. I haven’t tested modern Perl releases against Linux/FreeBSD, but Solaris 11 is rock solid with ithreads and event_mpm.



From: Joe Schaefer <joe@sunstarsys.com>
Sent: Tuesday, August 16, 2022 12:08 AM
To: modperl@perl.apache.org
Subject: Experience running mod_perl2 with mpm_event on Solaris 11



You can read about it in the URL below, but I’ve had it running for over two years as the linchpin of a Perl-based CMS that The ASF used to use itself (under prefork).



It screams under HTTP2.



See

https://sunstarsys.com/CMS/

--

Joe Schaefer, Ph.D.

<https://ci3.googleusercontent.com/mail-sig/AIorK4xJ9wGYA7VWN-zW0DcpKll4IC6JxLGTMmDkmdn4h4eHliQhOGGu1nAHJcSkYVnw1jXF8E--UGA>

<joe@sunstarsys.com <mailto:joe@sunstarsys.com> >

954.253.3732 <tel://954.253.3732>

Some HTTP/2 benchmarks from last year: https://www.youtube.com/watch?v=gf19vVF-G9E



From: joe@sunstarsys.com <joe@sunstarsys.com>
Sent: Tuesday, August 16, 2022 12:28 PM
To: modperl@perl.apache.org
Subject: RE: Experience running mod_perl2 with mpm_event on Solaris 11



To the best of my knowledge, the underlying problem with mod_perl+ithread is that it requires a reentrant malloc in libc. I haven’t tested modern Perl releases against Linux/FreeBSD, but Solaris 11 is rock solid with ithreads and event_mpm.



From: Joe Schaefer <joe@sunstarsys.com <mailto:joe@sunstarsys.com> >
Sent: Tuesday, August 16, 2022 12:08 AM
To: modperl@perl.apache.org <mailto:modperl@perl.apache.org>
Subject: Experience running mod_perl2 with mpm_event on Solaris 11



You can read about it in the URL below, but I’ve had it running for over two years as the linchpin of a Perl-based CMS that The ASF used to use itself (under prefork).



It screams under HTTP2.



See

https://sunstarsys.com/CMS/

--

Joe Schaefer, Ph.D.

<https://ci3.googleusercontent.com/mail-sig/AIorK4xJ9wGYA7VWN-zW0DcpKll4IC6JxLGTMmDkmdn4h4eHliQhOGGu1nAHJcSkYVnw1jXF8E--UGA>

<joe@sunstarsys.com <mailto:joe@sunstarsys.com> >

954.253.3732 <tel://954.253.3732>

On Aug 16, 2022, at 12:27 PM, joe@sunstarsys.com wrote:
> To the best of my knowledge, the underlying problem with mod_perl+ithread is that it requires a reentrant malloc in libc.

That's it? This is the first I'm learning this. Is there an option to compile Perl and mod_perl with a reentrant malloc on Linux?

Thanks,
Ed

We've been plagued by endless Segmentation Faults on non-Solaris systems, where the backtrace indicated the problem was in mod_perl -> Perl Code -> malloc (at the top of the frame). For a while I thought p5p fixed this in 5.30+ releases, but since nobody confirmed that suspicion I think the problem is more on the OS/Platform level.

-----Original Message-----
From: Edward J. Sabol <edwardjsabol@gmail.com>
Sent: Tuesday, August 16, 2022 2:27 PM
To: mod_perl list <modperl@perl.apache.org>
Subject: Re: Experience running mod_perl2 with mpm_event on Solaris 11

On Aug 16, 2022, at 12:27 PM, joe@sunstarsys.com wrote:
> To the best of my knowledge, the underlying problem with mod_perl+ithread is that it requires a reentrant malloc in libc.

That's it? This is the first I'm learning this. Is there an option to compile Perl and mod_perl with a reentrant malloc on Linux?

Thanks,
Ed

See % man mallopt for ENV tunables on Linux. On the surface, glibc malloc
should work as well as Solaris libc malloc re threading, but I don't have
the patience to track it down since I don't run Linux in my shop.

On Tue, Aug 16, 2022 at 3:50 PM <joe@sunstarsys.com> wrote:

> We've been plagued by endless Segmentation Faults on non-Solaris systems,
> where the backtrace indicated the problem was in mod_perl -> Perl Code ->
> malloc (at the top of the frame). For a while I thought p5p fixed this in
> 5.30+ releases, but since nobody confirmed that suspicion I think the
> problem is more on the OS/Platform level.
>
> -----Original Message-----
> From: Edward J. Sabol <edwardjsabol@gmail.com>
> Sent: Tuesday, August 16, 2022 2:27 PM
> To: mod_perl list <modperl@perl.apache.org>
> Subject: Re: Experience running mod_perl2 with mpm_event on Solaris 11
>
> On Aug 16, 2022, at 12:27 PM, joe@sunstarsys.com wrote:
> > To the best of my knowledge, the underlying problem with
> mod_perl+ithread is that it requires a reentrant malloc in libc.
>
> That's it? This is the first I'm learning this. Is there an option to
> compile Perl and mod_perl with a reentrant malloc on Linux?
>
> Thanks,
> Ed
>


--
Joe Schaefer, Ph.D.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>

Whatever you do, do not use Perl's sbrk-based malloc implementation. It's a disaster with ithreads.

-----Original Message-----
From: Edward J. Sabol <edwardjsabol@gmail.com>
Sent: Tuesday, August 16, 2022 2:27 PM
To: mod_perl list <modperl@perl.apache.org>
Subject: Re: Experience running mod_perl2 with mpm_event on Solaris 11

On Aug 16, 2022, at 12:27 PM, joe@sunstarsys.com wrote:
> To the best of my knowledge, the underlying problem with mod_perl+ithread is that it requires a reentrant malloc in libc.

That's it? This is the first I'm learning this. Is there an option to compile Perl and mod_perl with a reentrant malloc on Linux?

Thanks,
Ed

I discuss different Dynamic Programming Language thread support at https://sunstarsys.com/CMS/technology. The people in the Perl community at large who knock Perl5's ithreads support are doing nobody any favors.

-----Original Message-----
From: Edward J. Sabol <edwardjsabol@gmail.com>
Sent: Tuesday, August 16, 2022 2:27 PM
To: mod_perl list <modperl@perl.apache.org>
Subject: Re: Experience running mod_perl2 with mpm_event on Solaris 11

On Aug 16, 2022, at 12:27 PM, joe@sunstarsys.com wrote:
> To the best of my knowledge, the underlying problem with mod_perl+ithread is that it requires a reentrant malloc in libc.

That's it? This is the first I'm learning this. Is there an option to compile Perl and mod_perl with a reentrant malloc on Linux?

Thanks,
Ed

The problem is really confined to embedded uses of ithreads, because Perl itself will mutex-wrap the malloc calls. In httpd, so do all apr_pool_t calls to malloc. It's when the two memory management techniques are interacting that there is no application-level way to guard against thread contention in libc's malloc.

Mod_perl+ithreads are awesome, when used intelligently. You gain intelligence from experience trying to use it in a lot of ways that suck, until you hit one the path that yields success.

-----Original Message-----
From: Edward J. Sabol <edwardjsabol@gmail.com>
Sent: Tuesday, August 16, 2022 2:27 PM
To: mod_perl list <modperl@perl.apache.org>
Subject: Re: Experience running mod_perl2 with mpm_event on Solaris 11

On Aug 16, 2022, at 12:27 PM, joe@sunstarsys.com wrote:
> To the best of my knowledge, the underlying problem with mod_perl+ithread is that it requires a reentrant malloc in libc.

That's it? This is the first I'm learning this. Is there an option to compile Perl and mod_perl with a reentrant malloc on Linux?

Thanks,
Ed

does perl5 support threading?

joe@sunstarsys.com wrote:
> I discuss different Dynamic Programming Language thread support athttps://sunstarsys.com/CMS/technology. The people in the Perl community at large who knock Perl5's ithreads support are doing nobody any favors.

Very interesting, Joe! Thank you for sharing your insights into this and experience with it. Here’s hoping someone can solve/fix the problem with mod_perl threads on Linux.

Regards,
Ed

On Aug 19, 2022, at 1:44 PM, joe@sunstarsys.com wrote:
> ?The problem is really confined to embedded uses of ithreads, because Perl itself will mutex-wrap the malloc calls. In httpd, so do all apr_pool_t calls to malloc. It's when the two memory management techniques are interacting that there is no application-level way to guard against thread contention in libc's malloc.
>
> Mod_perl+ithreads are awesome, when used intelligently. You gain intelligence from experience trying to use it in a lot of ways that suck, until you hit one the path that yields success.

My pleasure. Nobody’s going to fix this from the modperl developer side.
We don’t care any more. That ship sailed 20 years ago. I don’t think it’s
ever not worked on Solaris, so you get what you pay for in the end.

On Fri, Aug 19, 2022 at 9:25 PM Edward J. Sabol <edwardjsabol@gmail.com>
wrote:

> Very interesting, Joe! Thank you for sharing your insights into this and
> experience with it. Here’s hoping someone can solve/fix the problem with
> mod_perl threads on Linux.
>
> Regards,
> Ed
>
> On Aug 19, 2022, at 1:44 PM, joe@sunstarsys.com wrote:
> > ?The problem is really confined to embedded uses of ithreads, because
> Perl itself will mutex-wrap the malloc calls. In httpd, so do all
> apr_pool_t calls to malloc. It's when the two memory management techniques
> are interacting that there is no application-level way to guard against
> thread contention in libc's malloc.
> >
> > Mod_perl+ithreads are awesome, when used intelligently. You gain
> intelligence from experience trying to use it in a lot of ways that suck,
> until you hit one the path that yields success.
>
--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>

Segfaults in glibc malloc should be reported to glibc developers. Not
here. There’s nothing we can do about it other than to suggest Solaris for
high performance modperl shops.

On Fri, Aug 19, 2022 at 9:28 PM Joe Schaefer <joe@sunstarsys.com> wrote:

> My pleasure. Nobody’s going to fix this from the modperl developer side.
> We don’t care any more. That ship sailed 20 years ago. I don’t think it’s
> ever not worked on Solaris, so you get what you pay for in the end.
>
> On Fri, Aug 19, 2022 at 9:25 PM Edward J. Sabol <edwardjsabol@gmail.com>
> wrote:
>
>> Very interesting, Joe! Thank you for sharing your insights into this and
>> experience with it. Here’s hoping someone can solve/fix the problem with
>> mod_perl threads on Linux.
>>
>> Regards,
>> Ed
>>
>> On Aug 19, 2022, at 1:44 PM, joe@sunstarsys.com wrote:
>> > ?The problem is really confined to embedded uses of ithreads, because
>> Perl itself will mutex-wrap the malloc calls. In httpd, so do all
>> apr_pool_t calls to malloc. It's when the two memory management techniques
>> are interacting that there is no application-level way to guard against
>> thread contention in libc's malloc.
>> >
>> > Mod_perl+ithreads are awesome, when used intelligently. You gain
>> intelligence from experience trying to use it in a lot of ways that suck,
>> until you hit one the path that yields success.
>>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
> --
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>

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 <joe@sunstarsys.com> wrote:

>
>
> ---------- Forwarded message ---------
> From: Joe Schaefer <joe@sunstarsys.com>
> Date: Fri, Aug 19, 2022 at 10:37 PM
> Subject: Re: Experience running mod_perl2 with mpm_event on Solaris 11
> To: pengyh <pengyh@mail.de>
>
>
> 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 <joe@sunstarsys.com> wrote:
>
>> Lower case t on technology
>>
>> On Fri, Aug 19, 2022 at 10:17 PM Joe Schaefer <joe@sunstarsys.com> wrote:
>>
>>> https://sunstarsys.com/CMS/Technology
>>>
>>> On Fri, Aug 19, 2022 at 10:15 PM pengyh <pengyh@mail.de> 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.
>>> <joe@sunstarsys.com>
>>> 954.253.3732 <//954.253.3732>
>>>
>>>
>>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> <joe@sunstarsys.com>
>> 954.253.3732 <//954.253.3732>
>>
>>
>> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>

--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>

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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> wrote:
>
>>
>>
>> ---------- Forwarded message ---------
>> From: Joe Schaefer <joe@sunstarsys.com>
>> Date: Fri, Aug 19, 2022 at 10:37 PM
>> Subject: Re: Experience running mod_perl2 with mpm_event on Solaris 11
>> To: pengyh <pengyh@mail.de>
>>
>>
>> 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 <joe@sunstarsys.com> wrote:
>>
>>> Lower case t on technology
>>>
>>> On Fri, Aug 19, 2022 at 10:17 PM Joe Schaefer <joe@sunstarsys.com>
>>> wrote:
>>>
>>>> https://sunstarsys.com/CMS/Technology
>>>>
>>>> On Fri, Aug 19, 2022 at 10:15 PM pengyh <pengyh@mail.de> 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.
>>>> <joe@sunstarsys.com>
>>>> 954.253.3732 <//954.253.3732>
>>>>
>>>>
>>>> --
>>> Joe Schaefer, Ph.D.
>>> We only build what you need built.
>>> <joe@sunstarsys.com>
>>> 954.253.3732 <//954.253.3732>
>>>
>>>
>>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> <joe@sunstarsys.com>
>> 954.253.3732 <//954.253.3732>
>>
>>
>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> <joe@sunstarsys.com>
>> 954.253.3732 <//954.253.3732>
>>
>>
>>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
> --
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>

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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> 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 <joe@sunstarsys.com> wrote:
>>
>>>
>>>
>>> ---------- Forwarded message ---------
>>> From: Joe Schaefer <joe@sunstarsys.com>
>>> Date: Fri, Aug 19, 2022 at 10:37 PM
>>> Subject: Re: Experience running mod_perl2 with mpm_event on Solaris 11
>>> To: pengyh <pengyh@mail.de>
>>>
>>>
>>> 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 <joe@sunstarsys.com>
>>> wrote:
>>>
>>>> Lower case t on technology
>>>>
>>>> On Fri, Aug 19, 2022 at 10:17 PM Joe Schaefer <joe@sunstarsys.com>
>>>> wrote:
>>>>
>>>>> https://sunstarsys.com/CMS/Technology
>>>>>
>>>>> On Fri, Aug 19, 2022 at 10:15 PM pengyh <pengyh@mail.de> 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.
>>>>> <joe@sunstarsys.com>
>>>>> 954.253.3732 <//954.253.3732>
>>>>>
>>>>>
>>>>> --
>>>> Joe Schaefer, Ph.D.
>>>> We only build what you need built.
>>>> <joe@sunstarsys.com>
>>>> 954.253.3732 <//954.253.3732>
>>>>
>>>>
>>>> --
>>> Joe Schaefer, Ph.D.
>>> We only build what you need built.
>>> <joe@sunstarsys.com>
>>> 954.253.3732 <//954.253.3732>
>>>
>>>
>>>
>>>
>>> --
>>> Joe Schaefer, Ph.D.
>>> We only build what you need built.
>>> <joe@sunstarsys.com>
>>> 954.253.3732 <//954.253.3732>
>>>
>>>
>>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> <joe@sunstarsys.com>
>> 954.253.3732 <//954.253.3732>
>>
>>
>> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>

--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>

In message <CAFQGv+btWPyvVUp2EWZFN7RuV4SfGDihaDh48cM3n8QxPwBkJg@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
groenveld@acm.org

Lazy enough never to support HTTP/2?

On Fri, Aug 26, 2022 at 1:32 PM John D Groenveld <groenveld@acm.org> wrote:

> In message <
> CAFQGv+btWPyvVUp2EWZFN7RuV4SfGDihaDh48cM3n8QxPwBkJg@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
> groenveld@acm.org
>


--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>

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 <joe@sunstarsys.com> wrote:

> Lazy enough never to support HTTP/2?
>
> On Fri, Aug 26, 2022 at 1:32 PM John D Groenveld <groenveld@acm.org>
> wrote:
>
>> In message <
>> CAFQGv+btWPyvVUp2EWZFN7RuV4SfGDihaDh48cM3n8QxPwBkJg@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
>> groenveld@acm.org
>>
>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>

--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>

In message <CAFQGv+Z-Ncmv3kajc41ag_6aid9=ZhWWw5D7fCMmcGpdMXSa2w@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
groenveld@acm.org

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 <groenveld@acm.org> wrote:

> In message <CAFQGv+Z-Ncmv3kajc41ag_6aid9=
> ZhWWw5D7fCMmcGpdMXSa2w@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
> groenveld@acm.org
>


--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>

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 <joe@sunstarsys.com> 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 <groenveld@acm.org>
> wrote:
>
>> In message <CAFQGv+Z-Ncmv3kajc41ag_6aid9=
>> ZhWWw5D7fCMmcGpdMXSa2w@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
>> groenveld@acm.org
>>
>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <joe@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>

--
Joe Schaefer, Ph.D.
We only build what you need built.
<joe@sunstarsys.com>
954.253.3732 <//954.253.3732>

In message <CAFQGv+YB4BO3K4_HRYCcyj7LjsnejRH9hWYJw+9172ybc+q4xQ@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
groenveld@acm.org

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.