If you can take time to rewrite all codes with modPerl handlers, that will improve performance a lot.
On Sun, Feb 7, 2021, at 9:14 PM, Steven Haigh 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 📧 net...@crc.id.au 💻 https://www.crc.id.au > > On Sun, Feb 7, 2021 at 23:58, Steven Haigh <net...@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 📧 net...@crc.id.au 💻 https://www.crc.id.au >> >> On Sun, Feb 7, 2021 at 12:49, James Smith <j...@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 >>> <https://perl.apache.org/docs/20/api/ModPerl/PerlRunPrefork.html>` 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 <net...@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 📧 net...@crc.id.au 💻 https://www.crc.id.au [crc.id.au] >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.crc.id.au_&d=DwMFaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=oH2yp0ge1ecj4oDX0XM7vQ&m=bosoTbkecbnrPukObNK-5Duc1p3JTllIM7_FHhBYKW4&s=vQDi0ezyEZDOz86GVraerPdT76UjN2in3UdPh8fglRM&e=> >>> -- 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.