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
Related
Even tho the website is behind CloudFlare CDN, we decided to use OPCache to reduce the load on server as there are a maximum (peak) of ~400 active users per second (most of the time it's 50-100 u/s).
But most pages have some different data for each user, for example user's dashboard overview, most of the data is same but it has some different numbers for each user that needs to be up to date.
My Questions are:
Is it wise to use OPCache for such a website?
How will it handle pages with unique queries? will it take more RAM (caching multiple pages for each user) than running without OPCache?
Will it affect performance on pages such as Signup/Login etc?
I read that all PHP applications should use OPCache, is that correct?
P.S. The website is running on PHP 7.3.4
Yes it will gain performance improvement
If your RAM usage increased and you're concerned with it, you can fine tune memory consumption via opcache.memory_consumption
Affect meaning they will be faster
Yes, there really is no reason to not use OPCache other than edge cases (e.g., when your app's source code changes at a very fast rate or testing).
TLDR: Production code should always have OPCached enabled.
OPcache only caches the internal opcode representation of a PHP script, not its output. The queries performed or the content displayed by the page has no impact on how OPcache will behave.
This caching will improve the performance of all PHP web pages. As such, it should always be enabled on production sites.
Each PHP script is being compiled at runtime,
It takes time to transform the human readable code into a code that can be understood by the machine.
OpCache is a bytecode cache engine , it will compile the script to bytecode script only once - so you will save time - then the precompiled script is being stored in memory, which should lead to performance boosts in your PHP applications.
What i think you are missing is that the opcache DOES NOT cache the result of the script , but it is just compile the script .
Note this method is not good if the php script it self is changing for each user
or if it is loaded from -let's say for example- a database
As general view for this approach
Php caching whatever it was APC cache or opcache or else is amazing strategy this should increase php performance by 50% in general
As it act as follows
When php script excuted there's this involve three major steps
1-parse of the script
2-compile of the script
3-output
APC cache or else act as intermediary as it saves php script in the compiled form so php will start in the output stage directly and this will not affect queries but it will increase its speed as query for MySQL or else not just the statement of SELECT or whatever but it involves execution of extensions like PDO so it will become faster
You can classify extension as follows
APC or Xcache for php 5
In new php version use opcache
All of them have the same principle
Some developers like APC other like opcache
As example X-cart the popular shopping platform use xcache .
I am running PHP Version 5.3.5 and developing a website in Codeigniter 2.1.3
I am working now to improve website performance, and I found caching can be used like APC or memcached or Zend OpCache.
In codeigniter I used $this->output->cache(43829); for caching.
Output of actions got cached, and It returns same output on every request.
But I have dynamic pages so this caching will not work. I am looking around how APC can be used for ope-code caching and used to enhance web site performance.
Is APC stores opecode in cache that cane be used by zend engine for execution execution, without regenerating opecode on each request?
Attached is my PHP APC configuration
PHP 5.3 is nearly 2 years past end of life, and APC is not available for current PHP versions. PHP 5.5+ comes with Zend Opcache, which has equivalent functionality. Instead of trying to get your site to work with old technologies, simply upgrading your server to a current (and secure) version of PHP would give you this performance boost without you having to do anything else.
Output of actions got cached, and It returns same output on every request
While its faster than regenerating the page, its still far from optimal. Better to use a caching reverse proxy in such a case.
I am looking around how APC can be used for op[e]-code caching
Your question implies that you think you are not already using op-code caching. I suggest your first port of call is to see if it is already enabled. You can see this from the output of phpinfo() or check function_exists('apc_sma_info');
APC is unlikely to be provisioned for future versions of PHP. ZOP+ is the opcode cache which is currently bundled with PHP 5.4+. It will work with 5.3, but requires some effort. Tim is correct in saying the 5.3 is past its sell-by-date and should be upgraded.
Note that ZOP+ also includes an optimizer (and, rather alarmingly, it seems to have a significant impact on the performance of many frameworks). The performance of ZOP+ is more dependent on sizing the cache than in APC - but even with APC, sizing the cache wrongly will not give good results.
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.
What kinds of things should I avoid if I want to support PHP OpCode Caches? Are static calls evil? What about __autoload?
For every PHP-based web-application I've worked on for the past 3 years and a half, I've always used APC as an opcode cache, on all the servers I'm using...
... And I've never had to take of anything "special" while developping : in every case, using APC or not has been transparent, the only difference being about performances.
I've never had any problem with static calls, nor autoloading, for instance -- nor with anything else (And I've worked with a couple of different Frameworks and OSS Applications)
Still, one good habit : if you plan to use APC on your production server, also use it on your development machines, just in case -- but enable the apc.stat option on those, so your life is not complicated by the opcode caching mecanism.
An opcode cache is made to cache the compiled version of the script. The Zend Engine under the hood always compiles PHP scripts to faster opcodes before running the script, and it is these opcodes the cache will save. You script will therefore behave in exactly the same way as it should without the cache, only be faster to begin running.
The cache engine usually look in the timestamp (modification time, or mtime) of the PHP file. APC can be configured to look up the modification time on every request (the default), but it could also be configured to NOT check for modification time and in that case you have to manually clear the cache to take up changes. See this setting to the APC cache:
http://php.net/manual/en/apc.configuration.php#ini.apc.stat
Does anybody have experience working with PHP accelerators such as MMCache or Zend Accelerator? I'd like to know if using either of these makes PHP comparable to faster web-technologies. Also, are there trade offs for using these?
Note that Zend Optimizer and MMCache (or similar applications) are totally different things. While Zend Optimizer tries to optimize the program opcode MMCache will cache the scripts in memory and reuse the precompiled code.
I did some benchmarks some time ago and you can find the results in my blog (in German though). The basic results:
Zend Optimizer alone didn't help at all. Actually my scripts were slower than without optimizer.
When it comes to caches:
* fastest: eAccelerator
* XCache
* APC
And: You DO want to install a opcode cache!
For example:
alt text http://blogs.interdose.com/dominik/wp-content/uploads/2008/04/opcode_wordpress.png
This is the duration it took to call the wordpress homepage 10.000 times.
Edit: BTW, eAccelerator contains an optimizer itself.
MMCache has been deprecated. I recommend either http://pecl.php.net/package/APC or http://xcache.lighttpd.net/, both of which also give you variable storage (like Memcache).
Both are interesting and will provide speed boost since they compile source code into binary representation which is then executed by the PHP engine.
Any huge web site running with PHP (Facebook for example) is running some sort of opcode cache system like MMCache.
The problem is that they are not very easy to set up depending on your system.
Depending on how much of your PHP code is actually executed and how long that execution takes they can be a really big win. It certainly isn't going to hurt, but the gain you see will very much depend on where your time is currently spent.
btw mmcache has been rolled into a different project now, I forget the name but Google will tell you.
I use APC on my production servers and it works pretty well out of the box. Compile it and add it to PHP and there isn't much tweaking left to do for it. I check it every once in a while just to review stats but since I use MVC a lot all of the main files (routers, controllers, etc) rarely change on a day-to-day basis so that code stays compiled and runs pretty efficiently.
currently we use apc, free and was just a simple plug and play on our live servers. Provided a huge performance increase for our site, especially as the project size increased. I also have the apc.stat disabled so it doesn't check if the code has been updated, so whenever we need to update the code on the live site we restart apache.
I use APC, and can attest that it can dramatically reduce the CPU and I/O load on an app server if you maintain a high cache-hit rate. It not only saves you from having to compile, it can save you from having to read the php files from disk at all. (i.e. the bytecodes are served directly from main memory, so it's super fast) It lowers the speed to render a single page, and increases the requests per second your server can handle.
If you use RedHat or CentOS, installing APC is super simple:
yum install php-devel httpd-devel php-pear
pecl install apc
echo "extension=apc.so" > /etc/php.d/apc.ini
# if you're using SELinux:
chcon "system_u:object_r:textrel_shlib_t" /usr/lib/php/modules/apc.so
/etc/init.d/httpd restart
You asked about downsides. The only downside is that it requires some memory. The default on APC is 30MB, but it can be adjusted, and the cost of a little bit of memory more than pays for itself with the increased speed and response rate.
BlaM's testing included all the DB calls made by WordPress. When you're making fewer DB calls, you'll see the performance gain of opcode caches be even more dramatic.
I used Zend Accelerator a little back in the day (2004-ish). It certainly gave some significant performance wins on code it could work with, but unfortunately the system I was using was designed to quite often dynamically load code and then eval it, which Zend Accelerator couldn't do much with at the time (and I'd guess still can't).
On the down side, we certainly saw some caching issues (where the code would be changes, but the compiled version sync with the change for one reason or another). I imagine those problems have likely been ironed out by now.
Anyway, I don't have any hard comparison numbers, and certainly didn't write the same system in different environments for comparison, but for the vast majority of systems, PHP isn't going to kill you performance wise.
Have you checked out Phalanger? It compiles PHP to .NET code. Here are some benchmarks which show that it can dramatically improve performance.