O get_option () é mais rápido que o acesso ao get_transient ()?

8

Hoje, eu executo um teste no meu banco de dados para explorar a diferença de velocidade entre acessar uma chave a partir de opções, tabela personalizada e transitórios. Eu executei o teste por 1000 vezes e a seguir é o tempo necessário para executar 1000 operações de obtenção:

  1. get_transient() 0,0245 segundos
  2. get_option() 0,0068 segundos
  3. operação de seleção simples da tabela personalizada 0,65 segundos

Também verifiquei que o transitório não expirou durante este teste. Portanto, a pergunta é: é get_option()mais rápido do que get_transient()ou eu estraguei algo no meu teste? O atraso da tabela personalizada é devido às opções serem armazenadas em cache padrão pelo WordPress? Além disso, as opções também são armazenadas em cache por diferentes plugins de armazenamento em cache, como os transitórios?

learning_13
fonte
A resposta para isso é variável, tendo em mente que, com um cache de objeto, os transientes não usarão as opções. De qualquer forma, é uma micro-otimização e uma perda de tempo. Carregar automaticamente como uma opção simplesmente muda o custo em outro lugar
Tom J Nowell

Respostas:

15

Hoje, eu executo um teste no meu banco de dados para explorar a diferença de velocidade entre acessar uma chave a partir de opções, tabela personalizada e transitórios. Eu executei o teste por 1000 vezes e a seguir é o tempo necessário para executar 1000 operações de obtenção:

Lembre-se de que a tabela de opções é usada para opções e transitórios na maioria dos sistemas e que a tabela foi otimizada, com índices adicionados. Portanto, não é uma comparação justa

get_transient () 0.0245 segundos get_option () 0.0068 segundos operação de seleção simples da Tabela Personalizada 0.65 segundos

Essa também é uma comparação injusta, as opções com o autoloadconjunto de opções serão carregadas antecipadamente em uma única consulta. Então get_optionestá saindo WP_Cache, a opção já foi recuperada.

TLDR: Na verdade, não está buscando a opção, ela já foi buscada, está apenas retirando-a da memória devido à autoloadopção

Também verifiquei que o transitório não expirou durante este teste.

Isso não deve ter impacto em um sistema normal na recuperação transitória, afinal ele não sabe se expirou até que seja recuperado.

Portanto, a pergunta é: get_option () é mais rápido que get_transient () ou eu estraguei algo no meu teste?

Depende:

  • Na maioria dos sistemas, os transitórios são armazenados usando opções, ambos envolvem uma get_optionchamada
  • As opções autoloaddefinidas como true são todas carregadas em uma única chamada no início, para que sejam mantidas na memória, nenhuma consulta acontece depois disso.
  • O cache de objetos armazena em cache as opções carregadas automaticamente e os transientes

O atraso da tabela personalizada é devido ao padrão de opções em cache do WordPress?

Muito possível, mas a rapidez com que essa seleção leva depende muito do design da consulta e da tabela

Além disso, as opções também são armazenadas em cache por diferentes plugins de armazenamento em cache, como os transitórios?

Sim, WP_Cacheé usado, o que o armazenará na memória pelo restante da solicitação. Os plug-ins de cache podem persistir nesses valores por razões de desempenho.

Repetibilidade

Tudo isso é armazenado em cache, WP_Cacheportanto, na segunda vez que você o solicita, nenhum banco de dados está envolvido.

Variabilidade e Depende

Tudo isso assume uma base comum, mas e os caches de objetos?

Vamos introduzir uma instância do MemcacheD ou uma instância do Redis (eu recomendo que você faça isso se tiver a opção, ENORME benefícios de desempenho para sites bem construídos, especialmente se você os usar para cache de página, a menos que você tenha algo como a configuração do Varnish)

Agora temos uma nova situação:

  • Agora, os dados são armazenados na RAM e, uma vez buscados no banco de dados, são preparados, e os tempos de acesso são reduzidos drasticamente. Ainda mais lento que uma variável, mas significativamente mais rápido que uma consulta ao banco de dados
  • Muitos dados novos são armazenados e WP_Cachenormalmente não são. Por exemplo WP_Post, objetos, pós meta, etc
  • WP_Cache agora persiste nos pedidos
  • MemcacheD etc pode eliminar transientes expirados etc

