我应该使用什么标准来评估Perl“应用服务器”(mod_perl替换)？

简短版本：

我应该使用什么标准来评估Perl“应用服务器”(mod_perl替换)的可能候选者？

我们正在寻找一种可以重复执行各种 Perl 程序(作为服务)的框架,而不需要付出以下代价：

>每次执行一次重新启动perl解释器

>每次执行一次加载/编译Perl模块

(这两个都是运行mod_perl提供的好处)

笔记：

>我们并不关心mod_perl提供的任何其他优点,如深度Apache集成.

>这将是一个纯粹的应用程序服务器,这意味着不需要任何Web特定的功能(如果应用程序服务器提供它不是问题,只是不需要).

>我们当然会考虑明显的标准(原始速度,生产稳定性,积极发展,我们关心的操作系统的运行能力).我感兴趣的是这样一个框架/服务器可能不太琐碎和微妙的东西.

背景：

在$工作中,决定要替换当前情况的功能(简单的webapps是在Embperl中开发并通过Apache / mod_perl部署的).

决定使用一个(本土的)MVC系统,该系统将具有用于View的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功能,我想看看是否有其他选项可能适合账单).