WordPress Cron, W3 Total Cache y alto consumo de CPU

433

WordPress cron, caso real: Si te ha pasado que tu hosting que envía una notificación de un alto consumo de CPU, por encima de los límites que el servicio, esto te puede ayudar.

Notificación de Hostgator

Básicamente me notificaban que se había producido un alto consumo de recursos en el servidor provocando una sobrecarga en la CPU por encima de los límites que el servicio que tengo contratado establece. Como resultado el acceso a mi sitio web había sido deshabilitado temporalmente hasta que las causas fueran investigadas. Genial lo que me faltaba ya… Al intentar acceder a mi sitio me encuentro una página con un diseño minimalista precioso: (Click en la imagen para agrandar)

503 Service Unavailable
Al instante me doy a la tarea de investigar que pudo haber pasado, el correo de Hostgator me da una pista, múltiples accesos al wordpress cron (wp-cron.php).

¿Pero cuántos accesos?

Muchos, 52860 para ser exactos.

Al revisar mis estadísticas de tráfico en Google no encuentro nada anormal pues el número de visitas era similar al de los últimos días.

Frustrado y sin saber que hacer me pongo a investigar un poco sobre este archivo wp-cron.php… ¿Qué es un cron? No es más que el nombre de un comando de UNIX para programar tareas que deben ser ejecutadas en algún momento futuro.

¿Para qué sirve el wordpress cron (wp-cron.php)?

Al ser WordPress multiplataforma este archivo permite que su instalación sea fácil sin importar el sistema operativo. Además este archivo entre otras cosas también permite:

  • Chequear automáticamente actualizaciones de WordPress, Plantillas y Plugins.
  • Publicar posts en una fecha futura.
  • Enviar pingbacks.

Sin dudas es un archivo importante… Pero tiene un “problemita” Cada vez que se solicita una página por un visitante WordPress realiza una llamada a este archivo para comprobar si hay alguna necesidad de que se ejecute. Con lo cual si el sitio tiene un alto número de visitas la cantidad de llamadas a este archivo será equivalente a la cantidad de visitantes y como consecuencia se produce un alto consumo en la CPU del servidor. (Click en la imagen para agrandar)

La solución al “problemita”

¡Deshabilitar este archivo! Pero si acabo de decir que es muy importante… Y lo es, la solución es lo que se conoce como “real cron” que no es más que liberar a WordPress de manejar el cron y pasar la tarea al servidor de hosting que está más capacitado para realizarla. Antes de pasar a la solución les muestro porque una vez más el servicio técnico de Hostgator es impresionante y es lo que me ha hecho preferir siempre a esta empresa antes que a otras. Resulta que yo al ser programador tengo conocimientos de UNIX suficientes y una vez investigado y encontrado el problema me di a la tarea de solucionarlo y luego envié un correo a Hostgator para ponerles al tanto de lo que había hecho para que eliminaran la restricción de acceso a mi sitio web. Sin embargo cometí un error al omitir un signo y los administradores de Hostgator lo notaron y me lo hicieron saber en su respuesta. Eso es atención al cliente. (Click en la imagen para agrandar)

Respuesta de Hostgator

Volviendo a la solución si usas el servicio de hosting de Hostgator solo tienes que acceder al panel de administración y en la sección “Avanzado” hacer click en Cron Jobs. (Click en la imagen para agrandar)

Hostgator Cpanel

En la siguiente ventana ir a “Agregar nueva tarea de Cron” y en el parámetro “Hora” seleccionar “Cada hora por medio…”. Es decir cada 2 horas se va a ejecutar el archivo wp-cron.php lo cual es suficiente. No obstante puedes poner más o menos tiempo a tu elección. En el cuadro de texto “Comando” ingresar lo siguiente y sustituir tusitioweb.com por tu nombre de dominio real. (Click en la imagen para agrandar) wget -q -O – -t 1 http://tusitioweb.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Agregar Cron

Este comando para quienes no saben de UNIX o Linux lo que hace es ejecutar el archivo wp-cron.php llamándolo desde el servidor y desviar la salida y cualquier error que se produzca hacia el directorio /dev/null. Durante mi investigación pude observar que muchos artículos en internet omiten las opciones –q, –O – y -t. Incluso el artículo al que hace referencia el correo enviado por los administradores de Hostgator omite la opción –t 1 aunque esta última es opcional. Les explico que hace cada una de ellas:

  • wget: Realiza la petición del archivo wp-cron.php. En castellano simple, descarga el archivo.
  • -q: Significa “quiet” o sea el proceso ocurre “tranquilo” o en segundo plano.
  • -O –: Registra toda la salida en stdout (Standard Output) la cual es redirigida a /dev/null
  • -t 1: Este es mi pequeño aporte ya que wget si se produce un error intenta por defecto realizar la operación 20 veces. Estableciendo –t 1 le decimos a wget que intente solo una vez y si no puede realizar la operación que emita el error correspondiente. Al eliminar 19 posibles intentos estamos eliminando carga del CPU. Al terminar debe quedarte algo parecido a esto: (Click en la imagen para agrandar)
