如何在非持久CGI流程中提高Moose性能？ [英] How can I improve Moose performance in non-persistent CGI processes?

问题描述

Moose 是一个很棒的对象框架。问题是，加上其依赖性，它很大很大。我们的分析表明，在我们的平台上，仅加载Moose会在非持久CGI应用程序脚本上产生5-6秒的开销。

Moose is a fantastic object framework. The trouble is that, taken together with its dependencies, it's very big. Our profiling indicates that on our platform, simply loading Moose will incur a 5-6 second overhead on non-persistent CGI application scripts. That's just not acceptable for these one-off applications.

相反，当我们使用持久性流程系统（例如FCGI）时，这种启动开销被消除了（或仅发生一次），一切都很好。我们面临的问题是，我们不能保证所有代码都将始终在持久性进程下运行。

By contrast, when we're using a persistent process system (such as FCGI), this startup overhead is eliminated (or rather, only incurred once), and all is well. The problem we have is that we can't guarantee that all of our code will always run under a persistent process.

我们使用鼠标进行了调查作为功​​能受限的Moose替代品，但事实证明（如此答案）不是一个可行的选择。我们编写的用于Moose的任何库都将无法以细微但重要的方式使用Mouse。而且，我们真的不想派生所有模块，以便我们既可以在持久性环境中支持Moose，也可以为香草 CGI支持Mouse。

We investigated using Mouse as a feature-limited drop-in-replacement for Moose, but as it turns out (as mentioned in this answer) that's not a viable option. Any libraries we write to work with Moose will fail to work with Mouse in subtle but important ways. And we really don't want to fork all of our modules so that we can support both Moose in a persistent environment and Mouse for "vanilla" CGI.

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

Given that, we have the following options:

1. 分叉我们的内部模块适当时搭配Moose或Mouse。 （太好了！）


2. 仅开发用于FCGI /驼鹿的模块。不再支持香草 CGI。如果我们必须编写非持久性脚本，它们将无法利用我们的内部模块。


3. 不要使用Moose或Mouse ，但还有其他一些对象框架。

1. Fork our in-house modules to work with either Moose or Mouse, as appropriate. (Yuck!)
2. Only develop our modules for FCGI/Moose. Don't support "vanilla" CGI anymore. If we have to write scripts that aren't persistent, they won't be able to leverage our in-house modules.
3. Don't use either Moose or Mouse, but some other object framework.

哪个选项最好？我们现在倾向于2，如果必须让某些东西像普通CGI一样运行，我们会把它吸了。其他框架呢？

Which option is best? We are leaning towards 2 right now, and we'll just suck it up if we have to get something running as a vanilla CGI. How about other frameworks? Is there anything more lightweight we should be looking at?

推荐答案

我更愿意放弃原始的CGI支持。如今，FCGI托管确实非常便宜，并且没有理由顺应香草CGI（IMO），因为它只是强化了Perl运行缓慢的观点。但是，如果无法避免，则可以使用 Object :: Tiny 。但是，如果您需要角色，约束，元编程以及Moose提供的所有其他优点，那么除非您放弃香草CGI，否则您就不走运了。

My preference would be to drop vanilla CGI support. FCGI hosting is really cheap these days and there's no reason to pander to vanilla CGI (IMO) because it just reinforces the opinion that Perl is slow. But if you can't avoid it then you can use something like Object::Tiny. But if you need Roles, constraints, meta-programming and all the other loveliness that Moose provides, you're out of luck unless you drop vanilla CGI.

这篇关于如何在非持久CGI流程中提高Moose性能？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！