Taxa de acertos do cache de objetos do WordPress: significado e valores-alvo relevantes

O que o Cache de Objetos do WordPress armazena

O Cache de Objetos do WordPress armazena dados associados a uma chave e dentro de um grupo. Se o WordPress voltar a solicitar o mesmo valor, pode obtê-lo a partir da cache, em vez de voltar a executar o processo subjacente. Isto inclui, por exemplo, dados que, de outra forma, teriam de ser lidos da base de dados ou recalculados.

A implementação do Core integrada é, por predefinição, ligado à solicitação: Mantém os seus registos durante uma única solicitação. Assim, uma consulta posterior à página não obtém automaticamente acesso aos valores previamente guardados. No entanto, o cache consegue evitar acessos repetidos ainda no âmbito de uma mesma solicitação.

Um «drop-in» pode substituir a implementação principal por um Cache de objetos persistente substituir. Desta forma, as entradas adequadas podem ser mantidas para além das solicitações individuais. O Redis é uma opção possível para o backend, mas não é um requisito para o WordPress; também são possíveis outras abordagens de backend. Mesmo com uma solução de integração persistente, determinados grupos podem continuar a aplicar-se apenas à solicitação atual.

Os transientes são outra forma de armazenar dados necessários por um período limitado. Com um cache de objetos persistente, podem ser guardados nesse local, em vez de, normalmente, na base de dados. O seu tempo de validade não indica uma disponibilidade mínima garantida: um valor pode desaparecer mais cedo. Por isso, o código da aplicação deve estar preparado para a eventualidade de um transiente estar ausente e ser capaz de regenerar o valor, se necessário.

Esta distinção é fundamental para a avaliação posterior da taxa de acertos: o acesso à cache local durante um pedido e o acesso a um backend externo não são, necessariamente, o mesmo indicador. Por isso, verifica primeiro qual a implementação que está efetivamente a ser utilizada e quais os dados que esta trata de forma persistente.

Distinguir entre a cache de objetos e a cache de páginas

Quando uma página é carregada, pode ocorrer um Cache de página entregar uma resposta de página já gerada. Se a solicitação for respondida nessa instância, não precisa percorrer o mesmo caminho da aplicação WordPress que uma solicitação não armazenada em cache. O Object Cache, por outro lado, funciona dentro da aplicação com dados individuais armazenados em cache, e não com a resposta completa da página.

Imagina uma página de artigo acessível ao público: se a resposta estiver no cache da página, pode ser apresentada diretamente. Se, pelo contrário, o WordPress tiver de gerar a página, o cache de objetos pode ajudar em acessos repetidos aos dados. O trabalho que isso realmente poupa depende do pedido, das entradas armazenadas e da implementação em questão.

Isto tem consequências para a interpretação: uma boa taxa de cache de objetos descreve apenas os acessos ao cache registados. Não indica diretamente quantos visitantes já receberam uma resposta pronta do cache de páginas nem a rapidez com que todo o site responde. Quando o cache de páginas é intenso, os benefícios do cache de objetos podem tornar-se visíveis sobretudo nas restantes solicitações do WordPress.

O cache do navegador e o cache de opcode também desempenham outras funções. O cache do navegador mantém os recursos disponíveis para o visitante; um cache de opcode do PHP armazena código PHP compilado. Nenhum deles substitui o armazenamento de dados específicos da aplicação no cache de objetos, nem o fornecimento de uma resposta completa a partir de um cache de páginas.

A constante WP_CACHE Por si só, isto não ativa o Redis Object Cache. Para um Object Cache persistente, é necessária uma implementação adequada e a respetiva configuração suportada. Pode encontrar um exemplo complementar da interação entre vários níveis no artigo sobre o Motor de cache do AccelerateWP.

O que revelam os sucessos e os fracassos

A Acertar ocorre quando uma entrada procurada é encontrada no nível de cache em questão. Um Menina significa que não é encontrado nesse local. A taxa de acertos calcula a relação entre os acertos e o total de acertos e falhas registados: Acertos / (Acertos + Falhas) × 100. Se não houver nem acertos nem falhas, a taxa para esse período não está definida.

