Sometimes I like to use PHP's built-in development server to work on quick stuff like so:
php -S 127.0.0.1:8888
However I seem to run into heavy caching issues from time to time where I need to restart the server in order to see even simple HTML changes.
I haven't been able to find any options to disable this or otherwise pinpoint what might be causing this frustration.
Note: I usually have Chrome's Developer Tools open with browser caching disabled while I'm doing this. I don't think it's a browser caching issue.
Is there anything I can try?
If modifying your php scripts isn't resulting in a change, it could be a problem with opcode caching as opposed to browser caching (browser caching should be easily overridden by CTRL-F5 or CTRL-R, depending on your OS). This happens when the server is pre-compiling your php code to speed up responses.
This was the case with me, so I went in to /etc/php5/cli/conf.d/ and found the symlink to 05-opcache.ini and deleted that symlink, and restarted the builtin server. The problem where pages wouldn't change when I made edits to php code was resolved from that point onwards.
Related
Since about a week I've got a very strange caching problem. I did not make any changes I know of which could possibly lead to this problem.
It happens using:
PHP 8.1.9
Apache 2.4.48 or the built-in symfony web server
PHPStorm or notepad++
symfony or just plain PHP
Firefox or Edge
My output gets cached somehow. I can completely destroy the PHP code or rename/delete files -> still displayed correctly. Some time later it finally refreshes and displays the errors. The errors themselves don't get cached. Fixing them immediately returns the script to the expected behaviour. I've already disabled caching inside Firefox (in the settings and setting disk.cache.enabled to false), but it happens with Edge, too.
The only common thing my experiments share is the PHP version/installation, it probably does not have to do anything with Apache, symfony or the browser.
Any ideas?
I've found the answer.
Somehow opcache.revalidate_freq inside the php.ini was set to 200 and zend_extension=opcache enabled. I've never changed this manually. Would be interesting to find out what caused the change.
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'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.
I am building a framework where product instances use the main framework files, until there is a copy of it's own version of that file. To achieve this I have done the following:
set_include_path(MY_PRODUCT_ROOT.'/' . PATH_SEPARATOR . MY_FRAMEWORK_ROOT.'/');
So if I call include('view-users.php'); it will first look in MY_PRODUCT_ROOT for /view-users.php and if that's not found, it will then look to MY_FRAMEWORK_ROOT/view-users.php.
This procedure is working very nicely until I add files to the product root. I know that PHP/Apache is caching the includes and one would think to run clearstatcache(true); to clear any status caching. PHP likely uses file_exists inside it's include(); and thinks the new file still does not exist. I have tried restarting Apache with no effect.
Unfortunately running clearstatcache(true); does not help either. Only once I have deleted MY_FRAMEWORK_ROOT/file does it think to clear cache and try again, thus finding MY_PRODUCT_ROOT/file.
Im a little stumped, I know we need to refresh PHP/Apache's understanding of whether the file(s) exist or not, but clearstatcache(true); is not helping...
Any ideas?
UPDATE: Correction, restarting Apache seems to help now. I reiterate that this only occurs when trying to ADD a file to MY_PRODUCT_ROOT, to overlap an existing MY_FRAMEWORK_ROOT file, for customization
UPDATE: Development environment is Zend Server CE PHP 5.3.14 on Windows, Production environment Centos linux httpd, PHP 5.3+. The fact that Zend optimizer is enabled on my dev environment could have an effect, Also not using APC or any other caching scripts
Zend Optimizer+ speeds up PHP execution by opcode caching and optimization. It stores precompiled script bytecode in shared memory. This eliminates the stages of reading code from the disk and compiling it on future access. For further performance improvements, the stored bytecode is optimized for faster execution.
This is caching the file contents found in the includes, thus clearstatcache does not work. I have disabled my Zend Optimizer and it works now.
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.