我应该使用什么标准来评估 Perl“应用程序服务器”（mod_perl 替代品）？

简洁版本:

我应该使用什么标准来评估 Perl“应用程序服务器”（mod_perl 替代品）的可能候选者？

我们正在寻找某种框架，它允许重复执行各种 Perl 程序（作为服务），而不会产生以下成本：

1. 每次执行时重新启动 perl 解释器一次

2. 每次执行时加载/编译 Perl 模块一次

（这都是运行 mod_perl 提供的好处）

Notes:

• 我们不太关心 mod_perl 提供的任何额外好处，例如深度 Apache 集成。

• 这将是一个纯粹的应用程序服务器，这意味着不需要任何特定于 Web 的功能（如果应用程序服务器提供它，这不是问题，只是不需要）。

• 我们当然会考虑明显的标准（原始速度、生产就绪的稳定性、积极的开发、在我们关心的操作系统上运行的能力）。我感兴趣的是我们可能希望从这样的框架/服务器中得到的不那么琐碎和微妙的事情。

背景：

在 $work 中，权力决定他们想要取代当前的情况（在 Embperl 中开发简单的 Web 应用程序并通过 Apache/mod_perl 进行部署）。

决定使用（自行开发的）MVC 系统，该系统将具有用于视图的 Java Spring 前端；并且控制器将解析后端服务请求到执行模型职责的每个应用程序服务（不要纠结于此细节 - 它与主要问题不太相关）。

后端服务的选项之一是 Perl，这样我们就可以利用所有现有的 Perl IP（库、webapp 后端代码），而不必将其 100% 移植到 Java。

总结一下：

    | 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") |
================================================================================

现在，那些进行过 Perl Web 开发一段时间的人会立即注意到新设计中最明显的问题：

    | 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              |
=======================================================================

换句话说，在新模型中，我们mod_perl 作为持久服务器端应用程序容器不再具有任何性能优势！

因此，我们正在寻找可能的应用程序容器来提供相同的功能。

（作为旁注，是的，我们考虑过简单地使用 mod_perl 运行 Apache 实例作为这样的应用程序容器，作为一种可行的可能性。但是，由于不需要 Web 功能，我想看看是否有其他选项可以符合要求）。

Starman https://metacpan.org/module/Starman是一个高性能预分叉 PSGI/Plack Web 服务器，可以在该上下文中使用。构建服务无状态 JSON 对象的 REST 应用程序很容易（这是一个简单的用例）。

Starman 是一个生产就绪的服务器，在反向代理后面安装一组 Starman 实例非常容易（这个问题可能对你有帮助 https://stackoverflow.com/questions/4003714/nginx-and-perl-fastcgi-vs-reverse-proxy-psgi-starman），用于缩放目的