É get_option () mais rápido que acessar get_transient ()?

  

Hoje eu testei meu banco de dados para explorar a diferença de velocidade entre acessar uma chave de opções, tabela personalizada & transientes. Eu corri o teste por 1000 vezes e o seguinte é o tempo necessário para executar 1000 operações:

Tenha em mente que a tabela de opções é usada para opções e transientes na maioria dos sistemas, e essa tabela foi otimizada, com índices adicionados. Então 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

Esta também é uma comparação injusta, opções com o conjunto de opções de carregamento automático serão carregadas em avançado em uma única consulta no início. Então get_option está puxando de WP_Cache , a opção já foi recuperada.

  

Também verifiquei se o transiente não expirou durante esse teste.

Isso não deve afetar o sistema normal na recuperação temporária, afinal, ele não sabe se expirou até ser recuperado

  

Então a pergunta é, é get_option () mais rápido que get_transient () ou eu estraguei alguma coisa no meu teste?

Depende.

  

O atraso da tabela personalizada é devido às opções sendo armazenadas em cache pelo WordPress?

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

  

Além disso, as opções também são armazenadas em cache por diferentes plug-ins de armazenamento em cache, como os transientes?

Sim, WP_Cache é usado, que armazenará na memória pelo restante da solicitação

Repetibilidade

Estes são todos armazenados em cache via WP_Cache , então, da segunda vez que você solicitar, nenhum DB estará envolvido.

Variabilidade e depende

Isso tudo assume uma base comum, mas e os caches de objetos?

Vamos apresentar uma instância do MemcacheD ou uma instância do Redis (É altamente recomendável que você faça isso, se tiver a opção Benefícios de desempenho ENORMES para sites bem construídos, especialmente se você usá-los para o cache de páginas, a menos que tenha algo parecido com 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 drasticamente reduzidos. Ainda mais lento que uma variável, mas significativamente mais rápido que uma consulta de banco de dados
• Muitos dados novos são armazenados em WP_Cache , o que normalmente não é. Por exemplo. WP_Post objects, post meta, etc
• WP_Cache agora persiste entre as solicitações
• MemcacheD etc pode eliminar transientes expirados, etc.

Portanto, os transientes e 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.

Então, para desempenho devo usar transientes ou opções?

Embora seja uma questão digna de ser questionada, a resposta é que a diferença é insignificante e dentro das margens de erro

Portanto, pare de micro-otimização, eles são o mesmo meio de armazenamento, e isso não é digno do seu tempo

• Use as opções se precisar armazenar algo que tenha todo o site
• Use transientes para armazenar temporariamente coisas que são caras de calcular, para que você não precise compará-las

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

Existem coisas muito melhores para otimizar, que proporcionam economias significativamente maiores, por exemplo, usando taxonomias ao invés de meta em post queries, não usando __not style parameters, fazendo menos coisas na página, instalando um cache de objetos, posts mais baixos por página, evitando pedidos remotos etc

Que tal uma mesa personalizada que irá ...

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

Se nenhum objeto de armazenamento em cache for encontrado, get_transient chama get_option duas vezes, uma vez ou o intervalo de expiração e um para o valor, portanto, não será mais rápido.

get_option desempenho por si só será afetado se a opção é "autoloaded" (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_option , mesmo que seja para opções diferentes.

Quando você acessa o DB diretamente, você ignora todo o cache e outras melhorias de desempenho, e espera-se que ele seja mais lento, a menos que você mesmo implemente alguma lógica inteligente.

Tudo o que disse, não tenho certeza se o teste foi bom, mas independentemente disso, toda a discussão é inútil como se você realmente se importasse com o desempenho, você usará o sistema de cache de objetos (e o plug-in relevante) que trará acesso a dados tempo muito mais próximo de zero .... e, claro, se você decidir usar suas próprias tabelas DB, você deve integrar suas APIs de acesso com o mecanismo de cache de objetos.