DVK*_*DVK 15 perl web-applications mod-perl application-server
短版:
我应该使用什么标准来评估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功能,我想看看是否有其他选项可能适合账单).
Starman是一个高性能的preforking PSGI/Plack Web服务器,可以在这种情况下使用.构建一个提供无状态JSON对象的REST应用程序很容易(这是一个简单的用例).
Starman是一个可以生产就绪的服务器,在反向代理后面安装一组Starman实例非常容易(这个问题可能会对你有帮助),用于扩展目的
我想你已经确定了你需要知道什么以及测试什么:执行时间与内存.您还需要评估您所获得的灵活性和易部署性以及mod_perl保留您已经开发的软件(以及您的员工积累的经验)的有用性的巨大成功.请记住,如果您的新前端将与您自己网络中的应用程序通信,则可以通过CPU和计算机轻松分离服务.很大程度上取决于"web-ish"如何制作您的服务,以及它们是否可以有效地"守护".当然,Web前端有很多方法可以与其他服务进行通信,而perl可以处理所有这些服务...... TIMTOWTDI.
既然你提到"tuits"(即 "manpower")作为约束,也许短期内最好的方法是设置一个单独的apache- mod_perl实例作为"应用程序容器"并以这种方式运行你的应用程序(因为它们运行良好,方式已经,这是正确的吗？).毕竟,apache(和mod_perl)是众所周知的,经过战斗测试,并且具有显着的可调性和可配置性.部署选项非常灵活(相同的计算机,不同的计算机,故障转移,负载平衡,云,本地,VM),并且它们也经过了很好的测试.
一旦你开始运行,你就可以开始尝试各种"低人力需求"的方法来神奇地守护你的应用程序和服务apache.Plack并且Starman已经提到过,Mojolicious::是另一个能够使用JSON websockets等(和Plack)的框架.这些也经过了很好的测试,但可能不像mod_perlApache 那样熟悉.如果你是一个perl商店,你应该没有困难使用这些"现代"工具.有一天,如果你有更多的资源最终,你可以打造出你的所有基于Perl业务的复杂的网络平台,并使用所有酷"新"(或至少更新比mod_perl)的东西上CPAN喜欢POE,Plack等等.当您解决业务问题时,您可能会有很多乐趣来开发很酷的东西.
澄清我之前的评论:( Ubic请参阅MetaCPAN上的Ubic)可以对您的perl工具进行守护(并因此预编译),并提供一些免费的框架监控和管理工具.有一个Ubic模块可供设计用于 Plack被叫Ubic::Service::Plack.Ubic本身并不能为您的新Java/Swing应用程序提供与您的perl应用程序通信的简单解决方案,但它可能有助于管理/监控您提出的任何解决方案.
祝好运并玩得开心点!