Caché de objetos en todas partes
WordPress intenta reducir el número de consultas de 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 el caché, y lo devuelve desde allí en lugar de consultar la base de datos.
El "trabajo de caché" se realiza a través de WP_Object_Cache
class y wp_cache_*
funciones (que están más ajustados a eso) métodos de clase.)
Donde vive el caché
Por defecto, el "caché" no es más que una variable global de 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é.
Generalmente, 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 los complementos de "caché persistente" puede reducir drásticamente el número de consultas de la base de datos, ya que 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 del caché de objetos, y las solicitudes subsiguientes extraen datos del caché y no de la base de datos.
Lo mismo sucede con los términos de taxonomía, WordPress extrae todos los términos de una taxonomía una vez y luego los devuelve de la caché.
El caché de objetos se usa mucho en WordPress. No solo para publicaciones, meta valores 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
, WordPress no solo las extrae de la base de datos (o de la caché si están almacenadas en caché) sino que también actualiza la caché para todos los campos personalizados y todas las taxonomías relacionado con las publicaciones extraídas.
Entonces, cuando llama, por ejemplo, get_the_terms()
o get_post_meta()
, mientras que las publicaciones en bucle se obtienen a través de WP_Query
, en realidad no activa ninguna consulta de la base de datos, sino que extrae información de la caché.
Agradable, ¿no es así?
Bueno, sí, pero tiene un costo.
La actualización "mágica" de la memoria caché que WordPress realiza cuando se extraen publicaciones a través de WP_Query
ocurre en update_meta_cache
para meta y en update_object_term_cache
para taxonomías.
Si observa el código fuente de esas funciones, verá que WordPress realiza solo una consulta de db en cada función, pero también realiza mucho procesamiento. Por ejemplo, en update_object_term_cache
hay 7 anested foreach
... si tiene muchas taxonomías y el número de publicaciones por página es alto, esto no es muy eficaz.
Sobre esos argumentos WP_Query
, finalmente
Lo que hacen 'update_post_meta_cache'
y 'update_post_term_cache'
cuando se establece en false
es evitar que WordPress actualice la caché para campos personalizados y taxonomías, respectivamente.
En ese caso, la primera vez que se consulta un campo personalizado o una taxonomía, se desencadena una consulta de base de datos y los datos se almacenan en caché.
¿Vale la pena?
Como de costumbre, la respuesta es depende . La mayoría de las veces para establecer esos valores en false
, es una buena opción, porque evita el procesamiento innecesario y las consultas de la base de datos si no son necesarias, y la caché se actualiza de todos modos la primera vez que se requieren términos personalizados de campo / taxonomía.
Sin embargo, si va a llamar, incluso una vez, get_post_meta()
durante el ciclo y va a llamar a get_the_terms()
para todas (o la mayoría) de las taxonomías soportadas por las publicaciones, entonces la actualización de la caché se activa de todos modos y es posible que no haya un beneficio real al configurar esos argumentos de consulta en false
.