PDF de programación - Proyecto Cherokee: Diseño, implementación y aspectos de rendimiento de servidores web

Proyecto Cherokee: Diseæo, implementaci(cid:243)n y

aspectos de rendimiento de servidores web

Alvaro L(cid:243)pez Ortega <[email protected]>

1

Abstract(cid:151) Este art(cid:237)culo presenta los aspectos cr(cid:237)ticos que
intervienen en el desarrollo de un servidor web. En primer
lugar, se exponen los diferentes diseæos clÆsicos, detallando las
caracter(cid:237)sticas de cada uno de ellos y estudiando sus mejoras;
exponiendo en œltimo lugar el diseæo realizado en el servidor
web Cherokee.

A continuaci(cid:243)n, se estudian mØtodos para la implementaci(cid:243)n
de un servidor de alto rendimiento, as(cid:237) como posibles puntos de
mejora y aspectos del desarrollo para lograr un funcionamiento
mÆs e(cid:2)ciente.

Por œltimo se presentan datos detallados sobre el rendimiento
de cada uno de los principales servidores web libres y sus respec-
tivas arquitecturas, as(cid:237) como su comportamiento en diferentes
escenarios. Estas pruebas presentan la e(cid:2)cacia real de cada
servidor y por lo tanto de su arquitectura.

Index Terms(cid:151) servidor web, diseæo, rendimiento, Cherokee

I. INTRODUCCI(cid:211)N

D ESDE hace aæos, Internet ha estado creciendo de forma

espectacular, tanto en nœmero de usuarios como en la
cantidad de informaci(cid:243)n que transmite. En especial el World
Wide Web se ha posicionado como la aplicaci(cid:243)n mÆs impor-
tante de la pasada dØcada. Este crecimiento ha introducido
nuevos problemas en numerosos Æmbitos: bœsqueda y recu-
peraci(cid:243)n de informaci(cid:243)n, categorizaci(cid:243)n, (cid:2)ltrado, tØcnicas de
transmisi(cid:243)n y diseæo de servidores, entre otras. Este docu-
mento se va a centrar en el problema de diseæo de servidores
Web. Es necesario que el software que se ejecuta en los
nodos que forman Internet trabajen de una forma e(cid:2)ciente y
sean capaces de satisfacer todas las necesidades de servicio
de informaci(cid:243)n que reciban. Actualmente, existen sitios Web
muy activos que necesitan servir varios millones de peticiones
por minuto, y en estas ocasiones es cuando toma especial
relevancia el rendimiento del servidor. Existen numerosos
factores que intervienen en el funcionamiento de un servidor,
y que por lo tanto estÆn directamente relaccionados con su
e(cid:2)ciencia, siendo estos, los principales objetos de estudio del
art(cid:237)culo.

Por otro lado, se presentarÆ un proyecto de Software Libre
llamado Cherokee. Se trata de un servidor web, con un diseæo
modular basado en plug-ins. El objetivo de este diseæo es
poder dotar al servidor de toda clase de funcionalidades y
extensiones, posiblemente desarrolladas por terceras partes. En
Øl se han includo, como se expone a continuaci(cid:243)n, los diseæos
e implementaciones que han demostrado ser mÆs e(cid:2)cientes,
de forma que aun siendo mÆs grande, (cid:3)exible y complejo que
otros servidores web, tambiØn soporta un mayor volumen de
trÆ(cid:2)co.

Este art(cid:237)culo tambiØn compara el rendimiento de los servi-
dores web libres mÆs utilizados. El estudio se ha realizado

en mÆquinas de diferentes caracter(cid:237)sticas para obtener datos
de cada una de ellas: tanto SMP como monoprocesador. En
todos los casos el sistema operativo ha sido GNU/Linux.

II. DISE(cid:209)O

El objetivo de diseæo se centra en conseguir un alto nivel de
paralelismo a la hora de servir las conexiones. Es posible que
el servidor tenga que enviar varios millones de respuestas por
minuto, as(cid:237) que es cr(cid:237)tica la forma en la que son manejadas.
Resultar(cid:237)a completamente inœtil un servidor que responda
una por una las conexiones no concurrentemente. En este
hipotØtico diseæo, existir(cid:237)a una cola de conexiones en espera
- la del propio sistema operativo - en la que se almacenar(cid:237)an
hasta el momento en que, previo proceso de las anteriores,
fuese la primera de la cola. Este diseæo es inviable por varias
razones, la principal de ellas es la alta latencia que podr(cid:237)a
llegar a tener una conexi(cid:243)n, incluso rebasando el tiempo limite.
Resulta especialmente importante, el estudio de los

siguientes puntos [1] en cada una de las arquitecturas:

(cid:15) Velocidad de respuesta
(cid:15) Escalado con alta carga
(cid:15) Calidad de la respuesta en situaci(cid:243)n de sobrecarga

A. Servidores basado en procesos

El diseæo de servidores basados en procesos fue el pre-
decesor de todos los demÆs diseæos que se presentarÆn a
continuaci(cid:243)n. Se basa en la obtenci(cid:243)n de paralelismo mediante
la duplicaci(cid:243)n del proceso de ejecutaci(cid:243)n. Este es el mØtodo
sobre el que se implementaba el servidor de NCSA [2], y
porteriormente Apache [3]. Existen varios diseæos basados en
procesos; el primero de ellos y mÆs simple es en el que el
proceso principal espera la llegada de una nueva conexi(cid:243)n y
en ese momento, se duplica creando una copia exacta que
atenderÆ esta conexi(cid:243)n. Sobre esta opci(cid:243)n de diseæo caben
optimizaciones importantes, como las que incluy(cid:243) Apache con
la tØcnica de pre-fork.

