简短版本：
我应该使用什么标准来评估Perl"应用程序服务器"(mod_perl替代品(的可能候选者？
我们正在寻找某种框架，它允许重复执行各种Perl程序(作为服务(，而无需以下成本：
- 每次
执行一次重新调用 Perl 解释器
每次执行一次加载/编译 Perl 模块
(这两者都是运行mod_perl提供的好处(
笔记：
-
我们不太关心mod_perl太多所带来的任何额外好处，比如深度Apache集成。
-
这将是一个纯应用程序服务器，这意味着不需要任何特定于 Web 的功能(如果应用程序服务器提供它，这不是问题，只是不需要(。
-
我们当然会考虑明显的标准(原始速度、生产就绪稳定性、积极开发、在我们关心的操作系统上运行的能力(。我感兴趣的是我们可能希望从这样的框架/服务器中获得的不那么琐碎和微妙的东西。
背景：
在$work，决定他们想要取代当前情况的权力(在Embperl中开发并通过Apache/mod_perl部署的简单Web应用程序(。
决定使用一个(本土的(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功能，我想看看是否有任何其他选项适合该法案(。
Starman是一个高性能的预分叉PSGI/Plack Web服务器，可用于该上下文。构建为无状态 JSON 对象提供服务的 REST 应用程序很容易(这是一个简单的用例(。
Starman是一个生产就绪的服务器，在反向代理后面安装一组Starman实例非常容易(这个SO问题可能会帮助你(，用于扩展目的
我想你已经确定了你需要知道什么和要测试什么：执行时间与内存。您还需要评估mod_perl获得的灵活性和易于部署性，以及保留已开发软件的实用性(以及员工积累的经验(的巨大优势。请记住，如果您的新前端要与您自己的网络中的应用程序进行通信，则可以轻松地按 CPU 和机器分离服务。很大程度上取决于您如何"网络化"服务，以及它们是否可以有效地"守护程序化"。当然，Web前端有很多方法可以与其他服务通信，perl可以处理几乎所有服务......蒂姆托蒂。
既然你提到"tuits"(即"人力"(作为一个约束，也许短期内最好的方法是设置一个单独的apache - mod_perl实例作为"应用程序容器"并以这种方式运行你的应用程序(因为它们已经以这种方式运行良好，这是正确的吗？毕竟，apache(和mod_perl(是众所周知的，经过实战测试，并且非常可调整和可配置。部署选项非常灵活(同一台机器、不同的机器、故障转移、负载平衡、云、本地、虚拟机(，并且它们也经过了很好的测试。
一旦运行了它，您就可以开始尝试各种"所需的低人力"方法来神奇地守护您的应用程序和服务，而无需apache。 Plack和Starman已经提到，Mojolicious::是另一个能够与 JSON websockets 等(和 Plack(一起使用的框架。这些也经过了很好的测试，但可能不如mod_perl和Apache那么熟悉。不过，如果你是一个perl商店，使用这些"现代"工具应该不会有困难。有一天，如果你最终有了更多的资源，你可以为所有基于perl的服务建立一个复杂的网络平台，并使用CPAN上所有很酷的"新"(或至少比mod_perl更新(的东西，如POE，Plack等。在解决业务问题时，您可能会在开发很酷的东西时获得很多乐趣。
澄清我之前的评论：Ubic(参见MetaCPAN上的Ubic(可以守护(从而预编译(你的perl工具，并提供一些框架免费提供的监控和管理工具。有一个 Ubic 模块设计用于Plack称为 Ubic::Service::Plack 。 就其本身而言，Ubic 并没有为您的新 Java/Swing 应用程序提供一个简单的解决方案来与您的 perl 应用程序进行通信，但它可能有助于管理/监控您提出的任何解决方案。
祝你好运，玩得开心！
HTTP：:D aemon创建一个简单的守护进程，并具有稍后(require(或在守护程序启动之前编译代码的必要部分的所有好处。