我们正在研究让 APC 为每个帐户/站点仅创建一个缓存的方法。这可以通过 Fastcgi（上次更新于 2006 年...）来实现，但使用 Fastcgid APC 必须为同一帐户运行的多个进程创建多个缓存。
为了解决这个问题，我们一直在研究 PHP-FPM
PHP 进程管理器允许多个 PHP 进程共享单个 APC 缓存。
但从我读到的内容来看（我希望我错了），即使你为每个进程创建一个池，所有池中的所有站点都将共享相同的 APC 缓存。这又回到了与共享 Memcached 相同的问题：它不安全！
在 php-fpm 的网站上，我读到您可以 chroot php-fpm 池并为每个池定义特定的 UID 和 GID……如果是这种情况，那么 APC 是否应该使用该用户而不能访问其他池缓存？
此处（2011 年）的一篇文章建议您需要为每个池运行一个进程，在不同的端口和不同的配置文件上创建多个启动器，每个配置文件一个池：
http://groups.drupal.org/node/198168
这还有必要吗？
如果是这样，那么运行 800 个 php-fpm 进程会产生什么影响？主要影响内存吗？如果是这样，我如何才能确定内存影响是什么？
我猜想运行 800 次 php-fpm 会比让账户为单个站点创建多个 APC 缓存更好吗？
如果平均一个帐户创建一个 50MB 的缓存，并且每个帐户创建 3 个缓存，则每个帐户有 150Mb 的缓存，总共有 120GB……
但是如果每个账户平均只使用 50Mb，那么就需要 40GB
我们的下一台服务器上将至少有 128GB 的 RAM，因此如果运行 800 x PHP-FPM 不会产生超过 20GB 的开销，则 40GB 是可以接受的！
您认为 PHP-FPM 是在具有大量内存的服务器上提供安全 APC 缓存的最佳方式吗？
或者我应该考虑另一个系统？
谢谢 ！
答案1
我知道你想做什么，因为这是我领导的项目的一部分。我已经调查过了，似乎解决问题的唯一方法是使用修改版的 memcached 和 apc。
我认为目前 APC 确实允许将数据保存到 memcached 中，但我发现它不行，所以解决这个问题的最简单方法是破解 memcached，让它拥有具有不同缓存的不同账户，也许还有不同的缓存大小，然后破解 APC，允许查询 memcached 以从中获取操作码。
Memcached hack 也很有用，因为您可以为缓存设置到期时间，并评估哪些内容应该缓存，哪些内容不应该缓存：这样您就可以节省更多内存，并且只在需要时使用。要选择要使用的帐户，您需要对 memcached 服务器使用 SASL 身份验证（已为 memcached 开发），从而为该配置增加更多安全性。
Memcached 部署对于缓存等其他方面也很有用，因此我将遵循这条路径。
答案2
我确实不认为在这里使用 FastCGI 有什么问题。我来解释一下：对于点击频率高的网站，需要使用 APC，而对于偶尔被点击的网站，则根本不需要。
因此，关于内存效率：您的服务器上有多个站点，其中一些很受欢迎，而另一些则不受欢迎。您为每个站点设置了 FastCGI 进程池，PHP 管理其工作进程（使用带有 PHP_FCGI_CHILDREN 变量的 FastCGI shell 包装器），每个 FastCGI 池都有生命周期，APC 缓存在池中的所有 PHP 进程中共享。
热门网站会经常获得点击，并且 FastCGI 池不会死机，APC 将保留在内存中，所有 PHP 工作者都会有 50MB 的缓存。
不太受欢迎的网站将触发 FastCGI 终止策略，工作进程将完全关闭，APC 缓存将释放内存。当此网站受到攻击时，池将重新启动，第一次攻击将变慢。此模型有效地结合了低内存消耗和高资源使用率的 PHP-CGI 模式与具有热且就绪缓存的 PHP-FPM 进程池。
使用 PHP-FPM 模型，您必须为每个站点保留至少一个工作器，从而导致大量内存消耗。
附言：php-fpm 有按需补丁，但尚未在生产中测试。
答案3
我要补充的是，您的帖子帮助我发现了一个错误，即 APC 操作码缓存在多个 chrooted 实例之间混合了多个配置文件。因此，当使用 chrooted 池时，仍然需要单独的 php-fpm 守护进程，您永远不应该使用多个池，因为 chrooted 路径可能会在池之间崩溃。