Mailing List Archive

On 25.01.2019 18:35, John Dunlap wrote:
> I'm in the process of optimizing our web application for performance and one thing that I
> was really excited to try was mod_http2 because it allows the browser to send multiple
> requests through the same TCP connection with compressed headers. However, when I enabled
> it and restarted apache I was greeted with this:
>
> [Fri Jan 25 12:30:57.813355 2019] [http2:warn] [pid 10186] AH10034: The mpm module
> (prefork.c) is not supported by mod_http2. The mpm determines how things are processed in
> your server. HTTP/2 has more demands in this regard and the currently selected mpm will
> just not do. This is an advisory warning. Your server will continue to work, but the
> HTTP/2 protocol will be inactive.
> [Fri Jan 25 12:30:57.828217 2019] [mpm_prefork:notice] [pid 10186] AH00163: Apache/2.4.29
> (Ubuntu) OpenSSL/1.1.0g mod_apreq2-20090110/2.8.0 mod_perl/2.0.10 Perl/v5.26.1 configured
> -- resuming normal operations
> [Fri Jan 25 12:30:57.828238 2019] [core:notice] [pid 10186] AH00094: Command line:
> '/usr/sbin/apache2'
>
> The last time I tried to use either mpm_worker or mpm_event my application was plagued by
> seemingly random segfaults. Are there any plans to support other MPM's? If not, the
> benefits of HTTP2 appear to be permanently out of reach for our mod_perl applications and
> that, honestly, might force us into seriously reevaluating our technology stack. :(
>

Am I allowed to jump into the same thread, and ask about what the general status of
mod_perl is, nowadays (if someone knows) ?
I am very happy with mod_perl, which we have been using for many years and still use
extensively in our applications.
And it is true that mod_perl allows one to "do things" in/with Apache httpd, that no other
Apache add-on module seems to even approach.
But it seemed that it took quite a long time for mod_perl to become available again when
Apache went from 2.2 to 2.4, and it seems indeed that not much is happening lately in
terms of making it work reliably under MPM's other than prefork.
So I am curious too, like John above.

(Mind you, for us MPM prefork and HTTP 1.1 are still perfectly ok, but the question is
more about the longer-term future).

A. Warnier
(acting as) CTO
Mira Consulting GmbH

> On 25.01.2019 18:35, John Dunlap wrote:
> > I'm in the process of optimizing our web application for performance and one thing that I
> > was really excited to try was mod_http2 because it allows the browser to send multiple
> > requests through the same TCP connection with compressed headers. However, when I enabled
> > it and restarted apache I was greeted with this:
> >
> > [Fri Jan 25 12:30:57.813355 2019] [http2:warn] [pid 10186] AH10034: The mpm module
> > (prefork.c) is not supported by mod_http2. The mpm determines how things are processed in
> > your server. HTTP/2 has more demands in this regard and the currently selected mpm will
> > just not do. This is an advisory warning. Your server will continue to work, but the
> > HTTP/2 protocol will be inactive.
> > [Fri Jan 25 12:30:57.828217 2019] [mpm_prefork:notice] [pid 10186] AH00163: Apache/2.4.29
> > (Ubuntu) OpenSSL/1.1.0g mod_apreq2-20090110/2.8.0 mod_perl/2.0.10 Perl/v5.26.1 configured
> > -- resuming normal operations
> > [Fri Jan 25 12:30:57.828238 2019] [core:notice] [pid 10186] AH00094: Command line:
> > '/usr/sbin/apache2'
> >
> > The last time I tried to use either mpm_worker or mpm_event my application was plagued by
> > seemingly random segfaults. Are there any plans to support other MPM's? If not, the
> > benefits of HTTP2 appear to be permanently out of reach for our mod_perl applications and
> > that, honestly, might force us into seriously reevaluating our technology stack. :(
> >
>
> Am I allowed to jump into the same thread, and ask about what the general status of
> mod_perl is, nowadays (if someone knows) ?
> I am very happy with mod_perl, which we have been using for many years and still use
> extensively in our applications.
> And it is true that mod_perl allows one to "do things" in/with Apache httpd, that no other
> Apache add-on module seems to even approach.
> But it seemed that it took quite a long time for mod_perl to become available again when
> Apache went from 2.2 to 2.4, and it seems indeed that not much is happening lately in
> terms of making it work reliably under MPM's other than prefork.
> So I am curious too, like John above.
>
> (Mind you, for us MPM prefork and HTTP 1.1 are still perfectly ok, but the question is
> more about the longer-term future).

I'm also curious about this as I anticipate HTTP/2 support becoming
a valuable and important feature in the future (the recent updates to
mod_perl2 have been good for us).

We use mod_perl2 extensively in all the web site application
programming that we do. We just finished writing an online store
application, and are now in the process of creating a social network
platform, both of which are using mod_perl2 and PostgreSQL.

Being able to write Perl code to handle the authentication phases
directly, and pass our DBI handle and other instantiated Perl objects
to other Perl scripts in the same session using $r->pnotes has also
provided wonderful performance benefits.

Perl has such a vast array of modules that make it easy to
accomplish a lot productively without having to "re-invent the wheel"
and so I regard mod_perl2 as one of Apache HTTPd's most valuable
modules that has ever been created.

Randolf Richardson - randolf@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/

On 1/25/19 10:54 AM, Randolf Richardson wrote:
>> On 25.01.2019 18:35, John Dunlap wrote:
>>> I'm in the process of optimizing our web application for performance and one thing that I
>>> was really excited to try was mod_http2 because it allows the browser to send multiple
>>> requests through the same TCP connection with compressed headers.
<snip>
>>> Are there any plans to support other MPM's? If not, the
>>> benefits of HTTP2 appear to be permanently out of reach for our mod_perl applications and
>>> that, honestly, might force us into seriously reevaluating our technology stack. :(
>>>
>> Am I allowed to jump into the same thread, and ask about what the general status of
>> mod_perl is, nowadays (if someone knows) ?
<snip>
>> (Mind you, for us MPM prefork and HTTP 1.1 are still perfectly ok, but the question is
>> more about the longer-term future).
> I'm also curious about this as I anticipate HTTP/2 support becoming
> a valuable and important feature in the future (the recent updates to
> mod_perl2 have been good for us).
>
> Randolf Richardson - randolf@inter-corporate.com
> Inter-Corporate Computer & Network Services, Inc.
> Beautiful British Columbia, Canada
> http://www.inter-corporate.com/
>
>
I have to add my voice to the growing chorus here.  As it stands, we are
forced to choose between mod_perl and HTTP/2.  At the moment, our shop
has chosen to keep mod_perl, but I share the above concerns, and I'd
rather see mod_perl be ready if there is ever a major cultural shift /
push to HTTP/2 in the broader market.

> On 25 Jan 2019, at 20:00, Michael A. Capone <mcapone@cablewholesale.com> wrote:
>
>
>
> On 1/25/19 10:54 AM, Randolf Richardson wrote:
>>> On 25.01.2019 1modperl@perl.apache.org8:35, John Dunlap wrote:
>>>> I'm in the process of optimizing our web application for performance and one thing that I
>>>> was really excited to try was mod_http2 because it allows the browser to send multiple
>>>> requests through the same TCP connection with compressed headers.
> <snip>
>>>> Are there any plans to support other MPM's? If not, the
>>>> benefits of HTTP2 appear to be permanently out of reach for our mod_perl applications and
>>>> that, honestly, might force us into seriously reevaluating our technology stack. :(
>>>>
>>> Am I allowed to jump into the same thread, and ask about what the general status of
>>> mod_perl is, nowadays (if someone knows) ?
> <snip>
>>> (Mind you, for us MPM prefork and HTTP 1.1 are still perfectly ok, but the question is
>>> more about the longer-term future).
>> I'm also curious about this as I anticipate HTTP/2 support becoming
>> a valuable and important feature in the future (the recent updates to
>> mod_perl2 have been good for us).
>>
>> Randolf Richardson - randolf@inter-corporate.com
>> Inter-Corporate Computer & Network Services, Inc.
>> Beautiful British Columbia, Canada
>> http://www.inter-corporate.com/
>>
>>
> I have to add my voice to the growing chorus here. As it stands, we are forced to choose between mod_perl and HTTP/2. At the moment, our shop has chosen to keep mod_perl, but I share the above concerns, and I'd rather see mod_perl be ready if there is ever a major cultural shift / push to HTTP/2 in the broader market.

as a owner of a small but quite fast growing company that first used MPW worker which was a little bit unstable and then went for prefork and this is working very well for now ...but it would be fantastic to have a stable worker for http/2, so if someone? can fix it we can probably sponsor part of work for I am sure that changing technic cost a lot more … /Sive

On 1/25/2019 11:00 AM, Michael A. Capone wrote:
> I have to add my voice to the growing chorus here.

Me too. Frequently when the topic of mod_perl going stale comes up
somebody jumps in with "That's old stuff, you should be using
PSGI/Plack". Those people simply don't understand the overall utility of
mod_perl beyond simply running a webapp <sigh>. I have authentication
and authorization handlers written in mod_perl, and the ability to
directly access the Apache API allows things that PSGI simply cannot do.

Agree with this we use AAA handlers - but more importantly output
filters to allow content to be decorated per site (independent of what
generates the content perl/java/php proxied content etc...} and add in a
few useful extra logging features that rely on things like transHandlers
and log & cleanup handlers you just can't quite get these working well
with plack/PSGI.

There is a balance between HTTP/1.1 and HTTP/2.0 that you can strike by
mixing a matching backends dependant on content - I use three apaches on
my machines one using event handler which receives all requests, and
servers some static content and proxies back to either a dev apache or
live apache dependent on what the URL is...

This gives me the best of both worlds....

On 25/01/2019 20:15, Paul B. Henson wrote:
> On 1/25/2019 11:00 AM, Michael A. Capone wrote:
>> I have to add my voice to the growing chorus here.
>
> Me too. Frequently when the topic of mod_perl going stale comes up
> somebody jumps in with "That's old stuff, you should be using
> PSGI/Plack". Those people simply don't understand the overall utility
> of mod_perl beyond simply running a webapp <sigh>. I have
> authentication and authorization handlers written in mod_perl, and the
> ability to directly access the Apache API allows things that PSGI
> simply cannot do.


--
The Wellcome Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.

Hi!

Perhaps in the same boat? Our company can sponsor between $1000 - $10000 to a project developing modPerl 3 (Perl 6 + stabil mpm-worker/event)

If some more in the boat can tribute also it would be awasame ...

/Sive

I would prefer to see a mod_perl 2.6 or 3 against perl 5 rather than
perl 6 - I think it wouldn't go to far against perl 6 as there isn't the
uptake - we would be unlikely to migrate to a perl 6 backend - there is
too much pressure already to move to an alternative language (python at
the moment - until we point out most of it's pitfalls when it comes to
web work!) that I don't think we would justify moving to a Perl 6
environment where there is little or no code to rely on!

On 26/01/2019 22:02, Sive Lindmark wrote:
> Hi!
>
> Perhaps in the same boat? Our company can sponsor between $1000 - $10000 to a project developing modPerl 3 (Perl 6 + stabil mpm-worker/event)
>
> If some more in the boat can tribute also it would be awasame ...
>
> /Sive
>


--
The Wellcome Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.

On Fri, Jan 25, 2019 at 11:35 AM John Dunlap <John@lariat.co> wrote:

> I'm in the process of optimizing our web application for performance and
> one thing that I was really excited to try was mod_http2 because it allows
> the browser to send multiple requests through the same TCP connection with
> compressed headers. However, when I enabled it and restarted apache I was
> greeted with this:
>
> [Fri Jan 25 12:30:57.813355 2019] [http2:warn] [pid 10186] AH10034: The
> mpm module (prefork.c) is not supported by mod_http2. The mpm determines
> how things are processed in your server. HTTP/2 has more demands in this
> regard and the currently selected mpm will just not do. This is an advisory
> warning. Your server will continue to work, but the HTTP/2 protocol will be
> inactive.
>

To this question, the answer should be blatantly obvious; http2 doesn't
simply support multiple requests (connection: keepalive solved that)
but supports parallel requests. This clearly isn't compatible with any
single-threaded/single-worker per connection strategy.

A hybrid mod_prefork could be coded to dispatch all worker requests
across to distinct worker processes for a single connection, but I
don't anticipate anyone interested in doing such development.


> The last time I tried to use either mpm_worker or mpm_event my application
> was plagued by seemingly random segfaults. Are there any plans to support
> other MPM's? If not, the benefits of HTTP2 appear to be permanently out of
> reach for our mod_perl applications and that, honestly, might force us into
> seriously reevaluating our technology stack. :(
>

Your compatibility with the worker MPM is likely much stronger than
with the event MPM; however... all request workers can behave in a
"free threaded" manner under mod_http2, eliminating the relative
simplicity of the worker MPM. Working out each and any of these
specific segfaults occurs is the only way to improve the situation.

For the general mod_perl activity to increase, the Apache Perl Project
needs active volunteers and contributions. Consider this entire thread
an open invitation to participate.

Hello William.
Thank you for commenting on this.

On 27.01.2019 21:13, William A Rowe Jr wrote:
> On Fri, Jan 25, 2019 at 11:35 AM John Dunlap <John@lariat.co <mailto:John@lariat.co>> wrote:
>
> I'm in the process of optimizing our web application for performance and one thing
> that I was really excited to try was mod_http2 because it allows the browser to send
> multiple requests through the same TCP connection with compressed headers. However,
> when I enabled it and restarted apache I was greeted with this:
>
> [Fri Jan 25 12:30:57.813355 2019] [http2:warn] [pid 10186] AH10034: The mpm module
> (prefork.c) is not supported by mod_http2. The mpm determines how things are processed
> in your server. HTTP/2 has more demands in this regard and the currently selected mpm
> will just not do. This is an advisory warning. Your server will continue to work, but
> the HTTP/2 protocol will be inactive.
>
>
> To this question, the answer should be blatantly obvious; http2 doesn't
> simply support multiple requests (connection: keepalive solved that)
> but supports parallel requests. This clearly isn't compatible with any
> single-threaded/single-worker per connection strategy.
>
> A hybrid mod_prefork could be coded to dispatch all worker requests
> across to distinct worker processes for a single connection, but I
> don't anticipate anyone interested in doing such development.
>
> The last time I tried to use either mpm_worker or mpm_event my application was plagued
> by seemingly random segfaults. Are there any plans to support other MPM's? If not, the
> benefits of HTTP2 appear to be permanently out of reach for our mod_perl applications
> and that, honestly, might force us into seriously reevaluating our technology stack. :(
>
>
> Your compatibility with the worker MPM is likely much stronger than
> with the event MPM; however... all request workers can behave in a
> "free threaded" manner under mod_http2, eliminating the relative
> simplicity of the worker MPM. Working out each and any of these
> specific segfaults occurs is the only way to improve the situation.
>
> For the general mod_perl activity to increase, the Apache Perl Project
> needs active volunteers and contributions. Consider this entire thread
> an open invitation to participate.
>

Invitation accepted, but
how can people who are not C programmers really contribute ?

I believe that there is a much wider user base for mod_perl, than may be evident from
activity on the user list or on Bugzilla.

To quote Philippe Chiasson in
http://www.apache.org/foundation/records/minutes/2018/board_minutes_2018_11_21.txt :

"It's not that the project is dead, in my opinion, more like dormant. It works,
it's being used by a large number of users, and is extremely stable."

Exactly. And therefore, there is very little noise about it.
mod_perl may be suffering from its general "it just works" aspect, and therefor be less
attractive to developers (of mod_perl itself).

So let's imagine that there are currently worldwide a few hundreds/thousands users of
mod_perl (by which I mean application developers who use mod_perl daily to
develop/maintain important (to them) web-based applications), but of which only a tiny
percentage is fluent in C (in which mod_perl is written). And among these people, there
are quite a few which have a vested interest in the future of mod_perl (that's certainly
my case, and my company's case), but who themselves don't feel qualified to be able to
contribute to the code (also my case).
What could these mod_perl users do, to trigger renewed interest if the further development
of mod_perl, by people qualified to do so ?

Say for example that, collectively, we would be very interested in someone picking up and
resolving these problems that exist in running mod_perl with Apache MPM's other than prefork.
What would be the best way for us collectively to to try get the ball moving in that
direction, and more than anything, avoid having mod_perl maybe being moved sooner or later
to the Apache Attic, for lack of /perceived/ interest ?

Genuinely curious and interested

André Warnier (soliplaya at apache.org)
(don't let the Tomcat committer label fool you; I'm a perl and mod_perl guy)

Hi William!

Count on us, my firm can sponsor work as I stated before, and also contribute setting up test cases and perhaps also do some coding if we have the knowledge to do whats needed.
My coders are not used to be part of any open source project, so we can not take any leading roll though.

How could a sponsor model work?

I have followed crypto world for some time now, and they sometimes set up price for someone thats achieve a goal. Something we can do here?

/Sive

I will second what Sive is saying. My organization does not have in-house
experience writing C code(our internal skill sets are web application and
database development) but we are potentially interested in sponsoring some
development on mod_perl with the goal of adding support for mpm_worker and
or mpm_event because we are interested in taking advantage of mod_http2. In
addition to our sponsorship, we could also assist in testing changes and
provided segfaults and debugging/environmental information from out
development and testing environments. Is anyone who is able to do this kind
of development interested in having a conversation with Sive and myself
with respect to sponsoring some development?

On Mon, Jan 28, 2019 at 1:11 AM Sive Lindmark <sive@capestream.se> wrote:

> Hi William!
>
> Count on us, my firm can sponsor work as I stated before, and also
> contribute setting up test cases and perhaps also do some coding if we have
> the knowledge to do whats needed.
> My coders are not used to be part of any open source project, so we can
> not take any leading roll though.
>
> How could a sponsor model work?
>
> I have followed crypto world for some time now, and they sometimes set up
> price for someone thats achieve a goal. Something we can do here?
>
> /Sive
>
>

--
John Dunlap
*CTO | Lariat *

*Direct:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co

As a long-time fan and user of mod_perl, I like so much the way this
conversation is turning.

I also wonder if there is a formal process, perhaps an ASF process, for
coordinating the objectives voiced in this thread with the resources
required to achieve them?

For example, I believe Steve Hay has led mod_perl2 development lately,
versions 2.0.9 and 2.0.10, anyway. Should he be engaged, or if the
leadership of the project has been handed off, whoever has taken over? Do
the project steward(s) follow this mailing list?

I don't mean to get in the way of positive and well-intended progress. I
love mod_perl and only want the best for its future development.

But there might be other development plans in progress with which
coordination would be helpful.

--
Read my Latest Blog Post for Telecom Pros: *Excel Telecom Tricks -
Sequential Numbering
<https://bangkokbeachtelecom.com/sequential-numbering/>*
Russell Lundberg
Bangkok, Thailand +66 91 546 4539
https://bangkokbeachtelecom.com/
LinkedIn Profile <https://th.linkedin.com/in/russelllundberg>


On Mon, Jan 28, 2019 at 8:04 AM John Dunlap <John@lariat.co> wrote:

> I will second what Sive is saying. My organization does not have in-house
> experience writing C code(our internal skill sets are web application and
> database development) but we are potentially interested in sponsoring some
> development on mod_perl with the goal of adding support for mpm_worker and
> or mpm_event because we are interested in taking advantage of mod_http2. In
> addition to our sponsorship, we could also assist in testing changes and
> provided segfaults and debugging/environmental information from out
> development and testing environments. Is anyone who is able to do this kind
> of development interested in having a conversation with Sive and myself
> with respect to sponsoring some development?
>
> On Mon, Jan 28, 2019 at 1:11 AM Sive Lindmark <sive@capestream.se> wrote:
>
>> Hi William!
>>
>> Count on us, my firm can sponsor work as I stated before, and also
>> contribute setting up test cases and perhaps also do some coding if we have
>> the knowledge to do whats needed.
>> My coders are not used to be part of any open source project, so we can
>> not take any leading roll though.
>>
>> How could a sponsor model work?
>>
>> I have followed crypto world for some time now, and they sometimes set up
>> price for someone thats achieve a goal. Something we can do here?
>>
>> /Sive
>>
>>
>
> --
> John Dunlap
> *CTO | Lariat *
>
> *Direct:*
> *john@lariat.co <john@lariat.co>*
>
> *Customer Service:*
> 877.268.6667
> support@lariat.co
>

> On 27 Jan 2019, at 20:13, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
>
> On Fri, Jan 25, 2019 at 11:35 AM John Dunlap <John@lariat.co <mailto:John@lariat.co>> wrote:
> I'm in the process of optimizing our web application for performance and one thing that I was really excited to try was mod_http2 because it allows the browser to send multiple requests through the same TCP connection with compressed headers. However, when I enabled it and restarted apache I was greeted with this:
>
> [Fri Jan 25 12:30:57.813355 2019] [http2:warn] [pid 10186] AH10034: The mpm module (prefork.c) is not supported by mod_http2. The mpm determines how things are processed in your server. HTTP/2 has more demands in this regard and the currently selected mpm will just not do. This is an advisory warning. Your server will continue to work, but the HTTP/2 protocol will be inactive.
>
> To this question, the answer should be blatantly obvious; http2 doesn't
> simply support multiple requests (connection: keepalive solved that)
> but supports parallel requests. This clearly isn't compatible with any
> single-threaded/single-worker per connection strategy.
>
> A hybrid mod_prefork could be coded to dispatch all worker requests
> across to distinct worker processes for a single connection, but I
> don't anticipate anyone interested in doing such development.
>
> The last time I tried to use either mpm_worker or mpm_event my application was plagued by seemingly random segfaults. Are there any plans to support other MPM's? If not, the benefits of HTTP2 appear to be permanently out of reach for our mod_perl applications and that, honestly, might force us into seriously reevaluating our technology stack. :(
>
> Your compatibility with the worker MPM is likely much stronger than
> with the event MPM; however... all request workers can behave in a
> "free threaded" manner under mod_http2, eliminating the relative
> simplicity of the worker MPM. Working out each and any of these
> specific segfaults occurs is the only way to improve the situation.
>
> For the general mod_perl activity to increase, the Apache Perl Project
> needs active volunteers and contributions. Consider this entire thread
> an open invitation to participate.

Given that Perl is single-threaded by design and history and has no reliable support for threading, I think that mod_perl and direct http/2 support in the same instance are probably fundamentally incompatible. I.e. if you have 10 perl threads running (each in a single process), then it doesn’t matter if you can multiplex 20 http/2 connections, they will all just block. If you’re very attached to mod_perl, you should already be using a 2-tier strategy anyway, with N fat mod_perl Apache instances handling only HTTP/1.1 requests and a second front-end proxy layer of whatever front-end proxy makes sense handling HTTP/2 requests for both static and dynamic content requests. This was standard advice 20 years ago as far as I recall and is even more prudent now.

- Mark

We can give that a try but I'm not sure how much it would help us because
we're already pulling all of our static content directly from Amazon
Cloudfront. The vast majority of our requests are for dynamic content.

On Mon, Jan 28, 2019 at 8:38 PM Mark Blackman <mark@blackmans.org> wrote:

>
>
> On 27 Jan 2019, at 20:13, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
>
> On Fri, Jan 25, 2019 at 11:35 AM John Dunlap <John@lariat.co> wrote:
>
>> I'm in the process of optimizing our web application for performance and
>> one thing that I was really excited to try was mod_http2 because it allows
>> the browser to send multiple requests through the same TCP connection with
>> compressed headers. However, when I enabled it and restarted apache I was
>> greeted with this:
>>
>> [Fri Jan 25 12:30:57.813355 2019] [http2:warn] [pid 10186] AH10034: The
>> mpm module (prefork.c) is not supported by mod_http2. The mpm determines
>> how things are processed in your server. HTTP/2 has more demands in this
>> regard and the currently selected mpm will just not do. This is an advisory
>> warning. Your server will continue to work, but the HTTP/2 protocol will be
>> inactive.
>>
>
> To this question, the answer should be blatantly obvious; http2 doesn't
> simply support multiple requests (connection: keepalive solved that)
> but supports parallel requests. This clearly isn't compatible with any
> single-threaded/single-worker per connection strategy.
>
> A hybrid mod_prefork could be coded to dispatch all worker requests
> across to distinct worker processes for a single connection, but I
> don't anticipate anyone interested in doing such development.
>
>
>> The last time I tried to use either mpm_worker or mpm_event my
>> application was plagued by seemingly random segfaults. Are there any plans
>> to support other MPM's? If not, the benefits of HTTP2 appear to be
>> permanently out of reach for our mod_perl applications and that, honestly,
>> might force us into seriously reevaluating our technology stack. :(
>>
>
> Your compatibility with the worker MPM is likely much stronger than
> with the event MPM; however... all request workers can behave in a
> "free threaded" manner under mod_http2, eliminating the relative
> simplicity of the worker MPM. Working out each and any of these
> specific segfaults occurs is the only way to improve the situation.
>
> For the general mod_perl activity to increase, the Apache Perl Project
> needs active volunteers and contributions. Consider this entire thread
> an open invitation to participate.
>
>
> Given that Perl is single-threaded by design and history and has no
> reliable support for threading, I think that mod_perl and direct http/2
> support in the same instance are probably fundamentally incompatible. I.e.
> if you have 10 perl threads running (each in a single process), then it
> doesn’t matter if you can multiplex 20 http/2 connections, they will all
> just block. If you’re very attached to mod_perl, you should already be
> using a 2-tier strategy anyway, with N fat mod_perl Apache instances
> handling only HTTP/1.1 requests and a second front-end proxy layer of
> whatever front-end proxy makes sense handling HTTP/2 requests for both
> static and dynamic content requests. This was standard advice 20 years ago
> as far as I recall and is even more prudent now.
>
> - Mark
>


--
John Dunlap
*CTO | Lariat *

*Direct:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co

Ok, hopefully Amazon Cloudfront is already using HTTP/2 on your behalf and proxying just the dynamic content requests via HTTP/1.1 to your mod_perl instances.


> On 28 Jan 2019, at 21:02, John Dunlap <John@lariat.co> wrote:
>
> We can give that a try but I'm not sure how much it would help us because we're already pulling all of our static content directly from Amazon Cloudfront. The vast majority of our requests are for dynamic content.
>
> On Mon, Jan 28, 2019 at 8:38 PM Mark Blackman <mark@blackmans.org <mailto:mark@blackmans.org>> wrote:
>
> Given that Perl is single-threaded by design and history and has no reliable support for threading, I think that mod_perl and direct http/2 support in the same instance are probably fundamentally incompatible. I.e. if you have 10 perl threads running (each in a single process), then it doesn’t matter if you can multiplex 20 http/2 connections, they will all just block. If you’re very attached to mod_perl, you should already be using a 2-tier strategy anyway, with N fat mod_perl Apache instances handling only HTTP/1.1 requests and a second front-end proxy layer of whatever front-end proxy makes sense handling HTTP/2 requests for both static and dynamic content requests. This was standard advice 20 years ago as far as I recall and is even more prudent now.
>
> - Mark
>
>
> --
> John Dunlap
> CTO | Lariat
>
> Direct:
> john@lariat.co <mailto:john@lariat.co>
>
> Customer Service:
> 877.268.6667 <>
> support@lariat.co <mailto:support@lariat.co>
> <100x60.png>
> <100x60.png>

I'm pretty sure that they are but, unfortunately, we make a lot of dynamic
requests.

On Mon, Jan 28, 2019 at 9:08 PM Mark Blackman <mark@blackmans.org> wrote:

> Ok, hopefully Amazon Cloudfront is already using HTTP/2 on your behalf and
> proxying just the dynamic content requests via HTTP/1.1 to your mod_perl
> instances.
>
>
> On 28 Jan 2019, at 21:02, John Dunlap <John@lariat.co> wrote:
>
> We can give that a try but I'm not sure how much it would help us because
> we're already pulling all of our static content directly from Amazon
> Cloudfront. The vast majority of our requests are for dynamic content.
>
> On Mon, Jan 28, 2019 at 8:38 PM Mark Blackman <mark@blackmans.org> wrote:
>
>>
>> Given that Perl is single-threaded by design and history and has no
>> reliable support for threading, I think that mod_perl and direct http/2
>> support in the same instance are probably fundamentally incompatible. I.e.
>> if you have 10 perl threads running (each in a single process), then it
>> doesn’t matter if you can multiplex 20 http/2 connections, they will all
>> just block. If you’re very attached to mod_perl, you should already be
>> using a 2-tier strategy anyway, with N fat mod_perl Apache instances
>> handling only HTTP/1.1 requests and a second front-end proxy layer of
>> whatever front-end proxy makes sense handling HTTP/2 requests for both
>> static and dynamic content requests. This was standard advice 20 years ago
>> as far as I recall and is even more prudent now.
>>
>> - Mark
>>
>
>
> --
> John Dunlap
> *CTO | Lariat *
>
> *Direct:*
> *john@lariat.co <john@lariat.co>*
>
> *Customer Service:*
> 877.268.6667
> support@lariat.co
> <100x60.png>
> <100x60.png>
>
>
>

--
John Dunlap
*CTO | Lariat *

*Direct:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co

time for more cores or optimising your Perl?

> On 28 Jan 2019, at 21:10, John Dunlap <John@lariat.co> wrote:
>
> I'm pretty sure that they are but, unfortunately, we make a lot of dynamic requests.
>
> On Mon, Jan 28, 2019 at 9:08 PM Mark Blackman <mark@blackmans.org <mailto:mark@blackmans.org>> wrote:
> Ok, hopefully Amazon Cloudfront is already using HTTP/2 on your behalf and proxying just the dynamic content requests via HTTP/1.1 to your mod_perl instances.
>
>
>> On 28 Jan 2019, at 21:02, John Dunlap <John@lariat.co <mailto:John@lariat.co>> wrote:
>>
>> We can give that a try but I'm not sure how much it would help us because we're already pulling all of our static content directly from Amazon Cloudfront. The vast majority of our requests are for dynamic content.
>>
>> On Mon, Jan 28, 2019 at 8:38 PM Mark Blackman <mark@blackmans.org <mailto:mark@blackmans.org>> wrote:
>>
>> Given that Perl is single-threaded by design and history and has no reliable support for threading, I think that mod_perl and direct http/2 support in the same instance are probably fundamentally incompatible. I.e. if you have 10 perl threads running (each in a single process), then it doesn’t matter if you can multiplex 20 http/2 connections, they will all just block. If you’re very attached to mod_perl, you should already be using a 2-tier strategy anyway, with N fat mod_perl Apache instances handling only HTTP/1.1 requests and a second front-end proxy layer of whatever front-end proxy makes sense handling HTTP/2 requests for both static and dynamic content requests. This was standard advice 20 years ago as far as I recall and is even more prudent now.
>>
>> - Mark
>>
>>
>> --
>> John Dunlap
>> CTO | Lariat
>>
>> Direct:
>> john@lariat.co <mailto:john@lariat.co>
>>
>> Customer Service:
>> 877.268.6667 <>
>> support@lariat.co <mailto:support@lariat.co>
>> <100x60.png>
>> <100x60.png>
>
>
>
> --
> John Dunlap
> CTO | Lariat
>
> Direct:
> john@lariat.co <mailto:john@lariat.co>
>
> Customer Service:
> 877.268.6667 <>
> support@lariat.co <mailto:support@lariat.co>
> <100x60.png>
> <100x60.png>

Our servers already have 32 Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz
cores(if you count hyper threading) so optimization is the road I've been
going down. I've also Apache::VMonitor to get, at least, *some* insight
into the internals of mod_perl but I'm uncertain how to use the information
it gives me to optimize the server.

On Mon, Jan 28, 2019 at 9:12 PM Mark Blackman <mark@blackmans.org> wrote:

> time for more cores or optimising your Perl?
>
> On 28 Jan 2019, at 21:10, John Dunlap <John@lariat.co> wrote:
>
> I'm pretty sure that they are but, unfortunately, we make a lot of dynamic
> requests.
>
> On Mon, Jan 28, 2019 at 9:08 PM Mark Blackman <mark@blackmans.org> wrote:
>
>> Ok, hopefully Amazon Cloudfront is already using HTTP/2 on your behalf
>> and proxying just the dynamic content requests via HTTP/1.1 to your
>> mod_perl instances.
>>
>>
>> On 28 Jan 2019, at 21:02, John Dunlap <John@lariat.co> wrote:
>>
>> We can give that a try but I'm not sure how much it would help us because
>> we're already pulling all of our static content directly from Amazon
>> Cloudfront. The vast majority of our requests are for dynamic content.
>>
>> On Mon, Jan 28, 2019 at 8:38 PM Mark Blackman <mark@blackmans.org> wrote:
>>
>>>
>>> Given that Perl is single-threaded by design and history and has no
>>> reliable support for threading, I think that mod_perl and direct http/2
>>> support in the same instance are probably fundamentally incompatible. I.e.
>>> if you have 10 perl threads running (each in a single process), then it
>>> doesn’t matter if you can multiplex 20 http/2 connections, they will all
>>> just block. If you’re very attached to mod_perl, you should already be
>>> using a 2-tier strategy anyway, with N fat mod_perl Apache instances
>>> handling only HTTP/1.1 requests and a second front-end proxy layer of
>>> whatever front-end proxy makes sense handling HTTP/2 requests for both
>>> static and dynamic content requests. This was standard advice 20 years ago
>>> as far as I recall and is even more prudent now.
>>>
>>> - Mark
>>>
>>
>>
>> --
>> John Dunlap
>> *CTO | Lariat *
>>
>> *Direct:*
>> *john@lariat.co <john@lariat.co>*
>>
>> *Customer Service:*
>> 877.268.6667
>> support@lariat.co
>> <100x60.png>
>> <100x60.png>
>>
>>
>>
>
> --
> John Dunlap
> *CTO | Lariat *
>
> *Direct:*
> *john@lariat.co <john@lariat.co>*
>
> *Customer Service:*
> 877.268.6667
> support@lariat.co
> <100x60.png>
> <100x60.png>
>
>
>

--
John Dunlap
*CTO | Lariat *

*Direct:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co

> On 28 Jan 2019, at 21:14, John Dunlap <John@lariat.co> wrote:
>
> Our servers already have 32 Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz cores(if you count hyper threading) so optimization is the road I've been going down. I've also Apache::VMonitor to get, at least, *some* insight into the internals of mod_perl but I'm uncertain how to use the information it gives me to optimize the server.

Plenty of traffic sounds like a nice problem to have, more machines then? :) I have a hosting business (UK) on the side (http://www.exonetric.com <http://www.exonetric.com/>) and would love to sell you some hosting! On the other hand, if your Perl just needs some TLC, then plenty of contractors can help find the hotspots and optimise for you.

- Mark

Yes! Lots of traffic is arguably the best kind of problem to have! :) We
can definitely throw servers at the problem and scale horizontally but
those costs add up and I'm afraid that, unless we can somehow get more
concurrency out of mod_perl, a day will come when we're forced to
acknowledge that we can do more work for less money in a different
language. I was really hoping that a different MPM and http/2 would help in
that regard but it's not sounding hopeful. :(

On Mon, Jan 28, 2019 at 9:18 PM Mark Blackman <mark@blackmans.org> wrote:

>
>
> On 28 Jan 2019, at 21:14, John Dunlap <John@lariat.co> wrote:
>
> Our servers already have 32 Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz
> cores(if you count hyper threading) so optimization is the road I've been
> going down. I've also Apache::VMonitor to get, at least, *some* insight
> into the internals of mod_perl but I'm uncertain how to use the information
> it gives me to optimize the server.
>
>
> Plenty of traffic sounds like a nice problem to have, more machines then?
> :) I have a hosting business (UK) on the side (http://www.exonetric.com)
> and would love to sell you some hosting! On the other hand, if your Perl
> just needs some TLC, then plenty of contractors can help find the hotspots
> and optimise for you.
>
> - Mark
>


--
John Dunlap
*CTO | Lariat *

*Direct:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co

I think Perl is fine, but naive Perl (or anything else) doesn’t scale. Are you actually maxing out your CPU (re-examine your code) or are your mod_perl instances all hanging around waiting for a database to return (re-examine your queries/indices).

- Mark

> On 28 Jan 2019, at 21:27, John Dunlap <John@lariat.co> wrote:
>
> Yes! Lots of traffic is arguably the best kind of problem to have! :) We can definitely throw servers at the problem and scale horizontally but those costs add up and I'm afraid that, unless we can somehow get more concurrency out of mod_perl, a day will come when we're forced to acknowledge that we can do more work for less money in a different language. I was really hoping that a different MPM and http/2 would help in that regard but it's not sounding hopeful. :(
>
> On Mon, Jan 28, 2019 at 9:18 PM Mark Blackman <mark@blackmans.org <mailto:mark@blackmans.org>> wrote:
>
>
>> On 28 Jan 2019, at 21:14, John Dunlap <John@lariat.co <mailto:John@lariat.co>> wrote:
>>
>> Our servers already have 32 Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz cores(if you count hyper threading) so optimization is the road I've been going down. I've also Apache::VMonitor to get, at least, *some* insight into the internals of mod_perl but I'm uncertain how to use the information it gives me to optimize the server.
>
> Plenty of traffic sounds like a nice problem to have, more machines then? :) I have a hosting business (UK) on the side (http://www.exonetric.com <http://www.exonetric.com/>) and would love to sell you some hosting! On the other hand, if your Perl just needs some TLC, then plenty of contractors can help find the hotspots and optimise for you.
>
> - Mark
>
>
> --
> John Dunlap
> CTO | Lariat
>
> Direct:
> john@lariat.co <mailto:john@lariat.co>
>
> Customer Service:
> 877.268.6667 <>
> support@lariat.co <mailto:support@lariat.co>
> <100x60.png>
> <100x60.png>

On 1/28/2019 12:38 PM, Mark Blackman wrote:
>
> Given that Perl is single-threaded by design and history and has no
> reliable support for threading, I think that mod_perl and direct http/2

Perhaps I am confused, but I do not necessarily agree with this
statement. See, for example:

https://perl.apache.org/docs/2.0/user/intro/overview.html#Threads_Support

Both perl and mod_perl support threads, typically the problem arises not
with native Perl thread support, but rather thread-unsafe user code or
modules.

> On 28 Jan 2019, at 21:34, Paul B. Henson <henson@acm.org> wrote:
>
> On 1/28/2019 12:38 PM, Mark Blackman wrote:
> >
>> Given that Perl is single-threaded by design and history and has no reliable support for threading, I think that mod_perl and direct http/2
>
> Perhaps I am confused, but I do not necessarily agree with this statement. See, for example:
>
> https://perl.apache.org/docs/2.0/user/intro/overview.html#Threads_Support
>
> Both perl and mod_perl support threads, typically the problem arises not with native Perl thread support, but rather thread-unsafe user code or modules.
>

https://perldoc.perl.org/threads.html#WARNING <https://perldoc.perl.org/threads.html#WARNING> Threads are discouraged in Perl these days

- Mark