4

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 !

Tiffany Walker
  • 6,541
  • 13
  • 53
  • 77

3 Answers3

2

I really don't see a problem with using FastCGI here. I'll explain: APC is needed for sites with high frequency of hits and not needed at all for sites that get hits occasionally.

So, concerning memory efficiency: you have several sites on your server, some of them popular and some of them not. You have pool of FastCGI proccesses for each site and PHP manages its workers (using FastCGI shell wrapper with PHP_FCGI_CHILDREN variable), each FastCGI pool has lifetime, APC cache is shared within all PHP processes of pool.

Popular sites will get hits often and FastCGI pool will not die, APC will remain in memory, one say 50MB cache for all PHP workers.

Not so popular sites will trigger FastCGI kill policy and workers will be shutdown completely with APC cache freeing memory. When this site will get a hit the pool will be restarted and first hit will be slower. This model combines effectively PHP-CGI mode with low memory consumption and high resource usage with PHP-FPM pool of processes with hot and ready cache.

With PHP-FPM model you'll have to keep at least ONE worker for each site resulting in great memory consumption.

ps. there are ondemand patch for php-fpm but haven't tested it in production yet.

Andrei Mikhaltsov
  • 2,987
  • 1
  • 22
  • 31
1

I'll add that your post helped me to find a bug where APC opcode cache was mixing several configuration files between several chrooted instances. So when using chrooted pools having separate php-fpm daemons is still a need, you should never use several pool where the chrooted path may collapse between pools.

regilero
  • 1,470
  • 1
  • 9
  • 14
0

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.

Alessio Periloso
  • 188
  • 1
  • 9