Pré-aquecendo o cache de página inteira do Magento Enterprise

19

Os benefícios de desempenho do cache de página inteira no Magento Enterprise são bastante conhecidos. O que pode não ser tão conhecido é que, para que todos os benefícios sejam alcançados, ele deve ser totalmente preenchido e quente, principalmente em conjuntos de produtos grandes, nos quais você não tem apenas algumas páginas, fazendo uso de tráfego orgânico para prepará-lo rápido o suficiente.

O Magento inclui um cronograma interno para rastrear o site e aquecer o FPC de manhã cedo.

Eu já vi e ouvi falar de problemas causados ​​por tarefas matinais demorando muito para serem executadas, impedindo a execução de outras tarefas e gostaria de saber o que os outros usam ou sugerem que sejam usados ​​para fazer isso. Algumas idéias que tenho são:

  • Crie um script de shell para rastrear todas as páginas no arquivo de mapa do site gerado.
  • Use uma entrada separada do crontab e um script PHP curto para inicializar o Magento e executar o processo do rastreador diretamente.

Quaisquer pensamentos e / ou experiências sobre isso são bem-vindos!

performance cache magento-enterprise full-page-cache cron davidalger
fonte
1
Na verdade, você pode chamar o rastreador Enterprise de um arquivo separado e usar o crontab dos servidores para acioná-lo, para que não atrapalhe.
Toon Van Dooren

Respostas:

16

Você pode usar o cerco em combinação com o sitemap.xmlarquivo, como o MageSpeedTest .

#categories
curl http://yourmagentostore.com/sitemap.xml | sed 's/\<url\>/\<url\>\n/g' | grep 0.5 | sed 's/.*loc>\(.*\)<\/loc.*/\1/g' > urls.txt
#products
curl http://yourmagentostore.com/sitemap.xml | sed 's/\<url\>/\<url\>\n/g' | grep 1.0 | sed 's/.*loc>\(.*\)<\/loc.*/\1/g' >> urls.txt

Então corra

siege -i -c 1 -t 7200s -f urls.txt

Conteúdo proveniente daqui .

Ashley Schroder
fonte
Você também pode adicionar um atraso entre solicitações usando–delay
Ben Lessani - Sonassi
Nota: Esses comandos sed não funcionam no Darwin, mas no CentOS.
Davidalger 18/05
1
Isso não garante que todos os URLs sejam "aquecidos". o cerco selecionará aleatoriamente os URLs a serem atingidos no arquivo, mas não visitará necessariamente todos os URLs.
913 Joe Constant
22

Nós simplesmente não o fazemos. Sempre. Vamos dizer isso repetidamente, mas

Armazenamento em cache! = Desempenho

Seu site precisa ser rápido sem a adição de FPC (ou verniz, por isso). Sempre haverá um momento em que o conteúdo não é preparado (seu cenário acima).

Em uma loja descarregada, o tempo de carregamento da página com o FPC não deve ser muito mais impressionante do que o não-FPC; O Magento é bastante capaz de < 400mscarregar as páginas em caches padrão (em categorias / produtos / páginas de pesquisa). O FPC reduzirá isso para < 80ms- mas vem com advertências.

  1. As informações de estoque / preço estão desatualizadas até a invalidação ou a expiração do TTL

  2. Novos itens / pesquisa mais relevante ficam desatualizados até a expiração da invalidação ou do TTL

    etc.

Por que confiar no FPC (ou verniz) é uma má idéia

Se você deseja garantir continuamente que os caches sejam preparados manualmente, provavelmente há alguns motivos

  1. Você não tem espaço suficiente para manter os caches preparados (consulte 'Onde o FPC é útil')
  2. Seu site é muito lento sem eles

Você não pode armazenar tudo em cache

Se você compra uma loja com apenas 5 categorias, aninhado em 2 níveis, 5 atributos filtráveis, 5 opções de atributos cada e 1000 produtos; isso é muitas combinações possíveis.

25 opções para escolher, escolhendo uma até 5 vezes seguidas - não sou estatístico , mas sei que é ... (supondo que o número de opções de atributos não diminua completamente)

25 possible URLs on the first selection
20 possible URLs on the second selection
15 possible URLs on the third selection
10 possible URLs on the fourth selection
5  possible URLs on the fifth selection

5^5 = 3,125 possible combinations (for top level categories)
5^4 = 625 possible combinations (for 2nd level categories)

