auto">

Interestingly, I did get things working with ModPerl::PerlRegist=
ry.

What I couldn't find *anywhere* is that the da=
ta 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* /va=
r/log/httpd/error_log (didn't show up in the vhost error_log!):

<=
div> readline() on unopened f=
ilehandle DATA at /usr/lib64/perl5/vendor_perl/Template/Provider.pm line 63=
8.

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-wrot=
e that bit of code, and things started working.

I =
had to fix a few lib path issues, but after getting my head around that, mo=
st things seem to work as before - however I don't notice much of an improv=
ement in execution times, I do see this improvement using 'ab -n 100 -c32':=

an>Apache + ExecCGI: Requests per second:    13.50 [#/sec] (mean)=

Apache + mod_perl=
: Requests per second:    59.81 [#/sec] (mean)

r>

This is obviously a good thing.

I hav=
en'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 suggestion=
s here from those who have done it in the past to save me going down some d=
ead ends :D

As welsey=
said =E2=80=93 try Registry, that was the standard way of using mod_perl t=
o cache perl in the server  =E2=80=93 but your problem might be due to=
the note in PerlRun=E2=80=A6



ption">https://perl.apache.org/docs/2.0/api/ModPerl/PerlRun.html#Descriptio=
n

META: =
document that for now we don't chdir() into the script's dir, because it af=
fects the whole process under threads. y:"Calibri",sans-serif">0/api/ModPerl/PerlRunPrefork.html">ModPerl::PerlRunPrefork> should
be used by those who run only under prefork MPM.fareast-language:EN-US">

{tbh most people don=E2=80=99t use mod perl under threads anyway as there i=
sn=E2=80=99t really a gain from using them}



It suggests you use ModPerl/PerlRunPrefork =E2=80=93 as this does an additi=
onal step to cd to the script directory =E2=80=93 which might be your issue=
=E2=80=A6.

&nbs=
p;

0cm 0cm">

From:=3D"EN-US"> Steven Haigh <netwiz-at-crc.id.au>


Sent: 07 February 2021 01:00

To: modperl-at-perl.apache.org

Subject: Moving ExecCGI to mod_perl - performance and custom 'module=
s' [EXT]

 

Hi all,

 

So for many years I've been slack and writing perl s=
cripts 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-40=
0ms 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 load=
ing perl, its modules etc etc

 

I know that the current trend would be to re-write t=
he 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 sec=
ond seems to be excessive

 

Would I be correct in thinking that mod_perl would h=
elp 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 comm=
on 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 t=
rack? wasting my time? or just a simple mistake?

 

--n>

Steven =
Haigh
k;background:white">=F0=9F=93=A7d:white">
netwiz-at-crc.id.au=3D"color:black;background:white">
or:black;background:white">=F0=9F=92=BBckground:white">
w.crc.id.au_&d=3DDwMFaQ&c=3DD7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQ=
nqBo&r=3DoH2yp0ge1ecj4oDX0XM7vQ&m=3DbosoTbkecbnrPukObNK-5Duc1p3JTll=
IM7_FHhBYKW4&s=3DvQDi0ezyEZDOz86GVraerPdT76UjN2in3UdPh8fglRM&e=3D">=
https://www.crc.id.au
[crc.id.au]





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