Hoy vamos a echar un vistazo a la tabla wp_options en su base de datos de WordPress. Este es un aspecto que se suele pasar por alto cuando se trata de rendimiento general de base de datos y de WordPress. Especialmente en sitios más antiguos y de gran tamaño, esto puede ser el culpable de los tiempos de consulta lentos en su sitio debido a la carga automática de los datos que se dejaron los plugins y temas de terceros. Eche un vistazo a estos consejos sobre cómo controlar, diagnosticar y limpiar la tabla wp_options.
¿Cuál es la Tabla wp_options?
La tabla wp_options contiene todo tipo de datos para el sitio WordPress como:
- Dirección URL del sitio, URL de inicio, administración de correo electrónico, categoría predeterminada, posts por página, formato de hora, etc.
- Ajustes de plugins, temas, widgets
- Los datos temporalmente en cache
La tabla contiene los siguientes campos, uno del que nos preocupamos más cuando se trata de desempeño:
- option_id
- option_name
- option_value
- autoload
Una de las cosas importantes que hay que entender acerca de la tabla wp_options es el campo autoload. Este contiene un valor sí o no (flag). Esto básicamente controla sí es o no será cargado por la función wp_load_alloptions(). Los datos cargados automáticamente son datos que se cargan en cada página de su sitio WordPress. Al igual que como le mostramos cómo deshabilitar ciertos scripts de cargarse en todo el sitio, la misma idea se aplica aquí. El atributo autoload se establece en «Sí» por defecto para los desarrolladores, pero no cada plugin teóricamente debería cargar sus datos en cada página.
El problema que pueden tener los sitios WordPress es cuando hay una gran cantidad de datos de autocarga en la tabla wp_options. Esto normalmente es el resultado de lo siguiente:
- Los datos se están cargado automáticamente mediante un plugin, cuando realmente debería estar establecido a «no.» Un buen ejemplo de esto sería un plugin de formulario de contacto. ¿Necesita cargar datos en cada página o sólo en la página de contacto?
- Plugins o temas han sido eliminados del sitio WordPress, pero sus opciones todavía están rezagadas en la tabla wp_options. Esto podría significar que los datos de autocarga innecesariamente reciben consultas con cada solicitud.
- Los desarrolladores de plugins y temas están cargando datos en la tabla wp_options en lugar de utilizar sus propias tablas. Hay argumentos para ambos lados de esto, ya que algunos desarrolladores prefieren plugins que no creen tablas adicionales. Sin embargo, la tabla wp_options tampoco fue diseñada para albergar miles de filas.
¿Cuánto es demasiado de datos de autocarga? Esto puede variar, por supuesto, pero idealmente, usted quiere estar entre 300 KB y 1 MB. Una vez que empiece a acercarse al rango 3-5 MB o más, los datos deberían ser optimizados o eliminados de ser autocargados. Y algo superior a 10 MB debería ser abordado de inmediato. Esto no siempre significa que va a causar un problema, pero es un buen lugar para comenzar.
Solución de Problemas de Datos de Auto Carga en la Tabla wp_options
Si está experimentando lentitud en su sitio WordPress, puede ser debido a una consulta o datos de autocarga dejados atrás de un antiguo WordPress plugin. A continuación, le mostraremos cómo verificar el tamaño de datos de autocarga en su base de datos, así como sumergirse en datos de un sitio en vivo y compartir lo que hicimos para limpiarlo.
Verificar el Tamaño de los Datos de Autocarga
La primera cosa a hacer es comprobar el actual tamaño cargado automáticamente en su sitio WordPress. Para ello, inicie sesión en phpMyAdmin. Haga clic en la base de datos en el lado izquierdo y, a continuación, en la ficha SQL. A continuación, introduzca el comando siguiente y presione «ir».
SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes';Es posible que tenga que modificar la consulta anterior si su sitio WordPress está utilizando un prefijo diferente a wp_.
El autoload_size devolverá el tamaño en bytes. Hay 1024 bytes en un KB y 1024 KBs en un MB. En nuestro caso, 249,025 bytes equivalen a 0.25 MB. Por lo tanto, para este sitio, este ¡es un buen tamaño! Si devuelve algo por debajo de 1 MB no debe estar preocupado. No obstante, si el resultado fue mucho más, siga adelante con este tutorial.
A continuación está un sitio que probamos en el cual 137,724,715 bytes fueron devueltos o en su lugar 137 MB. Este es un buen ejemplo de un sitio donde algo está definitivamente mal o, más bien, hay cosas que optimizar.
También podría utilizar una consulta más larga como la siguiente. Esto le mostrará el tamaño de datos de autocarga, cuántas entradas están en la tabla, y las primeras 10 entradas por tamaño.
SELECT 'autoloaded data in KiB' as name, ROUND(SUM(LENGTH(option_value))/ 1024) as value FROM wp_options WHERE autoload='yes'
UNION
SELECT 'autoloaded data count', count(*) FROM wp_options WHERE autoload='yes'
UNION
(SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 10)Si usted tiene acceso a New Relic (requiere licencia), también puede utilizarlo para ayudar a solucionar problemas de consultas conectadas a la tabla wp_options. La pestaña bases de datos señalará a la tabla y el tipo de consulta que consume la mayor parte del tiempo. Si selecciona una de las entradas en la lista puede ver más detalles, incluidas algunas consultas de ejemplo. En este ejemplo de abajo, usted puede ver que los datos muestran datos de autocarga en la tabla wp_options. Seguramente, un análisis rápido del sitio en cuestión confirmó casi 250 MB de datos de autocarga.
Ordenar los Datos de Autocarga Superiores
El siguiente paso sería ordenar rápidamente los elementos superiores con datos de autocarga. Aquí está un breve comando SQL que puede utilizar para ver la lista de los principales 10:
SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 10;De nuevo, es posible que tenga que modificar la consulta anterior si su sitio WordPress está utilizando un prefijo diferente que wp_.
Sumergiendo en Datos de Autocarga en wp_options
El siguiente paso fue observar algunos de los principales datos de autocarga.
301_redirects
Como podemos ver en la parte superior de la opción superior de autocarga se encuentran 301_redirects. Esto está probablemente relacionado directamente con un plugin de redirección en el sitio o el WordPress SEO plugin, que también tiene una función de redirección. En este caso, la mejor recomendación es aplicar la redirección a nivel del servidor.
¿Por qué? Porque WordPress plugins gratuitos para implementar redirecciones a veces pueden causar problemas de rendimiento, ya que la mayoría de ellos utilizan la función wp_redirect, que requiere la ejecución de código y recursos adicionales. Y por supuesto, también son datos de autocarga en la tabla wp_options.
Si eres cliente de Kinsta, puedes añadir fácilmente redirecciones a nivel de servidor utilizando la herramienta de reglas de redirección dentro de tu panel de MyKinsta. Esto no sólo es mejor para el rendimiento, sino que también tienes un plugin menos del que preocuparte.
wpurp_custom_template_
La siguiente opción de datos de autocarga superiores fue wpurp_custom_template_#. Podemos ver que hay bastantes filas diferentes para esto. Normalmente, usted debería ser capaz de encontrar este nombre de opción y conectar los puntos mirando en la carpeta plugins o temas. En este caso, hicimos un comando grep del servidor para ver si pudiéramos encontrarlo. También puede verlo vía SFTP.
grep -Ri "wpurp_custom_template_"El comando anterior, sin embargo, no devolvió nada, así que nos fuimos a Google y realizamos una búsqueda. Pronto descubrimos que estaba relacionado con un WordPress plugin que ya no estaba instalado en el sitio, conocido como WP Ultimate Recipe. Este es un ejemplo clásico de datos de autocarga innecesarios dejados atrás. Tenemos un extenso tutorial sobre cómo desinstalar WordPress plugins (de la manera apropiada). Y por la forma correcta, nos referimos a realmente limpiar lo que quedó atrás.
um_cache_userdata_
La siguiente opción de datos superiores de autocarga era um_cache_userdata_#. Podemos ver que hay bastantes filas diferentes para esto. Debido a que esto fue hacia el fondo, rápidamente, hemos modificado nuestro comando MySQL para mostrar los 40 datos de autocarga superiores:
SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 40;O suma de todos los valores con ese prefijo:
SELECT 'sum size in KiB', ROUND(SUM(length(option_value))/1024,0) FROM wp_options WHERE autoload='yes' AND option_name like "um_cache_userdata_%"Pudimos ver que había muchas más entradas para um_cache_userdata_# en la tabla wp_options. Nuevamente ejecutamos un comando grep para comprobar nuestras carpetas de plugins y temas.
grep -Ri "um_cache_userdata_"Entonces pudimos identificar rápidamente esto como relacionado con el plugin Ultimate Member. Una búsqueda rápida en Google devolvió unas buenas soluciones para este problema (véase el artículo de asistencia técnica). ¡Nunca subestime el poder de una búsqueda en Google! Resulta que había unas opciones diferentes disponibles en el plugin para solucionar este problema.
- Ultimate Member > Panel de Control > Cache de Usuario > Borrar Cache.
- Ultimate Member -> Configuración -> Avanzado -> Detener caching de datos del perfil de usuario (cambiar a ON) y, a continuación, guarde los cambios.
Otra opción para ver lo que es una opción de autocarga es pulsando el botón Editar, y esto puede listar el directorio del plugin/tema, o listar el sitio web del desarrollador.
Cron Jobs
Otra opción frecuente que vemos con una gran cantidad de datos de autocarga es cron. Para ello, podría ser cualquier cosa relacionada con cron. Lo que usted puede hacer es presionar el botón «Editar» para ver cuál es la causa. He aquí un ejemplo a continuación en que era evidente que «do_pings» estaba causando el problema. Nuevamente, una búsqueda rápida en Google reveló una solución rápida para limpiar do_pings.
Limpieza de la Tabla wp_options
Si usted está viendo un montón de lo que mencionamos anteriormente, entonces es probable que sea hora de una limpieza de todos los datos de autocarga en su tabla wp_options. También es recomendable que intente mantener el número de filas en la tabla wp_options a un mínimo. Por favor haga siempre copias de seguridad antes de eliminar datos de la base de datos. Si usted no se siente cómodo haciendo esto usted mismo, siempre recomendamos contratar un desarrollador de WordPress. Este es también un buen escenario donde un entorno de staging puede ser práctico.
Al igual que hicimos anteriormente, necesitará iniciar sesión en phpMyAdmin. Haga clic en la base de datos en el lado izquierdo y, después, en la pestaña SQL. Después, introduzca el comando siguiente y presione «ir».
SELECT * FROM `wp_options` WHERE `autoload` = 'yes'Es posible que tenga que modificar la consulta anterior si su sitio WordPress está utilizando un prefijo diferente distinto a wp_. Esto le mostrará todos los datos de la tabla wp_options que está en automática.
Desplácese hacia abajo, a través de las filas podemos ver todo tipo de plugins que ya no están instalados o utilizados en el sitio. Esto es sólo un ejemplo que vamos a utilizar, pero en este caso, hemos notado un montón de filas Jetpack. Jetpack ya no estaba siendo utilizado en el sitio web en cuestión.
Siempre es una buena idea comprobar la documentación del desarrollador del plugin ya que a veces tienen una opción para limpiar sus tablas dejadas atrás. En cuyo caso, a veces es más seguro y más fácil simplemente instalar nuevamente el plugin, compruebe su opción de limpieza automatizada y después, elimine el plugin correctamente. No obstante, le mostraremos cómo limpiar las tablas manualmente.
Así, en este caso, podemos ejecutar la siguiente consulta para encontrar los datos de autocarga en la tabla wp_options desde el plugin Jetpack. Para modificar la consulta con su propia, simplemente reemplace %jetpack%.
SELECT *
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%jetpack%'Después puede seleccionar todas las filas y hacer clic en «Eliminar».
O puede ejecutar el siguiente comando:
DELETE
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%jetpack%'Puede luego enjuagar y repetir la operación con los demás datos de autocarga que quedaron atrás de plugins y temas en la tabla wp_options.
Limpiar Transitorios
A menos que se esté utilizando una object cache, WordPress almacena registros transitorios en la tabla wp_options. Normalmente estos tienen un tiempo de caducidad y deben desaparecer con el tiempo. Sin embargo, ese no es siempre el caso. Hemos visto algunas bases de datos donde hay miles de antiguos registros transitorios. También es importante destacar que los transitorios no son cargados automáticamente de forma predeterminada. Puede utilizar una consulta como la siguiente para ver si hay algún dato de autocarga transitorio.
SELECT *
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%transient%'Sin embargo, una opción más segura y mejor sería utilizar un plugin gratuito como Transient Cleaner que puede limpiar solamente los transitorios expirados de su wp_options.
Limpiar Sesiones de WordPress
Otro problema común que hemos visto es que los cron jobs escapan de la sincronización o no desencadenan correctamente y las sesiones no se limpiadas. El resultado: toneladas de líneas de _wp_session_ en su base de datos. En este ejemplo abajo el sitio en cuestión se ahogó en más de 3 millones de líneas en su tabla wp_options. Y la tabla ha crecido hasta 600 MB en tamaño.
Podría usar una consulta como la que se ve abajo si tal problema surge.
En la mayoría de los casos puede eliminarlas (como un cron job haría) con el comando siguiente:
DELETE FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'Después de limpiar las sobras de las líneas de _wp_session_ rows la tabla contuvo mil líneas y el tamaño se redujo a 11 MB.
Al mismo tiempo los picos causados en MySQL se arreglaron.
Agregar un Índice al Campo de Autocarga
Y si la limpieza de la tabla wp_options no fue suficiente, usted podría intentar agregar un «índice» al campo de autocarga. Básicamente, esto le puede ayudar a buscar de manera más eficiente. El impresionante equipo en 10up realizó algunos escenarios de prueba en una tabla wp_options con un número típico de registros de autocarga para mostrar cómo añadir un índice de autoload a las consultas wp_options puede aumentar el rendimiento.
También recomendamos consultar estos dos recursos de WP Bullet:
