We are looking into finding a way to get APC to only create one cache per account / site. This can be done with Fastcgi (last update 2006…) but with Fastcgid APC will have to create multiple caches for multiple processes run by the same account.
To get around this problem, we have been looking into PHP-FPM
PHP process manager allows multiple PHP processes to share a single APC cache.
But from what I have read (I hope I'm wrong) , even if you create a pool per process, all sites accross all pools will share the same APC cache. This brings us back to the same problem as with shared Memcached: it's not secure !
On php-fpm's site I read that you can chroot php-fpm pools and define a specific UID and GID per pool… if this is the case then shouldn't APC have to use this user and not have access to other pools cache ?
An article here (in 2011) suggests that you would need to run one process per pool creating multiple launchers on different ports and different config files with one pool per config file :
http://groups.drupal.org/node/198168
Is this still neceessary ?
If so what would be the impact of running say 800 processes of php-fpm ? Would it be mainly memory ? If so how can I work out what the memory impact would be ?
I guess that it would be better to run 800 times php-fpm then to have accounts creating multiple APC caches for a single site ?
If on average an account creates a 50MB cache and creates 3 caches per account that makes 150Mb per account which makes 120GB…
However if each account uses on average only 50Mb that would make 40GB
We will have at least 128GB of ram on our next server so 40GB is acceptable if running 800 x PHP-FPM does not create an overhead of more than 20GB !
What do you think is PHP-FPM the best way to go to provide secure APC cache on shared hosting with a server that has a decent amount of memory ?
Or should I be looking at another system ?
Thanks !
Best Answer
I know what are you are trying to do, since it is part of the project I am leading. I've already investigated about it and it seems the only way to solve the problem is to use a modified version of memcached and apc.
I thought currently APC did allow to save data into memcached, but I've discovered it doesn't, so the easiest way to solve the problem is hacking memcached allowing it to have different accounts with different caches, and maybe different cache sizes, and then hack APC too, allowing to query memcached to fetch opcodes from it.
Memcached hack would also be useful because you could set an expiring time to the cache and evaluate what should be cached and what shouldn't: this way you would save more ram, and use it only on demand. To select the account you want to use, you would then use the SASL authentication (that has already been developed for memcached) against the memcached server, putting more security in this configuration.
Memcached deploy would also be useful for other things like caching, so I am going to follow this path.