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

Question

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

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

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

鉴于此，我们有以下选择：

1. 分叉我们的内部模块，根据需要使用Moose或Mouse。 （呸！）
2. 仅开发我们的FCGI / Moose模块。不再支持“香草”CGI了。如果我们必须编写非持久性脚本，他们将无法利用我们的内部模块。
3. 不要使用Moose或Mouse ，而是使用其他一些对象框架。

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

Answer 1

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

Answer 2

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

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

这或多或少是FCGI所做的，所以使用FCGI可能更有意义。

另一方面，拥有一个非cgi后端服务器可能会有实际的好处，可以根据需要使用任何抽象接口。

例如，如果您使用TCP（或UDP）套接字，那么您可以让本机桌面应用程序与CGI相同的后端。

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

Answer 3

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

Matt Trout（mst），目前落后于MooseX :: Antlers的人，表示希望能够在必要时在CGI环境中运行应用程序。我建议现在坚持使用FCGI并且纠缠他，你可以做些什么来帮忙！

Answer 4

还有另一种选择 - PPerl。

我从未使用它，但它看起来确实很有趣。写它的人（Matt Sergeant又名波特） - 它几乎可以保证你提供高质量的代码。

Answer 5

Jonathan Rockway几个月前写过关于APP::Peristent（奇怪的是，不在CPAN中）的文章。我没有使用它，但基于他上面链接的博客文章，它看起来提供了一个相当透明的服务器 - 客户端架构，你可以包装你的CGI的实际处理。

Answer 6

App::Persistent，pperl，SpeedyCGI以及其他可能的基本概念是将Perl程序编译为字节代码的过程只进行一次，某种缓存是之后用于调用。由于据说Moose有很长的编译时间，我首先尝试这种方法。

我已经成功地使用pperl在2001年左右的古代系统上绘制了大量的MRTG图形.Perl程序是针对每个图形执行的，这是一个相当大的开销 - 这可能与你的CGI相当场景。