Todavía más sobre el consumo de CPU con WordPress

Una nueva revisión de factores que pueden influir en el tiempo de procesamiento en sitios web gestionados con WordPress

Muchos de quienes utilizamos WordPress sabemos que una de las preocupaciones a tener en cuenta es el consumo de CPU, un tema que ha dado para más de algún post —como aquellas [lecciones aprendidas->WordPress y uso de CPU: algunas lecciones] hace algún tiempo o el segundo round de soluciones publicadas más recientemente.

Revisión de factores que influyen en el consumo de CPU

A fines de enero, Alex King publicaba un artículo en el que se preguntaba si tras la reconstrucción de su sitio se encontraba recurriendo a demasiados plugins, cuestión sobre la que existe consenso como uno de los factores que aumentan el consumo de CPU.

En éste, King llamaba la atención sobre dos mediciones que, en principio, podrían darnos una pista del tiempo de procesamiento necesario para crear una página: el número de consultas a la base de datos (queries) y el “tiempo de generación” (load time), información que a veces es posible encontrar al pie de página de varios themes (de forma visible o marcado como comentario XHTML). Por ejemplo, en Hemingway encontramos este código:

<!--
<?php echo get_num_queries(); ?> queries.
<?php timer_stop(1); ?> seconds.
–>

En la conversación desarrollada en los comentarios surge la pregunta evidente: ¿según qué parámetros juzgar el número de consultas y el tiempo de generación?, es decir, es bastante difícil (por no decir imposible) establecer límites con los cuales comparar tus propias mediciones.

Por otra parte, he detectado una contradicción a la suposición que sustenta la hipótesis de que un número “alto” de consultas y tiempo de generación significa un mayor gasto de CPU, ya que desde [mi cambio de theme->¡Perestroika!] he seguido atentamente estas medidas y los reportes de consumo de recursos de DreamHost. La cuestión es la siguiente: el tema actual supone un mayor número de consultas y tiempo de generación, pero los reportes de consumo de recursos bajaron significativamente —con [Satori->], los reportes de consumo de recursos rondaban los 1800 segundos diarios mientras que con el tema actual han bajado a alrededor de 1000.

Desde el cambio, el número de visitas ha aumentado y los plugins utilizados son los mismos, por lo que no podrían explicar esta diferencia. Entonces ¿qué podría hacerlo? Se me ocurren las siguientes posibilidades:

  • La utilización del WordPress Theme Toolkit para controlar algunas opciones del theme —es esperable que se requieran más recursos para leer las opciones desde la base de datos a que si estuvieran explícitas en el código del theme
  • La utilización de archivos “incluídos” vía php include.

Si alguien tiene más datos al respecto, sería buena idea poder sistematizarlos en una guía para optimizar el rendimiento de themes para WordPress.

Ajustando WP-Cache

El plugin WP-Cache 2.0 es una de las medidas más fáciles y efectivas que tomar para controlar el consumo de CPU en sitios con WordPress —para los que todavía no lo conocen, lo que este plugin hace es que en la primera vez que un usuario ve una página (post, categoría, archivo) creada por WordPress, almacena una copia estática (o sea, tal como se ve tras haber sido procesada en PHP). La segunda vez que alguien desea ver esa página, en vez de volver a construirla, sirve la copia estática, con lo que se ahorra bastante tiempo de procesamiento y consultas a la base de datos.

Aumentar el tiempo de expiración…

Una de las opciones de WP-Cache permite fijar el “tiempo de expiración” de las copias estáticas creadas por el plugin, es decir, tras cuánto tiempo se considerará que esa copia estática debería volver a construirse.

El valor predeterminado del plugin es de 3600 segundos (o sea, una hora), lo que está bien para blogs con una alta frecuencia de posts o comentarios, pero si este no es tu caso, aumentar el tiempo de expiración de las copias estáticas no es una mala idea, puesto que el consumo de recursos y el tiempo de respuesta de tu sitio puede disminuir considerablemente.

