Para quienes somos usuarios de WordPress, la cuestión del rendimiento ha sido una preocupación constante desde que empezamos a saber de casos en que las compañías de hosting mostraban una evidente atención al elevado consumo de recursos de éste. Con el tiempo, hemos [aprendido algunas lecciones->WordPress y uso de CPU: algunas lecciones] y quizás nos hemos acostumbrado a la necesidad de prestar atención al [consumo de recursos->Todavía más sobre el consumo de CPU con WordPress]. Incluso, hemos visto como algunos personajes insignes, como Armonth o aNieto2K regularmente nos van ofreciendo consejos para ver algunas mejoras en este aspecto.
Con la publicación de WordPress 2.3, más de alguno se ha planteado la pregunta sobre la necesidad de actualizar, o incluso, de considerar alguna alternativa. Pero… ¿con qué vara podemos juzgar el rendimiento de WordPress?
En lo personal, no solo por lo anterior, sino también ante la curiosidad y “necesidad” de conocer otros CMS me he puesto a hacer algunas pruebas para evaluar su performance. En esta comparación voy a dejar de lado todos los demás aspectos, lo único que medí fue el rendimiento de seis sistemas de gestión de contenidos.
El escenario
Para facilitar las cosas, instalé XAMPP, versión 1.6.3b (al momento de escribir esto ya se puede descargar la 1.6.4), que incluye PHP 5.2.3 y MySQL 5.0.45
Los CMS testeados fueron:
- Drupal 5.2
- Habari 0.2DR
- NucleusCMS 3.24
- Serendipity 1.2
- Textpattern 4.0.5
- WordPress 2.3
Con la excepción de [Habari->WordPress y Habari], todos son proyectos que podríamos considerar bastante maduros en su desarrollo, aunque su popularidad no es necesariamente proporcional a aquello —con todo lo que ello implica para estos proyectos de código abierto/software libre en términos de comunidad.
Traté de igualar tanto como fuera posible las condiciones de la medición. Puesto que la idea de un CMS es precisamente gestionar y presentar contenidos, agregué a cada uno de ellos 7 posts llenos de [Lorem ipsum->@wikipedia]. Aparte de eso, no cambié ninguna otra cosa desde su instalación predeterminada.
La prueba fue realizada con ab: ab -c5 -t30 http://localhost/CMS/.
Cache y aceleradores
- De ellos, Drupal cuenta con un módulo de cache incorporado en la descarga inicial, con el que es posible seleccionar dos niveles, “normal” (recomendado para la mayoría) y “agresivo” (su funcionamiento dependerá de los módulos instalados); en este caso medí también su rendimiento con la modalidad normal de cache.
- Para WordPress instalé el archi-conocido WP-Cache, que también entró en la comparación. No tuve suerte con 1 Blog Cacher 2.0: ni siquiera en una instalación nueva lo pude hacer funcionar correctamente.
- No use módulos/plugins de cache con Habari, Textpattern, Serendipity ni Nucleus —con los dos primeros, simplemente no encontré ninguno (claro, debo aclarar que mi búsqueda fue bastante superficial, ya que el objetivo no era ver medir la efectividad de los módulos de cache); el plugin para Serendipity se encuentra en una fase bastante temprana de desarrollo, y en el caso de Nucleus, si bien existen plugins, son bastante antiguos (2005).
Los resultados
Vamos a la parte interesante.
| CMS | Complete requests |
|---|---|
| Drupal | 401 |
| Drupal + Normal Cache | 5029 |
| Habari | 597 |
| NucleusCMS | 1224 |
| Serendipity | 336 |
| Textpattern | 1084 |
| WordPress | 254 |
| WordPress + WP-Cache | 14108 |
Y bien… resulta que WordPress sale bastante mal parado por sí mismo, pero gana por lejos con WP-Cache activado.
Entre los restantes CMS, Nucleus y Textpattern se llevan los laureles; Drupal también merece una distinción por su módulo de cache incorporado, que si bien no produce una mejora tan impresionante como la de WP-Cache, es de todos modos considerable.
Como comentario, debo agregar que al medir el rendimiento de Habari en su instalación predeterminada (con sólo un post, sin más contenidos agregados), sus números también eran bastante promisorios: 1169 peticiones completadas. Al agregar más contenido el resultado fue el que ven publicado, disminuyó a alrededor de la mitad.
Finalmente, debo aclarar también que si bien traté de ser bastante riguroso, los resultados de esta medición no son de ningún modo concluyentes.