Re: Moving ExecCGI to mod_perl - performance and custom 'modules'

[Gazzali Jaleel]

Porting code from CGI to mod_perl is a fun project.

This is a late reply to your original post but wanted to point out an 
excellent resource - the Practical mod_perl book. The link for the book 
on the mod_perl site (perl.apache.org) is broken but you can find it at 
https://modperl2book.org/mp1/. It was written when mod_perl 1 was in use 
but the concepts explained are still valid. Be aware there was some 
renaming in mod_perl 2. For example, Apache::Registry became 
ModPerl::Registry.


Chapter 6, "Coding with mod_perl in mind" is full of good stuff about 
what to watch out for as you refactor your code for mod_perl, including 
the problem with __DATA__ that you had (from a later post). In fact, the 
whole book is a great read. I highly recommend skimming through it and 
reading in detail as you see fit.



On 2/6/2021 4:59 PM, Steven Haigh wrote:

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 

Re: Solution for $r->connection->client_addr->port

[Gazzali Jaleel]

On 2/25/2019 2:57 PM, Randolf Richardson wrote:

On 2/25/2019 2:28 PM, Randolf Richardson wrote:

[sNip]

As long as one isn't relying on the client's dynamic TCP port number
from $r->connection->remote_addr->port for anything (as I've
discovered no longer works in the current release of mod_perl2),
updating to the newest mod_perl2 should ultimately be relatively
problem-free.  (This client port number business has not been a high
priority for me to raise as an issue, but if it is something that
Hans or anyone else is needing I'll gladly chime in with my vote for
wanting it fixed.)


Does this work for you?
$r->connection->client_addr->port;


Unfortunately, this does not work for me, and this error is appended
to the web server's error log:

Can't locate object method "port" via package "APR::SockAddr" at
/internet/com/example/www/test.pl line 42.


Does test.pl load APR::SockAddr?


No, it wasn't.


use APR::SockAddr ();


Adding that line resolves the problem, and shows the correct dynamic
port number.

This is great!  Thank you.



Sure thing, glad it works.

I suppose the Apache2::Connection documentation should be updated, so 
that 'remote_addr' is replaced by the correct 'client_addr'.




The doc. states remote_addr returns an APR::SockAddr object but there's
no remote_addr in my Apache2::Connection. However, there's a client_addr
which does return an APR::SockAddr object.


In case you're interested, these are the relevant modules I'm using
(output filtered from "apt" on Ubuntu Linux 18.04 LTS on my laptop):

apache2/bionic-updates,now 2.4.29-1ubuntu4.5 amd64

apache2-bin/bionic-updates,now 2.4.29-1ubuntu4.5 amd64

apache2-data/bionic-updates,bionic-updates,now 2.4.29-1ubuntu4.5
all

apache2-dev/bionic-updates,now 2.4.29-1ubuntu4.5 amd64

libapache2-mod-apreq2/bionic,now 2.13-5build3 amd64

libapache2-mod-perl2/bionic-updates,bionic-security,now
2.0.10-2ubuntu3.18.04.1 amd64

libapache2-request-perl/bionic,now 2.13-5build3 amd64

perl/bionic-updates,bionic-security,now 5.26.1-6ubuntu0.3 amd64

perl-base/bionic-updates,bionic-security,now 5.26.1-6ubuntu0.3
amd64


Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/

Re: Compile mod_perl 1.0 on ubuntu 12.04 or later

[Gazzali Jaleel]

On 2/25/2019 2:28 PM, Randolf Richardson wrote:

[sNip]

As long as one isn't relying on the client's dynamic TCP port number
from $r->connection->remote_addr->port for anything (as I've
discovered no longer works in the current release of mod_perl2),
updating to the newest mod_perl2 should ultimately be relatively
problem-free.  (This client port number business has not been a high
priority for me to raise as an issue, but if it is something that
Hans or anyone else is needing I'll gladly chime in with my vote for
wanting it fixed.)


Does this work for you?
$r->connection->client_addr->port;


Unfortunately, this does not work for me, and this error is appended
to the web server's error log:

Can't locate object method "port" via package "APR::SockAddr" at
/internet/com/example/www/test.pl line 42.


Does test.pl load APR::SockAddr?

