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.
- As informações de estoque / preço estão desatualizadas até a invalidação ou a expiração do TTL
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
- Você não tem espaço suficiente para manter os caches preparados (consulte 'Onde o FPC é útil')
- 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
- Rastrear a partir de um modelo (por exemplo, sitemap)
- 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
- mage-perftest
- HTTrack
- Nutch
- Sphider
- 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