MESSAGE
| DATE | 2021-02-07 |
| FROM | Steven Haigh
|
| SUBJECT | Re: [Hangout - NYLXS]
|
From hangout-bounces-at-nylxs.com Sun Feb 7 10:44:50 2021
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: from www2.mrbrklyn.com (www2.mrbrklyn.com [96.57.23.82])
by mrbrklyn.com (Postfix) with ESMTP id B7507163FF7;
Sun, 7 Feb 2021 10:44:49 -0500 (EST)
X-Original-To: hangout-at-www2.mrbrklyn.com
Delivered-To: hangout-at-www2.mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 1000)
id 5A11C163FF7; Sun, 7 Feb 2021 10:44:29 -0500 (EST)
Resent-From: Ruben Safir
Resent-Date: Sun, 7 Feb 2021 10:44:29 -0500
Resent-Message-ID: <20210207154429.GE25439-at-www2.mrbrklyn.com>
Resent-To: hangout-at-mrbrklyn.com
X-Original-To: ruben-at-mrbrklyn.com
Delivered-To: ruben-at-mrbrklyn.com
Received: from mxout1-ec2-va.apache.org (mxout1-ec2-va.apache.org
[3.227.148.255]) by mrbrklyn.com (Postfix) with ESMTP id E5286163FE3
for ; Sun, 7 Feb 2021 07:58:36 -0500 (EST)
Received: from mail.apache.org (mailroute1-lw-us.apache.org [207.244.88.153])
by mxout1-ec2-va.apache.org (ASF Mail Server at
mxout1-ec2-va.apache.org) with SMTP id 1B14D4292D
for ; Sun, 7 Feb 2021 12:58:36 +0000 (UTC)
Received: (qmail 38979 invoked by uid 500); 7 Feb 2021 12:58:35 -0000
Mailing-List: contact modperl-help-at-perl.apache.org; run by ezmlm
Precedence: bulk
Delivered-To: mailing list modperl-at-perl.apache.org
Received: (qmail 38925 invoked by uid 99); 7 Feb 2021 12:58:33 -0000
Received: from spamproc1-he-fi.apache.org (HELO spamproc1-he-fi.apache.org)
(95.217.134.168)
by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 07 Feb 2021 12:58:33 +0000
Received: from localhost (localhost [127.0.0.1])
by spamproc1-he-fi.apache.org (ASF Mail Server at spamproc1-he-fi.apache.org)
with ESMTP id A314AC0116
for ; Sun, 7 Feb 2021 12:58:32 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at spamproc1-he-fi.apache.org
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=6.31
tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.2, SPF_PASS=-0.001,
URIBL_BLOCKED=0.001] autolearn=disabled
Authentication-Results: spamproc1-he-fi.apache.org (amavisd-new);
dkim=pass (4096-bit key) header.d=crc.id.au
Received: from mx1-ec2-va.apache.org ([116.203.227.195])
by localhost (spamproc1-he-fi.apache.org [95.217.134.168]) (amavisd-new,
port 10024) with ESMTP id LySzupcwQ743 for ;
Sun, 7 Feb 2021 12:58:27 +0000 (UTC)
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=202.172.99.24;
helo=mailfilter.crc.id.au; envelope-from=netwiz-at-crc.id.au; receiver=
Received: from mailfilter.crc.id.au (mailfilter.crc.id.au [202.172.99.24])
by mx1-ec2-va.apache.org (ASF Mail Server at mx1-ec2-va.apache.org) with
ESMTPS id A2F03BCD8D
for ; Sun, 7 Feb 2021 12:58:26 +0000 (UTC)
Received: from mailfilter.crc.id.au (localhost [127.0.0.1])
by mailfilter.crc.id.au (Proxmox) with ESMTP id 7F80B3A4;
Sun, 7 Feb 2021 23:58:23 +1100 (AEDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crc.id.au; h=cc
:cc:content-type:content-type:date:from:from:in-reply-to
:message-id:mime-version:references:reply-to:subject:subject:to
:to; s=default; bh=5KEwKMv+3LCUx0jAWXhx4zgOC2ooOyKNLr0oVlGL+jY=; b=
L886HPHBx4Ia/iEPw5MDrjNFUkPLqLC0KoSYZr2km58WgUYT7mcZI0UQ4ZL3ugfA
x4vD+UYROqo4gZ5NYPa3fVjFSfBfD6/9YEGwB9hVWvx3xhhZMU88rfduAYidD1By
y/T6TK7L9lM8mSubcfJiqB+8UAslu7Id90UVsswqXlZ5hgXETuiiKPHyg+lrt7L6
T+6pFpBmBpCmJ5LILgOHMafeZ8awGBVMevwDqJ1abq7+61FVsRsmCZi0npTcSM6O
w6KWZqWW5YHqs0lI1qSymkXCQIB4zb8kV+OnvnX/YvQYhu3t3dpx3G6/6pEYxfW6
eTYogHn9p7YkQNIf3LciRQeAYBw17cl3QPhrRcxMpj/wkmhqDcG0xf2oCnCCftmU
9O78VdHF4udCYQ49C41AwXSSOsTdxzQCQ51DYYvnw8LgGEQSvkpxrCT5qau2O0rV
4uXqcbjrj90SWgTFjn4yThdBCUaP+UZAPnMO6rB0n54CP86KGkCRvthGcVhbxUpL
v0QfiH1P/tP+Cj9qoxSH8z9ccrFkmIKypz3TZgdiUQMrootqrydkTqRI2Dz5w53G
e5tbwbe7tl+4awfHgfFCV9HOcj+oTl/BE/BLsycV2MVtyvY7mOI0f2QenSLkbQ5U
IpwuswQ6thpSyK3YC2Qe9q6aAaovlHxAeDKPFvvevAA=
Date: Sun, 07 Feb 2021 23:58:17 +1100
From: Steven Haigh
To: James Smith
Cc: modperl-at-perl.apache.org
Message-Id: <5DT5OQ.TMVDQL2ALCKH-at-crc.id.au>
In-Reply-To:
References:
X-Mailer: geary/3.38.1
MIME-Version: 1.0
Subject: Re: [Hangout - NYLXS]
=?utf-8?q?Moving_ExecCGI_to_mod=5Fperl_-_perfo?=
=?utf-8?q?rmance_and_custom_=27modules=27_=5BEXT=5D?=
X-BeenThere: hangout-at-nylxs.com
X-Mailman-Version: 2.1.30rc1
List-Id: NYLXS Tech Talk and Politics
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Content-Type: multipart/mixed; boundary="===============1072508528=="
Errors-To: hangout-bounces-at-nylxs.com
Sender: "Hangout"
--===============1072508528==
Content-Type: multipart/alternative; boundary="=-vujNhbwcS7yqOceEQWRi"
--=-vujNhbwcS7yqOceEQWRi
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Interestingly, I did get things working with ModPerl::PerlRegistry.
What I couldn't find *anywhere* is that the data I was loading in=20
Template Toolkit was included in the file in the __DATA__ area - which=20
causes mod_perl to fall over!
The only way I managed to find this was the following error in the=20
*system* /var/log/httpd/error_log (didn't show up in the vhost=20
error_log!):
readline() on unopened filehandle DATA at=20
/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=20
kills mod_perl. Not sure why - but I stripped all the templates=20
out and put them in a file instead and re-wrote that bit of code, and=20
things started working.
I had to fix a few lib path issues, but after getting my head around=20
that, most things seem to work as before - however I don't notice much=20
of an improvement in execution times, I do see this improvement using=20
'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=20
up needing a bit of a rewrite of code to take advantage of. I'd be open=20
to suggestions here from those who have done it in the past to save me=20
going down some dead ends :D
--
Steven Haigh
=F0=9F=93=A7 netwiz-at-crc.id.au
=F0=9F=92=BB https://www.crc.id.au
On Sun, Feb 7, 2021 at 12:49, James Smith wrote:
> As welsey said =E2=80=93 try Registry, that was the standard way of using=
=20
> mod_perl to cache perl in the server =E2=80=93 but your problem might be=
=20
> due to the note in PerlRun=E2=80=A6
>=20
>
> META: document that for now we don't chdir() into the script's dir,=20
> because it affects the whole process under threads.=20
> ModPerl::PerlRunPrefork=20
> =20
> should be used by those who run only under prefork MPM.
> {tbh most people don=E2=80=99t use mod perl under threads anyway as ther=
e=20
> isn=E2=80=99t really a gain from using them}
>=20
> It suggests you use ModPerl/PerlRunPrefork =E2=80=93 as this does an=20
> additional step to cd to the script directory =E2=80=93 which might be yo=
ur=20
> issue=E2=80=A6.
>=20
>=20
>=20
> *From:*Steven Haigh
> *Sent:* 07 February 2021 01:00
> *To:* modperl-at-perl.apache.org
> *Subject:* Moving ExecCGI to mod_perl - performance and custom=20
> 'modules' [EXT]
>=20
>=20
>=20
> Hi all,
>=20
>=20
>=20
> So for many years I've been slack and writing perl scripts to do=20
> various things - but never needed more than the normal apache=20
> +ExecCGI and Template Toolkit.
>=20
>=20
>=20
> One of my sites has become a bit more popular, so I'd like to spend a=20
> bit of time on performance. Currently, I'm seeing ~300-400ms of what=20
> I believe to be execution time of the script loading, running, and=20
> then blatting its output to STDOUT and the browser can go do its=20
> thing.
>=20
>=20
>=20
> I believe most of the delay would be to do with loading perl, its=20
> modules etc etc
>=20
>=20
>=20
> I know that the current trend would be to re-write the entire site in=20
> a more modern, daemon based solution - and I started down the=20
> Mojolicious path - but the amount of re-writing to save 1/3rd of a=20
> second seems to be excessive
>=20
>=20
>=20
> Would I be correct in thinking that mod_perl would help in this case?
>=20
>=20
>=20
> I did try a basic test, but I have a 'use functions' in all my=20
> scripts that loads a .pm with some global vars and a lot of common=20
> subs - and for whatever reason (can't find anything on Google as to=20
> why), none of the subs are recognised in the main script when loaded=20
> via ModPerl::PerlRun.
>=20
>=20
>=20
> So throwing it out to the list - am I on the right track? wasting my=20
> time? or just a simple mistake?
>=20
>=20
>=20
> --
>=20
> Steven Haigh =F0=9F=93=A7netwiz-at-crc.id.au=20
> =F0=9F=92=BBhttps://www.crc.id.au [crc.id.au]=20
> =3DDwMFaQ&c=3DD7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=3DoH2yp0ge1ecj4=
oDX0XM7vQ&m=3DbosoTbkecbnrPukObNK-5Duc1p3JTllIM7_FHhBYKW4&s=3DvQDi0ezyEZDOz=
86GVraerPdT76UjN2in3UdPh8fglRM&e=3D>
>=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.
--=-vujNhbwcS7yqOceEQWRi
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Interestingly, I did get things wo=
rking with ModPerl::PerlRegistry.
What I couldn't =
find *anywhere* is that the data I was loading in Template Toolkit was incl=
uded in the file in the __DATA__ area - which causes mod_perl to fall over!=
The only way I managed to find this was the follo=
wing error in the *system* /var/log/httpd/error_log (didn't show up in the =
vhost error_log!): <=
/span>readline() on unopened filehandle DATA at /usr/lib64/perl5/vendor_per=
l/Template/Provider.pm line 638.
Took me a L=
ONG 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 workin=
g.
I had to fix a few lib path issues, but after g=
etting 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 impro=
vement using 'ab -n 100 -c32':
"white-space: pre-wrap;"> Apache + ExecCGI: Requests per second: &nb=
sp; 13.50 [#/sec] (mean) ap;"> Apache + mod_perl: Requests per second: 59.81 [#/=
sec] (mean)
This is obviously a good thing.<= /div>
I haven't gotten into the preload or DBI sharing y=
et - 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 pas=
t to save me going down some dead ends :D ture" dir=3D"auto"> lor: rgb(255, 255, 255);">
wrap; background-color: rgb(255, 255, 255);">--ir=3D"auto"> On Sun, Feb 7, 2021 at 12:49, James Smith <js5-at-sanger.ac= uk> wrote:
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::PerlRunPreforke> 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] 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?
--=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
--=-vujNhbwcS7yqOceEQWRi-- --===============1072508528== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hangout mailing list Hangout-at-nylxs.com http://lists.mrbrklyn.com/mailman/listinfo/hangout --===============1072508528==-- --===============1072508528== Content-Type: multipart/alternative; boundary="=-vujNhbwcS7yqOceEQWRi" --=-vujNhbwcS7yqOceEQWRi Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Interestingly, I did get things working with ModPerl::PerlRegistry. What I couldn't find *anywhere* is that the data I was loading in=20 Template Toolkit was included in the file in the __DATA__ area - which=20 causes mod_perl to fall over! The only way I managed to find this was the following error in the=20 *system* /var/log/httpd/error_log (didn't show up in the vhost=20 error_log!): readline() on unopened filehandle DATA at=20 /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=20 kills mod_perl. Not sure why - but I stripped all the templates=20
out and put them in a file instead and re-wrote that bit of code, and=20
things started working.
I had to fix a few lib path issues, but after getting my head around=20
that, most things seem to work as before - however I don't notice much=20
of an improvement in execution times, I do see this improvement using=20
'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=20
up needing a bit of a rewrite of code to take advantage of. I'd be open=20
to suggestions here from those who have done it in the past to save me=20
going down some dead ends :D
--
Steven Haigh
=F0=9F=93=A7 netwiz-at-crc.id.au
=F0=9F=92=BB https://www.crc.id.au
On Sun, Feb 7, 2021 at 12:49, James Smith wrote:
> As welsey said =E2=80=93 try Registry, that was the standard way of using=
=20
> mod_perl to cache perl in the server =E2=80=93 but your problem might be=
=20
> due to the note in PerlRun=E2=80=A6
>=20
>
> META: document that for now we don't chdir() into the script's dir,=20
> because it affects the whole process under threads.=20
> ModPerl::PerlRunPrefork=20
> =20
> should be used by those who run only under prefork MPM.
> {tbh most people don=E2=80=99t use mod perl under threads anyway as ther=
e=20
> isn=E2=80=99t really a gain from using them}
>=20
> It suggests you use ModPerl/PerlRunPrefork =E2=80=93 as this does an=20
> additional step to cd to the script directory =E2=80=93 which might be yo=
ur=20
> issue=E2=80=A6.
>=20
>=20
>=20
> *From:*Steven Haigh
> *Sent:* 07 February 2021 01:00
> *To:* modperl-at-perl.apache.org
> *Subject:* Moving ExecCGI to mod_perl - performance and custom=20
> 'modules' [EXT]
>=20
>=20
>=20
> Hi all,
>=20
>=20
>=20
> So for many years I've been slack and writing perl scripts to do=20
> various things - but never needed more than the normal apache=20
> +ExecCGI and Template Toolkit.
>=20
>=20
>=20
> One of my sites has become a bit more popular, so I'd like to spend a=20
> bit of time on performance. Currently, I'm seeing ~300-400ms of what=20
> I believe to be execution time of the script loading, running, and=20
> then blatting its output to STDOUT and the browser can go do its=20
> thing.
>=20
>=20
>=20
> I believe most of the delay would be to do with loading perl, its=20
> modules etc etc
>=20
>=20
>=20
> I know that the current trend would be to re-write the entire site in=20
> a more modern, daemon based solution - and I started down the=20
> Mojolicious path - but the amount of re-writing to save 1/3rd of a=20
> second seems to be excessive
>=20
>=20
>=20
> Would I be correct in thinking that mod_perl would help in this case?
>=20
>=20
>=20
> I did try a basic test, but I have a 'use functions' in all my=20
> scripts that loads a .pm with some global vars and a lot of common=20
> subs - and for whatever reason (can't find anything on Google as to=20
> why), none of the subs are recognised in the main script when loaded=20
> via ModPerl::PerlRun.
>=20
>=20
>=20
> So throwing it out to the list - am I on the right track? wasting my=20
> time? or just a simple mistake?
>=20
>=20
>=20
> --
>=20
> Steven Haigh =F0=9F=93=A7netwiz-at-crc.id.au=20
> =F0=9F=92=BBhttps://www.crc.id.au [crc.id.au]=20
> =3DDwMFaQ&c=3DD7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=3DoH2yp0ge1ecj4=
oDX0XM7vQ&m=3DbosoTbkecbnrPukObNK-5Duc1p3JTllIM7_FHhBYKW4&s=3DvQDi0ezyEZDOz=
86GVraerPdT76UjN2in3UdPh8fglRM&e=3D>
>=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.
--=-vujNhbwcS7yqOceEQWRi
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Interestingly, I did get things wo=
rking with ModPerl::PerlRegistry.
What I couldn't =
find *anywhere* is that the data I was loading in Template Toolkit was incl=
uded in the file in the __DATA__ area - which causes mod_perl to fall over!=
The only way I managed to find this was the follo=
wing error in the *system* /var/log/httpd/error_log (didn't show up in the =
vhost error_log!): <=
/span>readline() on unopened filehandle DATA at /usr/lib64/perl5/vendor_per=
l/Template/Provider.pm line 638.
Took me a L=
ONG 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 workin=
g.
I had to fix a few lib path issues, but after g=
etting 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 impro=
vement using 'ab -n 100 -c32':
"white-space: pre-wrap;"> Apache + ExecCGI: Requests per second: &nb=
sp; 13.50 [#/sec] (mean) ap;"> Apache + mod_perl: Requests per second: 59.81 [#/=
sec] (mean)
This is obviously a good thing.<= /div>
I haven't gotten into the preload or DBI sharing y=
et - 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 pas=
t to save me going down some dead ends :D ture" dir=3D"auto"> lor: rgb(255, 255, 255);">
wrap; background-color: rgb(255, 255, 255);">--ir=3D"auto"> On Sun, Feb 7, 2021 at 12:49, James Smith <js5-at-sanger.ac= uk> wrote:
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::PerlRunPreforke> 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] 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?
--=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
--=-vujNhbwcS7yqOceEQWRi-- --===============1072508528== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hangout mailing list Hangout-at-nylxs.com http://lists.mrbrklyn.com/mailman/listinfo/hangout --===============1072508528==-- |
|