Portanto, agora os transitórios e as opções têm o mesmo custo de acesso. Eles já estavam próximos, mas agora são insignificantes e têm mais a ver com a carga da CPU no momento em que a solicitação foi feita.

Portanto, para desempenho, devo usar transitórios ou opções?

Embora seja uma pergunta digna de reflexão, a resposta é que a diferença é insignificante e está dentro das margens de erro

Não é tão simples assim

Portanto, pare de otimizar, eles são o mesmo meio de armazenamento e isso não vale o seu tempo

  • Use as opções se precisar armazenar algo em todo o site
  • Use transientes para armazenar temporariamente itens caros de calcular, para que você não precise da próxima vez

Não vale a pena escolher um com base no desempenho; não há diferença significativa.

Há coisas muito melhores a serem feitas para otimizar que proporcionam economias significativamente maiores, por exemplo, usando taxonomias em vez de meta em consultas de postagem, não usando __notparâmetros de estilo, fazendo menos coisas na página, instalando um cache de objeto, diminuindo postagens por página, evitando solicitações remotas etc

Que tal uma tabela personalizada que irá ...

Não, a tabela de opções já está bem otimizada, o uso de uma tabela personalizada simplesmente moverá as operações para fora do sistema WP Caching, forçando você a escrever sua própria

Tom J Nowell
fonte
Em relação, a opção é carregada automaticamente no meu caso. A tabela personalizada contém apenas duas linhas e uma consulta de seleção para buscar dados.
learning_13
Estou fazendo isso no meu plug-in e tenho que escolher entre qualquer um deles. A tabela personalizada foi mais fácil de implementar, de acordo com meu design, mas o custo da busca é grande o suficiente para atrasar o carregamento da página.
learning_13
2
@ learning_13, você estava fazendo a pergunta errada, e talvez eu e Tom não tenhamos transmitido a mensagem em nossas respostas - O cache adequado fará com que você decida usar o desempenho suficiente para sites que se preocupam com desempenho. A decisão sobre como armazenar dados deve ser tomada com base na estrutura do seu plug-in e em sua funcionalidade; o desempenho deve ser a última coisa a se pensar.
27618 Mark Kaplun
2
@ aim100k, por favor, não envolva "pais" nas respostas aqui. O que as pessoas fazem para viver não deve ser mencionado, a menos que seja relevante para a resposta ou pergunta. Se você não gostar de uma resposta, diminua o seu voto. Se você acha que a resposta pode ser tecnicamente correta, mas ofensiva, tente editá-la, sinalizá-la ou discuti-la no meta site.
Mark Kaplun
@ mark-kaplun, Digamos que eu armazene dados na tabela personalizada e os busco para cada renderização de postagem em que meu plug-in esteja envolvido para mostrar alguns dados. Então, os plug-ins de cache ou a otimização de cache do usuário cuidarão do cache dessa tabela? E os esforços adicionais na implementação e no design serão alterados apenas para usar transitórios / opções em vez de usar uma tabela personalizada que se encaixa mais no meu projeto, uma micro otimização (prematura) sobre a velocidade de carregamento da página?
learning_13
4

Se nenhum cache de objeto for encontrado, get_transientchama get_optionduas vezes, uma vez ou o intervalo de expiração e um para o valor, portanto, não será mais rápido.

get_optiono desempenho por si só será afetado se a opção for "carregada automaticamente" (padrão) ou não. Todas as opções carregadas automaticamente são recuperadas em uma solicitação para o banco de dados e armazenadas no cache de memória e, portanto, deve haver muito pouco impacto em quantas vezes você chama, get_optionmesmo que seja para opções diferentes.

Quando você acessa o banco de dados diretamente, ignora todos os caches e outras melhorias de desempenho, e espera-se que seja mais lento, a menos que você implemente alguma lógica inteligente.

Tudo isso dito, não tenho certeza se o seu teste foi bom, mas, independentemente disso, toda a discussão é inútil, como se você realmente se importasse com o desempenho, usará o sistema de cache de objetos (e o plug-in relevante) que aproximará mais o tempo de acesso aos dados. para zero .... e, é claro, se você decidir usar suas próprias tabelas de banco de dados, deverá integrar suas APIs de acesso ao mecanismo de armazenamento em cache de objetos.

Mark Kaplun
fonte