![]() |
PHP LsPCI and APC ? ==> PHP LSAPI and APC ?
Edit : Sorry about the title, obviously not LSPCI but LSAPI ! :)
Hello, We're looking into purchasing a LSWS licence for our new server configuration and I've read your documentation about APC and am not sure which is the best configuration for this. We run cPanel serveurs with CloudLinux 6 + CageFS. I've already read this : http://www.litespeedtech.com/support...p:opcode_cache But have also read that Litespeed 4.2 added suexec support. This is what we are lookind for : 1) PHP to be run with the same user as the FTP user (I've read that some hosts dont want this but we do because our customers like being able to run updates and installs without playing with chmods). 2) To have a single APC cache per user shared by multiple children. 3) To be sure that cache is not accessible between different user accounts. Before looking at litespeed we looked at PHP-FPM but PHP-FPM's pools did not prevent users from accessing each other's cache and it was too complicated to run multiple instances of PHP-FPM (one instances with one pool per user). Is Litespeed the miraculous solution to my problem ? Thanks ! :) |
in lsws admin console,
Server->General->Cloud Linux there are 4 choices: Disabled LVE CageFS CageFS without suEXEC "CaseFS" can meet your requirement 1) however 2) 3) is not possible in shared host environment which may have thousands of user accounts -- at the time being. there is a workaround to meet the requirements closely. choose xcache instead of apc, while one copy of opcode cache is shared by all accounts, only admin can see the cache's content. |
Quote:
Does XCache have an object cache like APC ? If so would it be secured between users ? Lots of scripts are compatible with APC, I'm not sure how many can nativly use Xcache object caching |
xcache has opcode cache as well as variable cache, like apc.
xcache is popular and famous enough, no less than apc. Quote:
it's like all accounts may store php session in /tmp, but it's regarded safe enough - php script can't make use of it to see other account's data. |
Thanks :)
Will XCache prevent users from accessing each others Object cache code ? Also Quote:
And is there some form of ETA for this feature ? |
Quote:
With APC and PHP-FPM, APC is launched at the startup of PHP when it is owned by root so when PHP-FPM forks an instance of PHP this instance accesses a global instance of APC. If the unix user : UserA runs apc_store ('foo', 'hello world'); Then unix user: UserB runs : print apc_fetch('foo'); It will output 'hello world' If unix user UserB then runs : apc_store('foo', 'Goodbye world'); UserA expects the value to be Hello world but when he runs : apc_fetch('foo'); it outputs 'Goodbye World' |
I've just read that xcache caches per process just like APC.
If xcache has no protection to prevent users from accessing each other's cache set with xcache_set() and retrieved with xcache_get() then xcache has exactly the same problem as APC. As far as I can see the only solution here to use Xcache or APC would be to either run one PHP process per user and fork this process for that user (Fastcgi can do this but fcgid can't from what I've understood LSAPI can't either |
Quote:
"In suEXEC daemon mode, all PHP worker processes are forked off the same parent process running as root, PHP opcode cache memory are shared by all PHP processes, and it won’t be flushed as long as the parent process still running. " http://blog.litespeedtech.com/2012/09/ |
sorry for confusion.
Quote:
lsphp suEXEC daemon mode + xcache will meet the requirement closely. however, it's close, not exactly as 2) + 3). since Quote:
Quote:
however, there is no problem for opcode cache since the php scripts under each account has different path, so the opcode cache can't be accessed each other. |
Quote:
|
| All times are GMT -7. The time now is 01:30 PM. |