Мы ищем способ заставить 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 для одного сайта?
Если в среднем учетная запись создает кеш 50 МБ и создает 3 кеша для каждой учетной записи, что составляет 150 МБ на учетную запись, что составляет 120 ГБ…
Однако, если каждая учетная запись использует в среднем только 50 МБ, это составит 40 ГБ.
У нас будет как минимум 128 ГБ оперативной памяти на нашем следующем сервере, поэтому 40 ГБ будет приемлемым, если запуск 800 x PHP-FPM не создает накладных расходов более 20 ГБ!
Как вы думаете, PHP-FPM - лучший способ обеспечить безопасный кеш APC на общем хостинге с сервером с приличным объемом памяти?
Или мне стоит поискать другую систему?
Спасибо !
Я действительно не вижу здесь проблемы с использованием FastCGI. Я объясню: APC необходим для сайтов с высокой частотой посещений и совсем не нужен для сайтов, которые время от времени посещаются.
Итак, по поводу эффективности памяти: у вас на сервере несколько сайтов, некоторые из них популярные, а некоторые нет. У вас есть пул процессов FastCGI для каждого сайта, и PHP управляет своими работниками (используя оболочку оболочки FastCGI с переменной PHP_FCGI_CHILDREN), каждый пул FastCGI имеет время жизни, кеш APC используется всеми процессами PHP пула.
Популярные сайты будут часто получать запросы, и пул FastCGI не умрет, APC останется в памяти, например, кеш 50 МБ для всех рабочих PHP.
Не очень популярные сайты будут запускать политику уничтожения FastCGI, и рабочие будут полностью отключены с освобождением памяти кешем APC. Когда этот сайт получит обращение, пул будет перезапущен, и первое обращение будет медленнее. Эта модель эффективно сочетает в себе режим PHP-CGI с низким потреблением памяти и высоким использованием ресурсов с пулом процессов PHP-FPM с горячим и готовым кешем.
С моделью PHP-FPM вам нужно будет держать как минимум ОДНОГО рабочего для каждого сайта, что приведет к большому потреблению памяти.
пс. есть патч ondemand для php-fpm, но он еще не тестировался в производстве.
Я добавлю, что ваш пост помог мне найти ошибку, при которой кеш кода операции APC смешивал несколько файлов конфигурации между несколькими экземплярами chrooted. Поэтому, когда использование chrooted-пулов с отдельными демонами php-fpm по-прежнему необходимо, вам никогда не следует использовать несколько пулов, где chrooted-путь может обрушиться между пулами.
Я знаю, что вы пытаетесь сделать, поскольку это часть проекта, который я возглавляю. Я уже исследовал это, и кажется, что единственный способ решить проблему - использовать модифицированную версию memcached и apc.
Я думал, что в настоящее время APC позволяет сохранять данные в memcached, но я обнаружил, что это не так, поэтому самый простой способ решить проблему - взломать memcached, позволяя ему иметь разные учетные записи с разными кешами и, возможно, с разными размерами кешей, и затем взломайте и APC, чтобы запросить memcached для получения из него кодов операций.
Взлом Memcached также будет полезен, потому что вы можете установить время истечения срока действия кеша и оценить, что следует кэшировать, а что нет: таким образом вы сэкономите больше оперативной памяти и будете использовать ее только по запросу. Чтобы выбрать учетную запись, которую вы хотите использовать, вы должны затем использовать аутентификацию SASL (которая уже была разработана для memcached) против сервера memcached, что повысит безопасность этой конфигурации.
Развертывание Memcached также будет полезно для других вещей, таких как кеширование, поэтому я собираюсь следовать по этому пути.