Cada plugin que se agrega a un sitio WordPress impacta en el tiempo de ejecución y en las consultas a la base de datos. En este tutorial explicamos cómo identificar el origen del tiempo de ejecución y, con esa información, usted y nuestro equipo de soporte de WPML podrán reconocer los cuellos de botella y mejorar el desempeño del sitio web.

Instalar y activar el plugin Debug Objects

Utilizaremos el plugin Debug Objects para ver y entender las consultas a las bases de datos necesarias para el funcionamiento de su sitio web. Debug Objects muestra un detalle pormenorizado de las búsquedas que se ejecutan sobre cada página del sitio. Esta salida está disponible solo para usted cada vez que inicie sesión como administrador; los visitantes no tienen acceso a la información de depuración.

Para instalar el plugin, vaya al panel de WordPress y seleccione Plugines en el menú de la izquierda y luego Agregar nuevo. En el campo de búsquedas, ingrese “debug objects” y pulse retorno.

En la pantalla de resultados de la búsqueda, haga “clic” en el botón Instalar ahora:

Instalar el plugin Debug Objects
Instalar el plugin Debug Objects

Luego que la instalación esté completa, active el plugin.

Alternativamente, puede descargar Debug Objects directamente del repositorio de WordPress y subirlo a su servidor en wp-content/plugins. Luego, puede activarlo desde la página Plugines en el administrador de WordPress.

Inhabilitar Xdebug

Si no está familiarizado con Xdebug, puede saltear esta sección. Si está utilizándolo, asegúrese de inhabilitarlo antes de realizar pruebas de desempeño. Xdebug generará una carga importante en el servidor, por lo cual todos los resultados se mostrarán sesgados. Interiorícese de cómo inhabilitar Xdebug.

Configurar Debug Objects para analizar consultas SQL

Primeramente, agregue esta línea a su archivo wp-config.php (este archivo está en el directorio principal de la instalación de WordPress):

define( 'SAVEQUERIES', TRUE );

Ahora vaya a Herramientas -> Debug Objects e inhabilite todas las opciones excepto DB Query:

Configurar Debug Objects
Configurar Debug Objects

Vaya al final de la página y presione el botón Guardar.

Verificar la salida del depurador

Luego de activar y configurar correctamente el plugin, es posible comenzar la depuración. Mientras ha iniciado sesión como administrador en WordPress, visite cualquier página que presienta que tienen problemas de ejecución (si este es el caso de muchas páginas, elija la más problemática) y presione el enlace Objects en la barra del menú del administrador en la parte superior:

Enlace de Debug Objects
Enlace de Debug Objects

Podrá ver tres pestañas con la información de depuración:

Salida de Debug Objects en tres pestañas
Salida de Debug Objects en tres pestañas

Cómo leer y entender la salida del depurador

En esas tres pestañas se puede ver mucha información, pero tan solo una parte es relevante para nosotros y para el plugin WPML. En términos generales, solo estamos interesados en dos cosas:

  • Consultas muy lentas: en algunas ocasiones, mucho del problema de desempeño se debe a unas pocas consultas que insumen un tiempo muy largo de procesamiento.
  • Muchas consultas repetidas: en otras ocasiones, no hay consultas lentas sino muchas consultas rápidas que, tomadas en conjunto, insumen un tiempo muy largo de procesamiento.

Identificación de consultas lentas

Vaya a la primera pestaña, denominada DB Queries, y realice una búsqueda de la consulta más lenta. El plugin Debug Objects contribuye resaltando con un borde naranja las consultas que requieren más de 0.5 ms:

Consultas lentas
Consultas lentas

Debajo de la cadena de la consulta se puede ver el nombre de la función que la originó. Sin embargo, esto puede resultar engañoso dado que la pestaña muestra solamente la última función de la pila completa de ejecución, por lo que no podemos estar seguros de si la misma se originó en el núcleo de WordPress o en algún plugin (o qué plugin la ejecutó).

Verificar si la consulta se originó en el plugin WPML

Copie la consulta lenta (ctrl+C) y seleccione la pestaña dos, denominada Plugin DB queries. Podrá ver algunas tablas con consultas, organizadas de acuerdo a los nombres de los plugines, y los archivos a través de los cuales pasó la consulta. Si el plugin WPML participó en la ejecución de dicha consulta, aparecerá en la tabla correspondiente.

Presione “ctrl+F” y luego “ctrl+V” para pegar la consulta copiada.

Esta acción iniciará una búsqueda de la consulta seleccionada dentro de esa tabla. Probablemente verá más de un resultado. Para navegar entre ellos, presione la tecla F3.

Para cada resultado, verifique si el mismo aparece registrado en la tabla localizada bajo uno de los plugines de WPML. Si la respuesta es afirmativa, registre:

  • nombre del plugin,
  • el archivo que la ejecutó,
  • y el número de línea en el archivo (primera columna en la tabla).

Detalles de la consulta
Detalles de la consulta

