Estudamos muitos fóruns e não sabemos a resposta para o seguinte. Temos os dois APCe Memcacheinstalados em nossos servidores. Não temos certeza de qual é a melhor e correta configuração.
Minha pergunta
Quais são / são as melhores configurações para executar o Magento usando o Memcache + APC ao mesmo tempo? (Ou isso não é nada inteligente)
Pesquisa de base
Aqui, o Memcache e a APC são recomendados como cache rápido e lento (mas sem disco). Parece que isso só funciona quando você tem RAM suficiente (e com certeza)
E este artigo é sobre Memcache ou APC - e temos ambos
E aqui afirma que o Memcache só funciona realmente quando você também possui um back-end lento
E acho que este artigo está dizendo o mesmo
Esta é a solução do meu ISP para 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>Situação
Hospedagem compartilhada Brim FPC instalado: http://ecommerce.brimllc.com/full-page-cache-magento.html (esse FPC também possui um cache de arquivos escalonável para torná-lo mais complexo)
Respostas:
Você precisa entender a distinção clara entre esses dois produtos para entender como usá-los.
Usando APC como um cache OPCode
Basta instalar o módulo no seu servidor
E ative-o no seu
php.iniVocê então habilita e ajusta a configuração do tempo de execução para se adequar, por exemplo.
Em seguida, reinicie o PHP / Apache
Depois disso, não há mais nada a fazer. Confirme se o APC está ativado com uma rápida
phpinfo()- mas, nesse caso, a parte do cache do OPCode do APC está ativa.Nada precisa ser configurado no lado do Magento.
Usando a APC como um back-end rápido
Você precisa adicionar o seguinte ao seu
./app/etc/local.xmlEm seguida, limpe seus caches de loja existentes. Para verificar se está funcionando, carregue uma página no front-end e o
./var/cachediretório deverá permanecer vazio.Usando o Memcache como um back-end rápido
Você precisará instalar o Memcache como uma extensão PHP e instalar o respectivo Memcache Daemon (Memcached) em seu servidor.
E habilite-o no seu php.ini
Em seguida, instale o Memcached no servidor. Para RH / Centos, ajuste a URL para se adequar à sua versão de lançamento e arquitetura da CPU.
Em seguida, modifique o Magento para usar o Memcache como um back-end rápido, altere o caminho do soquete para uma conexão TCP / IP adequada.
As advertências do Memcache e da marcação - o que é armazenar
O Memcache suporta apenas um único nível de relacionamentos de valor-chave, portanto, não pode armazenar as tags de cache do Magento (que são usadas para liberar os dados do cache independentemente). Como resultado, você precisa especificar a
slow_backendpara manter o relacionamento da tag de conteúdo do cache ou não definir um.Se você definir a
slow_backend, corre o risco de as tags de cache aumentarem tanto que o desempenho é negado; também há o problema inerente que você não pode escalar em vários servidores se cada servidor estiver mantendo suas próprias tags de cache.Portanto, ao usar o Memcache, a melhor abordagem (com a ressalva de que você não pode liberar caches de forma independente) é não se incomodar em usar o
slow_backend.Nesse caso, sugerimos removê
<slow_backend>database</slow_backend>-lo e substituí-lo por:Isso interromperá / desabilitará o segundo nível de armazenamento em cache (e impedirá o armazenamento de tags), mas ainda permitirá o desempenho do Memcache.
Qual usar
Se for uma implantação de servidor único - não há mal algum em usar a APC para tudo.
Se for uma configuração distribuída - você precisará usar o Memcache como back-end rápido (para que todas as máquinas possam acessar o armazenamento comum).
Mais preocupante é que, se o seu provedor de hospedagem não puder lhe dizer a configuração correta a ser usada, você certamente estará com o host errado.
Atribuições: sonassi.com , php.net , repoforge.org
fonte
slow_backend must implement the Zend_Cache_Backend_ExtendedInterface interfaceno Mage 1.7.0.2Concordo plenamente com as respostas anteriores, mas aqui está uma pequena precisão para concluí-lo: Sim, o apc pode ser usado como um mecanismo de armazenamento em cache e como um otimizador de código de bytes PHP. Mas dois pontos precisam ser esclarecidos:
Como um back-end rápido, as diretivas de configuração usadas pela APC para entender como os dados devem ser salvos são gerenciadas por meio das diretivas apc.user_%. Os outros dizem respeito apenas ao cache do código de bytes (Ex apc.ttl: a duração da expiração do cache do opcode, apc.user_ttl: a duração da expiração dos dados armazenados em cache pelo seu Magento).
E como um back-end rápido, a APC tem exatamente o mesmo comportamento que o memcached: não gerencia as tags de cache e, para o Magento, requer um back-end lento configurado (ou usa por padrão o arquivo de back-end lento).
Pela minha experiência, em sites com grande tráfego, se você usar o apc apenas como otimizador de código de bytes, precisará entre 96 e 256Mo no valor de configuração apc.shm_size. Aumente também o apc.num_files_hint de 1000 para 15000: por padrão, o código de bytes do cache do apc armazena apenas 1000 arquivos e o Magento contém cerca de ~ 20.000 arquivos PHP e PHTML por padrão (
find . -type f -name "*.php" -o -name "*.phtml" | wc -l). Portanto, personalize esse valor com seu código-fonte.Se você usa o APC ou o memcached como back-end rápido, é difícil fornecer algumas dicas sobre a memória necessária: isso realmente depende da política de cache aplicada à sua instância.
Por enquanto, sua configuração de cache funciona assim:
Por que esses dois níveis de gerenciamento? memcached e outros back-ends rápidos são armazenamentos de memória. Isso significa que os dados podem estar corrompidos ou desaparecerem.
Como você pode aumentar esse desempenho de configuração?
Desabilitar a segunda gravação é provavelmente uma das opções mais eficientes. Isso é explicado no quarto artigo que você mencionou. Mas você não pode usar sem modificações o código-fonte slow_backend_store_data. No seu contexto, não recomendo fazer essa personalização pelos seguintes motivos: seus dados armazenados no cache nunca serão controlados. Você armazenará dados na memória, obterá desempenho, mas talvez envie aos seus visitantes um conteúdo inválido. Portanto, você precisa encontrar uma solução que garanta acesso à memória (para melhor desempenho), controle de gravação e a capacidade de desativar o cache slow_backend_store_data. Você pode alcançar este contexto:
substitua o servidor memcached por um redis (o redis pode controlar a leitura e gravação como é feito por um sistema de arquivos) e continue usando o apc como um otimizador de código de bytes
* assegure-se de poder usar a opção slow_backend_store_data * personalizando seu código-fonte ou alternando para um back-end lento do banco de dados (sim, aumenta a carga do servidor de banco de dados, mas se sua política de cache estiver bem definida, ela não deverá ser um problema)
* desative a opção slow_backend_store_data * : nesta configuração, não é mais necessário, você tem o controle de leitura e gravação feito pelo redis.
fonte
Como observação adicional, descobrimos que, ao usar o APC com Magento (para cache de opcode - usamos Redis para página convencional do Magento e cache de bloco), é importante garantir que a configuração de status seja 0 em produção (mas 1 em desenvolvimento):
A configuração apc.stat é usada para determinar se um script deve ser verificado em cada solicitação para determinar se ele foi modificado ( http://www.php.net/manual/en/apc.configuration.php#ini.apc.stat ) e, portanto, defini-lo como 0 em um ambiente de produção trará o benefício de desempenho da APC que não fará essa verificação a cada solicitação.
Vale ressaltar que, uma vez que o apc.stat esteja definido como 0, você provavelmente terá que reiniciar o processo do servidor da web para detectar alterações de arquivo (por exemplo, pós-implantação), mas isso deve fazer parte da sua estratégia de pós-implantação de qualquer maneira.
fonte
A melhor coisa que fizemos para acelerar significativamente o back-end é instalar o REDIS como um manipulador de cache . Agora também é suportado no núcleo a partir do Magento 1.8 ou superior.
Nada se compara ... agora é click click clickerdy click
http://www.magentocommerce.com/knowledge-base/entry/redis-magento-ce-ee
Além disso, você pode considerar adicionar a extensão Redis Session para também adicionar sessões ao servidor de memória redis ...
Boa sorte!
fonte
Nesse arquivo local.xml, o Magento seleciona a última entrada e usa o Memcache. Eu acho que há uma confusão entre como a APC e o Memcache podem trabalhar com o Magento.
Primeiro, a APC tem 2 usos:
Memcache, por outro lado, é apenas um armazenamento de chave / valor. A grande vantagem do Memcache é que ele pode funcionar no modo cliente-servidor, para que vários servidores front-end possam usar o mesmo cache, o que é obrigatório se você tiver vários servidores que atendem ao mesmo site.
A configuração mais comum é instalar o APC para obter o cache do código de operação (para obter uma execução de script ~ 25% mais rápida) e usar o Memcache como um servidor de cache. Também usei a APC como um sistema de cache e, embora em teoria deva ser um pouco mais rápido que o Memcache, você não pode dizer a diferença.
fonte