Ok, o exposto acima não é um cenário provável, como eu imaginaria, em três cliques - o número de produtos disponíveis teria diminuído o suficiente para que o cliente encontrasse seu produto. Então, mesmo que fosse ...

25 possible URLs on the first selection
10 possible URLs on the second selection
3 possible URLs on the third selection

5^3 = 125 possible URL combinations

Depois, multiplicado por 5 categorias, ou seja, 625 URLs. Nesse estágio, estamos falando de um pequeno catálogo e ignorando completamente todos os URLs do produto.

Também não consideramos que, se você aninhar categorias com is_anchoron, isso aumentará exponencialmente.

Portanto, para rastrear esse volume de páginas - você espera que os tempos de carregamento da página sejam agradáveis ​​e baixos, para que seja um processo rápido e leve (derrotando assim o objetivo do rastreamento) - ou que você tenha tempo suficiente para concluir antes que o TTL expire.

Se suas páginas tiveram um tempo de carregamento de 0,4s e você tinha uma CPU de 8 núcleos - então ...

625 * 0.4 = 250 / 8 = 31 seconds

0,5 minutos, nada mal - mas vamos imaginar que você teve tempos de carregamento de página 2s

625 * 2 = 1250 / 8 = 156 seconds

Mas se você adotou o cenário máximo possível

3,750 * 2 = 7,500 / 8 = 937 seconds ~ 15 minutes

Portanto, esse é o seu servidor de produção, com carga de 100% da CPU por 15 minutos. Você reduziria a velocidade de rastreamento proporcionalmente ao TTL desejado.

Portanto, se você deseja que o conteúdo tenha um TTL de 3600s, o rastreamento pode ser 4 vezes mais lento - ou seja. apenas 25% da CPU dedicada ao rastreamento. São muitos recursos apenas para manter o conteúdo da categoria preparado - nem sequer consideramos produtos, termos de pesquisa ou visualizações adicionais da loja neste estágio

De fato, apenas observar o tamanho completo das combinações na catalog_url_rewritestabela (que nem sequer leva em consideração os parâmetros da navegação em camadas) dará uma idéia de quantos URLs você pode acabar precisando rastrear.

Cada loja certamente será diferente, mas o que estou tentando chegar em casa é que rastrear o site para obter o FPC principal não é prático. Apenas garanta que sua loja seja rápida para começar .

Onde o FPC é útil

Onde os benefícios do FPC entram em jogo é em uma loja muito carregada - onde você tem níveis genuinamente altos de tráfego e os caches são naturais e continuamente preparados apenas pela queda de seus pés.

O FPC entra em ação reduzindo as despesas gerais de infraestrutura no conteúdo geralmente solicitado - reduzindo as chamadas repetidas para o back-end do Magento.

Portanto, descobrimos que o FPC é ótimo para implantar quando você tem níveis muito altos de tráfego - não para reduzir o tempo de carregamento da página - mas para reduzir o uso de recursos.

Quem se importa, eu ainda quero rastejar

Bem, então você tem duas opções

  1. Rastrear a partir de um modelo (por exemplo, sitemap)
  2. Extraia links página por página e rastreie cada

E há muitos utilitários para fazer os dois, esses são alguns dos quais eu conheço

  1. mage-perftest
  2. HTTrack
  3. Nutch
  4. Sphider
  5. Crawler4j

Usando Mage-Perftest

Você pode rastrear sua loja com o Mage-Perftest facilmente, primeiro faça o download

wget http://sys.sonassi.com/mage-perftest          (64bit) OR
wget http://sys.sonassi.com/mage-perftest-i386     (32bit)
chmod +x http://sys.sonassi.com/mage-perftest*

Em seguida, defina o processo de rastreamento usando o mapa do site Magento (você pode personalizá-lo criando um mapa do site com qualquer URL, desde que os URLs sejam agrupados em <loc></loc>tags). O comando a seguir lerá todos os URLs do arquivo do mapa do site e rastreará (somente PHP) os URLs ao longo de 1440 minutos (1 dia). Se o servidor exceder 20% da CPU ou uma carga média de 2 - o rastreamento será interrompido temporariamente.

./mage-perftest -u www.example.com -s www.example.com/sitemap.xml -r auto -b -d 1440 -z -a 20 -l 2

Se você tiver 1000 URLs, rastreados por um dia, isso será de aprox. 1 solicitação a cada 86 segundo (s) ~ meta de 0,011 RPS

