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 y quizás nos hemos acostumbrado a la necesidad de prestar atención al consumo de recursos. 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, 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. 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.
14 Comments
Excelente articulo, esperaba que Habari saliera mejor parado contra wordpress
Interesante artículo pero un apunte personal (y algo offtopic) si hablas de “personajes” decir aNieto2k (que es su nick) vale pero no me pongas de nick el nombre de mi web que me hace raro xD ¡ah! ¡y es sin las www. ! :-P
Esperaba mejores resultados de drupal, jojo.
Es increíble el cambio de wordpress con un plugin.
Saludos
Hola Felipe,
¿Exactamente qué problema tuviste con 1 Blog Cacher?. Si ya tenías el WP-Cache no había más que subir los archivos y activar el plugin.
Saludos
No tenía instalado este plugin, ahora mismo lo instalo.
Excelente artículo, gracias.
Hola, tengo una preguntita…
El numero de request son por minuto no?
Son siempre al home o aleatorias?
Nos podes tirar las caracteristicas de tu pc para tener una idea :P
GRacias y excelente articulo!
¡Guau! ¡Reacciones! Vamos por partes:
Las características de hardware: Intel Core Duo T2250, 1 GB RAM, el disco es una partición ReiserFS, sobre Ubuntu 7.04
Heché de menos Xaraya[1] en la comparación. Excelente review!! ;-)
[1] http://www.xaraya.com
Muy interesante :D
GRacias
Ok, muchas gracias Felipe :)
el plugin para poner una cache al Nucleus es este:
http://forum.nucleuscms.org/viewtopic.php?t=16040
el autor original (moraes) lo presentó en este post:
http://forum.nucleuscms.org/viewtopic.php?t=11494
El plugin andaba un poco abandonado pero yo lo he retomado/actualizado. Los últimos cambios son de hace unos meses. Tengo pendiente corregir alguno de los bugs pero nunca me pongo a ello O:)
Muy interesante la comparativa. Por si te resulta de interés, aquí he ampliado la prueba con un plugin de Cache para Textpattern: http://www.textpatternmania.com/2007/10/22/sistemas-de-cache-en-txp-y-wordpress
Ola.! Ano Novo Feliz
En cuanto a drupal, hay que añadir que la cache que viene por defecto es bastante básica, y deja llamadas a la base de datos abiertas, lo que baja mucho el rendimiento.
El módulo boot (http://drupal.org/project/boost) mejora mucho el rendimiento original, puesto que crea una versión estática y “cierra el grifo” de llamadas a la base de datos.
Un saludo.
9 Trackbacks
[...] comenta más detalladamente la gráfica. Compártelo « 40 consejos para optimizar tu código [...]
[...] ha hecho un análisis de algunos de gestores de contenido muy populares de la red. WordPress, Drupal, NucleusCMS, TextPattern… Los resultados son [...]
[...] Para que vean como llego a estos resultados, los invito a que visiten su articulo en mas detalle. [...]
[...] Evaluación del rendimiento de algunos CMS: Drupal 5.2, Habari 0.2DR, NucleusCMS 3.24, Serendipity 1.2, Textpattern 4.0.5, WordPress 2.3. Vía. [...]
[...] interesando, sobre la comparación de algunos CMS más importantes. La evaluación estubo acargo de Felipe Lavin (Yukei) quien mostror una grafica con los resultado. [...]
¿Hay alternativas a WordPress?…
Felipe Hernán en Yukei.net realiza una comparación del rendimiento de WordPress y otros cuantos sistemas de publicación de blogs. La conclusión de este estudio es que WP mejora sustancialmente si va acompañado del plugin wp-cache. ¿Y cómo podemo…
[...] Yukei nos brinda una prueba sencilla de rendimiento de varios CMS para construir blogs. [...]
[...] publica un excelente artículo en el que repasa el rendimiento general de los CMS más utilizados. Un tema muy en cuenta entre los [...]
Acelerando WordPress…
Wordpress es el gestor de blogs más usado hoy en día. Es un sistema genial con muchísima flexibilidad para desarrollar fácilmente todo tipo de módulos y temas. Pero su rendimiento por defecto es muy bajo.
Si alguien usa un hosting sencillito y apa…