Um erro não é, automaticamente, uma falha técnica. Na primeira tentativa de acesso, uma entrada pode ainda estar em falta; mesmo após o seu prazo de validade, poderá ser necessário obtê-la novamente ou criá-la. O que é decisivo é quais as consequências que essas tentativas falhadas têm no processo concreto e se faz sentido, de todo, repetir os acessos.

O método Core do WordPress conta, na sua própria implementação, os acertos e as falhas na cache. No entanto, um plugin «drop-in» pode substituir essa implementação. Por isso, não é possível deduzir com certeza, a partir da contagem do núcleo, o que uma visualização de plugin regista: verifica, para a versão utilizada, quais as visitas e qual o período de tempo abrangidos pelo seu indicador.

O Redis apresenta a mensagem keyspace_hits e keyspace_misses pesquisas de chaves bem-sucedidas ou mal-sucedidas no espaço de chaves do Redis. Também uma pesquisa que falhou EXISTS-A falta pode ser considerada uma falta. Esta Taxa de acertos do Redis não é, portanto, automaticamente equiparável a uma quota do WordPress ou de um plugin.

Se uma instância do Redis for utilizada por vários sites ou aplicações, os seus contadores podem refletir, em conjunto, o tráfego desses sites ou aplicações. Nesse caso, sem telemetria separada adequada, não é possível atribuir de forma fiável uma quota global a um único site WordPress. Por isso, em qualquer comparação, deves indicar claramente a que nível e a que instância se referem os números.

Verificar cuidadosamente a área de medição e o acesso

Antes de efetuar a medição, verifica qual é a implementação do Object Cache que o WordPress utiliza. Se o WP-CLI estiver disponível e tiveres acesso ao diretório do WordPress, podes iniciar um inventário de leitura nesse diretório com o seguinte comando:

wp cache type

O resultado ajuda a classificar a implementação, mas não prova que todos os acessos relevantes sejam armazenados de forma persistente. O WordPress permite que um plug-in substitua a cache do núcleo; ao mesmo tempo, alguns grupos podem não ser persistentes. Por isso, registe também o plug-in utilizado e a sua versão.

Verifique na documentação da versão específica quais os acessos que compõem os «hits» e «misses» apresentados e durante que período são contabilizados. Só é possível comparar de forma significativa a taxa de um plugin com outro indicador se o âmbito de medição e o método de contagem forem conhecidos. É particularmente importante saber se a exibição se refere apenas a um pedido ou a um período mais alargado.

No caso do Redis, desde que haja ligação e autorizações, podes consultar as estatísticas e as informações de memória numa sessão da CLI do Redis, apenas em modo de leitura. Os comandos seguintes não incluem, deliberadamente, quaisquer dados de acesso:

INFO stats
INFO memory

Documenta o Gama de medição: Que instâncias ou nós foram consultados e que outros sites ou aplicações os utilizam? Os contadores globais do Redis, quando partilhados, não podem ser facilmente atribuídos a um único site. Verifica se as saídas contêm informações operacionais sensíveis antes de as partilhar; não é necessário realizar um flush nem um teste de carga para este inventário.

Se não tiveres acesso à CLI do Redis, pergunta ao teu fornecedor de alojamento quais são as métricas disponíveis e o seu âmbito de aplicação. Além disso, um painel de controlo só constitui uma base útil se ficar claro se mostra a mesma instância, nós individuais ou valores já agregados.

Calcular a taxa de acertos do Redis num intervalo

As estatísticas do Redis são valores de contagem, não uma conclusão definitiva sobre um determinado período de medição. Para uma análise por intervalos, consulta os valores relativos a keyspace_hits e keyspace_misses no início e no final do mesmo intervalo de tempo definido pela mesma instância. Anota ambos os momentos e a instância correspondente, para que as leituras coincidam.

Em seguida, subtrai o valor inicial do valor final para cada contador. O Taxa de acertos por intervalo é: ΔHits / (ΔHits + ΔMisses) × 100. O símbolo Δ representa a respetiva diferença. Se ambas as diferenças forem nulas, não houve consultas contabilizadas nesta janela; nesse caso, a taxa não está definida, em vez de ser igual a zero por cento.

