My opcache had a memory_consumption set of 512M and it was full.
So I increased it to 2048M, and restarted the php-fpm daemon. And it immediately filled up again:
This site is simply running a WP Multisite installation with 2 subdomain sites. Nothing special, really. It's a low traffic site, mostly static. It does have a Woocommerce shop, but with two products only. Nothing makes me think that this amount of cache consumption is justified.
Does PHP7's Opcache preallocate all of the memory it is configured to use?
Or is my cache genuinely filled?
Or am I setting the incorrect property?
My php-fpm config has:
php_value[opcache.memory_consumption] = 2048
How can I get further insight into what's going on?
The problem was in the way I had configured the opcache. I had configured it in the fpm pool by setting this property:
php_value[opcache.memory_consumption] = 2048
However, the right way of configuring it is in php.ini or in php.d:
opcache.memory_consumption=2048
I have setup my website on a new hosting (virtual cloud), however I am looking at the opcache and the scripts not being used for say a minutes or so are removed from the cache.
So is there a way to stop it? or is it a normal behaviour?
Thanks a lot.
There is configuration for that actually.
opcache.revalidate_freq=2, the default value is 2 seconds, opcache will try to check for timestamps every 2 seconds and if the files are changed it will revalidate.
You can change the value to match your needs, or you can just turn timestamp check off using this conf opcache.validate_timestamps=0, but in this case each time you deploy code to production you have to restart php-fpm (if you are using php-fpm) and web server
opcache.revalidate_freq=2 or any integer value
opcache.validate_timestamps=1 or opcache.validate_timestamps=0
Sounds like you need to define validate_timestamps=0 in php.ini. Beware of this though - if you upload any changes to your PHP files you will need to restart either Apache (if you use mod_php5) or PHP5-FPM, or clear the opcache manually.
For details on how to clear the opcache manually you basically have to create a PHP file with opcache_reset() and run it, but this has to be in the same SAPI as your other files - i.e. run by PHP5-FPM if that is what is serving the rest of your files.
http://ihaveabackup.net/2013/10/19/invalidating-the-opcache-in-php-5-5/
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).
This is an issue I've been having for a long time. I want to run PHP applications on my windows computer and it has a terribly high load time, around 10-25 seconds. I have tried many things:
First I tried a simple XAMPP installation
I read WAMP might be faster, so I tried WAMP, too. It gave me the same results
Then I installed an nginx server with PHP, but it did not help either
Finally, I installed an Ubuntu 11.10 in VirtualBox and I shared my windows files containing my project, but the result was even worse: over 22 second load time each time.
UPDATE: I have even tried APC - it improved a bit but still 6-8 sec/page
I uploaded my files to a linux server(shared hosting), on which it runs in around 300-500 ms. On the XAMPP installation I tried to run other (i.e. not Symfony2) applications as well(e.g. phpmyadmin), which too were slower than on the shared hosting, but not extremely slow, with 2-3 sec load time. Until I change to Linux as the main OS, how could I improve performance? I have a laptop with i7 CPU, 4 GB RAM, 5400RPM HDD, Win7 x64.
Thank you for your help!
UPDATE2: For some mysterious reason my Symfony routing didn't work with fcgid (it gave me a 404 error for everything) so I went back for using PHP as a module. Now, it has become the worst ever (worse than it used to be as a module): app mode 20-25 sec, and in dev mode, over 30s every time, so I get a timeout error, and it's the same with or without APC enabled.
Here you can see this error. This is reproduceable: each time it reaches a different point of execution within 30s:
Update:
Since PHP 5.5 has now integrated the PHP OPCache, this speeds up the execution time. In my setup a full request with database access takes 180ms now.
Steps:
Update to the latest php version
Enable OPCache
Disable xdebug
Set realpath_cache_size = 2M as DemonTPx mentioned
php.ini settings:
realpath_cache_size = 2M
[XDebug]
xdebug.profiler_enable = 0
xdebug.remote_enable = 0
[opcache]
zend_extension = "C:\xampp18\php\ext\php_opcache.dll"
opcache.enable = 1
opcache.enable_cli = 0
opcache.memory_consumption = 128
opcache.interned_strings_buffer = 8
opcache.max_accelerated_files = 4000
Why is Windows slower than Unix?
As discussed here, PHP is very slow in file_exists, and filemtime() on Windows. since Symfony2 is using these functions in dev mode a lot. we won't get under 700ms (in <= 5.4) on Windows. PHP 5.5 allows now 180ms.
A solution could be WinCache which was developed by microsoft to solve this problem on IIS. But as it only works on several Windows versions and also only with IIS it's no solution for me.
Alternative
Also a nice solution I can recommend is to have a Linux Virtual Machine on Virtualbox. This is easy to setup and is also more like the production environment.
I have the exact same problem. Setting the following in php.ini increased the performance for me from ~800ms to ~300ms:
php.ini:
realpath_cache_size = 2M
Still not the ~100ms I get from a unix machine, but it makes a difference at least
I had a similar problem with symfony 1 for a time on XP and Server 2003. The solution was to install a PHP accelerator (eAccelerator for us, APC might be a better bet these days) plus FastCGI/fcgid.
Addendum: it's been ages since I've used Apache on Windows. I have generally been of the view that its performance has been getting steadily better, rather than worse; however as with most unusual set-ups, good results are not guaranteed. As per my earlier comment, I recommend asking your question at Apache Lounge, where I previously have received some great expert advice.
If memory serves correctly, they can offer you a free Apache binary compiled with better tools than the standard one offered on the Apache website.
Wow, After trying many different things, I've finally succeeded to move from a 15s execution time to a 3s exec time on windows7 with wamp.
How to install wincache extension :
http://us2.php.net/manual/en/wincache.installation.php
Where to download the wincache dll:
http://sourceforge.net/projects/wincache/
My php.ini config change:
[PHP]
realpath_cache_size = 2M
extension=php_wincache.dll
; XDEBUG Extension
;zend_extension = "C:/Net Generation/wamp/bin/php/php5.5.12/zend_ext/php_xdebug-2.2.5-5.5-vc11.dll"
;
[xdebug]
xdebug.remote_enable = off
xdebug.profiler_enable = Off
xdebug.profiler_enable_trigger = off
xdebug.profiler_output_name = cachegrind.out.%t.%p
xdebug.profiler_output_dir = "C:/Net Generation/wamp/tmp"
xdebug.show_local_vars=0
xdebug.max_nesting_level=200
[opcache]
zend_extension = "C:/Net Generation/wamp/bin/php/php5.5.12/ext/php_opcache.dll"
opcache.enable = 1
opcache.enable_cli = 0
opcache.memory_consumption = 128
opcache.interned_strings_buffer = 8
opcache.max_accelerated_files = 4000
i think you have a problem with caching mechanism.
check app\cache directory.
there has to be a folder named dev.
if it does not exist or if it is empty check folder permissions.
when i delete dev and prod directories under app\cache directory it takes 18 seconds to load the page but after that it takes only 500 ms.
Some years ago i had the same problem. Which antivirus software do you run in the background?
Try to deactivate it for dev purposes or change it. It also could be some indexing services running in the background. Symfony 2 consists of >15000 files with vendors :)
Also try to do it the classic way by reinstalling Windows from the scratch.
My sites takes usually from 100-500ms and my laptop is slower than yours. (Intel C2D P8600)
Just a guess (and probably not the right one), but it could be MySQL related. Seeing how you mentioned PhpMyAdmin and Symfony 2 as PHP applications you tested, both rely on MySQL (assuming you have MySQL set up in Symfony 2). You did not mention this in your post, but in your VirtualBox setup, did you by any chance let the script running on Ubuntu connect to the MySQL server on your Windows host machine?
You could check out PHP Benchmark for some performance testing scripts, and see if these scripts perform better timewise.
Another thing you could try is use Xdebug and see if you find (a) certain (group of) function(s) that are taking up too much time.
I'm definately gonna keep this question as a favorite, because I am too curious to see what it was now :) good luck !
Check your computer random access memory, RAM using http://oca.microsoft.com/en/windiag.asp or run the memory test application shipped with your Ubuntu CD booting option.
In both cases choose what know as extra or deep test - I don't remember exactly- How ever, choose the test with more longtime these kind of tests has no end, you just wait till the test finish two phases and any problems with your RAM, commonly, shown.
Also, Check your hard drive with any mean of checking. after that try to perform disk defragmentation
I bit, your problem is hardware related problem.
My pages were taking 20 seconds to execute. I installed fast cgi, increased memory limits, everything, not working. Then started looking at timeline and noticed symfony firewall module was taking up most of it time. Turns out having "localhost" in my config for doctrine is what was causing issues. Changing it to 127.0.0.1 fixed the problem. Not sure why, but it's described here:
http://12wiki.blogspot.ca/2012/11/why-does-symfony-2-firewall-take-so.html
Page loading time is depends on the CSS + JS + Image loading time also. I had the same problem in CakePHP and solved the problem by using mod_expires in htaccess.
Have you tried "ExpiresByType" in your server htaccess file for CSS, JS and images? Check this page.
I am on LAMP with Alternative PHP Cache (APC). It worked fine until yesterday when I updated the website and changed a few MySQL queries (I don't see how it would affect the APC opcode cache.)
Today I see that the load has increased on the server and I see in Alternative PHP Cache, that the uptime of APC is somewhere around 15 minutes and then it gets restarted.
At this point the APC cache is only about 20% full of the available 30 MB. Using for opcode cache only. During this 15 minutes the cache works fine (99,8% cache hits). After this unwanted restart the APC cache is empty. Why is it restarting? Where can I find the logs for it?
It was a cPanel update that caused Apache to restart gracefully every 15 minutes.