So I am a mod_perl user for about 25 years now - pretty much I started with perl and mod_perl together :)
Looking at the conversation I can see it is diverging into two parts - one what to do with mod_perl and in general concerns with Perl. Yes we have alternatives to mod_perl and you should definitely consider Mojolicious if that suits your requirement but for that you need to understand what mod_perl is offering. mod_perl is allowing you to leverage apache as a foundation to handle HTTP requests while your code does whatever business needs you have to fulfill. To give an example - this is 1999 the internet has realized you could hack open SQL Servers on the internet using scripts. Now I am managing a website for a startup running a production server with 128MB RAM I think. Now imagine all the script kiddies hammering away at your webserver looking for SQL Server when you have only apache and mysql :( For the first three days our server was pretty much dead - it would maybe honor a request every few minutes. To solve it I add a PerlTransHandler and drop all requests for the nasty endpoints - guess what we are back online with no impact to the server any more. Another example - we learnt you could write Apache configuration in perl - it blew our mind. Rest assured most people dont know about this capability so God forbid you are stuck trying to solve something in this you will not find anything on Google. What we did was templatized the complete Apache config. We have clean segregation of which Location and LocationMatch urls need which library. We use a for loop to apply auth on everything and our configs are very easy to understand for perl programmers and it is very compact. Company decided everyone needed SSL - most teams needed to plan it out. We just included mod_ssl get the certificates and updated our config and we were done in three days. Need to add custom header on every request - done in two lines. We need to use the application in a variety of server configs - no problem we compute the number of child processes to spawn at run time. Have a low latency service which needs to respond fast - changed the logging to report the processing time as Aapche knows. What we learnt you do mod_perl if you have a plan to leverage apache. If you have a big fat application where receiving the request is a minor part of the solution then we split it up and handle the request in mod_perl and then hand over the hard work to a farm of servers. This way your mod_perl instance scales based on the volume of requests and the workers scale based on the amount of work to be done. Now why is it not popular - primarily because it was so difficult to setup initially. Most people did not have access to control apache config and they did not know what could be done. The community did not help encourage it either. I do not have root access on our servers -who cares. I have my own relocatable apache, own relocatable perl running on a non standard port and I dont bother any super user for help. As for Perl that is a separate conversation and I wont want to diverge from the subject of this email :) On Wed, Aug 7, 2024 at 6:07 PM Jeff Pang <j...@simplemail.co.in> wrote: > For me I run several apps on mod_perl, including a AI prediction app > which costs heavy CPU/ram. These apps run for long time and behave just > fine. > > Today it sounds very few people use mod_perl for development/deployment. > I think the main reasons may include, > > 1. perl for web development is somewhat out of date > 2. mp lacks threads support > 3. lacks a modern framework (rails like) > > And others? what's your thought? > > Thanks > > -- > regards, > Jeff Pang >
