I'm trying to get opcache working on my server that is hosting a website in apache2. I'm running debian 8.
However it seems to be hitting zero of the scripts.
I've already tried to change the php mode to cgi only but this didn't change anything. I've also tried to disable suPHP with the following command
a2endismod suPHP
again this didn't do anything for the problem.
Does anyone happen to know what could be causing this?
This was already answered here
To quote:
This looks like you are using cgi (FastCGI) rather than mod_php5. The shared memory area (SMA) is used for both, but it only persists request-to-request for the latter.
However, I should add that enabling following:
opcache.file_cache=/var/tmp/php/opcache
opcache.file_cache_only=1
made OPcache work with my setup - which is Apache+php as CGI/FastCGI (NOT php-fpm). Obviously this caching mechanism is filebased, not SHM (make sure
/var/tmp/php/opcache is accessible by webserver, might need 777 permissions).
You won't be seeing any cache hits/misses in the statistics after enabling the above, since - again - we disabled SHM Cache.
PS. sorry for necroposting, was just looking for a solution for a similar issue.
Related
I have a php script that is not reacting to code changes that I make (I inserted a deliberate syntax error which is not be being picked up).
I am running php 8.1 on apache2 (on a local copy of ubuntu 22.04). The script is part of a drupal 9.4 custom module.
Running phpinfo now shows:
Opcode Caching Disabled
Optimization Disabled
SHM Cache Enabled
File Cache Disabled
JIT Disabled
Can someone shed any light on might be going on?
I have disabled opcaching and JIT (my understanding from what I read is that SHM cache is therefore irrelevant). I have checked the paths in the script and the code editor align. I have cleared drupal and browser caches (several times) and restarted php-fpm and apache2. From my research I had expected these to cure the problem.
I also rebuilt the whole thing to my retired dev server (the only difference is ubuntu 20.04) and after the first successful run of the script I observed the same behaviour when I make changes to the script.
Googling has not yielded a solution that helps me identify where the problem lies, though it points me at opcache rather than drupal.
Problem solved. Really basic - I should have spotted it earlier. I had a duplicate script in another directory in the website file system, which drupal was using in preference to the one it should have been using.
Apologies for wasting other people's time!
I've been encountering a slew of issues with a fresh install of Laravel on Ubuntu recently but this latest one has me baffled. I was receiving the WSOD with zero errors in apache/php logs or laravel logs, despite having debug set to true and error display in PHP enabled. I updated the index.php file in public to add a die("Test"); line just to see if that was at least working.
It was, which was great - Test displayed on the site. However, now it won't go away. I've tried updating the text to something else, completely removing the line, etc., artisan cache-clear, composer cache clear and dump-autoload, and I've cleared out any cached items in the storage folders. I've cleared my personal cache and tried different browsers, also, so it's not a personal cache issue. I also tried restarting apache.
All of my chmod permissions should be correct at this point (bootstrap/cache is 755, all of the storage and subfolders are 755). I have had laravel write to the log for another issue (from CLI - a test I did just to make sure permissions were working) so that shouldn't be the problem.
I have this working perfectly fine in laragon on my local Windows machine but have had nothing but issues getting this guy up and running on this Ubuntu server. I have another prod instance of laravel that never gave me this much trouble, either, on another Ubuntu server (and usually it was just a permissions issue). Really not sure what to do at this point or what information might be useful. Hoping that someone else has run into something similar and can shed some light....
what kind of error show's the file /var/log/apache2/error_log?
what is the content of your laravel file storage/logs/laravel.logs?
how did you configure the vhost?
did you install laravel with composer?
give us more information please
Turns out the problem lay with the opcache PHP extension. This was enabled on all versions of PHP installed on my prod environment by default and wasn't something I was utilizing on my dev environment. Writing a test to clear opcache resolved this particular problem and I have since disabled the extension, as I was not intending to use it, anyways.
If anyone else runs into this problem and wants to disable, I simply went through WHM Easy Apache 4 and removed the opcache PHP extensions and then edited the php.ini files for all versions of PHP to set any opcache enabled type of flags to 0 (off).
In the documentation it says "mostly used for debugging" which would lead me think "never enable it unless you've a problem and need to do some debugging," however reading mostly everything that I could find about it says to enable it "opcache.enable_cli 1" but why? I could not find any information concerning this matter, so if anybody knows, why should I enable it if the documentation basically says to keep it on 0?
With PHP7 and file-based caching, it can now make sense to enable opcache for CLI. The best possibility would be to have a separate php.ini for CLI with the following configuration:
opcache.enable=1
opcache.enable_cli=1
opcache.file_cache="/tmp/php-file-cache"
opcache.file_cache_only=1
opcache.file_cache_consistency_checks=1
opcache.file_cache_only=1 makes sure that the in-memory opcache is disabled and only files are used, which is what you want for CLI. This should boost execution time by quite a bit.
In the php.ini for FPM, you will want to have the same settings but use opcache.file_cache_only=0, so in-memory opcache is used and the file cache is used as a fallback (which also makes FPM faster, because the file cache reduces warmup time when FPM is restarted or opcache is reset, because the cached files remain).
This way, CLI and FPM share the file cache, and FPM has the in-memory cache as a second primary cache for maximum speed. A great improvement in PHP7! Just make sure to choose a directory for opcache.file_cache that both CLI and FPM can write to, and that the same user does the writing/reading.
UPDATE 2017
I would not recommend to use the file cache with FPM anymore (only use it for CLI), because there is no way to reset the cache when setting opcache.validate_timestamps=0 - the file cache prevents PHP-FPM from recognizing any changes, because opcache_reset() or even a complete PHP-FPM restart does not affect the file cache and there is no equivalent for the file cache, so changed scripts are never noticed. I reported this as a "bug"/"feature request" in March 2016, but this is currently not seen as an issue. Just beware if you use opcache.validate_timestamps=0!
Leave it off. It's primarily there for use while debugging issues with OPcache itself.
The opcache.enable_cli option enables PHP OPcache when running PHP scripts from the command line (using the php command). However, keep in mind that for PHP 5.x the OPcache extension works by storing cached opcodes in the memory of the current process. This is only useful when the process that's running PHP is going to be handling multiple requests that can reuse these opcodes, like in a web server or under FastCGI. For a process like the PHP CLI, which runs one "request" and exits, it just wastes memory and time.
As per PHP docs:
opcache.enable_cli boolean enables the opcode cache for the CLI version of PHP. This is mostly useful for testing and debugging.
Therefore it should be disabled unless you're really need this.
This can be useful when you've some long-term migration process running from the command-line (personally I've tested OPcache v7.0.3 for CLI by running some extensive migration script and I didn't see much performance improvements).
Is it possible to check if a PHP opcode cache is installed and running on a server without having SSH access to the server? I've checked phpinfo() and can see no reference to APC or eAccelerator, but I'm aware there are other opcode cache systems and am not totally sure that checking phpinfo() is enough to let me know one way or the other.
var_dump(function_exists('apc_store')); or equivalent for the library of your choice.
If using a web server SAPI, as per usual, make sure you restart the server process after editing your php.ini to see the new additions reflected.
when we deploy our app, we simply create a new folder and point a symbolic link to it, so apache will always find its way to the latest build.
However, we get strange errors when we deploy and continue testing without first rebooting the apache server. We also have APC running and have a feeling that caching has something to do with this.
Is it normal that an apache restart is required when deploying a new version of our php application when APC is active? Or is there a better way, e.g. clearing the APC cache using a shell script?
You can use apc_clear_cache().
See related questions:
How to clear APC cache entries?
How to clear APC cache without crashing Apache?
depends if you have the apc.stat setting in php.ini On or Off. If Off (typical for a production site) then you need to clear the code cache or restart apache; if On, then it should pick up the new code automatically
Normally, APC will 'stat' each PHP file to see if it has been changed since it was last cached. So restarting Apache is not required for all application upgrades.
BUT if your application uses apc_store() to store application data in the cache and some of that data might change after an upgrade, then restarting Apache is an easy way to flush the entire APC cache.
I believe apache2ctl graceful would work, too.
Also, APC performs a little better if you turn off the 'stat' checking; so if you disable that feature, then you'll want to restart Apache anyway.