dongshuzhuo5659 2008-10-16 18:34
浏览 67
已采纳

PHP操作码缓存/ Zend加速和include_once与require_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. :)

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?

  • 写回答

2条回答 默认 最新

  • douyue4334 2008-10-17 00:18
    关注

    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..

    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.

    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.

    Correct me if I am wrong, but APC has optimizations especially for this case.

    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. :-)

    (Something to consider: You could develop with require_once and replace all calls with include_once when you deploy.)

    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.

    A pretty cool side-effect is that APC also allows you to store PHP variables in memory - sort of persistant, etc..

    A couple additional pointers:

    1. A lot of people claim to speed up any application with __autoload.
    2. With an opcode cache, avoid conditional require_once/include_once (e.g. in loops or in control-flow).
    3. Some people say that /absolute/path/to/file.php in include_ or require_once is faster than relying on the include_path.
    4. The order of the paths in your include_path matters as well.

    Hope that helps.

    本回答被题主选为最佳回答 , 对您是否有帮助呢?
    评论
查看更多回答(1条)

报告相同问题?

悬赏问题

  • ¥15 我想咨询一下路面纹理三维点云数据处理的一些问题,上传的坐标文件里是怎么对无序点进行编号的,以及xy坐标在处理的时候是进行整体模型分片处理的吗
  • ¥15 CSAPPattacklab
  • ¥15 一直显示正在等待HID—ISP
  • ¥15 Python turtle 画图
  • ¥15 关于大棚监测的pcb板设计
  • ¥15 stm32开发clion时遇到的编译问题
  • ¥15 lna设计 源简并电感型共源放大器
  • ¥15 如何用Labview在myRIO上做LCD显示?(语言-开发语言)
  • ¥15 Vue3地图和异步函数使用
  • ¥15 C++ yoloV5改写遇到的问题