如何在非持久性CGI流程中提高Moose性能？

Moose是一个梦幻般的对象框架.麻烦的是,与它的依赖关系一起,它是非常大的.我们的分析表明,在我们的平台上,只需加载Moose就会在非持久性CGI应用程序脚本上产生5-6秒的开销.这对于这些一次性应用程序来说是不可接受的.

相比之下,当我们使用持久性流程系统(例如FCGI)时,这种启动开销被消除(或者更确切地说,只发生一次),一切都很顺利.我们遇到的问题是我们无法保证所有代码都始终在持久进程下运行.

我们调查使用鼠标作为Moose的功能有限的替代品,但事实证明(如本答案所述)这不是一个可行的选择.我们编写的任何与Moose一起工作的库都无法以微妙但重要的方式使用Mouse.而且我们真的不想分叉我们所有的模块,以便我们可以在持久环境中支持Moose,而在"vanilla"CGI中支持Mouse.

鉴于此,我们有以下选择:

根据需要,将我们的内部模块与Moose或Mouse一起使用.(呸!)

只开发我们的FCGI/Moose模块.不再支持"香草"CGI了.如果我们必须编写非持久性脚本,他们将无法利用我们的内部模块.

不要使用Moose或Mouse,而是使用其他一些对象框架.

哪个选项最好？我们现在正倾向于2,如果我们必须得到像香草CGI一样的东西,我们就会把它吸收.其他框架怎么样？我们应该关注哪些更轻量级的东西？

我倾向于放弃vanilla CGI支持.FCGI托管这些天真的很便宜,没有理由迎合香草CGI(IMO),因为它只是强化了Perl缓慢的观点.但如果你无法避免它,那么你可以使用像Object :: Tiny这样的东西.但是如果你需要角色,约束,元编程以及Moose提供的所有其他可爱,除非你放弃vanilla CGI,否则你运气不好.

您可以使用Moose编写后端服务器应用程序,然后编写非常小的简单CGI脚本来查询后端.

+-------+    +--------------+
| Small |===>|  Persistent  |
|  CGI  |<===| Moose Server |
+-------+  ^  +--------------+
           |
         Socket
       Connection

这或多或少是FCGI的作用,因此使用FCGI可能更有意义.

另一方面,拥有一个非cgi后端服务器可能会带来真正的好处,该服务器可以根据需要使用任何抽象接口.

例如,如果您使用TCP(或UDP)套接字,那么您可以让本机桌面应用程序与CGI相同的后端.

在你的情况下最合适的是真的取决于你的具体情况.根据情况的细节,我可以看到自己决定使用这种方法或您在上面概述的任何方法.

我的建议是选择#2,然后帮助我们重构Moose,以便CGI变得可行.fREW目前正在开发Moose测试套件,以便启用MooseX :: Antlers项目,该项目应该减少大部分开销,这意味着Moose无法用于CGI环境.

Matt Trout(mst),目前落后于MooseX :: Antlers的人,表示希望能够在CGI环境中运行应用程序,如果有必要的话.我建议现在坚持使用FCGI并纠缠他,你可以做些什么来帮忙!