ZF2模块加载性能答案

【问题标题】：ZF2 module loading performanceZF2模块加载性能
【发布时间】：2012-12-17 17:57:03
【问题描述】：

据我了解，ZF2 应用程序中的每个已启用模块都会为每个请求加载（除非使用诸如 zf2-lazy-loading-module 模块提供的优化方法）。我一直在关注在modules.zendframework.org 上发布的模块，并且遇到了功能极其有限的模块，例如AkrabatFormatUkTelephone 模块，其目的是将电话号码格式化为英国格式。

虽然我理解开发应该专注于创建擅长做一件事的单一用途模块（而不是做很多事情但不是很好的模块），但我在想我们是否开始使用提供这样的模块如上所述，功能有限，我们将需要组合数百个模块来构建一个丰富的应用程序，这可能会对性能造成灾难性的影响。相反，我希望将这种功能放在一个类中（例如Zend\I18n？）并按需加载，这样会更优化。但是知道 Akrabat 的声誉，我想我一定是错过了什么，因此我的问题是：

像我提到的那样加载模块的性能是否比通过 PHP 类加载相同的功能要差得多（或者由于 ZF2 的设计方式而类似）？有人有关于模块与类加载性能的任何数据（即慢 5%、10%、15%）吗？

【问题讨论】：

标签： php performance class zend-framework2 autoload

【解决方案1】：

不要将此评论作为最终答案，因为希望 ZF2 开发人员中的某些人会对此有所了解，但通常只会主动加载 Module.php 和通常 module.config.php。其他所有内容都将简单地注册并按需调用。因此，只要您的 Module.php 和 module.config.php 的文件大小不是太大，性能就不应该是那么大的问题

在 Akrabats 示例中，所发生的只是新 ViewHelper 的注册表。没有其他的。 Zend 中的所有其他视图助手也是如此。在这些情况下，性能实际上并不重要。

就我个人而言，在我的 Webspace 和 BjyAuthorize、ZfcBase、ZfcUser 和我自己的模块上加载骨架的时间为 80 毫秒，加载时间增加到 100 毫秒。这是没有启用任何类型的内存缓存！

【讨论】：

是的，希望来自ZF2 开发团队的人会看到这个问题并提供他们的见解（我假设他们在设计模块系统时做了一些性能基准测试，希望他们愿意分享这些数据和我们一起）。
我可能会建议您前往 IRC#zftalk@freenode.net 并在那里发布您的问题。您应该特别寻找 EvanPro，因为他设计了 ModuleManager
谢谢。 IRC 的问题在于答案没有像在 StackOverflow 上那样获得相同的曝光率（就受众和时间而言）。希望 EvanPro 能看到这个问题。

【解决方案2】：

加载一个模块并不比加载任何类多多少，就像 Sam 指出的那样。只要你不使用你的模块中的任何东西并且做正确的事情，它只是被注册。

现在“做正确的事”是什么意思？

试着在你的模块类 bootstrap() 方法中放一个大循环。您会看到这会减慢应用程序上的每个请求，因为每个请求都会调用模块的引导方法，并且应该非常小心地使用它，仅用于轻量级任务。您通常使用 bootstrap() 方法的目的，甚至不会使您的应用程序减速一毫秒，但是在此方法中将文件写入磁盘可能会在每个请求中使您的应用程序减速数秒。

如果您的应用变得非常繁重，您应该尽可能使用 classmap_autoloader 和一些缓存。如果你做“正确的事情”，你不会有任何性能问题，只是因为你的应用程序中有许多模块或许多类。可以说，这完全是关于算法的。

继续使用最佳做法，就像您提到的那样。通常这些不是您应用程序的瓶颈，而是您自己的算法和故障。

编辑：当您使用来自社区的模块时，您应该始终检查它们是否存在性能问题。即使是看起来很轻的模块，如果算法不好，也可能成为应用程序的瓶颈。但是，您要加载附加模块的情况并不是重点。

【讨论】：

【解决方案3】：

好问题。我想为 Sam 的反应做一点贡献。

模块性能不仅仅是模块的加载（正如指出的那样非常快），还包括模块之间的通信。所以这个问题可能归结为：与传统的非模块化系统相比，ServiceLocator 和事件驱动系统有多慢/快？

我记得 ZF2 的构建考虑了性能。例如，ServiceLocator 注册工厂，以便可以即时实例化对象。所以这只需要一些额外的内存对象和实例化，我想这不会对您的应用程序的总体性能产生太大影响。 EventManager 的工作方式大致相同，我没有看到它被注册事件超载，即使在大型应用程序中也是如此。

另一方面，可能会减慢的是模块配置的加载。我认为使用缓存可能会解决这个问题。我不确定，但也许 Zend Optimizer 可能已经这样做了。

因此，简而言之，应用程序应该可以很好地扩展，前提是模块表现良好，并且不会过度注册事件或滥用 ServiceLocator。

【讨论】：

【解决方案4】：

从 MVC 组件的角度来看，根本没有模块！有一个大的配置文件 - 每个模块的配置合并的结果。除非您的模块没有 onBootstrap 方法或不做太多事情，否则模块加载与在每个模块上调用 new Module 一样快，这是无痛且内存便宜的。

我上面提到的配置合并过程只发生在默认启用的DEV模式下。

还有一些技巧可以加快您的 ZF2 应用程序，例如：

启用合并配置缓存
使用EdpSuperluminal module
从动作返回 ViewModel 对象，而不是数组
在 ViewModel 上显式设置模板名称
使用模板映射而不是单独使用模板路径堆栈
配置中的路由顺序很重要！它是一个 LIFO 队列（后进先出）。
确保不在 HTTP 上下文中加载控制台模块。
让Composer 自动加载，而不是 ZF2

...等等。在 ZF2 应用性能方面，Gary Hockin 有一个 quite good talk。

授权模块肯定会降低您的应用速度。幕后有很多事情：需要获取用户的身份（从数据库中？），需要根据您的规则对用户进行身份验证。当然，您可以通过使用 memcached 等来加快速度，但这需要对 ZF2 应用程序的生命周期、您使用的模块等有一定的了解。

还有即将发布的 Zend Framework 3，有些事情会进展得更快，但不要抱太大希望。大量开销是由于您对 ZF2 缺乏了解 - 无意冒犯！

【讨论】：