Después de actualizar a WordPress 6.6, me ha salido un pequeño problema de rendimiento en la sección Salud del Sitio (Site Health): básicamente me decía algo así «Automatically loaded options could affect performance» (Las opciones cargadas automáticamente podrían afectar al rendimiento).
¿Cuál es el problema? Parece que hay opciones en la base de datos de WordPress, concretamente en wp_options, que tiene la opción autoload en Yes. ¿Qué pasa con esto? Que esos datos se van a cargar en todas las páginas de tu instalación de WordPress, y pueden provocar una bajada de rendimiento.
El problema, es que muchos temas, plugins que ya no tenemos instalados, pueden haber dejado sus datos en esa tabla. También puede ser que tengamos muchos transients del propio WP en esa tabla (son un mecanismo de almacenamiento temporal de datos en la base de datos que permite guardar información con una fecha de caducidad): normalmente se van borrando automáticamente, pero a veces se pueden quedar colgados en esa tabla.
La cosa es que, si superas aproximadamente unos 900 Kb, te va a saltar el problema de rendimiento en Salud del Sitio. ¿Cómo borramos las opciones que no nos valen y que nos están fastidiando? Te cuento como lo he hecho yo.
¡Dato! Antes de hacer nada, asegúrate de tener una copia de seguridad de tu base de datos de WordPress.
Cómo elegir y borrar datos cargados automáticamente en la tabla wp_options
¿Cuándo deberías hacer esto? Si notas que tus páginas de WordPress de pronto no cargan tan rápido como deberían.
Tiene que tener acceso a tu base de datos con programas como phpMyAdmin, o como yo, directamente desde el panel de Virtualmin.
Comprobamos el tamaño de los datos con autoload Yes
Para ejecutar el comando debes buscar alguna pantalla en tu gestor de base de datos donde puedas ejecutar comandos SQL.
SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes';En mi caso, si te fijas en la imagen de arriba, me sale ya por debajo de lo 900 kb (unos 630 kb)… porque ya he ejecutado los siguientes comandos para borrar varias opciones que no debían estar allí. Pero antes de la limpieza, tenía más de 900 kb en esa tabla con autoload yes.
¿Quieres hacer lo anterior con WP-CLI? Este es el comando si lo tienes instalado en tu servidor:
wp option list --autoload=on --format=total_bytes¿Cómo podemos saber qué datos son los más pesados en esta tabla con autoload yes?
Pues ejecutamos el siguiente comando:
SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 10;Aquí es donde puedes identificar le nombre de plugins y temas que han metido datos en tu tabla. En mi caso era un transient que no se había borrado ni usando plugins como WP SWEEP. Si ves nombres de plugins o temas que ya no tienes instalados en WordPress, puedes procedes a borrar esos datos. ¿Cómo? Pues con este comando:
DELETE
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%wp-reset-log%'Si ya no tienes instalado el plugin WP Reset en tu WordPress, puedes ejecutar el borrado con tranquilidad. Si es otro plugin o tema, cambia wp-reset-log por el nombre correspondiente.
En mi caso, que era un transient de WordPress, puedes hacerlo de dos maneras:
Con un comando SQL:
SELECT *
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%transient%'Con un comando de WP-CLI (si lo tienes instalado):
wp transient delete --allCon este último comando vas a borrar todos los transients. No pasa nada. Es seguro. Luego se vuelven a regenerar si realmente son necesarios.
Puedes comprobar el tamaño de estos datos en tu base de datos con el comando:
wp option list --search="*_transient_*" --fields=option_name,size_bytes | sort -n -k 2 | tailTambién puedes usar WP-CLI para borrar los datos de esta tabla. El comando es el siguiente, pero primero debes conocer el nombre de la opción (cambias mi_opcion por el nombre de los datos que quieras borrar):
wp option delete mi_opcionY ahora te pasas por Salud del Sitio en WordPress… ¡Y te sigue diciendo que tienes un problema de rendimiento! Ya, el truco es que sigues teniendo esos datos en diferentes caches, en mi caso, en Opcache, y creo que también en memcached. No me cuesta nada borrar ambas caches y que el proceso de Salud del Sitio vuelva a correr.
En mi caso, que tengo acceso SSH al servidor Rocky Linux, aplico los siguientes comandos para borrar ambas caches.
Memcached
Tengo un script ejecutable que borra la memoria de Memcached (borrar-memcached.sh). Para hacerlo ejecutable solo tienes que hacer lo siguiente: chmod +x borrar-memcached.sh y luego ejecutarlo con ./borrar-memcached.sh
#!/bin/bash
# Vaciar la caché de Memcached
echo "flush_all" | nc localhost 11211
# Verificar si el comando se ejecutó correctamente
if [ $? -eq 0 ]; then
echo "La caché de Memcached ha sido vaciada exitosamente."
else
echo "Hubo un error al intentar vaciar la caché de Memcached."
fiEn este caso tengo un archivo llamado resetear_opcache.php que puedes ejecutar como php reset_opcache_cli.php
<?php
// Este script vacía la caché de Opcache
if (function_exists('opcache_reset')) {
opcache_reset();
echo "Opcache ha sido vaciado exitosamente.";
} else {
echo "Opcache no está habilitado.";
}
?>Después de hacerlo, el aviso de rendimiento ya ha desaparecido de mi panel de WordPress.
Referencias:
