Cubo-S: Mi Content Management System

En un post anterior explicaba mi framework: BlackAugust, ahora toca turno a Cubo-S, mi Sistema Administrador/Gestor de Contenidos (CMS); un CMS que está desarrollado usando BlackAugust, por supuesto. En los post's Sobre y BlackAugust doy mis razones del porqué uso un desarrollo propio en lugar de usar uno de los tantos CMS's y framework's disponibles, de esos: buenos, gratuitos y de código libre... por lo que no voy a redundar en este tema y me centraré en las cosas que hacen tan particular este sistema, que -entre otras cosas- son: características, desarrollo y rendimiento de CMS::Cubo-S. Este tipo de cuestiones harán que este sistema sea en algunos casos: una opción irrelevante, en algunos otros una opción ideal y en otros sencillamente una opción más.

Características de Cubo-S

Algunas de las características más trascendentes de Cubo-S son:

• Ligero: Uno de los principales problemas de los CMS actuales es, a la vez, una de sus principales cualidades... el soporte de: themes, plugins, idiomas, bloques, módulos, hacks, etc. Todo ese soporte extra pasa factura, sistemas como estos pronto requieren de optimizaciones, optimizaciones como uso de caché o servidores dedicados. Cubo-S soporta estas características un tanto más `nativas`, es decir, más integradas en su sistema, esto significa dos cosas:
  A. La incorporación de nuevas características está lejos de bajar un módulo y activarlo con un clic, aka: lejos de ser algo simple y sencillo.
  B. El consumo de recursos por extra agregado es muy inferior que hacen en otros CMS.
• ImageMagick Procesamiento Gráfico: Heredando la funcionalidad de su framework BlackAugust, este CMS procesa las imagenes (como para generar miniaturas) usando -predeterminadamente- bajo ImageMagick, generando miniaturas de gran calidad, así como posibilidad de incluir marca de agua automáticamente a las fotos subidas; se incluye soporte para el uso de las Librerías GD, sin embargo, se usan exclusivamente en caso de no estar disponible ImageMagick.
• CMS/Framework: Al igual que drupal, funcionan como excelentes frameworks, es decir, es un CMS base que puede extenderse para cubrir las necesidades requeridas, siempre con las mismas cualidades en rendimiento.
• Soporte nativo para el juego de caracteres UTF-8 (MultiByte String).
• Soporte para generación de feed's RSS.
• Soporte para caché en dos niveles, característica aún en desarrollo.

Cubo-S en desarrollo constante

Al momento de redactar este post (o intentarlo), Cubo-S se encuentra en etapa de desarrollo βeta... es plenamente funcional, que de hecho se está usando ya en dos sitios, todavía necesita ser pulido un poco más, siempre se puede mejorar el consumo de recursos y extender las funcionalidades.

Por otra parte... este CMS solo cuenta con un desarrollador (yo), estará en constante actualización, desarrollo, adoptando todo tipo de funcionalidades de moda, olvidando funcionalidades: anticuadas, viejas, innecesarias y sin utilidad.

Rendimiento de Cubo-S versus otros CMS

A continuación haré una pequeña comparación de Cubo-S, Drupal, Joomla! y WordPress, esto con el fin de acentuar el tema de rendimiento de estos cuatro CMS. Cabe destacar que esta prueba es simplemente `con fines educativos`, no significa nada en si misma, especialmente porque los cuatro sistemas pueden ser optimizados hasta un punto que no representen una carga al servidor, de esto se puede agregar que los tres sistemas basados en software libre tienen un soporte bestialmente superior a mi CMS.

¿Cómo se realizaron las pruebas?

Obviamente, todas las pruebas se realizaron en las mismas condiciones:

• Laptop: Core2Duo 1.8GHz, 2GB ram, Win7 Ultimate 32bits.
• Servidor: Apache/2.0.59 (Win32); PHP/5.2.3; MySQL 5.1.17-beta-community-nt-debug.
• PHP configurado como módulo de Apache.
• Los sistemas de software libre se ejecutaron después de su instalación, los tres no cargaron nada que no se haya incluido en su instalación por default (con excepción de Drupal, a éste le active el módulo Path, incluido en el mismo paquete de instalación), así como los tres corriendo en idioma inglés.
• En todos casos se uso el mismo post, que a la vez era el único, un post: solo texto, sin formato especial y de 3190 caracteres.
• En todos los casos el sistema solo tenía un usuario registro, el de la instalación (aunque Drupal y Cubo-S incluyen un usuario extra por default).
• En todos los casos se ejecuto tres veces la parte medida y el tiempo se promedio, esto debido a que siempre hay ligeras variaciones.

