LiteSpeed + APC + SuEXEC + FastCGI

[philipm]

History:
We are running litespeed (currently standard for testing), Plesk 9.5, SuEXEC enabled in litespeed, APC isntalled and compiled into PHP, and FastCGI module in Plesk for PHP.

Issue:
APC seems to be dumping about every 30 seconds(I assume this is a default timeout for a PHP thread), this only seems to be happening when the FastCGI module is enabled in Plesk, when we switch the PHP mode to Apache module there are no issues.

What we have tried:
We have tried to use the article listed here: www [dot] brandonturner [dot] net/blog/2009/07/fastcgi_with_php_opcode_cache (setting up the external app as a FastCGI module) I continue to get 503 errors when I view the apc.php page, when I leave the script handler as a litespeed API module and I have no issues (other than the APC dumping)

What we need:
We need FastCGI, SuEXEC, and some sort of caching (preferably memcaching, we would LIKE APC).

Does anyone have any suggestions?

 

[mistwang]

eAccelerator is recommended for LiteSpeed suEXEC PHP.
FastCGI is not as fast as our LSAPI PHP. LiteSpeed will use LSAPI by default even if you use Apache + FCGI PHP.

 

[philipm]

We have tried eAccelerator as well but the cache still appears to be clearing on a contant basis.

We don't care about the speed of FastCGI, we need it for its security concerns. We need to be able to keep the PHP processes locked to the user that started them for security reasons.

 

[mistwang]

LSAPI PHP does the same in suEXEC mode.

 

[NiteWave]

store eAccelerator's opcode in /dev/shm.

/dev/shm is in memory.

whether php process is running or killed, the cache is there until OS reboot.

I helped 1 customer to implement it, and clear the cache every 2 hours, it's working, and reduce the server load a lot as expected.

 

[philipm]

store eAccelerator's opcode in /dev/shm.

/dev/shm is in memory.

whether php process is running or killed, the cache is there until OS reboot.

I helped 1 customer to implement it, and clear the cache every 2 hours, it's working, and reduce the server load a lot as expected.

Thanks I will give that a try and see how it goes.

 

[philipm]

We now have it set up like you have stated. But the cache is clearing again when we have Plesk set like this: http cl.ly/78987e80e527b52ff326

When we have Plesk set as any other run as module it works fine but the php process appears to be started by www-data not by the user. I have the eAccelerator cache set to go to /dev/shm but that isn't helping at all. If I turn off PHP support in Plesk it still works but the php process is still started at www-data (that is what user LSWS is running as)

If there is any bit of the configuration that I can provide please let me know.

 

[NiteWave]

here's an example settings FYI:

eaccelerator.shm_only="0"
eaccelerator.cache_dir="/dev/shm/ea"

of course need create /dev/shm/ea first. and
chmod -R 777 /dev/shm/ea

run a few php scripts, and check
"find /dev/shm/ea -type f"
or
"du -sh /dev/shm/ea"
to see if the number of files or size is increasing? then the opcode cache of eAccelerator is working fine.

the cache is clearing again

yes. that's for shared memory(SHM) cache. the SHM cache will disappear when its associated php process terminates. but eAccelerator also store opcode cache on disk at the same time --- /dev/shm/ea in this case.

when another php process start, it'll look for opcode in /dev/shm/ea.