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

[ts77]

Hi there,

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?


Thanks,

thomas

 

[xing]

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.

 

[ts77]

Hi xing,

thanks a lot for your information.
I'm going to try it with php-5.1 then, as most of the apps I'm running are pretty much my own code.
The other legacy stuff can run on php-4.4 unaccelerated .

Thanks to lsws which gives me the option to run any vhost or directory on any external app I want or need .

 

[Xorlev]

Attempting to run Litespeed + PHP 5.1.4 + APC 3.1.10 resulted in 503 errors and "connection reset" errors for the socket in the log. Odd.

 

[xing]

Attempting to run Litespeed + PHP 5.1.4 + APC 3.1.10 resulted in 503 errors and "connection reset" errors for the socket in the log. Odd.

Strange indeed. It's humming along just fine on CentoS 4.3 Linux using the compile setup detailed in the wiki.

Let us know if you find out the cause.

 

[mistwang]

Please download and try the latest PHP LSAPI code.

 

[ts77]

Hmm, is that user running lsapi at all or does this mean that lsapi is more stable for using it with apc?

 

[mistwang]

I think he should be using lsapi, one bug has just been fixed in LSAPI library. It should not matter which API is used, APC stability wise.

 

[Xorlev]

I am running LSAPI for PHP 2.1 (recompiled today) and followed the instructions in the wiki. Odd, that.

 

[xing]

xorlev, does the lsapi php binary dump errors in the logs when you execute it manually?

1) Stop litespeed.

2) /lswsinstall/fcgi-bin/lsphp -i [or name of your php binary with lsapi compiled and APC installed/configure in .../conf/php.ini]

Running the above command with -i or -v should get you basic info, confirm that APC is installed, and no error should be thrown to the logs.

Are you getting the 503s immediately for every php script execution on litespeed startup? Do the errors go away when you disable APC in php.ini?

Please give paste us the APC config/loading portion within your php.ini.

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]

APC is indeed installed and is shown correctly in the php -i output.

Yes, immediately on load of a PHP script, and commenting out the extension (and rebooting LSWS) solves the problem.

extension_dir = "/opt/lsws/lsphp_install/lib/php/extensions/no-debug-non-zts-20050922/"
extension="apc.so"

Originally I had APC as SHM, but deciding to try it differently I enabled MMAP to no avail.

My thought here is a communication problem between PHP and Litespeed.

LSAPI PHP config:

Name	phpLsapi
Address	uds://tmp/lshttpd/lsphp.sock
Max Connections	20
Environment	PHP_LSAPI_MAX_REQUESTS=500
Initial Request Timeout (secs)	60
Retry Timeout (secs)	0
Persistent Connection	N/A
Connection Keepalive Timeout	N/A
Response Bufferring	No
Auto Start	Yes
Command	$SERVER_ROOT/fcgi-bin/lsphp
Back Log	100
Instances	20
Run On Start Up	N/A
Max Idle Time	N/A
Priority	0
Memory Soft Limit (bytes)	80M
Memory Hard Limit (bytes)	100M
Process Soft Limit	200
Process Hard Limit	200

 

[xing]

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.

Please email the following to xing@litespeedtech.com.

1) Your OS and version.

2) /lswsinstall/conf/httpd_config.xml

3) /yourvhost/conf/vhconf.xml

4) /lswsinstall/conf/php.ini (or your active php.ini if not in this location)

5) You php 5.1.4 config string ./configure... etc

6) Your APC 3.0.10 config string ../configure ...etc

7) Any other info that might be relevant.

I want to leave nothing to chance when replicating your system. Hopefully I can reproduce this error and resolve it once and for all.

 

[xing]

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.

Our wiki has been updated to reflect this problem on some systems.

http://www.litespeedtech.com/community/wiki/

 

[Xorlev]

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.

 

[xing]

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.

 

[Xorlev]

When I enabled it I was thinking memcache, not Turck MMCache. Ah, accidental oversights.