Question

简短版：

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

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

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

（两者都是运行mod_perl提供的好处）

备注：

我们并不太关心mod_perl提供的任何额外好处，例如深度Apache集成。
这将是一个纯粹的应用服务器，这意味着不需要任何特定于Web的功能（如果应用服务器提供它就不是问题，只是不需要）。
我们当然会考虑明显的标准（原始速度，生产就绪稳定性，主动开发，在我们关心的操作系统上运行的能力）。我感兴趣的是我们可能希望从这样的框架/服务器中获得的微不足道和微妙的东西。

背景

在$ work，决定他们想要替换当前情况的权力（简单的webapps正在Embperl中开发并通过Apache / mod_perl部署）。

决定使用一个（自行开发的）MVC系统，该系统将为View提供Java Spring前端;并且Controller会将后端服务请求分解为执行模型职责的每个应用程序服务（不要挂在这个细节上 - 它与主要问题不太相关）。

后端服务的一个选项是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作为持久服务器端应用程序容器所提供的任何性能优势!!!

因此，我们正在研究可能的app容器以提供相同的功能。

（作为旁注，是的，我们考虑过简单地运行一个带有mod_perl的Apache实例作为这样的app容器，作为一种可行的可能性。但是，由于不需要web功能，我想看看是否有其他选项可能适合该法案）。

Answer 1

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

Starman是一个可以投入生产的服务器，为了扩展目的，在反向代理（this SO question may helps you）后面安装一组Starman实例非常容易

Answer 2

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

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

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

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

祝你好运，玩得开心！

Answer 3

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

我应该使用什么标准来评估Perl“app server”（mod_perl替换）？

3 个答案: