Edit report at https://bugs.php.net/bug.php?id=76280&edit=1
ID: 76280
Comment by: spam2 at rhsoft dot net
Reported by: teo8976 at gmail dot com
Summary: Performance degrades permantly when overwriting PHP
files, until apache restart
Status: Open
Type: Bug
Package: opcache
Operating System: debian
PHP Version: 5.6.36
Block user comment: N
Private report: N
New Comment:
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
Previous Comments:
------------------------------------------------------------------------
[2018-04-28 15:13:39] teo8976 at gmail dot com
> 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".
------------------------------------------------------------------------
[2018-04-28 15:00:01] spam2 at rhsoft dot net
>> 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
------------------------------------------------------------------------
[2018-04-28 14:54:14] teo8976 at gmail dot com
> 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 supportedhttp://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.
------------------------------------------------------------------------
[2018-04-27 19:44:35] nikic@php.net
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.
------------------------------------------------------------------------
[2018-04-27 19:18:44] teo8976 at gmail dot com
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.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=76280
--
Edit this bug report at https://bugs.php.net/bug.php?id=76280&edit=1