What criteria should I use to evaluate a Perl "app server" (mod_perl replacement)?

Question

Short version:

What criteria should I use to evaluate possible candidates for a Perl "app server" (mod_perl replacement)?

We are looking for some sort of framework which will allow executing various Perl programs repeatedly (as a service) without the costs of:

1. re-launcing perl interpreter once per each execution

2. loading/compiling Perl modules once per execution

(both of which are the benefits that running mod_perl provides)

Notes:

• We do NOT much care about any additional benefits afforded by mod_perl too much, such as deep Apache integration.

• This will be a pure app server, meaning there is no need for any web specific functionality (it's not a problem if the app server provides it, just won't be needed).

• We will of course consider the obvious criteria (raw speed, production-ready stability, active development, ability to run on OSs we care about). What I'm interested in is less trivial and subtle things that we may wish from such a framework/server.

Background:

At $work, the powers that be decided that they want to replace a current situation (simple webapps being developed in Embperl and deployed via Apache/mod_perl).

The decision was made to use a (home-grown) MVC system that will have a Java Spring front end for the View; and the Controller will parsel out back-end service requests to per-app services that perform Model duties (don't get hung up on details of this - it's not very relevant to the main question).

One of the options for back-end services is Perl, so that we can leverage all our existing Perl IP (libraries, webapp backend code) going forward, and not have to port 100% of it to Java.

To summarize:

    | View    | Model/app | Model loaded/executed by:                          |
================================================================================
OLD | Empberl | Model.pm | mod_perl has Model.pm loaded, called from view.epl  |
NEW | Java    | Model.pm | perl generic_model.pl -model Model (does "require") |
================================================================================

Now, those of you who did Perl Web development for a while, will immediately notice the most glaring problem with the new design:

    | Perl interpreter starts  | Perl modules are loaded and compiled |
=======================================================================
OLD | Once per mod_perl thread | Once per mod_perl thread
NEW | Once per EVERY! request  | Once per EVERY! request              |
=======================================================================

In other words, in the new model, we no longer have any performance benefits afforded by mod_perl as a persistent server side app container!!!

Therefore, we are looking at possible app containers to serve the same function.

(as a side note, yes, we thought about simply running an instance of Apache with mod_perl as such an app container, as a viable possibility. However, since web functionality is not required, I'd like to see if any other options may fit the bill).

Answer 1

Starman is a High-performance preforking PSGI/Plack web server that may be used in that context. It's easy to build a REST application that serves stateless JSON objects (this is a simple use case).

Starman is a production-ready server and it's really easy to install a set of Starman instances behind a reverse-proxy (this SO question may helps you), for scaling purposes