Explicação de update_post_ (meta / term) _cache


23

Eu estava lendo algumas práticas recomendadas do 10up e elas mencionam a configuração desses dois sinalizadores como false em um WP_Query (dependendo do que você está consultando):

  • 'update_post_meta_cache' => false: útil quando a meta meta não será utilizada.
  • 'update_post_term_cache' => false: útil quando os termos de taxonomia não serão utilizados.

Estou assumindo que ele utiliza algo como, update_post_caches()mas não tenho nem 100% de certeza do que isso significa. Alguém poderia explicar o que essas duas bandeiras significam WP_Querye como elas são úteis? Quanto mais informações, melhor, pois eu não sei muito sobre como o WordPress armazena em cache as coisas, mas uma resposta bem pensada sobre esses dois sinalizadores também é aceitável.

Respostas:


30

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_Cacheclasse 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.phpe / 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_Querytem 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_Queryocorre em update_meta_cachemeta e em update_object_term_cachetaxonomias.

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_cacheexistem 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_Queryargumentos, 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.


Arrumado! Como sempre, sua visão é sempre apreciada, GM. Os transientes seriam considerados "cache persistente"? Então, para ir além, durante uma WP_Query, o motivo wp_reset_postdata()é redefinir global $poste 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.
Howdy_McGee

1
@Howdy_McGee O cache e o objeto de postagem não estão relacionados. Portanto wp_reset_postdata(), não faça nada em relação ao cache de objetos. wp_reset_postdata()somente redefina o objeto de postagem global, que é outra variável global, que nunca é armazenada em cache ... Transientes são uma coisa híbrida: quando você tem algum plug-in de cache persistente instalado, use-o temporariamente, mas se você não tiver um plug-in de cache persistente, os transientes use database.
gmazzap

Ah, eu apenas me apeguei à global variablenoção e assumi que eram os objetos global $postglobais $wp_query, obrigado pelo esclarecimento!
Howdy_McGee

Em uma nota lateral , fields => 'ids'define os dois caches como false. Suponho que isso faz sentido que um objeto de cache só funciona em objetos, mas eu pensei que seria apenas fazer uma menção: D
Howdy_McGee

3

O principal ponto de interesse aqui é a update_post_cachesfunção. É chamado depois que o WP_Query obteve todas as postagens do banco de dados. Geralmente, o motivo pelo qual você deseja que as postagens sejam exibidas é o que geralmente significa exibir os termos e algo com base nos metadados. Portanto, o WP_Query também consultará por padrão o banco de dados em busca dos dados de meta e termo relacionados às postagens retornadas. e armazena o cache *. Essas informações não estão explicitamente disponíveis nos dados retornados do WP_Query, mas quando você chamar as APIs relevantes para obter o termo e as meta informações de uma postagem específica, elas já estarão disponíveis na memória e não haverá necessidade de enviar um novo consulta ao banco de dados.

Isso permite que o wordpress reduza a sobrecarga relacionada ao envio de solicitações ao banco de dados, enviando apenas uma solicitação para obter as informações de todas as postagens, em vez de enviar uma solicitação para cada postagem.

No momento, não consigo encontrar nenhum exemplo não trivial de quando você não deseja que o cache seja atualizado, mas pode ser trivial se você quiser apenas uma lista dos títulos de todas as postagens. Para isso, você não precisa de termos ou metadados.

* cache - O mais importante aqui é o cache baseado em memória, no qual o WP armazena quase tudo o que obtém do banco de dados, mesmo sem ter nenhum plug-in de cache de objeto ativo. Obviamente, quando você tiver um cache de objeto, as informações também serão armazenadas lá.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.