Hasta donde he podido observar, aumentar esta opción hasta valores ridículamente altos (por ejemplo, ahora lo tengo en 180.000 segundos, es decir, 3.000 minutos o 50 horas) no debería causar ninguna dificultad, ya que el plugin es lo bastante “inteligente” como para determinar qué páginas re-generar y cuándo es apropiado hacerlo… bueno, casi.

… manteniendo tus páginas actualizadas

Decía casi porque en la práctica hay una importante excepción, y es que al usar Spam Karma junto a WP-Cache, este último no refresca las páginas tras la aprobación de un comentario.

Afortunadamente, alguien creó un plugin para “compatibilizar” Spam Karma y WP-Cache que indica directamente a WP-Cache que es necesario refrescar la copia cacheada.

7 thoughts on “Todavía más sobre el consumo de CPU con WordPress

  1. buen post felipe.

    igual creo que Spam Karma en sí es bastante pesado. se mete en el SQL y los PHP son bien grandotes. para protegerse de tamaña amenaza como lo es el SPAM, creo que la pega la cumple mejor Akismet.

    sólo una opinión. 🙂

  2. Sí, es pesadote, igual que Bad Behavior (que utilizaba antes de él) pero un poco menos… aparte que guardan mucha información desechable en la base de datos, por lo que se hace necesario optimizarla periódicamente

    Akismet… lo ocupé un tiempo pero no me funcionaba tan bien, me parece que su rendimiento es bastante relativo ya que a varias otras personas les he escuchado comentarios muy buenos; en mi caso, marcaba demasiados falsos positivos, y tener que revisar la lista de comentarios no me hacía mucha gracia

  3. Excelente artículo Felipe, en mi caso particular la combinación de Akismet + Comments Policy ha disminuido en casi un 90% el Spam y mi dolor de cabeza es el tiempo de carga de mi blog.

  4. Yo trato de usar pocos plugins. Mi problema son los hacks truchos que me hice =)
    Lo que trato de hacer es ocupar más caché (en css y javascript) e intentar evitar mucha consulta a mySQL.

    En cuanto al Spam, te recomiendo seriemante Akismet. Al principio también me dió un par de problemas, pero hoy trabaja como reloj, sin contar que es menos intrusivo para el usuario, y más relajado para tu instalación.

  5. ENCUENTRO MUY UTIL TU BLOG …..
    MIRA QUE EN LOS ULTIMOS MESES AL COMPAS DE LA SUBIDA DE MI TRAFICO SURGIERON INFINIDAD DE PROBLEMAS CON MI BLOG QUE ES SACADO DE LOS SERVIDORES POR QUE CONSUME LA BASE DE DATOS Y BLOQUEA EL SERVIDOR POR LO QUE LO SACAN DEL AIRE Y QUE DO SIN BLOG …
    LOS DEL HOSTING ME DICEN QUE SON MUCHOS ENLACES A LA VVVEZ Y QUE POR ESTO MAS DE 200 ENTRADAS POR SEGUNDOS CONSUMEN EL SERVER …
    NO SE MUCHO DE ESTO EN MIS ESTADISTICAS SIGUE IGUAL AHORA DESPUES DE UNA SEMANA POR FUERA SIGUE CON ERRORES DE CONEXIÒN AL INTENTAR ENTRAR AL BLOG Y AL ADMINISTRADOR…..
    HERMANO ME DICEN QUE LA SOLUCIÒN ES UN SERVER DEDICADO PERO NO CREO TENER UN BLOG TAN VISITADO PARA ESTE MENESTER …
    POR LOCUAL ME ENCUENTRO AQUI LADRANDO E IMPLORANDO
    PUES REQUIERO AYUDA PARA NO TENER QUE SACAR MI BLOG DEL AIRE

  6. Ola ! Que tal ? … and that’s about all I know in spanish 🙂

    The use of my WordPress Theme Toolkit has absolutely no impact on speed or db usage :
    – its modifications are only for the admin area, for readers things are exactly the same if a theme uses an admin menu or not
    – it adds no queries, be it for readers or in the admin area
    – no matter how options you have, they are all fetched at once in one query during init time

    From what I see here, 42 queries is pretty standard. And 0.31 seconds is pretty fast.

Comments are closed.

%d bloggers like this: