experiences with APC and php-4.4 / php-5.1 ?

2 weeks ago I upgraded my production environment from php-4.3.11 to 4.4.2, both running APC and through fastcgi.

Since then I'm having problems with my php-install, sometimes the php-processes just stall and nothing works anymore, sometimes I get core-files which essentially means that php was/is crashing.
Since I removed APC from the mix its running fine and without problems beside the higher server-load.

Does anyone have any experiences with running a similar setup?

As I could run at least some parts on php-5.1 ... would it help to have a php-5.1 running with APC, is it stable on this setup?

Thomas, I do not have much experience with PHP 4.X as I have moved everything to the 5.1.X branch so my feedback regarding APC will reflect that angle. It's been a long while since I touched PHP 4.X.

APC 3.0.10, latest release is rock solid, there are clients using LiteSpeed + PHP 5.1.X with APC 3.0.X with about 10 million page views per day and there has not been a single core-dump or error logged as result of APC for months. Of course, this is with an PHP 5.1.X optimized code base.

However, there is one caveat.

If you are using APC with something like vBulletin 3.5.4, you might encounter 1 or 2 scripts that give fatal errors under APC and none without APC. There appears to be unresolved bug in APC's PHP object handling code when the code is written based on PHP 4 standards.

vBulletin 3.5.4 uses mostly PHP 4 based object conventions so for these type of rather bloated programs that strive to have the highest PHP version compatibility, you might run into legacy problems with APC where the most recent efforts have gotten into PHP 5 compat. Once I get to reproduce the problem again I intend to file a bug report the APC devels.

Basically, if you develope and run your own programs, APC's stability and performance combination cannot be beat and you can always work around bugs. If you run 3rd party bloated programs, then you need to test it out and make sure everything works.

That's the best advice I have regarding this issue.

Because of the level and quality development that has gone into APC in the last year, LiteSpeed will likely standardize on APC, as part of it's add-on install option, in the very near future.

Also note when the php backened spawns processes to handel php requests, if APC is enabled with SHM (default), then you can check SHM allocation via "ipcs". There will be an entriy listed corresponding to every new php worker.

xorlev, now you have now pegged my interest in this most unusuall problem with APC + PHP5.1 + LiteSpeed. We have confirmed clients running the exact same config on Centos 4.3, Ubuntu Breezy, and Mac OS X 10.4, there appears to be an anonmaly unique to your setup.

I would like to replicate the exact conditions and reproduce this problem.

We have found that older Linux distros, the max allowed size of SHM segments are limited and will cause 503 errors. Best way to test is to leave the apc.shm_size line alone or set it to a value of "4" (4MB) and increase it as you go and as the need arises.

After extensive debugging, we've also found that the MMCache session module (--with-mm) causes 503 errors on PHP 5.1.4 w/ APC 3.0.10. The MMCache module version 1.3.1, but I'm not sure if it's the version, or the technology, but my best guess would be the latter.

Wiki has been re-updated to note that APC is a replacement for all other opcode caching modules and cannot coexist with any of them. If you use one, you need to remove/disable all others.

The problem is that unlike other extensions, APC hooks into the php compiler itself at a low level via hooks provided by PHP API and I'm sure the developers of the opcode caching mech didn't design their products to re-code already encoded/compiled php code when products are chained together.