Мы изучили много форумов и не знаем ответа на следующие вопросы. Мы оба APC
и Memcache
установили на наших серверах. Мы не уверены, какой правильный и лучший конфиг.
Мой вопрос
Каковы / являются наилучшими настройками для запуска Magento с использованием обоих Memcache + APC одновременно? (Или это вообще не умно)
Фундаментальные исследования
Здесь Memcache и APC рекомендуются как быстрый и медленный кеш (но без диска). Похоже, это работает только тогда, когда у вас достаточно оперативной памяти (и уверены в этом)
И эта статья о Memcache или APC - и у нас есть оба
И здесь говорится, что Memcache действительно работает только тогда, когда у вас также определен медленный бэкэнд
И я думаю, что эта статья говорит то же самое
Это решение моего провайдера для local.xml
<cache>
<backend>apc</backend>
<prefix>sitenamehere__</prefix>
</cache>
<cache>
<backend>memcached</backend>
<memcached>
<servers>
<server>
<host><![CDATA[127.0.0.1]]></host>
<port><![CDATA[11211]]></port>
<persistent><![CDATA[1]]></persistent>
</server>
</servers>
<compression><![CDATA[0]]></compression>
<cache_dir><![CDATA[]]></cache_dir>
<hashed_directory_level><![CDATA[]]></hashed_directory_level>
<hashed_directory_umask><![CDATA[]]></hashed_directory_umask>
<file_name_prefix><![CDATA[]]></file_name_prefix>
</memcached>
</cache>
ситуация
Общий хостинг Brim FPC установлен: http://ecommerce.brimllc.com/full-page-cache-magento.html (этот FPC также имеет масштабируемый файловый кеш, чтобы сделать его более сложным)
Ответы:
Вы должны понимать четкое различие между этими двумя продуктами, чтобы понять, как их использовать.
Использование APC в качестве кеша OPCode
Просто установите модуль на свой сервер
И включите его в своем
php.ini
Затем вы включаете и настраиваете конфигурацию среды выполнения в соответствии, например.
Затем перезапустите PHP / Apache
После этого больше нечего делать. Подтвердите, что APC включен быстро,
phpinfo()
но в противном случае в этот момент часть APC-кэша APC активна.Ничего не нужно настраивать на стороне Magento.
Использование APC в качестве быстрого бэкэнда
Вы должны добавить следующее к вашему
./app/etc/local.xml
Затем очистите существующие кэши магазина. Чтобы убедиться, что он работает, загрузите страницу в интерфейсе, и
./var/cache
каталог должен остаться пустым.Использование Memcache в качестве быстрого бэкэнда
Вам нужно будет установить Memcache как расширение PHP и установить соответствующий демон Memcache (Memcached) на ваш сервер.
И включите его в своем php.ini
Затем установите Memcached на сервер. Для RH / Centos настройте URL-адрес в соответствии с версией выпуска и архитектурой процессора.
Затем измените Magento для использования Memcache в качестве быстрого бэкэнда, измените путь к сокету на соединение TCP / IP, чтобы оно подходило.
Предостережения о Memcache и тегах - что это хранит
Memcache поддерживает только один уровень отношений ключ-значение, поэтому он не может хранить теги кэша Magento (которые используются для независимой очистки данных кэша). В результате вам нужно либо указать a
slow_backend
для поддержания отношения тега содержимого кеша, либо вообще не определять его.Если вы определите a
slow_backend
, то рискуете, что теги кеша станут настолько большими, что производительность будет сведена на нет; Существует также внутренняя проблема, которую нельзя масштабировать на нескольких серверах, если каждый сервер поддерживает свои собственные теги кеша.Таким образом, при использовании Memcache лучший подход (с предупреждением, что вы не можете очищать кэши независимо), состоит в том, чтобы не беспокоиться об использовании
slow_backend
.В этом случае мы предлагаем удалить
<slow_backend>database</slow_backend>
и заменить его на:Это сломает / отключит 2-й уровень кэширования (и предотвратит хранение тегов), но все же позволит повысить производительность Memcache.
Какой использовать
Если это развертывание на одном сервере - нет ничего страшного, если использовать APC для всего.
Если это распределенная установка - тогда вам нужно использовать Memcache в качестве быстрого бэкэнда (чтобы все машины могли получить доступ к общему хранилищу).
Еще одна проблема заключается в том, что если ваш хостинг-провайдер не может сказать вам правильную настройку для использования, вы, безусловно, с неправильным хостом.
Атрибуты: sonassi.com , php.net , repoforge.org
источник
slow_backend must implement the Zend_Cache_Backend_ExtendedInterface interface
в Mage 1.7.0.2Я вполне согласен с предыдущими ответами, но вот небольшая точность, чтобы завершить его: да, apc можно использовать как в качестве механизма хранения кэша, так и в качестве оптимизатора байтового кода PHP. Но необходимо уточнить два момента:
В качестве быстрого бэкэнда директивы конфигурации, используемые APC для понимания того, как он должен сохранять данные, управляются через директивы apc.user_%. Другие касаются только кеша байтового кода (например, apc.ttl: срок действия для кэша кода операции, apc.user_ttl: срок действия для данных, хранящихся в кеше вашего Magento).
И как быстрый бэкэнд, APC ведет себя точно так же, как memcached: он не управляет тегами кеша, а для Magento требуется настроенный медленный бэкэнд (или по умолчанию используется файл медленного бэкэнда).
По моему опыту, на сайтах с большим трафиком, если вы используете apc только в качестве оптимизатора байт-кода, вам нужно от 96 до 256Mo в значении конфигурации apc.shm_size. Также увеличьте значение apc.num_files_hint с 1000 до 15000: по умолчанию кэш-код кэша apc кэширует только 1000 файлов, а Magento по умолчанию содержит около 20 000 файлов PHP и PHTML (
find . -type f -name "*.php" -o -name "*.phtml" | wc -l
). Так что настройте это значение с вашим исходным кодом.Если вы используете APC или memcached в качестве быстрого бэкэнда, трудно дать вам несколько советов о необходимой памяти: это действительно зависит от политики кэширования, применяемой к вашему экземпляру.
На данный момент ваша конфигурация кеша работает так:
Почему эти два уровня управления? memcached и другие быстрые бэкэнды являются хранилищами памяти. Таким образом, это означает, что данные могут быть повреждены или исчезли.
Как вы можете увеличить производительность этой конфигурации?
Отключение второй записи, вероятно, является одним из наиболее эффективных вариантов. Это объясняется в четвертой статье, которую вы упомянули. Но вы не можете без изменений использовать исходный код slow_backend_store_data. В вашем контексте я не рекомендую выполнять эту настройку по следующим причинам: ваши данные, хранящиеся в кэше, никогда не будут контролироваться. Вы будете хранить данные в памяти, заработаете производительность, но, возможно, отправите своим посетителям недопустимый контент. Поэтому вам нужно найти решение, которое обеспечит вам доступ к памяти (для повышения производительности), контроль записи и возможность отключить кеширование slow_backend_store_data. Вы можете достичь этого контекста:
замените сервер memcached сервером redis (redis может управлять чтением и записью так, как это делает файловая система), и продолжать использовать apc в качестве оптимизатора байт-кода
* убедитесь, что вы можете использовать параметр slow_backend_store_data * либо путем настройки исходного кода, либо путем переключения на медленный бэкэнд базы данных (да, это увеличивает нагрузку на сервер базы данных, но если ваша политика кэширования хорошо определена, это не должно быть проблема)
* деактивировать параметр slow_backend_store_data * : в этой конфигурации он больше не требуется, у вас есть контроль чтения и записи, выполняемый redis.
источник
В качестве дополнительного примечания к этому мы обнаружили, что при использовании APC с Magento (для кэширования кода операции - мы используем Redis для обычной страницы Magento и блочного кэширования), важно убедиться, что параметр stat равен 0 при производстве (но 1 в разработка):
Параметр apc.stat используется для определения необходимости проверки сценария для каждого запроса, чтобы определить, был ли он изменен ( http://www.php.net/manual/en/apc.configuration.php#ini.apc.stat. ) и, следовательно, установка этого параметра в 0 в производственной среде принесет пользу производительности APC, не выполняющему эту проверку с каждым запросом.
Стоит отметить, что после установки значения apc.stat в 0 вам, вероятно, придется перезапустить процесс веб-сервера, чтобы получить изменения файла (т. Е. После развертывания), но это все равно должно быть частью вашей стратегии после развертывания.
источник
Лучшее, что мы сделали, чтобы значительно ускорить бэкэнд, - это установить REDIS в качестве обработчика кеша . Это теперь также поддерживается в ядре от Magento 1.8 и выше.
Ничто не сравнится ... теперь это клик клик кликни клик
http://www.magentocommerce.com/knowledge-base/entry/redis-magento-ce-ee
Кроме того, вы можете рассмотреть возможность добавления расширения Redis Session, чтобы также добавить сеансы на сервер памяти Redis ...
Удачи!
источник
Из этого файла local.xml Magento подхватит последнюю запись и использует Memcache. Я думаю, что существует путаница между тем, как APC и Memcache могут работать с Magento.
Во-первых, APC имеет 2 использования:
Memcache, с другой стороны, просто хранилище ключей / значений. Большим преимуществом Memcache является то, что он может работать в режиме клиент-сервер, поэтому несколько внешних серверов могут использовать один и тот же кэш, что необходимо, если у вас есть несколько серверов, обслуживающих один и тот же веб-сайт.
Самая распространенная установка - это установить APC для получения кэширования кода операции (чтобы вы быстрее выполняли скрипт на ~ 25%) и использовать Memcache в качестве сервера кэширования. Я также использовал APC в качестве системы кеширования, и хотя теоретически он должен быть немного быстрее, чем Memcache, вы не можете заметить разницу.
источник