Do PHP opcode cache work with __autoload?

Question 1

Sorry if this is basic, I am trying to learn as much as I can about OO in PHP and I am slowly learning how to use it (very limited).

So I am wanting to know if __autoload() has any affect on PHP opcode cache's?

Question 2

(Disclaimer : I only know APC)

What an opcode cache do is :

when a file is included/required, it take the full path to that file
check if the opcodes corresponding to that file are already in RAM (in opcode cache)
- if yes, return those opcode so they are executed
- if no, load the file and compile it to opcodes ; and store opcodes in cache.

The important point, here, is the entry point : the full path to the file.

What autoloading generally do is :

get the name of a class
transform it to the name of a file
include/require that file

So, the informations that are relevant for the opcode cache (full path to the file, and the fact that it is included/required) are still here.

In consequence, autoload shouldn't bring any trouble with op code caching.

(And, when using APC, it doesn't, as far as I can tell)

Question 3

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

Question 4

All the php-fpm workers share the same opcode cache as the parent php-fpm process; source. If you have a /apc_clear_cache.php file and you call that over HTTP (using something like curl), you will clear the opcode cache for all workers using the same php-fpm master process.

This blog article has a very good explanation of how apc works and how to clear it effectively during release.

Question 5

There seems to still be confusion about this topic, however in most cases it comes down to ease vs performance.

A good mailing list thread to read would be this one on Zend Frameworks mailing list:

http://n4.nabble.com/ZF-and-Autoloading-td640085i20.html

Now, the correlation is here because if you inherit from not-yet-defined class, you might rely on autoload to define it (though you might also rely on include), and actually the presence of the autoload facility may encourage you to use such inheritance. But this is not the autoload which brings trouble (see after Ramus' "it's not just autoload" in the blog for some examples of troublesome things). So the right phrase would be "people which tend to rely on autoload tend also to use code which defies compile-time binding". Which can't be seen as autoload fault, of course, and just avoiding autoload won't help a bit with that - you would also have to rewrite your code so that compile-time binding could happen. And it has nothing to do with uses of autoload with "new", for example.

As for the slowdown from the effects described above - i.e., absence of the compile-time binding - the code indeed becomes a bit slower and such code can lead in some obscure cases to some trouble to opcode caches (not in the autoload cases - but in cases where classes are defined inside conditions, or, God forbid, different definition is created depending on condition) - but it has next to nothing to do with using autoload by itself. The amount of slowdown, however, seem to be greatly exagerrated by people - it is nothing (and I repeat to be clear - NOTHING) compared to the performance benefit given by the opcode cache due to the absence of the disk operations and compilation stage. You could probably compose an artificial benchmark that would show some significant slowdown, but I do not believe any real application would even notice.

source: http://n4.nabble.com/ZF-and-Autoloading-td640085i20.html#a640092

Question 6

The products you list serve different purposes.

OPCode caches

There are many PHP Accelerators (OPCaches) as seen on this Wikipedia list. As is common with open source products, they are all fairly similar. XCache is the lighttp PHP accelerator, and is the de choice when you are running that HTTPd. It works well with Apache as well, however APC seems to be slightly more "plays well with others" socially speaking, being officially supported as part of PHP, and is released in-step with the official PHP distribution.

I abandoned usign eAccelerator due to its slowing development, and lagging against the releases of PHP, and the official blessed status APC offers with similar performance.

These products typically are drop in; no code change instant performance boost. With large codebases (Drupal, Wordpress) the performance can be up to 3x better while lowering response time and memory usage.

Data Caching

Memcache is a slightly different product -- you might think of it as a lightweight key value system that can be scaled to multiple servers. Software has to be enhanced to support Memcache, and it solves certain problems better than others. If you had a list of realtime stock values on your website, you might use Memcache to keep a resident list of the current value that is displayed accross your website. You might use it to store session data for short term reuse. You wouldn't use it for other things such as full-page caches, or as a replacement for MySQL.

There are also Wordpress addons such as WP-Super-Cache that can drastically improve Wordpress' performance (infact, WP-Super-Cache can rival static HTML based sites in many cases)

In summary -- I would highly recommend APC if you want a "set it and forget it, well supported product".

Do PHP opcode cache work with __autoload?

Answers

php,autoload,opcode-cache