It doesn't seem like APC has been updated to coincide with the php 5.4 release (I wish they would have included APC in PHP core like originally planned).
I can't seem to find any definitive answer to whether current APC works with php 5.4+. I managed to find Ubuntu packages for php 5.4, but php-apc packages won't install.
Zend OPCache included in PHP 5.5
On the 21st March 2013, the PHP 5.5 beta 1 was released including "Zend OPCache" - It looks firmly like this will be the replacement for APC going forward as it is included in the PHP core, and will have to be maintained for each new release.
I would personally advise those who depend on APC for it's opcode caching to test their code with the upcoming built-in opcode cache, and feed back any issues encountered to ensure a stable final release.
I do not know what this means for the future of APC.
APC FOR PHP 5.4+ IS STILL FLAGGED AS BETA
This means the developers do not consider it completely stable. While many people are experiencing no problems at all with the current SVN releases, there is still the odd report of edge cases from people under certain configurations, or under heavy load.
As with everything you would want to use in a production environment, make sure you thoroughly test any release (beta or stable) in development or pre-production environments first. This includes load testing!
As of the 3.1.13 release, commits to the SVN repository have slowed down somewhat and the bug list doesn't have that many recent additions. Make of that what you will.
On 10 December 2012 21:05, Rasmus Lerdorf wrote:
APC is at the point now for 5.4 where I don't think there are any more edge cases than we have in 5.3. Neither is perfect, but it is close enough for the majority of sites.
Anyone with C / gdb skills and some free time is urged to gloss over the bug list and see if they can fix anything, or improve this free open source product that we all rely on.
Alternative solutions exist, Wikipedia provides a list of PHP accelerators.
On the 13th of February 2013, Zeev Suraski announced the availability of the Zend Optimizer+ source code.
There has been quite a lengthy discussion about integrating Zend Optimizer+ into the PHP core in the next major version (the version after 5.5). People may wish to familiarise themselves with Zend Optimizer+ in advance, should this be the case.
Do not use APC 3.1.14
APC 3.1.14 has been removed from PECL downloads due to some serious memory issues that have been discovered but have not yet been tracked down.
If you're already using 3.1.14, you may wish to downgrade until 3.1.15 is released. Remember, this is still beta. If you are using it at all, you are using it at your own risk.
2013-01-02:
APC 3.1.14 is available, adding PHP 5.5 compatibility, in addition to resolving a fair number of other bugs.
Still beta
2012-09-03:
APC 3.1.13 is available, fixing a number of segfaults.
2012-08-16:
An APC 3.1.12 tag has been created, but is still marked as beta, its available on the APC PECL page, as well as the changelog.
Lots of bin_dump related bugs fixed this time around.
2012-07-19:
An APC 3.1.11 tag has been created, but is still marked as beta, its available on the APC PECL page, as well as the changelog. I've been following the relevant mailing lists, and they are still actively working on fixing APC bugs however it is a complex module and not many people seem to be up to the task. This release fixes the nasty stat=0 bugs when including files.
2012-04-11:
An APC 3.1.10 tag was created today, and a beta release of 3.1.10 was placed on the APC PECL page
The changelog states:
Add PHP 5.4 support (Dmitry, Anatoliy, Pierre)
Fixed bug #22679: Fix apc_bin_dump for constants. Use IS_CONSTANT_TYPE_MASK to handle all the constants, including the unqalified ones (instead of ~IS_CONSTANT_INDEX check)
Fixed bug #23822, php crashes on apache restart
As of PHP 5.4.7 and APC 3.1.13 (and even APC SVN trunk as of 2012-09-19), although it is "compatible" it is not stable on servers with heavy load, particularly if you're using PHP-FPM and $GLOBALS. Some of the developer discussions on APC talk about unresolved fringe cases.
I'm answering this question 6 months after it was asked because the problem is still prevalent, and encountering this thread w/o an answer like mine is what made me make the leap to PHP 5.4 w/ APC and get burnt. Hopefully this will help people avoid some pain.
It appears that the bug "may" have been fixed in the latest revision to the trunk. I've got it working now with PHP 5.4.0.
svn co http://svn.php.net/repository/pecl/apc/trunk/ apc-trunk
cd apc-trunk
phpize
./configure
make
make install
No, APC 1.3.9 (and as of this moment, even the svn trunk) isn't compatible with php 5.4.0, I know because I've just spent hours trying to get it to work (tested various svn/php.ini settings/compiler flags/you name it).
This is just ridiculous, APC is one of the most popular PHP extension and you'd expect after weeks of going through 8 PHP 5.4 RC's they'd have the time to get APC to work along side it.
Pathetic.
Well I'm trying for the last few days, and there is no way I can get an opcode cacher to work with php 5.4. Xcache won't compile, and apc will not recognize certain classes when cached.
I think this is the error Simon is talking about.
I heard there were some fixes in the trunk, but I also tried the latest trunk sources, but the same errors keep coming back.
I think php without a opcode cacher (there is none available right now) is not production worthy. Hopefull the people at apc will fix this asap.
UPDATE!!!
Xcache 2.0.0-rc1 is out and compatible with php 5.4. Enjoy!
I found apcu http://windows.php.net/downloads/pecl/releases/apcu/
Maybe this is apc for x64 on windows. It (version 4.0.1) worked on my application.
I am using AMPPS with PHP Version 5.5.19. Since some time now exactly from release of PHP 5.5 - APC is replaced with Zend OPCache which is included in PHP 5.5 and up. Now all you have to do to enable "APC" (currently "OPcache") is to edit your php.ini. Before [XDebug] section add the flowing lines:
php.ini
...
[OPcache]
zend_extension=php_opcache.dll
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=512
opcache.interned_strings_buffer=24
opcache.max_accelerated_files=4000
opcache.revalidate_freq=3
opcache.fast_shutdown=1
...
Please note that we need to have two instances of:
zend_extension =
One in [OPcache] and one in [XDebug] section. Xdebug is often not provided as default in your xampp/ampps/easyPHP server installation. You might find yourself in a situation where you will need to download Xdebug extension. You can do this easily by using an online application that defines the right Xdebug for your php. Visit http://xdebug.org/wizard.php and follow their simple instructions. Once you have downloaded the right version of Xdebug for your php version - edit the link of your zend_extension in [XDebug] section.
...
[XDebug]
zend_extension = "C:\Program Files (x86)\Ampps\php\ext\php_xdebug-2.2.6-5.5-vc11.dll"
......
Please note! that you have to add OPcache section before XDebug in your php.ini file!!! If you follow me correctly you should have two instances of zend_extension in your php.ini file (one in OPcache and one in Xdebug section).
This works perfectly for Symfony2 framework, and eliminates recommendation message to install and enable APC for your PHP and Xdebug.
Message to those who run symfony 2 and removed the warning message from "web/config.php", but still encounter a problem by running from command line "php app/check.php". If this happens, that means that your console is using a different php.ini file. Change your system PATH varible - make it point to the right php directory (where you have your php.exe file and which is used by your local server).
If you need deeper explanation let me know in the comment below. Regards.
There seems to be some issues yet to be ironed out. Check out the bugs and you might be able to figure out what is the solution to your particular problem.
I dealt with one such error some hours ago, and it turned out that using APC from the SVN trunk was the way to go. Hope this helps!
I've found that you need to clear the opcode cache on each page request otherwise classes that implement interfaces fail to load. This was compiled from the latest svn trunk, Apache 2.4.1, PHP 5.4.0.
APC - not recommended
Personally I didn't use APC with PHP 5.4 or PHP 5.5, but latest stable APC is not compatible with PHP 5.4, latest beta APC can be used with 5.4 but it is written that still have negative issues with APC.
If you have PHP 5.5
just use Zend Opcache. It is out of the box, so problems are minimum.
If you have PHP 5.4
I recommend XCache. It is fully compatible with PHP 5.4 and 5.5. Actively developed. Last stable version was released 3.5 months ago (10 October 2013). It improves performance even if you use fastcgi.
Zend OPCache is included in PHP 5.5 under the name php_opcache.dll in the php/ext directory.
In order to activate it:
Add the php_opcahe.dll file as a zend extension in your php.ini configuration file.
Use the format zend_extension = path/to/php/ext/php_opcache.dll.
Place the zend_extension before the xDebug zend_extension in your php.ini config.
Save your php.ini configuration file and restart your server.
APC has a new version: 3.1.14 since 2 January, which resolves some bugs:
http://pecl.php.net/package/APC
However, I have been running PHP 5.4.x with APC 3.1.13 from the dotdeb repository without any issues so far, so for me I would say it's stable. dotdeb has also informed me that they will be including the updated APC in the next release of PHP, which is expected to be 5.4.11.
We are experimenting memory free errors (apache segfault) with PHP 5.4.26 and APC 3.1.9.
There's an open bug for APC on PHP 5.4.X: https://bugs.php.net/bug.php?id=61934
I recommend not to use this plugin on PHP > 5.3.
In XAMPP Version 5.6.3 (PHP 5.6.3) all you have to do in your ini.php is this:
[OPcache]
zend_extension = php_opcache.dll
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=512
opcache.interned_strings_buffer=24
opcache.max_accelerated_files=4000
opcache.revalidate_freq=3
opcache.fast_shutdown=1
[XDebug]
zend_extension = "C:\xampp\php\ext\php_xdebug.dll"
xdebug.max_nesting_level = 200
xdebug.profiler_append = 1
xdebug.profiler_enable = 1
xdebug.profiler_enable_trigger = 0
;xdebug.profiler_output_dir = "C:\xampp\tmp"
;xdebug.profiler_output_name = "cachegrind.out.%t-%s"
;xdebug.remote_enable = 0
;xdebug.remote_handler = "dbgp"
;xdebug.remote_host = "127.0.0.1"
;xdebug.trace_output_dir = "C:\xampp\tmp"
Configuration for symfony2 framework.
Related
I read all over internet that APC will be included in PHP6. However the PHP6 project was cancelled and they skipped one major version to avoid confusion, which then again causes more confusion. This however is another discussion for another time.
My question is:
Will APC or any other cache module still be introduced, included and enabled by default in PHP7?
The reason why I am asking is because I am considering implementing memcached into my projects. But if there is a native cache solution in PHP7 i'd rather stick to that.
PHP 7 has a built-in opcache, APC is deprecated and will not work.
Enabling PHP7 Opcache
Reference: http://php.net/manual/en/intro.opcache.php
PECL Extension: # https://pecl.php.net/package/ZendOpcache
I'm using Ubuntu 12.04 LTS and needed PHP 5.4 so I'm using Ondřej Surý's (php5-oldstable) package.
Both phpinfo and the CLI show that JSON is enabled:
#php -i | grep -i json
json
json support => enabled
json version => 1.2.1
My application mostly works. But periodically (approx one page refresh in ten) there is a PHP error. This only happens intermittently.
PHP Startup: Unable to load dynamic library '/usr/lib/php5/20100525+lfs/json.so'
- /usr/lib/php5/20100525+lfs/json.so: cannot open shared object file:
No such file or directory "json.so"
How do I fix this?
I think that possible culprit (as I have answered in email) is that you are loading json extension somewhere from the configuration file.
The JSON extension is compiled in the core for PHP 5.4, so you should not load it by hand.
Please check that you don’t have:
json.ini somewhere in the /etc/php5/{mods-available} left over from previous PHP 5.5 installation
you are not loading JSON extension from the mentioned script, e.g. no dl(json.so).
Make sure you have stopped and started Apache2 (same applies to php5-fpm) when changing major versions. The symptoms might indicate that there was some stuck Apache2 thread with previous PHP from package loaded (that would be PHP 5.5 with json-c based JSON extension in this case).
Since you're saying that the json extension is loaded in phpinfo()'s output you could be dealing with a bug. Have you checked if the module file is actually there in the filesystem?
You have the following options:
Compile PHP 5.4 from source with Apache 2.4
Upgrade to the same repo's stable version which will give you PHP 5.5 + Apache 2.4.
Submit a bug with the Ondrej in Ubuntu's PPAs and wait for it to be resolved.
For more information check the debphp site.
Submitting a bug is a must, since if it is a real one it must be fixed for all users.
You could firstly go with option 2 if you don't conflict with the Migration guidelines like backward compatibility, deprecated functions, etc.. SO check it and decide.
It also strongly varies depending on the machine you have to do this with. If it is a critical production server, you may not want to compile of change versions on it. Go file the bug and see what the package maintainers have to say about this.
Also please write a reply here when your problem is resolved. I am quite curious as to what it is and hopefully was. :D
One point that doesn't diagnose or solve the issue (and seems to refer to PHP 5.5), but might help with tracing its root cause:
This Debian bug report and Phil Sturgeon's blog explain that some Linux distributions have chosen to replace the official PHP implementation of ext/json with the drop-in compatible pecl-json-c. The rationale was that Douglas Crockford's implementation contains a non-free clause in the license ("The Software shall be used for Good, not Evil"). See also this blog post.
I give up. I've asked this question some time ago but I'm again into that issue. I'm still stuck with compilation errors / missing files / other stuff that I can't / don't have time to fix. Don't get me wrong - I've compiled it several times, but none of the DLL files I've got worked. I use WAMPServer 2.1e [Apache 2.2.17, PHP 5.3.5] - after enabling php_runkit it does not start. Even already compiled DLLs from the Internet haven't worked. Another time Windows seems to be simply against me.
Now as a programmer I feel really, really lame to ask you the following: can someone compile PHP runkit DLL extension for me or point me to the WORKING one? Please test if it works and provide your WAMP stack configuration, so I can adjust mine.
You would be my hero.
I compiled Zenovich's fork for 5.3, no ZTS, VS9, commit f8daf39 with trivial changes in order to build in Visual Studio.
Unfortunately, the ZTS version seems to broken and did not compile. Its problems would require some effort to fix. So you must run PHP as a CGI binary, not as an Apache module.
Artefacto's binaries didn't work correctly for me so I compiled the newest runkit for PHP 5.3, 5.4 and 5.5 (both TS and NTS versions). You can grab it here - https://github.com/Crack/runkit-windows.
PHP 5.3 and 5.4 modules are compiled with VC9, 5.5 with VC11 so they work with official PHP binaries.
I am working on a website which is hosted on a VPS with CENTOS 5.4 i686 virtuozzo installed. I have a drupal installation on the server which gets around 100s of authenticated users at the same time.But at a certain point of time the server stopped responding and the site went offline. So, I tried installing the opcode cache - Alternative PHP Cache.
While the rest parts of the server work fine, the Drupal installation crashes as soon as I install PECL APC with the following message
Fatal error:Cannot run code from this file in conjunction with non encoded files in /home/apogee/public_html/2010/themes/zen/zen/block.tpl.php.
Could you please tell me a way to properly configure Drupal to use APC ?
Thanks
niting
I think the error comes from Zend Encoder...if you don't need it installed then uninstall it and see if that fixes things. If you do need it (closed-source module?), then not sure if that and APC can play nicely together...
you must be disable APC on php.ini
apc.enabled=0
APC and Zend Optimizer can't work with together
David Strauss at four kitchens has done some work on getting Pressflow (Performance tuned Drupal distribution) to work well with APC https://wiki.fourkitchens.com/display/PF/Tuning+APC.
With that much concurrent usage it may be worth your while to look into pressflow.
I have a couple of websites using APC and I've never seen that kind of error -- even with the Drupal-based ones.
After a bit of searching, it seems related to Zend Optimizer and/or Encoder (see the last answer on this thread, for instance), and not to Drupal itself.
I suppose you should use either Zend products, or APC, but not a combinaison of both.
I've been using PHP version 5.2 and now need to upgrade to version 5.3 (Windows/Apache). I have been using 5.2 for awhile now and have customized many things in php.ini and added some extra extensions.
How can I upgrade to version 5.3 without having to reconfigure everything? Or does upgrading require that I customize my PHP installation all over again?
Thanks, Brian
If you take a look at Upgrading to PHP 5.3 - an easy way, i think that will solve your problem, but if you're in a Linux machine that you can use apt-get the only thing that you need to do is:
$ sudo apt-get upgrade php php-* mysql-*
$ /etc/init.d/httpd restart
Regards.
The transition is not necessarily easy, but not hard also. PHP 5.3 brings some changes to the internal Zend API, so some PHP extension need to be upgraded (I had to upgrade xDebug). That means that you need to find the respective DLLs, which may not be that easy, depending on your current setup.
The config file, php.ini, is pretty much the same. You will actually have to take some things out actually (for example extension=php_pdo.dll is not needed anymore).
Just execute php -m from command line and see what errors are thrown. I have just copy-pasted the php.ini file from a 5.2 release and was done configuring 5.3 in a couple of minutes.
I mentioned xDebug a few lines above. If you use it, you should know that the line which activates xDebug is now:
zend_extension = "path\to\PHP 5.3.0\ext\php_xdebug.dll"
instead of:
zend_extension_ts = "path\to\PHP 5.3.0\ext\php_xdebug.dll"
The main thing I've run into is a mess of new E_DEPRECATED notices when doing anything from PEAR. Like the other comments, you'll want to adjust your error reporting levels appropriately.
Another thing to notice is that if you're upgrading from a package management system like macports or apt, some of the config layouts have changed and you'll have to adapt there.
Other than that, there aren't a lot of functional differences between 5.2 and 5.3.