Req #80812 [Csd]: opcache.cache_id should be PHP_INI_PERDIR

Edit report at https://bugs.php.net/bug.php?id=80812&edit=1 ID: 80812 User updated by: aschmidt at anamera dot net Reported by: aschmidt at anamera dot net Summary: opcache.cache_id should be PHP_INI_PERDIR Status: Closed Type: Feature/Change Request Package: opcache Operating System: Windows PHP Version: 7.4.15 Assigned To: cmb Block user comment: N Private report: N New Comment: Understood - thanks for those instructions, and (as usual) your patience. I will readily admit that I have stumbled upon this working configuration of mine through trial and error while progressing through PHP version, NOT through any deep understanding. It's entirely possible that I have by now "overcompensated" beyond the bare necessity. I have looked up the two mutexes between my batch and IIS instance and they are clearly different, as you suggested: \BaseNamedObjects\ZendOPcache.SharedMemoryMutex@5975a76bcbe21efa4a56d51fca8d6170@cli@808e3d627370b34f95293d8c0c3c6c26 \BaseNamedObjects\ZendOPcache.SharedMemoryMutex@dfff58c6ad17f8ba242c3d888a6b2843@cgi-fcgi@ec6cf683fce841a5803f62b5956b5f47 I will leave things alone for now - but the next time I do a version change, I'll make a point to set time aside and "step back" my "opcache_id" setting, and then use Process Explorer to view the respective handles. Previous Comments: ------------------------------------------------------------------------ [2021-03-02 15:54:00] cmb@php.net I do not understand why you would need to add the PHP versions there. A part of the mutex name is the "system" hash, which also includes the PHP version (in case of -dev versions even the timestamp of the build). Is there possibly a hash collision? You can check the names of the mutexes with Process Explorer[1]; select the PHP process, and press CTRL+H. The mutex name should begin with ZendOPcache.SharedMemoryMutex@. [1] <https://docs.microsoft.com/de-de/sysinternals/downloads/process-explorer> ------------------------------------------------------------------------ [2021-03-02 15:05:42] aschmidt at anamera dot net Two closing comments: a) Here's my working cache_id setting which will also cover CLI environments (where an AppPool ID doesn't exist), and further making it unique per PHP version to avoid the possibility of version clashes: opcache.cache_id="v"PHP_MAJOR_VERSION""PHP_MINOR_VERSION"_${APP_POOL_ID}" b) Please do note that the necessity of the above disproves the assertion/assumption that in my scenario there should not have been any Mutex problems in the first place. ------------------------------------------------------------------------ [2021-03-02 11:47:32] cmb@php.net Oh, I was not aware that app pool specific enviroments are only supported as of IIS 10. But your suggestion to use APP_POOL_ID for this purpose is great, so I've documented that[1]. Do you still want to have the changeability of opcache.cache_id changed to PHP_INI_PERDIR, or can this request be closed? [1] <https://github.com/php/doc-en/commit/7c6c83d08e97007ca75f739873f8125c6c0640cf> ------------------------------------------------------------------------ [2021-03-02 11:26:24] cmb@php.net The following pull request has been associated: Patch Name: Print error code if CreateMutex() fails On GitHub: https://github.com/php/php-src/pull/6745 Patch: https://github.com/php/php-src/pull/6745.patch ------------------------------------------------------------------------ [2021-03-01 22:07:11] aschmidt at anamera dot net That's a helpful suggestion. The tricky part is that Windows sets Environment Variables "per User", which is the same for all sites in my scenario. With IIS 10 there's an option that will support setting "per Pool" Environment Variables. However, even in prior IIS versions, the Application Pool Name itself is available as an environment variable, so one can use: opcache.cache_id=v74_${APP_POOL_ID} I've activated the above and initial tests have not yet caused any Mutex errors. ------------------------------------------------------------------------ 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=80812 -- Edit this bug report at https://bugs.php.net/bug.php?id=80812&edit=1