Consultas regulares de WPML y otros plugines y de Temas

Algunas consultas pasan a través de otros plugines y Temas, así como del plugin WPML. Por ejemplo: la traducción de cadenas de WPML proporciona servicios de traducción para cadenas localizadas en el núcleo de WordPress, en los temas y en otros plugines. Si el plugin de traducción de cadenas está presente en la lista de consultas a la base de datos, significa que WPML necesita traducir muchas cadenas diferentes de su sitio.

En ese caso, la consulta lenta aparecerá en la pestaña de consultas de Plugin DB bajo el nombre de nuestro plugin, así como también en las próximas tablas relacionadas con otros plugines o en la pestaña tres: Consultas a la base de datos de contenido de WP. Verifique esta ocurrencia antes de informar sobre una consulta lenta en nuestro foro. Si la misma consulta aparece en la tercera pestaña, registre el nombre del archivo que se indica en dicha pestaña. De esa forma, podremos identificar si un Tema en particular está involucrado en la ejecución de esta consulta lenta y su identidad.

Informar los resultados en el foro técnico de WPML

Cuando haya registrado toda la información relevante acerca de la consulta lenta, cree un informe en nuestro foro explicando el problema. Incluya la información siguiente:

  • la consulta lenta y cuánto tiempo insume su ejecución.
  • dónde se encuentra esta consulta en la segunda pestaña del registro de depuración. Si está ubicada en el plugin WPML y, en dicho caso, los archivos involucrados y sus números de línea.
  • dónde se encuentra esta consulta en la tercera pestaña, así como el nombre del archivo y su número de línea.

Copie el contenido de cada pestaña y compártalo con nosotros utilizando Pastebin.

Para lograr esto:

  1. vaya al foro de soporte técnico de WPML e inicie una hebra nueva. Describa el problema de desempeño percibido y dónde podemos verlo.
  2. abra la primera pestaña de los resultados de Debug Objects.
  3. seleccione el contenido de dicha pestaña. Asegúrese de incluir todo dentro de “consultas”, incluyendo la sección de “errores” y la lista completa de consultas.

    Selecciones todas las consultas
    Seleccione todas las consultas.

  4. copie (ctrl+C) la selección.
  5. vaya a pastebin.com, pegue (ctrl+V) la selección dentro del área de texto y presione el botón “Enviar”.

    Pegar en Pastebin
    Pegar en Pastebin

  6. copie la dirección URL de la barra de direcciones del navegador.

    Copie la dirección URL Pastebin
    Copie la dirección URL Pastebin

  7. pegue la dirección de Pastebin en la hebra de soporte.
  8. repita los pasos 2 a 6 con el contenido de las otras dos pestañas.

Con esto, nuestro personal de soporte sabrá el sitio web al que se hace referencia y qué páginas se cargan lentamente. Podrá ver la lista completa de consultas en ejecución y contribuir a identificar la causa del problema. Si el problema está en WPML, buscaremos una solución y, eventualmente, mejoraremos la versión. Si el problema radica en el Tema o en un plugin, nos podremos en contacto con los autores y haremos nuestro mejor esfuerzo para solucionar el inconveniente.


Apéndice: inhabilitar Xdebug

Xdebug es una extensión PHP que permite depurar problemas de código. Cuando se utiliza apropiadamente, contribuye a analizar la fuente de los problemas de desempeño.

Cuando está activo, agrega una carga considerable de trabajo al servidor porque captura lo que está sucediendo en tiempo real. Por esta razón, Xdebug NUNCA debe estar operativo al momento de medir desempeño. En caso contrario, obtendrá una medición errónea. La mayor parte del informe corresponderá a Xdebug y no al código que se está controlando.

La forma correcta de depurar temas de desempeño con Xdebug es medir sin Xdebug, obtener los resultados y luego encontrar el problema de la fuente de desempeño por medio de Xdebug.

Xdebug puede estar activo en el servidor incluso si no se está midiendo su salida. Esto sucede con frecuencia cuando se habilita Xdebug para algún proceso de depuración y se deja habilitado, pensando que está inactivo.

Para asegurarse de que está inactivo, se debe observar la salida de phpinfo().

Xdebug se muestra en la salida de phpinfo
Xdebug se muestra en la salida de phpinfo (malo para control de rendimiento)

Si desea inhabilitar Xdebug, elimínelo o márquelo como comentario en php.ini o conf.d/xdebug.ini:

zend_extension=xdebug.so

Eliminarlo, ¡no agregar la línea de arriba!

Así debe lucir phpinfo cuando Xdebug está inactivo:

phpinfo cuando Xdebug está inactivo (bueno para control de rendimiento)
phpinfo cuando Xdebug está inactivo (bueno para control de rendimiento)

Tan pronto como se hayan eliminado todas las referencias a Xdebug, se habrá desactivado para siempre.

Si alguna otra sección de ese archivo phpinfo contiene referencias a Xdebug, no tiene relevancia mientras no se muestren como una extensión cargada al inicio.