perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Dunlap <J...@lariat.co>
Subject Re: HTTP and MPM support
Date Mon, 28 Jan 2019 21:14:47 GMT
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

Mime
View raw message