PHP LsPCI and APC ? ==> PHP LSAPI and APC ?

[Monarobase]

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 !

[NiteWave]

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.

[Monarobase]

By using the PHP_LSAPI_CHILDREN method, only a single APC shared memory slice will be created and shared by all children.

Does this mean that multiple children are allowed but all run from the root user so APC stores can communicate between each other ?

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

[NiteWave]

xcache has opcode cache as well as variable cache, like apc.
xcache is popular and famous enough, no less than apc.

APC stores can communicate between each other ?

how can they communicate with each other (account?), can you give example?

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.

[Monarobase]

Thanks

Will XCache prevent users from accessing each others Object cache code ?

Also

however 2) 3)
is not possible in shared host environment which may have thousands of user accounts -- at the time being.

Does Litespeed have a list of features that are planned for the next major release ? If not is this a feature that's being concidered ?

And is there some form of ETA for this feature ?

[Monarobase]

how can they communicate with each other (account?), can you give example?

Here's an example :
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'

[Monarobase]

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

[waski]

Originally Posted by NiteWave

however 2) 3)
is not possible in shared host environment which may have thousands of user accounts -- at the time being.

I thought that your suexec deamon support opcache sharing along process as per you blog:

"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/

[NiteWave]

sorry for confusion.

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.

should add lsphp suEXEC daemon mode:

lsphp suEXEC daemon mode + xcache will meet the requirement closely.

however, it's close, not exactly as 2) + 3). since

2) To have a single APC cache per user shared by multiple children.

it's per user; while for lsphp + suEXEC daemon, all users share one lsphp parent process. assume there are 1 thousand users, 2) means need 1000 parent php process; while there is only 1 parent lsphp process in lsphp + suEXEC daemon.

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.

if this is confirmed, then there's really a problem in lsphp + suEXEC daemon mode regarding variable cache(or object cache).

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.

[waski]

Originally Posted by NiteWave

if this is confirmed, then there's really a problem in lsphp + suEXEC daemon mode regarding variable cache(or object cache).

Would you mind to confirm/deny that ? It might be quite an issue in case of security.