我该使用什么标准来评估一个Perl“应用服务器”（替代mod_perl）？

Question

简短版:

我应该使用哪些标准来评估可能的Perl“应用服务器”候选项（mod_perl替代品）？

我们正在寻找一种框架，可以允许重复执行各种Perl程序（作为服务），而不会产生以下成本：

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

2. 每次执行都加载/编译Perl模块

(这两者都是运行mod_perl提供的优点)

注意事项：

• 我们不太关心mod_perl提供的任何其他好处，比如深度Apache集成。

• 这将是一个纯粹的应用服务器，意味着不需要任何特定于Web的功能（如果应用服务器提供了它，那么也不会成为问题）。

• 当然，我们会考虑明显的标准（原始速度，生产就绪稳定性，活跃的开发，能够在我们关心的操作系统上运行）。 我感兴趣的是更少见但微妙的东西，即我们可能希望从这样的框架/服务器中获得什么。

背景：

在公司，决策者们决定要替换当前的情况（使���Embperl开发简单Web应用程序，并通过Apache/mod_perl部署）。

决定使用一个（自制的）MVC系统，该系统将具有Java Spring前端用于View； 而Controller将把后端服务请求解析为执行Model职责的每个应用程序服务（不要太拘泥于细节-这与主要问题不相关）。

后端服务的选项之一是Perl，这样我们就可以利用所有现有的Perl IP（库，Web应用程序后端代码）并向前推进，而无需将其全部移植到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功能，我想看看是否有其他选项可以胜任)。

- DVK

---

Java 和 Perl 的部分之间将使用什么协议进行通信？ - innaM

但是，您不能通过在apache mod_perl环境（或PSGI）中继续运行服务并从新的Java Swing应用程序中与它们所有进行通信来保持一个启动的“并行性”吗？这样会很慢吗？至少perl解释器正在运行、等待和准备。 - G. Cito

抱歉，我的上一条评论实际上是关于你的附注的进一步问题/回应。你测试过这个mod_perl应用容器方法吗？看起来www.apache.org使用```Qpsmtpd```以此方式来帮助处理他们的邮件列表传递（即嵌入到apache mod_perl实例中作为SMTP服务）。所以apache和mod_perl...“它们不仅仅是用于Web”的 :-) - G. Cito

@innaM - 协议并不是非常重要（也就是说，灵活性很高）。当前的无应用服务器设计只是一个命令行界面，通过 STDIN 传递等效的查询字符串，并将 JSON 响应发射到 STDOUT。 - DVK

@G.Cito - 是的，mod_perl是可能的替代方案之一。然而，我们需要看看是否存在更好的选择。 - DVK

潜在的社区维基候选人？ - G. Cito

Answer 1

Starman 是一个高性能的预派生 PSGI/Plack web 服务器，可以在这种情况下使用。可以轻松构建一个服务于无状态 JSON 对象的 REST 应用程序（这是一个简单的用例）。

Starman 是一个生产就绪的服务器，很容易安装一组 Starman 实例在反向代理后面（这个 SO 问题可能会帮助你），以进行扩展。

- Miguel Prz

Answer 2

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

由于您提到“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应用程序通信，但它可能有助于管理/监视您想出的任何解决方案。祝你好运，玩得开心！

- G. Cito

---

如果它们可以被高效地“守护进程化”，那就好了（原因不是技术上的，而是需要编写和测试守护进程的人力需求），否则我们显然不需要应用服务器 :) - DVK

请注意，使用Ubic，您可以“守护”几乎任何东西（就像您可以使用runit、daemontools、s6等工具一样）。我将编辑我的答案以澄清这一点。进行一些研究，比较在Ubic下作为“守护进程”运行的perl脚本与按请求或在mod_perl下启动它的响应性可能会有所帮助。但是要使其有用，我们需要知道您计划如何让Web服务和后端彼此通信。正如@Miguel所指出的那样，使用JSON进行此操作将非常容易。 - G. Cito

Answer 3

你可以使用HTTP::Daemon创建一个简单的守护程序，并在后期编译代码所需的必要部分(require)或在守护程序启动前提前编译，从而获得所有好处。

- maxim4d