Major move to Mojolicious - How?

[jocke76]

Hi

Background
With the changes to apache2/apreq that has been done the last couple of years our environment starts to crackle! 😬
We use CGI::Apache2::Wrapper instead of CGI since the memory footprint for CGI is so big, and recently when upgrading to Ubuntu 24.04 some functionality (upload) stopped working when using CGI::Apache2::Wrapper.
One more important thing is that we use a in-house modified version of CGI::Ajax for handling requests to the application.

I've been actively developing this web application in perl since 1999. It's a traditional LAMP stack using mod_perl and mostly our own javascript where needed, and Template Toolkit for templating. The code base is about 250 000 lines of code spread over 200 pm files, 100 perl scripts and 200 templates. Most of the installations (about 40 in production) uses Docker to run the apache process and then relies on a central MariaDB server and nginx as proxy.

Mojolicious
So, I've started thinking about the next step, where we need to go, and stumbled upon Mojolicious!

Questions ... that I can think of, but I'm welcome to have feedback on things I haven't maybe thought of!

1. Is there any approach to 'sneak' Mojolicious in to application? I'm afraid that we would need to 'wrap' about 1200 subs and write routes for them as well.
2. Is Mojolicious the way to go?
3. Speed? How does it compare to Apache2+mod_perl?
4. Will we have issues with memory footprint, since the code base is so large? (Today with Apache+!CGI.pm it's about 300 Mb but some of that is shared, but with CGI.pm it's about 500 Mb, for each apache child - using prefork.) One of our servers, running docker, hosts about 25 installations (97 apache childs) on 32 Gb without swap (don't ask why 🤔).

Thanks in advance!

[christopherraa]

Hi Joakim,

Having been through that process I would say it depends on the architecture and state of the current code base. What I've seen a lot of is structures / architecture of legacy applications (not meant derogatory!) that would be considered anti-patterns today, even though they would be consideres best practise for the time when it was created, and even now given the kind of beast mod_perl is. Those are the things that I've seen makes it so that most of these kinds of projects cannot simply be copy-pasta'ed. That said; these processes need to be super risky. There are lots of mitigating steps one can take. Some of the ones we focus heavily on are:

• scope reduction: making sure we have mechanisms for catching scope creep for individual tasks (workflow management basically)
• change isolation: change and conversion in one area should not adversely affect other parts of the application
• reproducibility: establishing robust tests for functionality under conversion, guards against regression
• reversibility: changes (especially deployed changes) must be reversable if unintended sife-effects are discovered

To answer your specific questions:

1. The methodology we use here at $work (where we do these things) is centered around the above items and the way it is done will in practical terms depend on details of the application in question. Usually we do migrations on an endpoint-to-endpoint basis where we endure that the ingress is able to route traffic to the new "modernized" application endpoints. This usually work great. For backend-changes, job queues etc there are a couple other factors we consider in our analysis but it is normally not difficult to do migration of those kinds of workloads either, primarily due to the focus on scope reduction.
2. "Yes" will be my answer. Been using Mojolicious since shortly after its inception and I must say I have never seen this level of quality or stability in an open source project.
3. Speed basically depend on the nature of your workload. What we have observed is a far lower memory footprint than mod_perl, higher level of stability, smoother hot-reloading (zero downtime deploys) and just generally higher throughput. You will probably be limited by the latency of the database operations you perform rather that the internals of Mojolicious.
4. Again; this depend highly on the workloads and the codebase, but generally I would say that what we observe is that Apache2+mod_perl while having good shared memory handling also bring a lot of complexity that effectively reduce scalability. Overall I would say you should expect your memory footprint to go down and efficiency of memory utilization go up.

I would also like to add that another benefit you will see is a massive reduction in complexity, both inter-application and in deployment, plus the added benefit of a higher iteration speed in doing further development on the application.

Ping me if you'd like to discuss this further.

[jocke76]

Thank you Christopher for a quick and comprehensive answer!
I see that you are located in Norway and as you've probably seen I'm in Sweden. I would be happy to pay for a few hours of one-on-one remote sessions to evaluate Mojolicious in relation to our code, if that is possible. If it's okey I'll just send you an email?

[christopherraa]

Absolutely. You can reach me at christopher [at] stix.no .

[Akron]

Hi!

In addition to the previous answer, I would suggest to also have a look at Mojolicious::Plugin::CGI as a reasonable first step to wrap a CGI-based application in Mojolicious. This is relatively simple and gives you the early opportunity to use Test::Mojo directly. After migrating your Tests to Test::Mojo I agree with the Endpoint-to-endpoint approach.

In my experience, Mojolicious is ideal for this type of migration.

[jocke76]

Thank you Akron! 👍
I will have a look at Mojolicious::Plugin::CGI.