opcache_invalidate is not safe under high concurrencies
Volt Version
1.7.1
Laravel Version
12.10.2
PHP Version
8.4.7
Database Driver & Version
No response
Description
This issue is specifically about this line in Volt. It would be nice if it can be avoided in productive environments: https://github.com/livewire/volt/blob/0ab9d34c53f87444017270a2178250a19f3083ec/src/ComponentFactory.php#L35
This was first raised in the FrankenPHP Repo, where @robsontenorio noticed that when stress testing, the application would end up in a memory corruption after a while.
This happens due to opcache_invalidate() being called each request leading to a buildup in memory that eventually leads to an opcache_reset().
opcache_reset() is currently not really safe under concurrency (both in FPM and FrankenPHP, so I'd recommend avoiding an opcache_reset if possible in production environments.
Also when testing with the reproducer, I noticed that the path passed to opcache_invalidate was that of a Blade file (which makes it look unitended)
Steps To Reproduce
You can use the reproducer provided by @robsontenorio https://github.com/robsontenorio/paper.mary-ui.com/tree/franken-bug
It will take a while for the corruption to appear, using postgres/mysql instead of sqlite will make it happen faster.
In addition to the crash issue caused by opcache_invalidate() mentioned by @AlliBalliBaba, this also results in a gradual increase in memory usage over time. cc @nunomaduro
This can easily be reproduced like this.
ab -n 10000 -c 20 http://localhost:8016/
I have also noticed the same opcache_invalidate() in the Laravel Framework itself, that also contributes to the gradual increase in memory usage. It was introduced by this PR https://github.com/laravel/framework/pull/50665
Cc @jessarcher
https://github.com/laravel/framework/blob/df12a087731b37708cfbba72172a4c381363fed2/src/Illuminate/Support/ServiceProvider.php#L562
But mostly, the main issue about memory usage is about Volt.