Bytecode caches and CMSimple_XH (plugins)

Discussions and requests related to new CMSimple features, plugins, templates etc. and how to develop.
Please don't ask for support at this forums!
Post Reply
cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Bytecode caches and CMSimple_XH (plugins)

Post by cmb » Sun Feb 01, 2015 2:26 pm

Hello Community,

since a long time several byte code caches are available for PHP, and since PHP 5.5.0 the OPcache extension is bundled with the standard PHP distribution. It seems to me that this will increase the adoption of byte code caches on shared hosting platforms, because there is now a common "standard".

For those who are unacquainted to the workings of byte code caches, I'll try to briefly explain. When a PHP script is requested (or included during such a request), the byte code cache will check whether the script is already cached in a reasonably up-to-date version. If it is, loading (i.e. reading and compiling) of the script will be skipped, and instead the already compiled script will be read from the cache. If it is not already cached, the script will be compiled and the result will be stored in the cache. As you can easily imagine, this technique can greatly speed up the execution of PHP scripts, especially if many small PHP files are involved[1].

Mostly these byte code caches work fully transparent, i.e. the PHP programmer can ignore their existence. However, when PHP files can be manipulated via CMSimple_XH (for instance, config.php), their current version might not be available right away. For instance, OPcache has the setting opcache.revalidate_freq; the larger this setting, the less often cached PHP files will be checked for modifications. Potential problems have been discussed in OD a while ago and for CMSimple_XH 1.5.9+ we've simply chosen to disable the OPcache completely. Since CMSimple_XH 1.6, however, this is not done anymore, but rather the core caters to an enabled OPcache by invalidating individual PHP files immediately after saving. This is done in XH_ArrayFileEdit::save(), and so works for core and plugin configuration and language files[2], as long as they are saved via the respective back-end forms.

That means that plugins which directly manipulate config, language or other PHP files[3] have to cater to OPcache themselves. It seems that the same technique as used by the core is appropriate[4]:

Code: Select all

// after saving the file $filename, invalidate its cached version
if (function_exists('opcache_invalidate')) {
    opcache_invalidate($filename);
}
BTW: of course, byte code caches may be relevant with regard to modifications via FTP, but that is outside the scope which developers can take care of.

[1] I've measured improvements of roughly factor two (!) on my machine for standard CMSimple_XH 1.6.5 with the default OPcache settings.
[2] I've just noticed that we might have to do that for template.htm as well -- I'll investigate.
[3] I presume that files are cached when they're requested or included, but not if they are processed otherwise.
[4] We might consider to offer an API, so other byte code caches could be taken into account, if that turns out to be relevant.
Christoph M. Becker – Plugins for CMSimple_XH

Post Reply