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.