use APR::SockAddr ();





The doc. states remote_addr returns an APR::SockAddr object but there's
no remote_addr in my Apache2::Connection. However, there's a client_addr
which does return an APR::SockAddr object.


In case you're interested, these are the relevant modules I'm using
(output filtered from "apt" on Ubuntu Linux 18.04 LTS on my laptop):

apache2/bionic-updates,now 2.4.29-1ubuntu4.5 amd64

apache2-bin/bionic-updates,now 2.4.29-1ubuntu4.5 amd64

apache2-data/bionic-updates,bionic-updates,now 2.4.29-1ubuntu4.5
all

apache2-dev/bionic-updates,now 2.4.29-1ubuntu4.5 amd64

libapache2-mod-apreq2/bionic,now 2.13-5build3 amd64

libapache2-mod-perl2/bionic-updates,bionic-security,now
2.0.10-2ubuntu3.18.04.1 amd64

libapache2-request-perl/bionic,now 2.13-5build3 amd64

perl/bionic-updates,bionic-security,now 5.26.1-6ubuntu0.3 amd64

perl-base/bionic-updates,bionic-security,now 5.26.1-6ubuntu0.3
amd64

Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/

Re: Compile mod_perl 1.0 on ubuntu 12.04 or later

[Gazzali Jaleel]

On 2/24/2019 4:44 PM, Randolf Richardson wrote:

On 2/22/19 10:54 AM, Matthias Schmitt wrote:

I doubt that you will be able to compile mod_perl 1.x with newer compilers and 
operating systems.


Hold my beer :).

[sNip]

I have a Makefile that does all of this.  I suppose I could publish
it on github or something, but given the age of apache 1.3, it
seems irresponsible to publish it at this point :).


Michael:  You deserve to get two beers back for this -- it's
wonderful that anyone can get help to get older systems working.

I do agree with you overall though that the focus should be on
Apache HTTPd 2.4, and given that the older options are discontinued I
also encourage putting time and effort into upgrading Perl code
instead of trying to get the older Apache HTTPd 1.x working.

As long as one isn't relying on the client's dynamic TCP port number
from $r->connection->remote_addr->port for anything (as I've
discovered no longer works in the current release of mod_perl2),
updating to the newest mod_perl2 should ultimately be relatively
problem-free.  (This client port number business has not been a high
priority for me to raise as an issue, but if it is something that
Hans or anyone else is needing I'll gladly chime in with my vote for
wanting it fixed.)


Does this work for you?
$r->connection->client_addr->port;

The doc. states remote_addr returns an APR::SockAddr object but there's 
no remote_addr in my Apache2::Connection. However, there's a client_addr 
which does return an APR::SockAddr object.




Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/

Re: mod_perl interpreter pool

[Gazzali Jaleel]

On 2/24/2019 1:32 PM, André Warnier (tomcat) wrote:

On 24.02.2019 01:50, Gazzali Jaleel wrote:


On 2/22/2019 2:15 PM, John Dunlap wrote:

The Prefork MPM has the following settings:

 StartServers 5
 MinSpareServers   5
 MaxSpareServers  10
 MaxRequestWorkers 150
 MaxConnectionsPerChild   0


I see these Apache directives but the documentation states that they 
only apply to a

threaded mod_perl/Apache which prefork definitely is not:
PerlInterpStart
PerlInterpMax
PerlInterpMinSpare
PerlInterpMaxSpare
PerlInterpMaxRequests

How does mod_perl allocate interpreters to the prefork worker 
processes? Is there one
perl interpreter for each of preform worker? Is there a pool of perl 
interpreters which
is smaller than the pool of prefork workers? Are there settings for 
configuring the size
of the perl interpreter pool? When a request comes in, does the user 
have to wait for a
perl interpreter process to start or is there already one waiting for 
them?


If you're asking about mod_perl and prefork:

Apache handles child process creation. Each Apache child process loads 
the Perl

interpreter when it starts


