[cpif] Gestión de conexiones simultaneas (era Re: r167 - trunk/frontend-web)

[Jesus Cea]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Como seguramente todos sabréis ya, cuando pedimos un objeto a un
servidor web, éste no los devuelve rápidamente y se cierra la conexión.
De esta manera, mientras estamos leyendo la página web, en realidad no
estamos conectados el servidor, y éste puede atender otras peticiones.
Así, procesando simultaneamente solo una conexión a la vez, podemos
atender a mucha gente.

Hasta ahora CPIF seguía ese modelo, procesando una petición por vez
(cada petición le lleva apenas unos milisegundos). Con el cambio que
acabo de hacer, se pueden procesar varias peticiones simultaneamente,
cada una en un hilo (thread) de ejecución separado e independiente.

¿Por qué este cambio?.

En principio CPIF incluye su propio servidor web, pero está diseñado
para tener "delante" un servidor web de verdad, tipo Apache o similar, o
un proxy de alta capacidad como SQUID. De esa forma el control de
concurrencia, resistencia ante ataques, etc., la lleva ese frontal, no
CPIF. Además, la idea es que las peticiones que procesa CPIF provengan
de ese frontal, que recibirá la respuesta de forma casi instantanea y
liberará a CPIF, aunque reenviar la página al navegador del usuario sea
un proceso lento si, por ejemplo, tenemos la línea saturada, el usuario
recibe muy lentamente, o nos están atacando.

Este esquema ha funcionado bien hasta ahora, porque CPIF procesa las
peticiones muy rápidamente (milisegundos). Pero esto va a dejar de ser así.

Álvaro está trabajando en los módulos de entrada de usuario bbcode, HTML
y smiley. Estos módulos analizan el texto que ha introducido el usuario
y genera la versión "web", con su código html, sus enlaces, sus
iconitos, etc. Esta operación puede ser potencialmente bastante lenta
para lo que es costumbre en CPIF (digamos, medio segundo). Medio segundo
de retardo cuando alguien escribe un mensaje nuevo es poco, pero en CPIF
estamos rompiendo moldes, así que si podemos evitar esas esperas, las
evitamos.

Hay otro caso más delicado y que justifica este cambio aún más: OpenID.
OpenID requiere realizar varias conexiones y verificaciones antes de
responder al usuario aceptando o rechazando su autentificación. Aquí
podemos irnos a cosas como 10 segundos de espera (la primera vez,
claro). Si dejamos de responder peticiones web durante 10 segundos, a
CPIF le esperaría un futuro más bien negro.

Con el cambio que acabo de publicar, atendemos hasta 16 conexiones
simultaneamente, de forma independiente. Y ese valor es configurable
simplemente editando un número. De esta forma si algunas de esas
conexiones son "lentas" porque, por ejemplo, estamos verificando su
autentificación OpenID, no hay problema, porque otras peticiones que
vayan llegando en paralelo se procesarán de forma concurrente.

Teniendo en cuenta el poco código que requieren estos cambios, la
(escasa) complejidad añadida vale la pena.

Podéis probar este caso muy fácilmente, en un servidor CPIF sin
actualizar (por ejemplo, el de Álvaro en http://perseverantia.com:8877/
, mientras no lo actualice), o bien probando un milestone 3 en local
(hola, David :-), tal y como se explica en el wiki
http://www.argo.es/~jcea/wikis/cpif/Milestones . Para ello basta con
abrir dos conexiones al servidor en cuestión (a mano, vía "telnet" o
similar), y hacer una petición HTTP en la SEGUNDA conexión. Veremos que
el servidor no responde. Eso es porque está esperando a procesar la
primera petición. Si ahora escribimos una petición HTTP en la primera
conexión, CPIF responderá rápidamente en ambas, porque en cuanto procese
la primera, atenderá la segunda (que escribimos medio minuto antes).

Con la versión actual de CPIF (y cuando Álvaro actualice), si se hace
esto, el servidor responde al momento, incluso aunque abramos 9
conexiones y hagamos la petición en la décima. Eso es porque procesamos
16 en paralelo. Naturalmente si abres 17 conexiones y metes la petición
en la 18, volverás a tener una pausa :).

Estoy dándole vueltas aún a si desplegar OpenID en este milestone o
esperar un poco más. En cualquier caso, este cambio lo hace posible :).

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
                               _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRngWJplgi5GaxT1NAQKQDQP/T9KsOkdvV54CB3T1PzbEcbafDXKEP+yw
lQG/2CVDso7ZdnfxNusxarcn5dzaI+P833ChS6WDPV6nBgkuJNhlTKYnZ+Y9y8WH
pr1At0+vLjxrNGFQ/ChF0hl/4nmI+iKttiYh4lWAbgdZk2abn3VIiOglhHLwGVDl
1rwUAONrmLI=
=GBOw
-----END PGP SIGNATURE-----