问题描述
我有一位同事正在研究基于PHP的应用程序的操作码缓存/Zend Acceleration(我一直认为这些都是同一件事).他的基准似乎表明，如果将(大型)类库包含在require_once中，则不会看到性能提升，但是在使用include_once时，确实会看到性能提升.
I have a colleague who is looking into opcode caching/Zend Acceleration (I've always assumed these are the same thing) for our PHP based application. His Benchmarks appear to indicate that we're NOT seeing a performance benefit if we include our (large) class libraries with require_once, but we DO see the performance benefit when using include_once.
这对我们俩来说都很难闻，但是我本人没有时间检查我们的基准方法，我的同事对鱼味的耐受性比我更大. :)
This smells fishy to both of us, but I don't have time to check into our benchmark methodology myself and my colleague has more tolerance for the smell of fish than I do. :)
有人遇到过这样的事情吗?如果不是，那么通过从include_once切换到require_once来考虑是否有其他可能导致性能提高的想法?
Has anyone ever run into anything like this? If not, any thoughts on other things that might be causing the appearance of a performance increase by switching from include_once to require_once?
推荐答案
对于初学者，这两个调用(require_once和include_once)都仔细检查了以前是否未包含文件.
For starters, both calls (require_once and include_once) double-check if a file has not been included before.
因此，他们俩都通过在所有可用路径中搜索文件并实质上检查文件之前是否未包含文件来实现此目的.
So the way they both achieve this is by searching the file in all available paths and by essentially checking if it hasn't been in the mix before etc..
在后台发生的事情是，他们评估所有不同的选项(例如，多个include_path等)，然后根据此缩写形式创建 realpath ，从而创建唯一的标识符.只有一条相同的路径，而不是两条.
In the background what happens is that they evaluate all the different options (e.g. multiple include_path's, etc.) and then by creating the realpath from this abreviated form they create a unique identifier. There is only one and the same path - not two.
这已经不是地球上最快的过程，通常会在每次使用PHP的请求中发生.然后添加另一个昂贵的操作，即当它创建我称为 realpath (realpath，因为它有点像 realpath()确实)检查文件是否存在.
This is already not the fastest process on the planet and generally happens on each request with PHP. Then add another expensive operation which is the stat when it creates what I called the realpath (realpath, because it's sort of what realpath() does) to check if the file exists.
如果我错了，请纠正我，但是APC对此情况进行了优化.
Correct me if I am wrong, but APC has optimizations especially for this case.
所以，无论如何-现在 require_once和include_once之间的区别，这是require_once在文件评估时(针对低级解析错误等)进行评估的文件包括它.这是一项额外的检查，如果您有足够的质量检查以至于解析错误永远不会潜入包含，您就可以摆脱它.
So anyway - now on to the difference between require_once and include_once, which is that require_once evaluates the file (for low-level parse errors, etc.) when it includes it. This is an additional check which you can get rid of if you have enough QA in place that a parse error can never sneak into an include.
找到其他地方很难. :-)
It's just tricky to find otherwise. :-)
(要考虑的事情:您可以使用require_once进行开发，并在部署时将所有调用替换为include_once.)
(Something to consider: You could develop with require_once and replace all calls with include_once when you deploy.)
对于操作码缓存-我建议 APC .之前已经在stackoverflow上进行过讨论.就我个人而言，我/我们正在使用它一段时间(我们每天使用3个前端和1个后端处理大约10万个访客)，我们感到非常高兴. APC还针对require_once/include_once疯狂进行了优化.
As for an opcode cache - I'd recommend APC. It's been discussed on stackoverflow before. Personally, I am/we are using it for a while (we handle roughly 100k visitors/day with 3 frontends and 1 backend) and we are very happy. APC is also optimized for the require_once/include_once madness.
一个很酷的副作用是APC还允许您将PHP变量存储在内存中-诸如持久性等等.
A pretty cool side-effect is that APC also allows you to store PHP variables in memory - sort of persistant, etc..
另外两个指针:
- 许多人声称可以使用 __autoload 来加速任何应用程序.
- 使用操作码缓存时，请避免有条件的require_once/include_once(例如，在循环或控制流中).
- 有人说include_或require_once中的/absolute/path/to/file.php比依赖include_path更快.
- include_path中路径的顺序也很重要.
- A lot of people claim to speed up any application with __autoload.
- With an opcode cache, avoid conditional require_once/include_once (e.g. in loops or in control-flow).
- Some people say that /absolute/path/to/file.php in include_ or require_once is faster than relying on the include_path.
- The order of the paths in your include_path matters as well.
希望有帮助.
这篇关于PHP Opcode缓存/Zend加速以及include_once与require_once的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！