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_Cache
clase 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.php
y / 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_Query
tiene 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_Query
realizan en update_meta_cache
meta y en update_object_term_cache
taxonomí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_cache
hay 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_Query
argumentos, finalmente
Qué 'update_post_meta_cache'
y 'update_post_term_cache'
hacer cuando se establece en false
es 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 false
es 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
.
wp_reset_postdata()
es restablecerglobal $post
y 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.