Hostsuar

Optimizar la tabla wp_options y los datos de tipo "autoload"

La tabla wp_options de WordPress almacena todas las configuraciones de la aplicación, plugins y temas instalados, es una tabla que tiende a acumular datos que pasan desapercibidos, por ejemplo de plugins que han sido desinstalados, pero cuyas rutinas no han purgado los datos, instalaciones antiguas que con el tiempo han ido acumulando datos innecesarios, datos de tareas cron a ejecutar e incluso información del sistema de caché.

wp_options es una tabla con una estructura muy sencilla, un identificador (option_id) un nombre (option_name), los datos que se almacenan asociados al nombre (option_value) y una configuración de tipo verdadero o falso que define si esta información se debe o no cargar en cada acceso (autoload).

Los valores autocargados (autoload) son poco conocidos, pero un factor decisivo en el rendimiento de WordPress, si tenemos configuraciones de gran tamaño con autoload activo, implicará que en cada acceso estos se deban obtener desde la base de datos de forma sucesiva, incluso varias veces en una única petición / acceso.

Si a esto le unimos un tamaño excesivo en estas filas, creamos la combinación perfecta para degradar el rendimiento y provocar lentitud y un consumo de recursos alto.

Averiguando el tamaño de los datos autoload

El primer paso es averiguar el tamaño total de los datos con autoload activo, WordPress recomienda que no se superen los 900KB para no incurrir en problemas de rendimiento.

El valor de 900KB es orientativo, podemos tener proyectos que requieran más y aun así tengan un buen rendimiento, pero como norma, es un límite adecuado que no se debería superar siempre que sea posible.

Para evaluar el tamaño total nos apoyaremos en phpMyAdmin, usaremos la herramienta disponible en la pestaña SQL donde ejecutaremos diversas consultas a fin de ir desgranando el problema.

En las consultas SQL de este artículo, nos basaremos en la nomenclatura común de la tabla wp_options, si tienes un prefijo diferente a wp_, bastaría con cambiar las referencias a wp_options cambiando wp_ por el prefijo específico que se utilice en tu base de datos.

Lo primero es averiguar el tamaño total de los datos que se cargan automáticamente en cada acceso a WordPress, para ello desde la pestaña SQL de phpMyAdmin ejecutamos:

SELECT
	'Total de datos autocargados en KB' AS name,
	ROUND(SUM(LENGTH(option_value)) / 1024) AS value
FROM
	wp_options
WHERE
	autoload = 'yes'
UNION
SELECT
	'Total de opciones con autoload "on"',
	count(*)
FROM
	wp_options
WHERE
	autoload = 'yes'

Esta consulta nos dará dos resultados, por un lado, el total de filas que tienen autoload activo, por otro el total de datos que ocupan en KB, cualquier valor superior a 900-1000 debería plantearnos el seguir revisando en mayor profundidad.

WordPress wp_options autoload

Identificar las opciones con mayor uso de espacio

Si tenemos un valor total problemático, el siguiente paso sería evaluar si es alguna opción específica la que lastra al resto, para ello vamos a usar otra consulta que nos dirá las 10 opciones que ocupan más espacio.

SELECT
	option_name,
	ROUND(LENGTH(option_value) / 1024) AS size
FROM
	wp_options
WHERE
	autoload = 'yes'
ORDER BY
	size DESC
LIMIT 10;

Usamos 10 para limitar los resultados a analizar, pero si cambiamos LIMIT 10, nos mostrará el número de resultados que definamos en el valor numérico. Respecto al total, de nuevo lo estamos calculando en KB.

El campo option_name nos da el identificador de la fila, si quisiésemos analizar la información que almacena, podemos usar el buscador de phpMyAdmin para localizar la fila, o ejecutar una consulta de búsqueda, por ejemplo vamos a evaluar que datos está almacenando revslider-addons con:

SELECT
	*
FROM
	wp_options
WHERE
	option_name LIKE '%revslider-addons%'

Si vemos una opción con un uso de espacio significativo y no reconocemos que puede ser, lo más sencillo es ir a Google y buscar el nombre de la opción, por ejemplo si buscamos icl_sitepress_settings, vemos que el primer artículo ya nos indica que se trata de una opción del plugin WPML e incluso un usuario solicita ayuda acerca de un uso desmesurado de espacio.

Aquí entraría un proceso de análisis e investigación que debe realizarse paso a paso, comprobando las opciones que incrementan el uso de espacio en la tabla wp_options, averiguando que plugin es el responsable de cada una de ellas, eliminando dichos datos si fuesen plugins desactivados o eliminados, e incluso contrastando con foros y desarrolladores si efectivamente el uso de espacio es o no normal para cada opción.

