OpCache and Shared Hosting Environment

webhostuk

Well-Known Member
Sep 11, 2013
149
15
18
UK
cPanel Access Level
Website Owner
Twitter
I just searched for few details and found out what it does :

==========================
When this is enabled, PHP will check the file timestamp per your opcache.revalidate_freq value.
When it's disabled, opcache.revaliate_freq is ignored and PHP files are NEVER checked for updated code. So, if you modify your code, the changes won't actually run until you restart or reload PHP
===========================
Ideally for security I feel it should be enabled, but if its related to speed then it should disabled.
 

LucasRolff

Well-Known Member
May 27, 2013
128
73
28
cPanel Access Level
Root Administrator
I do keep the defaults, they do good enough, additionally you can't expect users or software to support
validate_timestamps=0 - it can seriously break things.
 

MajorLancelot

Well-Known Member
Dec 17, 2014
51
4
83
Shinjuku-ku, Tokyo, Japan
cPanel Access Level
Root Administrator
Hello, Lucas.

The default is set to "1" which is one: PHP: Runtime Configuration - Manual.
Where it will break things is when you are with updating or deploying code and new code files can get mixed with old ones.
Not when it is disabled and you need to restart the machine or use:
PHP:
<?php
opcache_reset();
?>
to flush it.

Or am I misreading this?

This codeascraft.com/2013/07/01/atomic-deploys-at-etsy/ byRasmus Lerdorf is an interesting read.
 
Last edited by a moderator:

MajorLancelot

Well-Known Member
Dec 17, 2014
51
4
83
Shinjuku-ku, Tokyo, Japan
cPanel Access Level
Root Administrator
I just searched for few details and found out what it does :

Ideally for security I feel it should be enabled, but if its related to speed then it should disabled.
It is tricky kind of situation because it is always better when everything gets cleared so one doesn't run into issues with cache but then, the issue I mentioned earlier when this is enabled.

As you also rightly pointed out, enabling this comes with some performance hit.

It is more like trying to find that sweet balance between caching PHP code for performance, but not having to restart the web server each time some PHP code is edited/generated by customers.
 

sparek-3

Well-Known Member
Aug 10, 2002
1,929
178
343
cPanel Access Level
Root Administrator
I don't know how you are using PHP.

But if you're allowing opcache_reset() then you could be clearing the OpCache for everyone. If you are allowing opcache_get_status() then you could be potentially allowing any of your shared hosting accounts to know information about opcache'd scripts on other hosting accounts.

I think these issues could be alleviated if file based opcache was used.

But as far as I know, cPanel has never enabled it. And the feature request to enable it (which even includes the one line of code change that is required to make file based opcaching available in the feature request) is stuck in feature request purgatory.

Enable file-based OpCache for PHP 7.0/7.1
 

LucasRolff

Well-Known Member
May 27, 2013
128
73
28
cPanel Access Level
Root Administrator
Hello, Lucas.

The default is set to "1" which is one: PHP: Runtime Configuration - Manual.
Where it will break things is when you are with updating or deploying code and new code files can get mixed with old ones.
Not when it is disabled and you need to restart the machine or use:
PHP:
<?php
opcache_reset();
?>
to flush it.

Or am I misreading this?
The default is 1, meaning validate timestamps and flush opcache automatically when files change based on the revalidation frequency.
If you disable timestamp validation you have to call opcache_reset(); or restart the webserver (or the PHP processes) to make sure opcodes are removed from the shared memory cache - many systems do not function well with timestamp validation set to 0, so thus leaving it the default (1), to ensure compatibility and non-angry/confused customers :)

Only disable timestamp validation if you're in a very controlled environment and can reset the opcache as a part of your deployment steps.

As you also rightly pointed out, enabling this comes with some performance hit.
It does not come with a performance hit, by default timestamp validation is turned on, so you gain performance by disabling it - but regardless of anything, with or without timestamp validation, you're still having better performance than without opcache, so you're not taking any "performance hit".

I don't know how you are using PHP.

But if you're allowing opcache_reset() then you could be clearing the OpCache for everyone. If you are allowing opcache_get_status() then you could be potentially allowing any of your shared hosting accounts to know information about opcache'd scripts on other hosting accounts.

I think these issues could be alleviated if file based opcache was used.

But as far as I know, cPanel has never enabled it. And the feature request to enable it (which even includes the one line of code change that is required to make file based opcaching available in the feature request) is stuck in feature request purgatory.
When you're in a shared hosting environment, you should use a handler that is run under suexec, that can be fastcgi/fcgid or lsphp - so running opcache_reset() won't reveal anything about other users/customers, because the shared memory segment used by opcache is only for that given user.
 
  • Like
Reactions: cPanelMichael