Maybe this is stupid question but i'm trying to figure out how does max_accelerated_files actually work...
I understand the "description/instructions" from PHP net
opcache.max_accelerated_files integer The maximum number of keys (and
therefore scripts) in the OPcache hash table. The actual value used
will be the first number in the set of prime numbers { 223, 463, 983,
1979, 3907, 7963, 16229, 32531, 65407, 130987 } that is greater than
or equal to the configured value. The minimum value is 200. The
maximum value is 100000 in PHP < 5.5.6, and 1000000 in later versions.
But my question is what it does with this number once is configured. Does it allocate a memory for this setting? why don't we just set number 1000000 and that's it if we have enough memory? What happens if we let say configure this number to 2000 and we have 2010 files? Do they some sort stack and once its that file turn it gets cached? What happens with un cached files?
Thank you for your answers
OPCache stores cached scripts in an HashTable, a data structure with very fast lookup time (on average), so cached scripts can be retrieved quickly. max_accelerated_files represent the maximum number of keys that can be stored in this HashTable. You could think about it as the max number of keys in an associative array. The memory allocated for this is part of the shared memory that OPCache can use, that you can configure it with the opcache.memory_consumption option. When OPCache tries to cache more scripts than the available number of keys, it triggers a restart and clean the current cache.
So let's just say you configured opcache.max_accelerated_files to 223 and a request to your /home route parse and cache into OPCache 200 scripts. As long as your next requests will need only those 200 scripts OPCache is fine. But if one of the following requests parse 24 new scripts, OPCache triggers a restart to make room for caching those. Since you don't want that to happen you should monitor OPCache and choose an appropriate number.
Keep in mind that one file can be cached more than once with different keys if required with a relative path like require include.php or require ../../include.php. The cleanest solution to avoid this is to use a proper autoload.
Related
What will happen if I set higher value for a function in php.ini, For example set 2GB to opcache.memory_consumption for a normal e-commerce web application.
opcache.memory_consumption = 2048
Below is my pod resource configuration
resources:
limits:
cpu: "1"
memory: "1Gi"
requests:
cpu: "450m"
memory: "256Mi"
If I set 2GB for OPcache itself. What will happen if it's exceed actual memory limit of the application.
From the PHP manual:
opcache.memory_consumption int
The size of the shared memory storage used by OPcache, in megabytes. The minimum permissible value is "8", which is enforced if a smaller value is set.
OK, so what is the shared memory storage used for, and why might we want more of it? As it happens, Nikita Popov, one of the most important developers of PHP's internals right now, just wrote a blog post about how opcache works. Before going into details of how, he summarises thus:
The primary purposes of opcache is to cache compilation artifacts in shared memory, to avoid the need to recompile PHP scripts on every execution.
So, the memory is used to cache the result of compiling your PHP code to an intermediate representation used internally. The amount of space needed will depend on how much compiled code you're trying to cache at once.
How do we know if it's enough? By running the opcache_get_status() function. If the memory is full, or very nearly full, there's a chance that some of your scripts aren't getting cached because they don't fit in memory. In that case, increasing the configured memory size will improve performance by caching those files.
If the memory already has plenty of space, then increasing the size further won't make any difference, other than preventing the server using that memory for other things.
I have a potentially very large (several megabytes perhaps) PHP class, generated of course. Is there any setting or limitation that would cause opcache slowdown in this case?
You should check opcache.max_file_size option. This option can set a maximum file size to cache. Thus, big files can be skipped by opcode cacher. However, it defaults to 0, meaning all files will be cached.
Next option to check is opcache.max_accelerated_files. For big projects with Twig and annotations default value 2000 is not enought. Consider to increase it.
And the last one is opcache.memory_consumption. I noticed, that after reaching this limit, opcache won't add new items into the cache. So, increase it to 256M or 512M.
Few things make OPCache slow, like opcache.consistency_checks if is it enabled, OPcache will verify the cache checksum every N requests, where N is the value of this configuration directive. For your large file size i am sure it is not good idea to enable this.
Also, if you doubt that it is effecting OPCache, why can't you try tools like OpCacheGUI to check it.
I've searched all over the web for documentation including on the XCache website.
I'm new to PHP opcode caching and XCache. I'd like an explanation of how XCache works. I know that it stores compiled php code so that it doesn't need to be recompiled everytime. But how does XCache know when php code has been updated and thus the cache is out of date?
How do I know if I need to clear the cache?
Does XCache compile and cache all php code on the server? If so can this be configured?
What are clogs? OOMs? I see large numbers for both of these in the XCache Admin page interface.
In the Code Coverage Viewer... what does Percent mean? Is this the percentage of code that has been cached?
Does hits mean the number of lines of compiled code that has been read from cache?
Does lines mean the total number of lines of code?
What is the ToDo column for?
Why are some lines highlighted in red?
I'm using PHP 5.3.2, XCache 1.3.0, and Ubuntu 10.04 if it helps.
Xcache:
optimizes performance by removing the compilation time of PHP scripts
by caching the compiled state of PHP scripts into the shm (RAM) and
uses the compiled version straight from the RAM.
Based on observations using PHP 5.5.3 and Xcache 3.1.0 this is what I can deduce:
Cacher
This module deals with two kinds of caching Opcode and Variable.
The Opcode caching is designed to be a simple drop-in. You can't customize how it decides to cache, just how much:
xcache.count setting refers to how many cache threads and correlates to how many processor cores you want to utilize — the idea is that multithreading should be the fastest, but there is no guarantee so experiment yourself
As a guideline, valid count values would be 2^n like 1, 2, 4, 8 — 0 will disable the cacher and other values will get rounded to the nearest valid value
xcache.size setting refers to the aggregate memory of all cache threads. So, each thread gets roughly size/count amount of memory
OOM aka Out of Memory, refers to the event of a cache thread hitting it's maximum size
Variable caching requires using a simple get/set api in your app code. After enabling it using xcache.var_size and xcache.var_count (similar to Opcode settings) you use xcache_set($var1) and xcache_get($var1) in your scripts.
Invalidation
The xcache.stat setting controls whether or not to check if the file was modified since it was cached:
When set to On files get checked and re-cached
When set to Off skips the check will keep the first cached version as long as the expiration time, which could help performance by limiting disk i/o
In your dev environment it's a good idea to keep it On so you can update and check your code continuously — otherwise you have to flush the cache to see updates to files.
Flushing
There is a web admin interface which allows you to flush a particular cache. The web admin uses a php api: xcache_clear_cache(…).
Since the cache is RAM based anytime the server restarts the cache should be flushed.
Expiration
Cached items expire according to xcache.ttl and xcache.var_ttl which respectively control the number of seconds a cached item lives (0 is indefinite and the default).
Coverager
The coverager module, aka Code Coverage, is a little mysterious. According to the FeatureList it seems like a diagnostic tool intended to be enabled for temporary administrative/testing situations:
Coverager + real life testcase framework, this include: [TOSHARE]
real life testcase framework, a control script with real browser. you have to write the test cases.
builtin Coverager + its viewer from web, to see how much script you have tested.
the testcase+Coverager just help you make sure all real life php web applications is running correctly when
after enabling XCache
after upgrading php4 to php5
after upgrading php4/5 to php6
I'm using APC to reduce my loading time for my PHP files. My files load very fast, except for one file where I define more than 100 arrays. This 270 kb file takes 200 ms to load. The rest of the files are full of objects, methods, and functions.
I'm wondering: does OP code caching not work as well for arrays?
My APC cache should be big enough to handle all of my classes. Currently 40% of my cache is free. My hit rate is 99%.
apc.shm_size=32 M
apc.max_file_size = 1M
apc.shm_segments= 1
APC 3.1.6
I'm using PHP 5.2, Apache 2, and Windows Vista.
All your arrays need to be serialized when stored in cache and then unserialised again when you load them from cache, this costs time and might be the significant factor of speed loss that you experience. (for your info: Serialisation)
One way to speed up serialisation a bit is to use igbinary, igbinary can be used seamlessly with APC by putting apc.serializer=igbinary in php.ini or in the ini file that goes over APC. (note: this requires APC >= 3.1.7)
You could also put apc.stat (in the same ini file) as 0 so that it only check files for modifications once as opposed to every time.
One thing about opcode caching is that unless you have it configured correctly, it will continue to stat each file to look for changes. This can cause significant overhead if you need to parse and convert many files to opcode.
You typically get a huge boost in performance by setting apc.stat = 0. However, be aware, that in order to make changes to your code, you'll need to call apc_clear_cache() or restart apache.
http://www.php.net/manual/en/apc.configuration.php#ini.apc.stat
The problem was using the gettext library to translate everything. When I get rid of around 1000 function calls, the load time is reduced from 200 ms to 6 ms.
My guess is that the serialization of the data is also a problem, however it is a secondary one.
Recent versions of PHP have a cache of filenames for knowing the real path of files, and require_once() and include_once() can take advantage of it.
There's a value you can set in your php.ini to set the size of the cache, but I have no idea how to tell what the size should be. The default value is 16k, but I see no way of telling how much of that cache we're using. The docs are vague:
Determines the size of the realpath cache to be used by PHP. This value should be increased on systems where PHP opens many files, to reflect the quantity of the file operations performed.
Yes, I can jack up the amount of cache allowed, and run tests with ab or some other testing, but I'd like something with a little more introspection than just timing from a distance.
You've probably already found this, but for those who come across this question, you can use realpath_cache_size() and realpath_cache_get() to figure out how much of the realpath cache is being used on your site and tune the settings accordingly.
Though I can't offer anything specific to your situation, my understanding is that 16k is pretty low for most larger PHP applications (particularly ones that use a framework like the Zend Framework). I'd say at least double the cache size if your application uses lots of includes and see where to go from there. You might also want to increase the TTL as long as your directory structure is pretty consistent.
To expand on the answer provided by Noodles, you can create a little test.php with the following code:
<?php
echo "<br>cache size: ".realpath_cache_size();
echo "<br>";
echo "<br>cache: ".print_r(realpath_cache_get(););
?>
Upload this to your site and navigate to it. It will show you the amount of bytes currently being used by your cache, as well as what's actually in the cache. This value is changing all the time so keep hitting that F5 button to get a better sense of where you're at. It's a good idea also to do your testing during peak times.
If you see the value is frequently hitting your max cache size as defined in your php.ini then it's time to increase that value.
Keep in mind that the default PHP setting is 16K which is 16384 bytes.
the 16K is the # of files not activity.
Set to 1k for most sites. Very similar to settings in APC, xcache ea etc.