Um exemplo ilustrativo de cálculo, não uma medição: se os acertos aumentarem em 900 e os erros em 100, obtém-se 90 por cento num total de 1 000 consultas contabilizadas. Isto não significa que as páginas sejam 90 por cento mais rápidas, nem que tenham sido poupadas exatamente 900 consultas à base de dados. O Redis conta as consultas de chave; a sua importância para a aplicação depende do acesso em questão.

Se algum dos contadores regredir entre as leituras, a diferença simples calculada através desta fração não é válida. Um reinício ou a reinicialização das estatísticas podem causar isso. Recomece a janela de medição ou divida-a com base em dados operacionais fiáveis no ponto de ruptura, em vez de introduzir um valor negativo na fórmula.

No caso de vários nós, calcula-se primeiro, para cada nó em questão, as diferenças ao longo do mesmo período. Em seguida, soma-se separadamente os acertos e os erros e calcula-se a taxa global a partir desses valores. Uma média não ponderada dos valores percentuais individuais trata um nó com poucas consultas da mesma forma que um com muitas; isso pode distorcer consideravelmente o panorama geral.

Regista quais os nós que estão efetivamente incluídos e qual o papel que desempenham no ambiente. Uma taxa global calculada desta forma descreve apenas os contadores selecionados e os seus utilizadores; não resulta apenas da agregação para uma cota específica da cache de objetos do WordPress.

Relatório de medição e indicadores do Redis

Para além dos acertos e erros, outros indicadores do Redis ajudam a contextualizar os resultados. Também neste caso, as diferenças no período selecionado são mais reveladoras do que os valores totais isolados. A tabela seguinte distingue o significado dos valores das conclusões que estes, por si só, não sustentam.

Um aumento de expired_keys pode ser motivo para analisar mais detalhadamente os períodos de validade e os padrões de acesso. No entanto, não indica se um registo voltou a ser necessário pouco tempo após o seu termo. Da mesma forma, evicted_keys deve ser considerado no contexto do limite de memória configurado e da estratégia de substituição, em vez de se concluir imediatamente que é necessário aumentar a memória.

Um útil Relatório de medição Indique o início e o fim do intervalo de tempo, a instância ou o nó, as duas diferenças entre os contadores, a sua soma e a quota calculada. Especifique se a instância é partilhada e se se sabe de alguma reinicialização ou reinicialização durante o intervalo. Desta forma, as medições permanecerão rastreáveis posteriormente.

Registe, em paralelo, o tipo de pedido em análise e um indicador de latência adequado, bem como a carga da base de dados e a taxa de erros. Separe, por exemplo, as visualizações de páginas públicas das solicitações de utilizadores com sessão iniciada, caso existam dados adequados para o efeito. A quota do Redis, por si só, não revela qual destes tipos de pedidos beneficiou de um resultado positivo.

Para uma comparação posterior, o período, os nós e a composição das solicitações devem ser, na medida do possível, semelhantes. Anote também as alterações relevantes e as fases de aquecimento identificáveis. Nos casos em que faltem dados ou em que uma instância partilhada não permita uma atribuição, essa limitação deve constar no relatório, em vez de ser incluída numa conclusão aparentemente precisa.

Arranque a frio, loja e site estático

Após um reinício ou uma implementação, as entradas necessárias podem, inicialmente, não estar presentes. É normal que ocorram estas falhas durante o preenchimento da cache; com acessos repetidos, a taxa de acertos poderá aumentar posteriormente. Os valores da Fase fria e fase quente deves analisar separadamente, para que uma média a longo prazo não oculte nem os custos iniciais nem o comportamento posterior.

No caso de uma loja online ou de uma área reservada a utilizadores registados, as solicitações dinâmicas são particularmente interessantes: um cache de página não responde necessariamente a todas as chamadas relacionadas com o carrinho de compras ou a conta. Por isso, compare tipos de pedidos o mais semelhantes possível e preste atenção, além da taxa de acertos, aos seus tempos de resposta e à carga da base de dados. Uma elevada taxa de acertos no Redis, por si só, não indica se o cesto de compras é apresentado rapidamente e com o conteúdo correto.

