Re: [DISCUSS] The future of mod_perl

2021-03-19 Thread Matthias Schmitt
Hello,

> On 18 Mar 2021, at 23:05, Michel Jansen  wrote:
> 
> Isnt it interesting to know how many, happy, users modperl has?

Yes, count me in. Out of curiosity I tried to search for a mod_perl alternative 
for our applications, but have not found anything which could replace it. It 
might be old, but it is working. And it does this very well.
Even though I have not the knowledge to participate in the development process, 
I would be willing to invest more time into testing potential pre-releases or 
bug fixes.

Best regards

Matthias Schmitt

magic moving pixel s.a.
23, Avenue Grande-Duchesse Charlotte
L-3441 Dudelange
Luxembourg
Phone: +352 54 75 75
http://www.mmp.lu





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

2021-03-19 Thread 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