search

amnuts / opcache-gui

A clean, effective and responsive interface for Zend OPcache
1.21k stars 197 forks source link

Gui shows only info of domain where it is installed #78

Closed ruzakuku closed 1 year ago

ruzakuku commented 2 years ago

Greetings!

On one server (Centos 8 php-fpm 7.4 apache) all is okay. I installed the GUI on one domain and it shows the full info of cached files on all domains on the server.

But on another server (Centos 7 php-FCGId 7.4 apache), the GUI shows only the opcache info for the domain where it is uploaded! Global info (memory, keys etc) and cached files are only those of the domain. If I upload the GUI on another domain, it also shows the data of the considered domain, though the "global options" that are entered in the 10-opcache.ini are correct.

Though it doesn't hurt for good working, it is a problem when we need to check the values. Any suggestion to solve this?

Thank you and warm wishes for the new year!

amnuts commented 2 years ago

Hi @ruzakuku - happy new year to you, too!

This sounds like it might be expected behaviour for way the two servers are set up, given that one is loaded with apache and one is as-and-when FCGI starts that instance.

This thread might give a bit more information on what you're seeing: https://github.com/amnuts/opcache-gui/issues/76

MichaIng commented 2 years ago

Indeed, the GUI can only know about the OPcache usage of it's own OPcache instance, hence when it is accessed through Apache with mod_php, then it can only see the OPcache usage of that Apache webserver OPcache instance, when it is accessed with classic CGI, it can only see itself being cached, as a new PHP and OPcache instance is created, in which case OPcache itself often doesn't make sense 😉.

To be able to monitor and manage the OPcache for all web applications, all need to use the same FastCGI, i.e. PHP-FPM instance. In case of Apache one then often needs to actively configure it to not use it's internal mod_php but send PHP handler requests to the shared PHP-FPM server via mod_proxy_fcgi, which also requires using the event MPM. That is generally seen as the preferred setup nowadays, especially for high traffic websites since every single incoming request with MPM prefork + mod_php creates an own child process taking additional time and memory, while with event MPM and dedicated PHP-FPM server a (usually) already waiting handler thread is used on Apache and on PHP end, consuming nearly no additional memory or time for process spawning.