Por outro lado, num site predominantemente estático, grande parte das visualizações de páginas já pode provir da cache de páginas. Nesse caso, uma cache de objetos persistente atua sobretudo nas solicitações que o WordPress efetivamente processa. Por isso, avalia separadamente se essas solicitações restantes beneficiam do sistema e se o efeito se reflete em todo o site.

Se utilizares o Redis em conjunto com outros sites ou aplicações, os contadores de instâncias também incluem os acessos desses sites ou aplicações. Sem telemetria separada adequada, não é possível atribuir de forma fiável a quota global a um único site. Documenta também quais os nós que estão a ser monitorizados: caso contrário, uma alteração na quota pode dever-se igualmente a outra utilização ou a uma alteração no âmbito de medição.

Analisar valores anormais e erros

Uma taxa baixa é, em primeiro lugar, uma observação, não um diagnóstico. Um elevado número de acessos iniciais, tempos de vida curtos ou uma distribuição de acessos com chaves raramente reutilizadas podem ser possíveis explicações. Verifica se a composição das solicitações ou o intervalo de medição se alteraram antes de ajustares as configurações de memória ou de cache.

Os contadores expired_keys e evicted_keys fornecem mais informações: o primeiro conta as chaves expiradas, o segundo as chaves que foram substituídas devido ao limite de memória. As suas diferenças dependem da instância do Redis e têm de estar de acordo com a configuração e a utilização. A existência de muitas chaves expiradas não prova que o TTL tenha sido mal escolhido, nem que um período de validade mais longo seja adequado; tal pode prejudicar a atualidade dos dados armazenados.

Para as suas próprias extensões, em wp_cache_get o parâmetro $found Importante: distingue entre um valor encontrado e um valor guardado false de uma entrada não encontrada. Antes de realizar ações relacionadas com grupos, deves utilizar wp_cache_supports verificar se o backend específico suporta a função pretendida. Uma solução alternativa pode diferir da implementação do núcleo.

Aviso: Uma limpeza imprudente da cache pode afetar mais entradas ou aplicações do que o pretendido e distorcer a próxima medição devido a um arranque a frio. Verifica o âmbito de aplicação e obtém autorização antes de executares ações de eliminação. Pontos de partida adicionais para a Resolução de problemas num cache de objetos do WordPress lento ajudar a incluir também uma eventual sobrecarga da cache na análise.

Definir por si próprio valores-alvo adequados

Uma quota mínima universal de 90 por cento não constitui um requisito técnico viável. Faz mais sentido um intervalo-alvo específico para cada local, que se coadune com a distribuição de acessos esperada e com a utilidade da aplicação. O Redis recomenda que a quota observada seja avaliada no contexto do respetivo padrão de acessos; um valor percentual, por si só, não explica o desempenho do WordPress.

Começa por registar uma medição inicial representativa, indicando o período, o intervalo de medição, o número de acessos e a taxa. Para tal, registe os tempos de resposta dos tipos de pedidos mais importantes, a carga da base de dados e a taxa de erros. Identifique separadamente os arranques a frio e tenha em conta as diferenças típicas entre períodos de baixo e alto tráfego, em vez de considerar uma janela aleatoriamente favorável como o estado normal.

Em seguida, planeie uma alteração concreta e, após a aprovação, teste-a, se possível, primeiro num ambiente de teste adequado. Em seguida, compare períodos e combinações de pedidos semelhantes: a quota e o número de consultas alteram-se, mas também a latência ou a carga da base de dados? Desta forma, é possível distinguir melhor o efeito de uma mera deslocação dos acessos.

Mesmo uma taxa elevada pode esconder alguns erros, especialmente os mais dispendiosos. Por outro lado, uma taxa moderada não tem de ser um problema, desde que as consultas relevantes sejam respondidas de forma rápida e correta. Os custos operacionais adicionais associados ao Redis ou a outro backend persistente não se justificam automaticamente apenas por uma melhor taxa; tem em conta o suporte de alojamento, os custos e os possíveis cenários de falha.