Explicación de update_post_ (meta / term) _cache

23

Estaba leyendo algunas de las mejores prácticas de 10up y mencionan establecer estos dos indicadores en falso en una WP_Query (dependiendo de lo que esté consultando):

  • 'update_post_meta_cache' => false: útil cuando no se utilizará la meta meta.
  • 'update_post_term_cache' => false: útil cuando no se utilizarán términos de taxonomía.

Estoy asumiendo que la utilización de algo así update_post_caches(), pero ni siquiera estoy 100% seguro de lo que eso significa. ¿Podría alguien explicar qué significan estas dos banderas en WP_Queryay qué tan útiles son? Cuanta más información, mejor, ya que no sé mucho sobre cómo WordPress almacena en caché las cosas, pero una respuesta bien pensada con respecto a estos dos indicadores también es aceptable.

Howdy_McGee
fuente

Respuestas:

30

Objeto caché en todas partes

WordPress intenta reducir la cantidad de consultas a la base de datos tanto como sea posible.

Por ejemplo, cada vez que obtiene un metacampo o un campo de taxonomía, antes de consultar la base de datos, WordPress busca si eso ya fue consultado y almacenado en caché, y lo devuelve desde allí en lugar de consultar la base de datos.

El "trabajo de caché" se realiza a través de la WP_Object_Cacheclase y las wp_cache_*funciones (que son envoltorios para los métodos de esa clase).

Donde vive el caché

Por defecto, el "caché" no es más que una variable global PHP. Significa que está en la memoria, pero también significa que desaparece con cada solicitud.

Sin embargo, a través de dropins ( advanced-cache.phpy / o object-cache.php), es posible configurar una forma personalizada para manejar este caché.

Por lo general, estos dropins se utilizan para configurar algún tipo de mecanismo de almacenamiento en caché que "sobrevive" a las solicitudes singulares.

Por esta razón, entre las personas de WP, estos se conocen como complementos de "caché persistente" (incluso si fuera de la burbuja, las palabras "caché" y "persistente" no tienen mucho sentido juntas).

Las opciones populares hoy en día son Memcached o Redis .

Por lo tanto, al usar complementos de "caché persistente", puede reducir drásticamente el número de consultas de la base de datos, porque el caché no se actualiza en cada solicitud.

Algunos ejemplos

$foo = get_post_meta('foo', $post_id, true);
// a lot of code in the middle
$bar = get_post_meta('bar', $post_id, true);

Las 2 líneas de código anteriores activarán, como máximo, 1 consulta de base de datos.

De hecho, cuando consulta un campo personalizado, todos los campos para esa publicación se recuperan de la base de datos, se almacenan en caché a través de la caché de objetos y las solicitudes posteriores extraen datos de la caché y no de db.

Lo mismo ocurre con los términos de taxonomía, WordPress extrae todos los términos de una taxonomía una vez, luego los devuelve de la memoria caché.

La caché de objetos se usa mucho en WordPress. No solo para publicaciones, metavalores y taxonomías, sino también para usuarios, comentarios, datos de temas ...

¿Qué WP_Querytiene que ver con todo esto?

Cuando consulta algunas publicaciones a través de WP_Query, de forma predeterminada, WordPress no solo las extrae de la base de datos (o de la memoria caché si están en caché) sino que también actualiza la memoria caché para todos los campos personalizados y todas las taxonomías relacionadas con las publicaciones extraídas.

Por lo tanto, cuando llama, por ejemplo, get_the_terms()o get_post_meta()mientras realiza un bucle de publicaciones WP_Query, no desencadena ninguna consulta de base de datos, sino que extrae información de la memoria caché.

Bien, no lo es?

Bueno, sí, pero tiene un costo.

La actualización de caché "mágica" que WordPress hace cuando las publicaciones de extracción se WP_Queryrealizan en update_meta_cachemeta y en update_object_term_cachetaxonomías.

Si observa el código fuente de esas funciones, verá que WordPress realiza solo una consulta de base de datos en cada función, pero también procesa mucho. Por ejemplo, update_object_term_cachehay 7 anidadosforeach ... si tiene muchas taxonomías y el número de publicaciones por página es alto, esto no es muy eficiente.

