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