Actually, I believe that since this is "prefork", it is the main Apache 
process (which already contains a perl interpreter) which gets "forked" 
(in other words duplicated, as it is) to create a child.  So there is 
not really a perl interpreter "being started" here (at least not in the 
sense of "being loaded" etc), it is already loaded and it is part of 
what is being duplicated.
(For a more detailed and precise explanation and example, see : 
http://perl.apache.org/docs/2.0/user/handlers/server.html)

Correct me if I'm wrong.


That's right, thanks for catching it. Should've said child processes 
will already have the Perl interpreter loaded.




I have no qualms with the rest below, sounds correct to me.

  and the Perl interpreter persists in the process till the
process terminates. So, at any given time, there're as many Perl 
interpreters loaded and
ready as there're Apache processes. When a request comes in, if 
there's an available
Apache process to serve the request, it's served. If not, Apache will 
create a new process

or queue the request to be served when a process becomes available.

With the numbers above, your server is able to handle 150 simultaneous 
requests. If
processes are not busy serving requests, then Apache will kill idle 
processes based on
(Min|Max)SpareServers of 5,10. For an overly simple example, if you 
get 150 requests at
8:30 am,  the server could create 145 processes to meet demand. 
However, if not busy at
8:31 am, when everyone has stepped away for coffee, your process count 
could be down near
10. When the boss comes in at 10am and it's back to work, the server 
will create 140 new

... at 10:01am, it's down to 10 again.

Generally, with mod_perl, you don't want Apache to kill idle processes 
but want them to be
around, ready to handle new requests. For maximum performance,  
(Min|Max)SpareServers
could be as high as your MaxRequestWorkers. Of course, all of this 
depends on your RAM,
CPU utilization etc. and you should be able to find a happy medium as 
you tweak the numbers.




--
John Dunlap
/CTO | Lariat/
/
/
/*Direct:*/
/j...@lariat.co <mailto:j...@lariat.co>/
/
*Customer Service:*/
877.268.6667
supp...@lariat.co <mailto:supp...@lariat.co>

Re: mod_perl interpreter pool

[Gazzali Jaleel]

On 2/22/2019 2:15 PM, John Dunlap wrote:

The Prefork MPM has the following settings:

     StartServers 5
     MinSpareServers   5
     MaxSpareServers  10
     MaxRequestWorkers 150
     MaxConnectionsPerChild   0


I see these Apache directives but the documentation states that they 
only apply to a threaded mod_perl/Apache which prefork definitely is not:

PerlInterpStart
PerlInterpMax
PerlInterpMinSpare
PerlInterpMaxSpare
PerlInterpMaxRequests

How does mod_perl allocate interpreters to the prefork worker processes? 
Is there one perl interpreter for each of preform worker? Is there a 
pool of perl interpreters which is smaller than the pool of prefork 
workers? Are there settings for configuring the size of the perl 
interpreter pool? When a request comes in, does the user have to wait 
for a perl interpreter process to start or is there already one waiting 
for them?


If you're asking about mod_perl and prefork:

Apache handles child process creation. Each Apache child process loads 
the Perl interpreter when it starts and the Perl interpreter persists in 
the process till the process terminates. So, at any given time, there're 
as many Perl interpreters loaded and ready as there're Apache processes. 
When a request comes in, if there's an available Apache process to serve 
the request, it's served. If not, Apache will create a new process or 
queue the request to be served when a process becomes available.


With the numbers above, your server is able to handle 150 simultaneous 
requests. If processes are not busy serving requests, then Apache will 
kill idle processes based on (Min|Max)SpareServers of 5,10. For an 
overly simple example, if you get 150 requests at 8:30 am,  the server 
could create 145 processes to meet demand. However, if not busy at 8:31 
am, when everyone has stepped away for coffee, your process count could 
be down near 10. When the boss comes in at 10am and it's back to work, 
the server will create 140 new ... at 10:01am, it's down to 10 again.


Generally, with mod_perl, you don't want Apache to kill idle processes 
but want them to be around, ready to handle new requests. For maximum 
performance,  (Min|Max)SpareServers could be as high as your 
MaxRequestWorkers. Of course, all of this depends on your RAM, CPU 
utilization etc. and you should be able to find a happy medium as you 
tweak the numbers.




--
John Dunlap
/CTO | Lariat/
/
/
/*Direct:*/
/j...@lariat.co /
/
*Customer Service:*/
877.268.6667
supp...@lariat.co