Cron Terminado

Por último para desactivar el wordpress cron debes editar el archivo wp-config.php y al final justo encima del siguiente comentario: /* That’s all, stop editing! Happy blogging. */ Debes añadir la siguiente linea: define(‘DISABLE_WP_CRON’, true); Con eso queda desabilitado el archivo wp-cron.php en WordPress.

¿Y W3 Total Cache que pinta en todo esto?

Ay amigo, todo. Resulta que en parte el problema se hubiera podido evitar si yo no hubiese cometido un pequeño error la noche anterior.

Sino lo notaste, cuatro imágenes más arriba, en el correo donde me alertan del error en el comando de UNIX también el administrador de Hostgator se tomó la molestia de revisar el funcionamiento de mis plugins y encontró que W3TC estaba funcionando en modo “Preview” lo cual significa que realmente no estaba realizando su función.

Por lo tanto todo el tráfico de mi sitio estaba siendo manejado directamente por el servidor de hosting (Plan Baby de Hostgator). Al ser el tráfico elevado las llamadas al archivo wp-cron.php fueron elevadas (52860), se produjo un loop o ciclo que WordPress no pudo manejar y la carga del CPU aumentó por encima de los límites contratados trayendo como consecuencia que me inhabilitaran el acceso a la página. El error fue que estuve haciendo unas pruebas y puse W3TC en modo “Preview” y luego olvide volver a ponerlo activo. Otra vez gracias Hostgator porque yo ni me acordaba. Por si no lo sabes W3TC es un plugin que guarda en memoria cache todos los archivos estáticos de tu sitio web. Cuando un visitante busca tu página se le sirve la versión guardada en cache evitando así llamadas innecesarias al servidor. El resultado es un menor consumo de recursos y una mejora en los tiempos de carga de la página.

¿Qué aprendí hoy?

  1. WordPress en aras de poder ser instalado fácilmente en cualquier plataforma no realiza un trabajo muy eficiente permitiendo que el wordpress cron (wp-cron.php) se ejecute en cada visita al sitio web.
  2. Que la función que realiza dicho archivo debe ser manejada por el servidor de hosting y no por WordPress. Esto se conoce como “real cron”.
  3. W3 Total Cache es mucho más importante de lo que yo ya sabía y que tener un sistema de “caching” en WordPress es imprescindible.
  4. Mi plan contratado está llegando a sus límites de uso de CPU (un 25%) y solo se mantiene gracias a W3TC. Voy a pasar al plan superior en los próximos días (Business Plan).
  5. Que el servicio técnico y la atención al cliente de Hostgator son lo máximo. En realidad esto ya lo sabía.

¿Qué puedes hacer tú?

Si tienes un servicio de hosting compartido pues lo mismo que yo. Instala W3TC (arriba te puse el enlace a mi tutorial) y luego un real cron (arriba tienes los pasos). Con eso ayudaras a mantener los recursos del CPU en límites aceptables a medida que el tráfico hacia tu sitio web se incremente.

Mi consejo.

No te espantes solo porque usas un servicio de hosting compartido y quieras ahora mudar tu sitio a Amazon EC2 (Cloud Hosting). Lo mejor para bloggers y pequeñas empresas con poco presupuesto es agotar lo que tienen antes de pasar a un nivel superior y por supuesto más caro.

La secuencia ideal a medida que aumenta el tráfico hacia el sitio es la siguiente:

  1. Servidor Compartido. (Recomiendo Plan Baby de Hostgator, el que yo tengo).
  2. Servidor Compartido. (Recomiendo Plan Business de Hostgator, el que voy a tener en los próximos días).
  3. VPS (Virtual Private Server) Aquí tu tráfico empieza a ser bastante elevado.
  4. Servidor Dedicado. Aquí ya tu tráfico es bastante más elevado.
  5. Servidor en la Nube (Cloud Computing) con balanceo de carga. Amazon EC2, Windows Azure, etc. Ideal si tu sitio recibe visitas en el orden de las 5 o 6 cifras mensuales.

Por supuesto si lo que te sobra es dinero puedes pasar del paso 1 al 5 directamente. Amazon EC2 ofrece el plan micro gratis por un año pero una vez terminado ese año los costes se intensifican bastante. Sobre todo si usas mysql con EBS (Elastic Block Store) pero eso ya es otra historia. Espero que este artículo te sirva de ayuda y déjame saber tus opiniones y dudas en los comentarios.

¿Te ha resultado interesante este artículo?
También podría gustarte
Por favor espere, Cargando...
Do NOT follow this link or you will be banned from the site!