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

Question

短版本__：

我应该使用什么标准来评估Perl "app server“(mod_perl替换)的可能候选程序？

我们正在寻找某种框架，该框架允许重复执行各种Perl程序(作为服务)，而无需支付以下费用：

1. 每次执行重新启动perl解释器一次。
2. 每次执行一次加载/编译Perl模块

(这两者都是运行mod_perl所带来的好处)

备注：

• 我们不太关心mod_perl提供的任何额外好处，比如深入的Apache集成。
• 这将是一个纯应用服务器，这意味着不需要任何特定于web的功能(这不是一个问题，如果应用服务器提供，只是不需要)。
• 当然，我们将考虑明显的标准(原始速度，生产准备稳定，积极开发，运行在我们关心的开放源码软件上的能力)。我感兴趣的是不那么琐碎和微妙的事情，我们可能希望从这样的框架/服务器。

背景：

在$work，被决定要替换当前情况的权限(在Embperl中开发并通过Apache/mod_perl部署的简单webapp)。

这个决定是使用一个(自己开发的) MVC系统，它将为视图提供一个Java前端；Controller将把后端服务请求分配给执行Model职责的每个应用程序服务(不要对此细节挂起电话--这与主要问题没有太大关系)。

后端服务的选择之一是Perl，这样我们就可以利用所有现有的Perl (库，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功能，我想看看是否有任何其他选项符合此要求)。

Answer 1

史达曼是一种高性能的预分叉式PSGI/Plack web服务器，可以在该上下文中使用。构建一个为无状态JSON对象服务的REST应用程序很容易(这是一个简单的用例)。

Starman是一台可以生产的服务器，在反向代理(这个问题可能对你有帮助。)后面安装一组Starman实例非常容易，以便进行缩放。

Answer 2

我认为您已经确定了您需要知道的内容以及需要测试的内容:执行时间与内存。您还需要评估使用mod_perl所获得的灵活性和部署的易用性，以及维护您已经开发的软件的有用性(以及您的工作人员积累的经验)的巨大胜利。记住，如果您的新前端将在您自己的网络中与您的应用程序对话，您可以轻松地通过CPU和机器将服务分开。这在很大程度上取决于“web”您如何做出服务，以及它们是否可以有效地“去功能化”。当然，web前端有很多与其他服务对话的方法，perl可以处理几乎所有这些服务。TIMTOWTDI。

既然您提到"tuits“(即”人工“)是一种约束，那么短期内最好的方法可能是将单独的apache - mod_perl实例设置为”应用程序容器“，并以这种方式运行应用程序(因为它们已经以这种方式运行良好，这是正确的吗？)毕竟，apache (和mod_perl)是众所周知的，经过了战斗测试，并且具有明显的可调整性和可配置性。部署选项非常灵活(相同的机器、不同的机器、故障转移、负载平衡、云、本地、VM)，它们也经过了很好的测试。

一旦开始运行，您就可以开始尝试各种“低人力需求”的方法，在没有apache的情况下神奇地去守护您的应用程序和服务。已经提到了Plack和Starman，Mojolicious::是另一个能够使用JSON等(和Plack)的框架。它们也经过了很好的测试，但可能不像mod_perl和Apache那么熟悉。不过，如果您是perl专卖店，那么使用这些“现代”工具就不会有什么困难。有一天，如果您确实获得了更多的资源，您可以为所有基于perl的服务构建一个复杂的网络平台，并在CPAN上使用所有酷的“新”(或至少比mod_perl新的)东西，如POE、Plack等。在解决业务问题时，您可能会有很多乐趣来开发很酷的东西。

为了澄清我先前的评论：Ubic (请参阅Ubic on MetaCPAN)可以去守护(从而预编译)您的perl工具，并提供一些随框架免费提供的监视和管理工具。有一个可用于Plack的Ubic模块，称为Ubic::Service::Plack。Ubic本身并不能为您的新Java/Swing应用程序提供与您的perl应用程序对话的简单解决方案，但它可能有助于管理/监视您想出的任何解决方案。

祝你好运，玩得开心！

Answer 3

您可以使用HTTP::Daemon创建一个简单的守护进程，并在后台程序启动之前编译代码的必要部分(require)。