Sobre esos WP_Queryargumentos, finalmente

Qué 'update_post_meta_cache'y 'update_post_term_cache'hacer cuando se establece en falsees evitar que WordPress para caché de actualización para los campos personalizados y las taxonomías, respectivamente.

En ese caso, la primera vez que se consulta un campo personalizado o una taxonomía, se activa una consulta de base de datos y los datos se almacenan en caché.

¿Vale la pena?

Como de costumbre, la respuesta es que depende . La mayoría de las veces establecer esos valores falsees una buena opción, ya que evita el procesamiento innecesario y las consultas de la base de datos si no es necesario, y la memoria caché se actualiza de todos modos la primera vez que se requieren términos de campo / taxonomía personalizados.

Sin embargo, si va a llamar, incluso una vez, get_post_meta()durante el ciclo y va a llamar get_the_terms()a todas (o la mayoría) de las taxonomías admitidas por las publicaciones, la actualización de la memoria caché se activa de todos modos, y es posible que no haya ningún beneficio real en establecer esos argumentos de consulta en false.

gmazzap
fuente
¡Ordenado! Como siempre, su visión siempre es apreciada GM. ¿Los transitorios se considerarían "caché persistente"? Entonces, para ir más allá, durante una WP_Query, ¿la razón wp_reset_postdata()es restablecer global $posty restablecer la caché de objetos? Parece que si hiciera un WP_Query personalizado, crearía un nuevo objeto almacenado en caché, pero al restablecerlo también tendría que solicitar para obtener el caché original. O tal vez me estoy alejando demasiado en el contexto de esta pregunta.
Howdy_McGee
1
@Howdy_McGee La caché de objetos y el objeto de publicación no están relacionados. Por wp_reset_postdata()lo tanto , no haga nada con respecto al caché de objetos. wp_reset_postdata()solo restablece el objeto de publicación global, esa es otra variable global, que nunca se almacena en caché ... Los transitorios son una cosa híbrida: cuando tiene instalado un complemento de caché persistente, use transitoriamente, pero si no tiene un complemento de caché persistente, entonces los transitorios utilizar la base de datos
gmazzap
Ah, me aferré a la global variablenoción y asumí que se trataba de los objetos global $postglobales $wp_query, ¡gracias por la aclaración!
Howdy_McGee
En una nota al margen , fields => 'ids'establece ambas memorias caché en false. Supongo que tiene sentido que una caché de objetos solo funcione en objetos, pero pensé que solo haría una mención: D
Howdy_McGee
3

El principal punto de interés aquí es la update_post_cachesfunción. Se llama después de que WP_Query obtuvo todas las publicaciones del DB. Por lo general, la razón por la que desea las publicaciones en primer lugar es mostrarlas, lo que generalmente significa mostrar los términos y algo basado en los metadatos, por lo que WP_Query también consultará de forma predeterminada en la base de datos los meta y términos relacionados con las publicaciones devueltas y lo almacena en el caché *. Esta información no está explícitamente disponible en los datos devueltos por WP_Query, pero cuando llame a las API relevantes para obtener el término y la metainformación de una publicación específica, ya estará disponible en la memoria y no habrá necesidad de enviar una nueva consulta a la base de datos.

Esto permite que WordPress reduzca la sobrecarga relacionada con el envío de solicitudes a la base de datos enviando solo una solicitud para obtener la información de todas las publicaciones en lugar de enviar una solicitud por cada publicación.

En este momento no puedo encontrar ningún ejemplo no trivial de cuándo no querrá que se actualice el caché, pero podría ser trivial si solo desea una lista de los títulos de todas las publicaciones. Para eso no necesita término ni metadatos.

* caché: lo más importante aquí es el caché basado en memoria en el que WP almacena todo lo que obtiene de la base de datos, incluso sin tener ningún complemento de almacenamiento en caché de objetos activo. Obviamente, cuando tenga un almacenamiento en caché de objetos, la información también se almacenará allí.

Mark Kaplun
fuente