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

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

这对我们两个人来说都很腥,但我没有时间自己查看我们的基准测试方法,而且我的同事对鱼的气味比我更容忍.:)

有没有人碰到这样的事情？如果不是,那么通过从include_once切换到require_once,对可能导致性能出现的其他事物的任何想法都会增加？

对于初学者,两个调用(require_once和include_once)都会仔细检查之前是否包含过文件.

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

在后台,会发生的是他们评估所有不同的选项(例如,多个include_path等),然后通过从这个简化形式创建realpath,他们创建一个唯一的标识符.只有一条路径 - 而不是两条路径.

这已经不是地球上最快的过程,通常会在PHP的每个请求中发生.然后添加另一个昂贵的操作,当它创建我称之为realpath(realpath,因为它是realpath()所做的那样)来检查文件是否存在时是stat .

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

所以无论如何 - 现在是require_once和include_once之间的区别,这是require_once 在包含它时评估文件(对于低级解析错误等).这是一个额外的检查,如果你有足够的QA,解析错误永远不会潜入包含,你可以摆脱它.

找到其他方法真的很棘手.:-)

(需要考虑的事项:您可以使用require_once进行开发,并在部署时使用include_once替换所有调用.)

至于操作码缓存 - 我推荐APC.之前已经在stackoverflow上进行了讨论.就个人而言,我/我们正在使用它一段时间(我们每天处理大约10万访客,有3个前端和1个后端),我们非常高兴.APC还针对require_once/include_once疯狂进行了优化.

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

另外几个指针:

很多人声称用__autoload加速任何应用程序.

使用操作码缓存,避免使用条件require_once/include_once(例如在循环或控制流中).

有人说include_或require_once中的/absolute/path/to/file.php比依赖include_path更快.

include_path中路径的顺序也很重要.

希望有所帮助.