Cache de objeto em qualquer lugar
O WordPress tenta reduzir o número de consultas ao banco de dados o máximo possível.
Por exemplo, sempre que você obtém um meta-campo ou um campo de taxonomia, antes de consultar o banco de dados, o WordPress verifica se ele já foi consultado e armazenado no cache e o retorna a partir daí, em vez de consultar o banco de dados.
O "trabalho de cache" é feito por meio de WP_Object_Cache
classe e wp_cache_*
funções (que são wrapper para os métodos dessa classe).
Onde vive o cache
Por padrão, o "cache" nada mais é do que uma variável global do PHP. Isso significa que está na memória, mas também significa que desaparece a cada solicitação.
No entanto, via dropins ( advanced-cache.php
e / ou object-cache.php
), é possível configurar uma maneira personalizada de lidar com esse cache.
Geralmente, esses dropins são usados para configurar algum tipo de mecanismo de cache que "sobrevive" às solicitações singulares.
Por esse motivo, entre os funcionários do WP, eles são conhecidos como plug-ins de "cache persistente" (mesmo que fora da bolha as palavras "cache" e "persistente" não façam muito sentido juntos).
Atualmente, as opções populares são Memcached ou Redis .
Portanto, usando plug-ins de "cache persistente", você pode reduzir drasticamente o número de consultas ao banco de dados, porque o cache não é atualizado a cada solicitação.
Alguns exemplos
$foo = get_post_meta('foo', $post_id, true);
// a lot of code in the middle
$bar = get_post_meta('bar', $post_id, true);
As 2 linhas de código acima acionarão, no máximo, 1 consulta ao banco de dados.
De fato, quando você consulta um campo personalizado, todos os campos para essa postagem são recuperados do banco de dados, armazenados em cache por meio do cache de objetos e as solicitações subsequentes extraem dados do cache e não do db.
O mesmo acontece com os termos de taxonomia, o WordPress puxa todos os termos para uma taxonomia uma vez e depois os retorna do cache.
O cache de objetos é usado amplamente no WordPress. Não apenas para postagens, meta valores e taxonomias, mas também para usuários, comentários, dados de temas ...
O que WP_Query
tem a ver com tudo isso?
Quando você consulta algumas postagens via WP_Query
, por padrão, o WordPress não apenas as extrai do banco de dados (ou do cache se elas estiverem armazenadas em cache), mas também atualiza o cache para todos os campos personalizados e todas as taxonomias relacionadas às postagens extraídas.
Portanto, quando você chama, por exemplo, get_the_terms()
ou get_post_meta()
enquanto as mensagens em loop são recebidas WP_Query
, na verdade, você não aciona nenhuma consulta ao banco de dados, mas extrai as informações do cache.
Legal, não é?
Bem, sim, mas tem um custo.
A atualização de cache "mágica" que o WordPress faz quando recebe postagens WP_Query
ocorre em update_meta_cache
meta e em update_object_term_cache
taxonomias.
Se você olhar para o código fonte dessas funções, verá que o WordPress realiza apenas uma consulta de banco de dados em cada função, mas também processa muito. Por exemplo, update_object_term_cache
existem 7 aninhadosforeach
... se você possui muitas taxonomias e o número de postagens por página é alto, isso não é de grande desempenho.
Sobre esses WP_Query
argumentos, finalmente
O que fazer 'update_post_meta_cache'
e 'update_post_term_cache'
quando definido false
é para impedir que o WordPress atualize o cache para campos e taxonomias personalizados, respectivamente.
Nesse caso, na primeira vez em que um campo personalizado ou uma taxonomia é consultada, uma consulta ao banco de dados é acionada e os dados são armazenados em cache.
Vale a pena?
Como sempre, a resposta é que depende . Na maioria das vezes, para definir esses valores false
, é uma boa opção, pois evita consultas desnecessárias de processamento e banco de dados, se não for necessário, e o cache é atualizado de qualquer maneira na primeira vez que termos de campo / taxonomia personalizados são necessários.
No entanto, se você chamar, mesmo uma vez, get_post_meta()
durante o loop e chamar get_the_terms()
todas (ou a maioria) das taxonomias suportadas pelas postagens, a atualização do cache será acionada de qualquer maneira, e pode não haver benefício real em definindo esses argumentos de consulta para false
.
wp_reset_postdata()
é redefinirglobal $post
e redefinir o cache de objetos? Parece que se eu fizesse um WP_Query personalizado, ele criaria um novo objeto em cache, mas a redefinição também teria que ser solicitada para obter o cache original. Ou talvez eu esteja indo muito longe no contexto desta pergunta.