Search code examples
phpoptimizationapcopcode-cache

Basics of PHP opcode cache

Currently on a very large project that I do not plan to re-use for another site, I have the site's name hardcoded into the files everywhere. Now, if I were ever to change the site name it would take a lot of effort to change that everywhere. I know the obvious solution is to just store the name as a variable or a constant, but I guess you could call it my micro-optimizing way of thinking: I always figured it would be one less thing PHP has to parse. I do realize it won't make much difference, but I just wanted to know whether using an opcode cache like APC would mean that PHP wouldn't even have to re-parse that?

Solution

  • Really : you shouldn't care about anything like that.

    Any difference in configuration will means much more difference (for instance, the apc.stat option, for APC, can have quite an impact on the load of your server -- and anything like DB queries you do will have hundreds of time more impact)

    Here, what probably matters is maintenability :

    • does it get you any benefit (except from that nano-optimisation) to have the site name not hard-coded ?
    • does it get you any benefit to have it hard-coded (same exception) ?

    If the answer is "no" in either case, and your application works... well, that's what matters !


    If you have time to spend with that kind of less than micro optimisations, it would probably be better spent going through your application code with a profiler, going through your DB queries, the number of HTTP requests you are doing to fetch static JS/CSS/images, upgrading PHP or modifying your code so it can run on PHP 5.3 (as PHP 5.3 comes with some optimisations over 5.2), ...

    All those will most probably get you a higher gain ;-)


    Edit after the comment :

    Basically, when a PHP file is loaded :

    • the file is read from disk
    • it's parsed and compiled to opcode
    • the opcodes are executed

    With an opcode cache :

    • if there is a place in RAM containing the opcodes, those are loaded from RAM (is, no reading of a file, nor parsing/compiling)
      • if not, see the steps before -- just add a "store the opcodes to RAM" before execution, for the next request
    • and the opcodes are executed

    The apc.stat option defines whether APC should examine the last modification date/time of a file to decide between using the opcodes from RAM, or re-compiling the file if it is more recent that the opcodes in RAM.

    Disabling this option means :

    • files are not checked on disk => faster, and uses less resources
      • For instance, I've seen a drop of CPU-load, between 10 and 15%, when disabling this option on a quite loaded server
    • but as there is no check for modification, if you want a modification to be taken into account, you have to clear the cache


    Still, what I said is true : there are probably lots of things you can optimise that will mean more important gain than a simple "should I use hard-coded values" versus "should I use constants/variables".