Ben Lessani - Sonassi
fonte
Sua linha de abertura é muito verdadeira… o cache da página não é o caminho para obter desempenho. Eu sei isso. Você não sabe quantas vezes eu disse aos clientes a mesma coisa. Serei sincero, nunca configurei um site em que tenhamos um rastreador que preparava o FPC antes e só o vi usado uma vez em que um cliente o habilitou no administrador ... diminuindo a velocidade desde que eles usem tags de cache baseadas em arquivo. A principal razão pela qual estou perguntando é porque estou explorando idéias relacionadas a isso com base em algumas pesquisas no white paper da Nexcess. Para sites insanamente alto tráfego, priming o cache após rubor-lo no início da manhã pode ser crítico
davidalger
1
Eu respeito o Nexcess - mas seu white paper se concentra muito no armazenamento em cache para obter desempenho - em vez de garantir que o ambiente já tenha desempenho e que o código seja limpo, rápido e eficiente. Fornecemos verniz para nossos clientes - mas não recomendamos seu uso até que seja necessário. Somente então como um meio de reduzir custos de infraestrutura - ie. quando ~ 94% do tráfego de não conversão / checkout consome ciclos de CPU. O armazenamento em cache cria boas estatísticas de referência artificial - mas não significa nada na realidade se os TTLs forem muito longos (conteúdo obsoleto) - ou se não houver tráfego suficiente para mantê-lo preparado.
Ben Lessani - Sonassi
1
Para sites de tráfego insanamente alto - temos alguns, e tentar manter um cache quente por meio de rastreamento artificial é inútil - o tráfego natural faz isso muito bem. O rastreamento apenas remove os recursos que, de outra forma, seriam usados ​​pelos clientes.
Ben Lessani - Sonassi
Eu imploro para diferir em seu white paper com foco no uso de cache para desempenho. Eles estavam mostrando quanto rendimento um cluster 2 + 1 poderia alcançar. Eles nem sequer tocaram nos tempos de carregamento da página, apenas no rendimento da transação. O hardware que eles têm é o mais otimizado possível ... e sim, percebo os efeitos dos TTLs no conteúdo em cache. Só para reiterar, não pretendo obter desempenho aqui, já o temos. O que isso estaria explorando são maneiras de ignorar atrasos / quedas na taxa de transferência devido à descarga do cache pela manhã, ou seja, antes que o tráfego normal melhore.
Davidalger 17/05
1
Estou confuso então. Se sua loja já é rápida - mas cai quando você limpa o cache. A) Não limpe o cache de manhã, faça-o na noite anterior e deixe a pesquisa rastrear bots (google / bing etc.) faça a preparação para você ou b) obtenha a infraestrutura correta . Se sua loja dobradiças FPC / Varnish para evitar lag / desaceleração -, então parece que você está correndo em uma faca de ponta ...
Ben Lessani - Sonassi
0

Hoje, vou guardar todo o meu discurso para uma postagem de blog, mas, enquanto isso, tenho um pico no meu pequeno aquecedor de cache wfpc.

Teste de desempenho

Você pode testar o desempenho do seu site Magento

./wfpc -t http://mymagentosite.com/sitemap.xml

Finished testing your Magento site performance
Total download time (in seconds)   : 5.0269110202789
Total download time (formatted)    : 0:0:5.026
Average page time (in milliseconds): 502.69110202789

Aquecimento FPC

E você pode aquecer o FPC, que acessará todos os URLs em sitemap.xml.

./wfpc -w http://mymagentosite.com/sitemap.xml

Você também pode colocar um atraso entre as solicitações, se quiser. Aqui está um atraso de 1 segundo entre as solicitações.

./wfpc -w -d=1 http://mymagentosite.com/sitemap.xml

O modo de teste atinge apenas 10 URLs aleatoriamente; portanto, depois de aquecer seu FPC, você pode executar o modo de teste para descobrir quanta diferença o FPC faz!

Pensamentos

Pessoalmente, acho que um mais quente faz sentido ... Em um site pequeno, com cerca de 40 páginas, o tempo de download é reduzido pela metade pelo FPC. Em um site grande com quase 40.000 produtos usando Lesti_FPC com APCu como back-end, estou usando pouco mais de 200 MB para o cache, o que francamente não é nada no servidor de produção de 8 GB.

troca rápida
fonte