Desde phpMyAdmin podrás navegar de forma sencilla por los resultados que ofrezca cada consulta SQL, eliminando las filas o editando su contenido.

Tamaño total tabla wp_options

Aunque en el artículo estamos tratando los datos de tipo autoload, aquellos que cargan en cada acceso, también sería interesante evaluar el tamaño y número de filas de la tabla wp_options para datos autocargados o no, al poder de igual forma influir en el rendimiento de nuestro proyecto.

Desde phpMyAdmin podremos buscar esta tabla y ver de un vistazo tanto el número de filas como tamaño que ocupa la tabla:

tamaño tabla wp_options

Un número elevado de filas podría indicar problemas con los datos transitorios o sesiones (que trataremos a continuación), mientras que un número bajo de filas, pero alto en uso de espacio en disco, podría orientarnos hacía un escenario en el que unas pocas filas están abusando del almacenamiento en esta tabla, para este segundo supuesto podemos usar una consulta SQL anterior, modificándola para que nos devuelva las filas con mayor uso de espacio con independencia de si tienen o no autoload activo.

SELECT
	option_name,
	ROUND(LENGTH(option_value) / 1024) AS size
FROM
	wp_options
ORDER BY
	size DESC
LIMIT 10;

Tareas futuras almacenadas en "cron"

Ya hemos hablado del sistema de tareas cron de WordPress, tiene un diseño obsoleto y problemático, en la tabla wp_options encontraremos una fila específica cuya finalidad es almacenar todas las tareas pendientes.

Si buscando aquellas filas que ocupan mayor espacio damos con una con nombre cron, sería la relativa al almacenamiento de tareas programadas, tendrías que editar esta fila y ver el valor de option_value para evaluar que tipo de tareas se están almacenando y cuál puede ser el causante del "cuello de botella".

La fila cron es de tipo autoload, por lo que cargará en todos los accesos, de ahí la importancia de que tenga un uso de espacio razonable.

Datos transitorios

Los datos transitorios son datos temporales, información que se almacena en wp_options y que tendría una fecha de expiración o caducidad en la que son eliminados.

Pero puede suceder que estos datos no se estén purgando, llegando a acumular miles de registros sin utilidad alguna, el primer paso sería evaluar cuantos registros de este tipo tenemos, lo podemos hacer con la siguiente consulta.

SELECT COUNT(*) 
FROM wp_options 
WHERE option_name LIKE '%transient%'

Si vemos un número elevado, podríamos apoyarnos en un plugin como Transient Cleaner o Transient Manager para indagar y purgar estos datos desde la propia interfaz de WordPress.

Datos relativos a las sesiones

Similar a los transients o transitorios, tenemos las sesiones que almacenan información de cada login que un usuario realiza sobre su cuenta, primero contaremos cuantas filas de este tipo tenemos.

SELECT COUNT(*) 
FROM wp_options 
WHERE option_name LIKE '%_wp_session_%'

Aquí depende de cada proyecto (no es lo mismo un foro con miles de usuarios que un blog personal), pero un resultado que supere las 1000 filas podría requerir purgado, tan sencillo como ejecutar:

DELETE FROM `wp_options` 
WHERE `option_name` LIKE '_wp_session_%'

Eliminar las sesiones no causaría ningún problema, si hay algún usuario conectado en su área personal en ese momento, WordPress solicitará de nuevo que conecte con su usuario y contraseña.

Índices para acelerar wp_options

Bajo una situación normal, cuando realices una búsqueda en una tabla por medio de una consulta SQL, se revisará una a una cada fila hasta dar con la que coincide con las condiciones definidas, esta tarea es bastante eficiente, pero cuanto mayor sea el número de filas, peor será el rendimiento.

Un índice no es más que una guía en la que los valores son ordenados, de forma que MySQL elimine la necesidad de ir fila a fila.

En tablas wp_options con un número elevado de filas, podría ser de ayuda crear un incide que combine el valor de autoload con option_name para mejorar el rendimiento de búsquedas que se realicen con estos dos condicionales.

Para crear este índice, accederíamos a cPanel, herramienta phpMyAdmin, conectamos con la base de datos sobre la que queramos proceder, y finalmente en la pestaña SQL ejecutamos la secuencia para crear el índice:

CREATE INDEX autoloadindex ON wp_options(autoload, option_name);

Object cache

Hemos tratado un número considerable de casos prácticos para evaluar y optimizar la tabla wp_options, pero podríamos llegar al punto de haber optimizado y depurado todo lo posible y aun así seguir con un número elevado de filas o de espacio total ocupado por wp_options.

Un recurso adicional para optimizar el rendimiento es utilizar algún tipo de object cache, encontrarás información detallada acerca de la caché de objetos de WordPress en el manual "qué es el caché de objetos (object cache) y cómo configurarla con WordPress".