Here's some example performance data (oh come on, I can't attach a screenshot??) https://ibb.co/h3J6bx

This is avarage execution time (measured on the server side) of all requests, but graphs for any given single url would show exactly the same pattern.

Please check whether the deployment of new files triggered an opcache restart (because the opcache SHM memory limit was reached). Generally any slowdown should only be temporary though.

In any case, PHP 5 is no longer supported and PHP 7 has quite a lot of changes to improve performance, including in opcache. Additionally, the second-level file cache can be used to reduce the performance impact of opcache restarts.

> Please check whether the deployment 
> of new files triggered an opcache restart

How can I check that?

> Generally any slowdown should only be temporary though

It isn't. When this happens, the slowdown is permanent until I restart apache.
In the screenshot I attached (where I unintentionally cut off the part that showed the times), it went on for several hours. It was also surprisingly "stable", everything being consistently X% slower (of course it is possible that the slowdown was affecting a specific piece of code being called by all scripts)

> In any case, PHP 5 is no longer supported

http://php.net/supported-versions.php says "security support until 31 december" this year. Something that can cause a website to go down permanently because of a performance degradation with no good reason, I would call a security issue.

>> Please check whether the deployment 
>> of new files triggered an opcache restart
>>
> How can I check that?

look at the opcache vars and in doubt feed "opcache status panel" into Google and ask yourself why you don't have such tool installed - not knowing what a server does would i personally call a security issue (and no such a panel out-of-the-box is no good idea because *that* would be a security issue)

> Something that can cause a website to go down 
> permanently because of a performance degradation 
> with no good reason, I would call a security issue

nosense - following your logic running a server without opcache would be insecure at all

> nosense - following your logic running a server without 
> opcache would be insecure at all

No, that is not following my logic. I meant something that can cause a SUDDEN crash of a website just because you do something as trivial as upload some files. I thought "security support" implicitly covered fixes for bugs so serious as to cause a system to go completely down triggered by trivial events.

I know *strictly speaking* this is not security related, but I thought in the context of support version lifecycle "security" was short for "is secure and at least barely usable".

the problem is pretty sure that your "opcache.memory_consumption" setting is too low and you are trahsing opcache with a lot of changes - so either increase you config or reload the webserver after chaning lot of files

the most lkiley problem is that your configuration don't suite your workload and since you even don't know how to look pretty clear says you never gave a damn about your configs

> the most lkiley problem is that your configuration don't suite your workload

Let's assume this is the case.

That would explain a TEMPORARY degradation in performance.

Even if that is justified by a bad configuration which is my fault, if that doesn't recover on its own after a while that no file is being changed, then there's a bug.

> pretty clear says you never gave a damn about your configs

Indeed, I never did. But again, if I need to worry about fine-tuning my configs just for PHP to be stable, then it's ill-designed.

Is this still an issue with any of the actively supported PHP
versions[1]?

If so: if updated files are being cached by OPcache, the old files
will never be removed from the shared memory (this is reporteded
as wasted memory).  This wasted memory may sum up to the point
where you no longer have sufficient free memory, so no more files
can be cached, what would cause them to be executed uncached.
That might explain the behavior you've described.

[1] <https://www.php.net/supported-versions.php>

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.

> if updated files are being cached by OPcache, the old files
> will never be removed from the shared memory (this is reporteded
> as wasted memory).  This wasted memory may sum up to the point
> where you no longer have sufficient free memory, so no more files
> can be cached, what would cause them to be executed uncached.

That is the current behavior?? If that wasted memory never gets freed, that sounds like a bug to me.

I haven't tested PHP 7 yet.

Consider to read <http://blog.jpauli.tech/2015-03-05-opcache-html/>.

> That is the current behavior?? 
> If that wasted memory never gets freed, that sounds like a bug to me.

no, that's by design to avoid memory fragmentation which has it's own problems like APC had with it - in theory a ton of cache memory free but no free segment large enough to cache anything useful anymore

Recently upgraded to 7.4, still observing the issue.

why didn't you read http://blog.jpauli.tech/2015-03-05-opcache-html/ in the meantime to fix your buggy expectations?

Feedback has been given, but still, this behaves as intended[1].

[1] <https://github.com/php/php-src/blob/php-7.4.16/ext/opcache/ZendAccelerator.c#L2118-L2126>