Respecto a la forma en que se contabiliza el tiempo y la cantidad de consultas a la DB:

• En los casos Drupal y WordPress:
  index.php Se agregó al inicio (un espacio después de la tag: <?php) un código que guardaba tres variables: el tiempo (con microsegundos) e inicializaba dos contadores en cero (para consultas y ejecuciones).
  Se edito el archivo class correspondiente a la capa de base de datos MySQL (`includes/database.mysql.inc` en el caso de Drupal y `wp-includes/wp-db.php` en el caso de WordPress) a la cual, en su función respectiva al Query, se agrego la condición: preg_match('/^(\s*SELECT+?)/i',$query) para detectar si eran consultas o ejecuciones (UPDATE, DELETE, INSERT, etc.).
  Y al final del archivo index.php se imprimían los resultados.
• En el caso de Joomla! solo se pudo contabilizar el tiempo.

1. RESULTADOS, Mostrando la portada.

• Cubo-S Consultas: 7 Ejecuciones: 1 Tiempo: 0.068s
• Drupal Consultas: 42 Ejecuciones: 0 Tiempo: 0.246s
• Joomla! Consultas: NA Ejecuciones: NA Tiempo: 0.368s
• WordPress Consultas: 17 Ejecuciones: 0 Tiempo: 0.401s

2. RESULTADOS, Mostrando únicamente el post.

• Cubo-S Consultas: 7 Ejecuciones: 1 Tiempo: 0.079s
• Drupal Consultas: 42 Ejecuciones: 1 Tiempo: 0.248s
• Joomla! Consultas: NA Ejecuciones: NA Tiempo: 0.362s
• WordPress Consultas: 17 Ejecuciones: 0 Tiempo: 0.337s

3. RESULTADOS, Mostrando un post con 50 comentarios.

• Cubo-S Consultas: 8 Ejecuciones: 1 Tiempo: 0.226s
  Esta prueba no la había realizado antes, la primera vez que la hice tuvo un pésimo desempeño, apenas alcanzaba poco más de 3s de tiempo, realmente un desastre, tuve que ver la falla para corregirla y optimizarlo hasta el tiempo mencionado.
• Drupal Consultas: 42 Ejecuciones: 1 Tiempo: 0.43s
• Joomla! Consultas: NA Ejecuciones: NA Tiempo: NA
  No encontre niguna opción para habilitar los comentarios, tampoco encontré ningún módulo o plugin en el paquete de instalación para tal efecto, por tanto este sistema no `concurso` en esta prueba.
• WordPress Consultas: 17 Ejecuciones: 1 Tiempo: 1.17s

Como mencionó en el punto sobre mi sistema, inicialmente tuvo un desastroso desempeño, alcanzando un tiempo de más de 3s, tuve que revisar su código y desmenuzarlo para darme cuenta de cuál era el problema, era el motor de bbcode, el que sirve para convertir a negritas, cursivas, tachadas y la conversión de url en links, esta funcionalidad la hago usando expresiones regulares con preg_replace, tuve que mejorarlas para pasar de ese 3s+ a 0.226s. Quitando esta funcionalidad el tiempo se mantenía muy apenas pasando los 0.11s, me parece curioso el caso de WordPress que no hace uso de expresiones regulares para este tipo de cuestiones y aún así el consumo de recursos incrementa exponencialmente al agregar cada comentario.

Conclusión

Cubo-S es un sistema nuevo, se podría decir que inmaduro, tiene rivales muy difíciles, con años de experiencia, con un ejercito de desarrolladores y toneladas de soporte a modo de: foros, plugins, themes, idiomas, etc. Sin embargo, creo yo que mi sistema va excelente para el tiempo que lleva, para el hecho que solo es un desarrollador el que está detrás de este proyecto. En un tiempo más será un opción bastante real, debe tener la altura para competir con los grandes (con excepción de Joomla!, que siempre lo eh considerado como PHPNuke 1.1).

Otro punto es que Cubo-S no tiene activada ningún tipo de caché, algunos de los CMS anteriores si hacen uso de esta característica (cachés parciales), la caché da un buen tanto de rendimiento extra, el framework en el que está basado mi CMS soporta dos niveles de caché, activando la caché de primer nivel se ganaría un buen tanto de rendimiento, activando la segunda... el consumo de recursos se reducía un 90%+, el segundo nivel de caché consiste en guardar las páginas en modo HTML puro y servirlas sin necesidad de cargar PHP, algo muy parecido a lo que hace el plugin SuperCache de WordPress, sin embargo, este nivel aún está en desarrollo.

Y por supuesto que....