TYPO3 Core

I don't think we need a TYPO3 specific solution here. There are already existing solutions like the Cachetool which should be evaluated first.

Ok, nice tool, but seams not to work for PHP as Apache module.
On the other side, TYPO3 with PHP-FPM, is also problematic, as it only clears the opcode cache of the running FPM which got the clear call and not on all instances. :(
This both issues are independent of the used opcode cache.

Here are my ideas on that topic:

1. We write a script (completely TYPO3 independent), which reliably clears opcode caches, when requested with any sapi (fcgi, fpm, mod_php, cli) for that respective sapi
2. We secure it with a token, which is valid for only 30 seconds. Caches are only cleared if token is valid
3. We change our code that only a (lightwight) event is triggered when opcache should be cleared
4. By default (certain extension maybe) we register a listener, which calls this script from a (configured or detected) URL with a token provided

Benefit:

1. Default listener can be removed if not needed
2. Other listeners can do custom stuff (see #66495)
3. Cleaner, more decoupled code with better functionality

@Mathias

The tool also won't work for fpm, if you aren't in the group of the running webserver. As you can't open the socket to write too. So it seams this won't work by hosters.
Also in the last days I got issues, with PHP7 on cli and PHP5.6 on mod_php, sometimes I hate customers which change their environments without inform us. ;)
So it seams, we will need a web endpoint for every sapi to handle this.

On the other side, this leads, for me, to the result, that APCu/Xcache (user cache) isn't useable on fpm, as the fpm instances do not synchronize?

or: we remove all opcode cache clearing code and advice users not to use opcode caches (or clear them manually after deployment)

From the Slack discussion:

my conclusion:
- opcache is a good thing
- never clear all opcode caches, if not necessary
- only the admin knows which instances are on the server and which pools actually use a certain path/files (dependency)

1. normal users can clear opcache via install tool
2. any cli script needs proper post processing by the admin knowing the dependencies of the code and which processes (apache, fpm) are affected

CacheTool actually is just the tool for the admin who knows what to clear, that's already documented in the basic usage of the tool, where one has to define which FPM is to be connected

As long as there is no information available for a CLI tool, which reports the connection between php-file and possibly affected processes, there is no sane way to clear opcode cache automatically. There can always be a setup that is not covered by the script.

Markus Klein wrote:

From the Slack discussion:

my conclusion:
- opcache is a good thing

It depends imho. During development they are pretty annoying if configured not to respect file changes (which is the default imho)

- never clear all opcode caches, if not necessary

TYPO3 currently flushes all opcode caches automatically on certain incidents.
This can be a big issue for high traffic sites.

- only the admin knows which instances are on the server and which pools actually use a certain path/files (dependency)

That is exactly why I argue, that TYPO3 cannot do something useful in itself

1. normal users can clear opcache via install tool

I would be fine keeping this tool.

1. any cli script needs proper post processing by the admin knowing the dependencies of the code and which processes (apache, fpm) are affected

I would abstain from implementing any CLI solution. Do you agree?

CacheTool actually is just the tool for the admin who knows what to clear, that's already documented in the basic usage of the tool, where one has to define which FPM is to be connected
As long as there is no information available for a CLI tool, which reports the connection between php-file and possibly affected processes, there is no sane way to clear opcode cache automatically. There can always be a setup that is not covered by the script.

So you agree to just close this ticket as "won't fix"?

On top of that I would remove all code that clears OPCache "automatically". On low traffic sites the benefit of an OPCache is rather low. On high traffic sites, the impact of clearing the OPCache can be harmful.

But I will not fight for that…

During development ..

I agree of course. My words were more about production.

TYPO3 currently flushes all opcode caches automatically on certain incidents.

I'm not sure how this is implemented in FPM. But if two sites (FPM pools) use different users, I would hope that other user's caches are not affected.

I would abstain from implementing any CLI solution. Do you agree?

Full ACK!

IMO we can close this one.

On top of that I would remove all code that clears OPCache "automatically"

I'm only aware of one place, where we do that, but we only clear a dedicated folder path, I'm fine with that as we do not flush the whole cache.

At first, we only clear the complete opcode cache on the button, installing an extension and building the ClassLoader cache crashes (only for 6.2?). Otherwise we clear the opcode cache on a per file base.
Clearing the opcode cache completely means we clear it for the running User (fcgi and fpm after rework) or all (mod_php as there are no different users).
Updating an extensions via CLI needs to clear the opcode cache via CLI. Also other deployment strategies without ExtensionManager seems to need this.
The complete clear for installing extensions may also be reworked to only per file base for all files inside the updated extension.

OPcache is defaulting to check timestamps of files every 2 seconds, you can change this to 0 to check on every request or disabling the timestamp checking to never check. Last szenario is the fastest one for High Traffic sites.