There is one other thing you can do relatively easily that may get you a marginal gain when Apache spins up new children. Load some or all of your Perl dependencies before Apache forks. There is also an opportunity to load other static resources at this time, but that can get a little more involved and/or confusing. There is some documentation here:
https://perl.apache.org/docs/2.0/user/handlers/server.html#Startup_File
Adam
> On Feb 7, 2021, at 8:15 AM, Steven Haigh <netwiz@crc.id.au> wrote:
>
> ?
> In fact, I just realised that 'ab' test is rather restrictive.... So here's a bit more of an extended test:
>
> # ab -k -n 1000 -c 32
>
> Apache + ExecCGI:
> Requests per second: 14.26 [#/sec] (mean)
> Time per request: 2244.181 [ms] (mean)
> Time per request: 70.131 [ms] (mean, across all concurrent requests)
>
> Apache + mod_perl (ModPerl::PerlRegistry):
> Requests per second: 132.14 [#/sec] (mean)
> Time per request: 242.175 [ms] (mean)
> Time per request: 7.568 [ms] (mean, across all concurrent requests)
>
> Interestingly, without Keepalives, the story is much the same:
>
> # ab -n 1000 -c 32
>
> Apache + ExecCGI:
> Requests per second: 14.15 [#/sec] (mean)
> Time per request: 2260.875 [ms] (mean)
> Time per request: 70.652 [ms] (mean, across all concurrent requests)
>
> Apache + mod_perl (ModPerl::PerlRegistry):
> Requests per second: 154.48 [#/sec] (mean)
> Time per request: 207.140 [ms] (mean)
> Time per request: 6.473 [ms] (mean, across all concurrent requests)
>
> Running some benchmarks across various parts of my site made me realise I also had some RewriteRules in the apache config that still had H=cgi-script - changed those to H=perl-script and saw similar improvements:
>
> ExecCGI - Requests per second: 11.84 [#/sec] (mean)
> mod_perl - Requests per second: 130.97 [#/sec] (mean)
>
> That's quite some gains for a days work.
>
> --
> Steven Haigh
>
> ???? netwiz@crc.id.au
> ???? https://www.crc.id.au
>
>> On Sun, Feb 7, 2021 at 23:58, Steven Haigh <netwiz@crc.id.au> wrote:
>> Interestingly, I did get things working with ModPerl::PerlRegistry.
>>
>> What I couldn't find *anywhere* is that the data I was loading in Template Toolkit was included in the file in the __DATA__ area - which causes mod_perl to fall over!
>>
>> The only way I managed to find this was the following error in the *system* /var/log/httpd/error_log (didn't show up in the vhost error_log!):
>> readline() on unopened filehandle DATA at /usr/lib64/perl5/vendor_perl/Template/Provider.pm line 638.
>>
>> Took me a LONG time to find a vague post that reading in lines from <DATA> kills mod_perl. Not sure why - but I stripped all the templates out and put them in a file instead and re-wrote that bit of code, and things started working.
>>
>> I had to fix a few lib path issues, but after getting my head around that, most things seem to work as before - however I don't notice much of an improvement in execution times, I do see this improvement using 'ab -n 100 -c32':
>>
>> Apache + ExecCGI: Requests per second: 13.50 [#/sec] (mean)
>> Apache + mod_perl: Requests per second: 59.81 [#/sec] (mean)
>>
>> This is obviously a good thing.
>>
>> I haven't gotten into the preload or DBI sharing yet - as that'll end up needing a bit of a rewrite of code to take advantage of. I'd be open to suggestions here from those who have done it in the past to save me going down some dead ends :D
>>
>> --
>> Steven Haigh
>>
>> ???? netwiz@crc.id.au
>> ???? https://www.crc.id.au
>>
>>> On Sun, Feb 7, 2021 at 12:49, James Smith <js5@sanger.acuk> wrote:
>>> As welsey said – try Registry, that was the standard way of using mod_perl to cache perl in the server – but your problem might be due to the note in PerlRun…
>>>
>>> https://perl.apache.org/docs/2.0/api/ModPerl/PerlRun.html#Description
>>> META: document that for now we don't chdir() into the script's dir, because it affects the whole process under threads. ModPerl::PerlRunPrefork should be used by those who run only under prefork MPM.
>>> {tbh most people don’t use mod perl under threads anyway as there isn’t really a gain from using them}
>>>
>>> It suggests you use ModPerl/PerlRunPrefork – as this does an additional step to cd to the script directory – which might be your issue….
>>>
>>> From: Steven Haigh <netwiz@crc.id.au>
>>> Sent: 07 February 2021 01:00
>>> To: modperl@perl.apache.org
>>> Subject: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]
>>>
>>> Hi all,
>>>
>>> So for many years I've been slack and writing perl scripts to do various things - but never needed more than the normal apache +ExecCGI and Template Toolkit.
>>>
>>> One of my sites has become a bit more popular, so I'd like to spend a bit of time on performance. Currently, I'm seeing ~300-400ms of what I believe to be execution time of the script loading, running, and then blatting its output to STDOUT and the browser can go do its thing.
>>>
>>> I believe most of the delay would be to do with loading perl, its modules etc etc
>>>
>>> I know that the current trend would be to re-write the entire site in a more modern, daemon based solution - and I started down the Mojolicious path - but the amount of re-writing to save 1/3rd of a second seems to be excessive
>>>
>>> Would I be correct in thinking that mod_perl would help in this case?
>>>
>>> I did try a basic test, but I have a 'use functions' in all my scripts that loads a .pm with some global vars and a lot of common subs - and for whatever reason (can't find anything on Google as to why), none of the subs are recognised in the main script when loaded via ModPerl::PerlRun.
>>>
>>> So throwing it out to the list - am I on the right track? wasting my time? or just a simple mistake?
>>>
>>> --
>>> Steven Haigh ???? netwiz@crc.id.au ???? https://www.crc.id.au [crc.id.au]
>>> -- 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.
https://perl.apache.org/docs/2.0/user/handlers/server.html#Startup_File
Adam
> On Feb 7, 2021, at 8:15 AM, Steven Haigh <netwiz@crc.id.au> wrote:
>
> ?
> In fact, I just realised that 'ab' test is rather restrictive.... So here's a bit more of an extended test:
>
> # ab -k -n 1000 -c 32
>
> Apache + ExecCGI:
> Requests per second: 14.26 [#/sec] (mean)
> Time per request: 2244.181 [ms] (mean)
> Time per request: 70.131 [ms] (mean, across all concurrent requests)
>
> Apache + mod_perl (ModPerl::PerlRegistry):
> Requests per second: 132.14 [#/sec] (mean)
> Time per request: 242.175 [ms] (mean)
> Time per request: 7.568 [ms] (mean, across all concurrent requests)
>
> Interestingly, without Keepalives, the story is much the same:
>
> # ab -n 1000 -c 32
>
> Apache + ExecCGI:
> Requests per second: 14.15 [#/sec] (mean)
> Time per request: 2260.875 [ms] (mean)
> Time per request: 70.652 [ms] (mean, across all concurrent requests)
>
> Apache + mod_perl (ModPerl::PerlRegistry):
> Requests per second: 154.48 [#/sec] (mean)
> Time per request: 207.140 [ms] (mean)
> Time per request: 6.473 [ms] (mean, across all concurrent requests)
>
> Running some benchmarks across various parts of my site made me realise I also had some RewriteRules in the apache config that still had H=cgi-script - changed those to H=perl-script and saw similar improvements:
>
> ExecCGI - Requests per second: 11.84 [#/sec] (mean)
> mod_perl - Requests per second: 130.97 [#/sec] (mean)
>
> That's quite some gains for a days work.
>
> --
> Steven Haigh
>
> ???? netwiz@crc.id.au
> ???? https://www.crc.id.au
>
>> On Sun, Feb 7, 2021 at 23:58, Steven Haigh <netwiz@crc.id.au> wrote:
>> Interestingly, I did get things working with ModPerl::PerlRegistry.
>>
>> What I couldn't find *anywhere* is that the data I was loading in Template Toolkit was included in the file in the __DATA__ area - which causes mod_perl to fall over!
>>
>> The only way I managed to find this was the following error in the *system* /var/log/httpd/error_log (didn't show up in the vhost error_log!):
>> readline() on unopened filehandle DATA at /usr/lib64/perl5/vendor_perl/Template/Provider.pm line 638.
>>
>> Took me a LONG time to find a vague post that reading in lines from <DATA> kills mod_perl. Not sure why - but I stripped all the templates out and put them in a file instead and re-wrote that bit of code, and things started working.
>>
>> I had to fix a few lib path issues, but after getting my head around that, most things seem to work as before - however I don't notice much of an improvement in execution times, I do see this improvement using 'ab -n 100 -c32':
>>
>> Apache + ExecCGI: Requests per second: 13.50 [#/sec] (mean)
>> Apache + mod_perl: Requests per second: 59.81 [#/sec] (mean)
>>
>> This is obviously a good thing.
>>
>> I haven't gotten into the preload or DBI sharing yet - as that'll end up needing a bit of a rewrite of code to take advantage of. I'd be open to suggestions here from those who have done it in the past to save me going down some dead ends :D
>>
>> --
>> Steven Haigh
>>
>> ???? netwiz@crc.id.au
>> ???? https://www.crc.id.au
>>
>>> On Sun, Feb 7, 2021 at 12:49, James Smith <js5@sanger.acuk> wrote:
>>> As welsey said – try Registry, that was the standard way of using mod_perl to cache perl in the server – but your problem might be due to the note in PerlRun…
>>>
>>> https://perl.apache.org/docs/2.0/api/ModPerl/PerlRun.html#Description
>>> META: document that for now we don't chdir() into the script's dir, because it affects the whole process under threads. ModPerl::PerlRunPrefork should be used by those who run only under prefork MPM.
>>> {tbh most people don’t use mod perl under threads anyway as there isn’t really a gain from using them}
>>>
>>> It suggests you use ModPerl/PerlRunPrefork – as this does an additional step to cd to the script directory – which might be your issue….
>>>
>>> From: Steven Haigh <netwiz@crc.id.au>
>>> Sent: 07 February 2021 01:00
>>> To: modperl@perl.apache.org
>>> Subject: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]
>>>
>>> Hi all,
>>>
>>> So for many years I've been slack and writing perl scripts to do various things - but never needed more than the normal apache +ExecCGI and Template Toolkit.
>>>
>>> One of my sites has become a bit more popular, so I'd like to spend a bit of time on performance. Currently, I'm seeing ~300-400ms of what I believe to be execution time of the script loading, running, and then blatting its output to STDOUT and the browser can go do its thing.
>>>
>>> I believe most of the delay would be to do with loading perl, its modules etc etc
>>>
>>> I know that the current trend would be to re-write the entire site in a more modern, daemon based solution - and I started down the Mojolicious path - but the amount of re-writing to save 1/3rd of a second seems to be excessive
>>>
>>> Would I be correct in thinking that mod_perl would help in this case?
>>>
>>> I did try a basic test, but I have a 'use functions' in all my scripts that loads a .pm with some global vars and a lot of common subs - and for whatever reason (can't find anything on Google as to why), none of the subs are recognised in the main script when loaded via ModPerl::PerlRun.
>>>
>>> So throwing it out to the list - am I on the right track? wasting my time? or just a simple mistake?
>>>
>>> --
>>> Steven Haigh ???? netwiz@crc.id.au ???? https://www.crc.id.au [crc.id.au]
>>> -- 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.