我应该使用什么标准来评估 Perl “应用服务器”（mod_perl 替换）？答案

【问题标题】：What criteria should I use to evaluate a Perl "app server" (mod_perl replacement)?我应该使用什么标准来评估 Perl “应用服务器”（mod_perl 替换）？
【发布时间】：2013-06-03 20:04:57
【问题描述】：

短版：

我应该使用什么标准来评估 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 功能，我想看看是否有其他选项可能适合）。

【问题讨论】：

将使用什么协议使 java 和 perl 部分相互通信？
但是你不能通过继续在apache mod_perl 环境（或 PSGI）中运行服务并从你的新 Java Swing 事物中与它们交谈来保持一个启动的“并行性”吗?是不是太慢了？至少 perl 解释器正在运行，等待并准备就绪。
对不起，我的意思是我之前的评论是关于您的旁注的进一步问题/回应。您是否测试过这种mod_perl 应用容器方法？似乎 www.apache.org 以这种方式运行或运行 Qpsmtpd 来帮助处理他们的邮件列表传递（即作为 SMTP 服务嵌入到 apache mod_perl 实例中）。所以apache 和mod_perl ...“它们不仅仅用于网络”:-)
@innaM - 协议不是非常相关（如灵活）。当前的无应用服务器设计只是简单的命令行界面，在 STDIN 上传递等效的查询字符串并将 JSON 响应发送到 STDOUT。
@G.Cito - 是的，mod_perl 是可能的替代品之一。但是，我们需要看看是否存在更好的替代方案。

标签： perl web-applications application-server mod-perl

【解决方案1】：

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

【讨论】：

【解决方案2】：

我认为您已经确定了您需要了解和测试的内容：执行时间与内存。您还需要评估使用mod_perl 获得的灵活性和易于部署，以及保留您已经开发的软件的实用性（以及您的员工积累的经验）的巨大胜利。请记住，如果您的新前端将与您自己网络中的应用程序通信，您可以轻松地按 CPU 和机器分离服务。很大程度上取决于您可以如何“网络化”您的服务以及它们是否可以有效地“守护”。当然，Web 前端有很多方法可以与其他服务通信，而 perl 几乎可以处理所有这些……TIMTOWTDI。

由于您提到“tuits”（ie“manpower”）作为约束，短期内最好的方法可能是设置一个单独的 apache - mod_perl 实例作为“应用程序容器”并以这种方式运行您的应用程序（因为它们已经以这种方式运行良好，这是正确的吗？）。毕竟，apache（和mod_perl）是众所周知的，经过实战考验，并且非常可调整和可配置。部署选项非常灵活（同一台机器、不同机器、故障转移、负载平衡、云、本地、VM），并且它们也经过了很好的测试。

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

澄清我之前的评论：Ubic（参见 MetaCPAN 上的 Ubic）可以守护（并因此预编译）您的 perl 工具，并提供一些随框架免费提供的监控和管理工具。有一个 Ubic 模块可用于 Plack，称为 Ubic::Service::Plack。 Ubic 本身并没有为您的新 Java/Swing 应用程序与您的 perl 应用程序通信提供简单的解决方案，但它可能有助于管理/监控您提出的任何解决方案。

祝你好运，玩得开心！

【讨论】：

" 如果它们可以被有效地“守护”。 - 他们不能（原因不是技术性的，而是编写和测试守护进程的人力需求），否则我们显然不需要应用服务器 :)
请注意，使用Ubic，您几乎可以“守护”任何东西（就像使用runit、daemontools、s6 等一样）。我将编辑我的答案以澄清这一点。比较在Ubic 下作为“守护程序”运行的 perl 脚本的响应性与根据请求或在mod_perl 下启动它的响应性的一些研究可能会有所帮助。但是为了使这一点有用，我们需要知道您计划如何让 Web 服务和后端相互通信。正如@Miguel 所说，为此使用 JSON 相当容易。

【解决方案3】：

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

Starman 是一个生产就绪的服务器，很容易在反向代理 (this SO question may helps you) 后面安装一组 Starman 实例，以实现扩展

【讨论】：