PHP操作码缓存/ Zend加速和include_once与require_once

Question

我有一位同事正在研究基于PHP的应用程序的操作码缓存/ Zend Acceleration（我总是认为这些是相同的事情）。他的基准测试似乎表明，如果我们用require_once包含我们的（大）类库，我们就没有看到性能优势，但我们在使用include_once时看到了性能优势。

这对我们两个人都有些腥味，但我没有时间自己检查我们的基准测试方法，而且我的同事对鱼的气味比我更容忍。 ：）

有没有人碰到这样的事情？如果没有，那么通过从include_once切换到require_once来对可能导致性能提升的其他事情有任何想法吗？

Answer 1

对于初学者，两个调用（require_once和include_once）都会仔细检查以前是否包含过文件。

所以他们两者实现这一目标的方法是在所有可用路径中搜索文件，并基本上检查它是否在混合之前等等。

在后台发生的事情是他们评估所有不同的选项（例如多个include_path等），然后通过从这个相关的表单创建 realpath ，他们创建一个唯一的标识符。只有一条路径 - 而不是两条路径。

这已经不是地球上最快的过程，通常会在PHP的每个请求中发生。然后添加另一个昂贵的操作，当它创建我称之为 realpath 的时候是stat（realpath，因为它有点像 realpath（）确认文件是否存在。

如果我错了，请纠正我，但APC特别针对这种情况进行了优化。

所以无论如何 - 现在在require_once和include_once之间的差异，这就是require_once评估文件（对于低级解析错误等）的时候包括它。这是一个额外的检查，如果您有足够的QA，解析错误永远不会潜入包含内容，您可以摆脱它。

找到其他方面真的很棘手。 ： - ）

（需要考虑的事项：您可以使用require_once进行开发，并在部署时使用include_once替换所有调用。）

对于操作码缓存 - 我建议 APC 。之前已经在stackoverflow上进行了讨论。就个人而言，我/我们正在使用它一段时间（我们每天处理大约10万访客，有3个前端和1个后端），我们非常高兴。 APC还针对require_once / include_once madness进行了优化。

一个非常酷的副作用是APC还允许你将PHP变量存储在内存中 - 有点持久等等。

另外几个指示：

1. 很多人声称使用 __autoload 来加速任何申请。
2. 使用操作码缓存，避免使用条件require_once / include_once（例如在循环或控制流中）。
3. 有人说include_或require_once中的/absolute/path/to/file.php比依赖include_path更快。
4. include_path中路径的顺序也很重要。

希望有所帮助。

Answer 2

我无法保证任何东西，因为我没有深入了解它，但是，我看到了两者之间的速度差异。它们对我来说从来都不足以让我转而使用include_once而不是require_once。

我总是认为差异是因为require_once必须在水下做更多工作。至少还有一个潜在的错误准备和处理，当需要的文件不存在时还有很多工作要做。