Cherokee - Alternativa a Apache open suerce

Características

• Es software libre, publicado bajo la licencia GPL (General Public License).

• Escrito en C, unas 50.000 líneas de código.

• Es un proyecto que desarrolla una nueva implementación de este tipo de aplicaciones.

• El fin último de Cherokee es hacer un servidor con unas características de las que Apache carece debido a su diseño original.

• Su diseño es un híbrido que combina las características de servidores basados en sockets no bloqueantes con las de servidores basado en hilos, en busca de obtener beneficios de ambos modelos y minimizar los aspectos negativos.

• Básicamente, su funcionamiento es el de un servidor que procesa varias peticiones en cada uno de sus hilos. Estos hilos ni se crean ni se destruyen, se generan cuando arranca el servidor y permanecen vivos hasta que termina su ejecución.

• En su implementación, se ha puesto especial interés en la velocidad, flexibilidad y capacidad de ser empotrado.

Velocidad: en el último benchmark (técnica utilizada para medir el rendimiento de un sistema, frecuentemente en comparación con algún parámetro de referencia) realizado hasta el momento, Cherokee fue cinco veces más rápido que Apache. Lo vemos:

Figura 2

Flexibilidad: Cherokee, igual que Apache, dispone de un sistema para la carga dinámica de módulos basado en plug-ins, tanto para manejadores (handlers) como para codificadores (encoders) y sistema de logging.

Capacidad de ser empotrado dentro de otras aplicaciones. Todo el código se encuentra en una librería dinámica (libcherokee) que puede utilizar cualquier aplicación. El API de esta librería es muy sencillo; básicamente permite crear, configurar y ejecutar diferentes formas objetos “servidor”.

• Al igual que Apache, Cherokee escala a servidores SMP (Symetric Multi-Processing. Sistemas con varios procesadores) y a sistemas multihilo. Es capaz de manejar más de un hilo y en cada uno de ellos, de nuevo, volver a procesar conexiones mediante compartición de tiempo.

Arquitectura

Hay tres grupos de módulos cargables: handlers, encoders y validators.

• Handlers. Son manejadores de peticiones. Cuando el servidor procesa una petición, decide que clase de manejador debe utilizar. Dependiendo del módulo, la respuesta será una u otra.

Tipos de manejadores: files (servir ficheros al cliente), redir (redireccionar peticiones), Cgi’s, etc.

• Encoders. Módulos que implementan una funcionalidad de conversión de la información que se puede enviar a los clientes si estos lo soportan. Cherokee puede enviar ciertos elementos de una página Web comprimidos para dotar de mayor rapidez de respuesta. El encoder más útil es el de GZip (explicar)

• Validators. Módulos que implementan posibles formas de validar al usuario. Actualmente se puede validar con LDAP (no incluida en Cherokee por defecto), PAM y htpasswd.

Flujo de una petición

Figura 3

Básicamente, la secuencia de ejecución es idéntica a la del servidor Web Apache.

Fijémonos que los subsistemas de recepción, de análisis de la petición y de registro cumplen la misma función que en Apache.

El resto de subsistemas (control de acceso, handlers o “manejadores” y encoders) se cargarán dinámicamente*, es decir, no hace falta modificar el código fuente de Cherokee, simplemente lo especificaremos en los archivos de configuración. Por ejemplo, si nuestro sitio Web sólo sirve ficheros PHP sin autentificación alguna, Cherokee hará uso del handler para scripts php más los tres subsistemas “fijos”. Los demás módulos no se tendrán en cuenta, ocupando así mucho menos espacio en memoria.

*Esta técnica se define como carga dinámica de módulos basado en plug-ins. Cada modulo es considerado como un subproceso del servidor Web. Esto hace que su diseño sea lo más modular posible y de este modo, cualquier nueva característica será implementada como módulo cargable.

Esta arquitectura modular ha sido elegida para permitir cargar y ejecutar únicamente las partes y funcionalidades que sean necesarias en cada caso concreto. De esta forma se ahorran recursos, se aumenta la seguridad (menos código en ejecución implica menos posibilidad de existir un bug en él) y se disminuye ligeramente la carga del servidor Web.