大佬教程收集整理的这篇文章主要介绍了我应该使用什么标准来评估Perl“应用服务器”(mod_perl替换)?,大佬教程大佬觉得挺不错的,现在分享给大家,也给大家做个参考。
我应该使用什么标准来评估Perl“应用服务器”(mod_perl替换)的可能候选者?
我们正在寻找一种可以重复执行各种Perl程序(作为服务)的框架,而不需要付出以下代价:
>每次执行一次重新启动perl解释器
>每次执行一次加载/编译Perl模块
(这两个都是运行mod_perl提供的好处)
笔记:
>我们并不关心mod_perl提供的任何其他优点,如深度Apache集成.
>这将是一个纯粹的应用程序服务器,这意味着不需要任何Web特定的功能(如果应用程序服务器提供它不是问题,只是不需要).
>我们当然会考虑明显的标准(原始速度,生产稳定性,积极发展,我们关心的操作系统的运行能力).我感兴趣的是这样一个框架/服务器可能不太琐碎和微妙的东西.
背景:
在$工作中,决定要替换当前情况的功能(简单的webapps是在Embperl中开发并通过Apache / mod_perl部署的).
决定使用一个(本土的)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功能,我想看看是否有其他选项可能适合账单).
Starman是一个生产就绪的服务器,在反向代理(this SO question may helps you)后面安装一套Starman实例非常简单,用于缩放
以上是大佬教程为你收集整理的我应该使用什么标准来评估Perl“应用服务器”(mod_perl替换)?全部内容,希望文章能够帮你解决我应该使用什么标准来评估Perl“应用服务器”(mod_perl替换)?所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错,欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。