El diseæo de un servidor basado en procesos con pre-fork
consiste en la creaci(cid:243)n previa de un grupo de procesos y
su mantenimiento hasta que sea necesaria su utilizaci(cid:243)n. El
aumento en el rendimiento de este diseæo frente a uno basado
en procesos es grande; es muy posible que en la creaci(cid:243)n
de los procesos se realice en tiempo que de otra forma ser(cid:237)a
perdido y que incrementar(cid:237)a la latencia de la conexi(cid:243)n.

Las principales ventajas de este diseæo residen en su simpli-
cidad de implementaci(cid:243)n y su seguridad. En la implementaci(cid:243)n
de uno de estos servidores œnicamente hay que tener en

cuenta un hilo l(cid:243)gico de ejecuci(cid:243)n. El programador se abstrae
del hecho de que es necesario conseguir concurrencia en
la respuesta de las peticiones e implementa uno a uno, los
pasos por los que debe pasar una conexi(cid:243)n; posteriormente, la
concurrencia en ejecuci(cid:243)n vendrÆ dada por la duplicaci(cid:243)n de
procesos. El aspecto positivo en cuanto a la seguridad consiste
en el hecho de que cada conexi(cid:243)n se responde desde un
proceso completamente aut(cid:243)nomo. Si existiese algœn problema
de seguridad en la implementaci(cid:243)n del servidor, s(cid:243)lo afectar(cid:237)a
al proceso que lo ejecutase, no al servidor completo.

La gran desventaja de este diseæo es el bajo rendimiento.
La creaci(cid:243)n de un proceso o eliminaci(cid:243)n de un proceso son
tareas pesadas para el sistema operativo y consumen una gran
cantidad de tiempo [4], especialmente cuando se trata de pro-
gramas linkados dinÆmicamente - es decir, que deben buscar
s(cid:237)mbolos en librer(cid:237)as dinÆmicas del sistema. Por otro lado,
el diseæo adolece de otros problemas tambiØn relaccionados
con el Æmbito de los procesos. Las partes comunes que se
podr(cid:237)an compartir entre procesos son duplicadas, ademÆs de
no ser posible compartir ninguna informaci(cid:243)n de una forma
e(cid:2)ciente entre los diferentes procesos. Esta restricci(cid:243)n elimina
la posibilidad de la utilizaci(cid:243)n de cachØs comunes en el
servidor as(cid:237) como de cualquier otra tØcnica de optimizaci(cid:243)n
que implique el acceso a un recurso compartido entre mÆs de
una conexi(cid:243)n.

B. Servidores basados en hilos

El diseæo de servidores basados en hilos (o threads), hoy
en d(cid:237)a es mucho mÆs comœn que el basado en procesos. Los
conceptos bÆsicos respecto al funcionamiento de un servidor
basado en procesos son aplicables tambiØn a este modelo.
Las principales diferencias de los dos modelos reside en el
propio concepto de hilo. Al contrario que en el caso anterior,
la creaci(cid:243)n de un hilo no es tan costosa como la de un
proceso. Varios hilos de un mismo proceso si pueden compartir
datos entre ellos, ya que comparten el mismo espacio de
direccionamiento y œnicamente de publica el espacio de pila
para cada uno de ellos.

El modelo de servidor basado en hilos hereda muchas de
las caracter(cid:237)sticas de los servidores basados en procesos, entre
ellas la de la simplicidad en su diseæo e implementaci(cid:243)n. Por
otro lado, en el caso de los servidores basado en hilos, el
compartir el espacio de direccionamiento en memoria implica
un riesgo de seguridad del que no adolecen los servidores
basado en procesos. Si uno de los hilos del proceso ejecuta
una instrucci(cid:243)n ilegal y produce cualquier tipo de fallo en el
uso de la memoria, el servidor completo pararÆ de ejecutarse.

2

caso de tratarse de que el descriptor no se hubiese (cid:2)jado como
no bloqueante, el proceso se quedar(cid:237)a parado en la llamada al
sistema hasta que se recibiera informaci(cid:243)n. De lo contrario, si
el descriptor se ha (cid:2)jado en modo no bloqueante, la llamada a
la funci(cid:243)n de lectura retornar(cid:237)a inmediatamente indicando en
el c(cid:243)digo de error que no ha podido leer nueva informaci(cid:243)n.
Normalmente, estos servidores utilizan una llamada al
sistema que examina el estado de los descriptores con los
que trabaja. Cada sistema operativo implementa una o mÆs
de estas funciones de examen de descriptores:

select
kqueue
poll
epoll

MacOS X, y sistemas antiguos
FreeBSD, OpenBSD y NetBSD [5]
La mayor(cid:237)a de los sistema Unix actuales
Linux 2.6

El objetivo de estas funciones es examinar el estado de un
grupo de descriptores; normalmente los asociados con los
sockets de cada una de las conexiones. La llamada a una
de estas funciones realizarÆ una espera - no activa - hasta
el momento que uno de los descriptores sometidos a examen
cambie su estado o se alcance un l(cid:237)mite de tiempo especi(cid:2)cado
en uno de los parÆmetros con los que se llam(cid:243) a la funci(cid:243)n.
Las ventajas de este modelos de diseæo reside principal-
mente en su velocidad. Como se expondrÆ mÆs adelante, los
servidores basados en sockets no bloqueantes consiguen un
alto rendimiento [6].

Por otro