15

短版：

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

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

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

  2. 每次执行一次加载/编译 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 功能，我想看看是否有任何其他选项可以符合要求）。

4

3 回答 3

7

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

Starman 是一个生产就绪的服务器，为了扩展目的，在反向代理后面安装一组 Starman 实例非常容易（这个 SO 问题可能对您有所帮助）

于 2013-06-07T15:27:35.633 回答
5

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

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

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

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

祝好运并玩得开心点！

于 2013-06-07T14:37:44.300 回答
1

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

于 2013-06-11T01:34:11.050 回答