Get Firefox

Firefox 4.0

stopsoftwarepatents.eu petition banner Manifiesto por la liberación de la cultura 
No a la traza privada
Últimos cambios
Últimos Cambios
Vote for Public Maps - Reject INSPIRE! Geocaching
Mi estado actual en Jabber/XMPP: - jabberES - jabber.org

Compresión de los enlaces servidor <-> servidor

Última Actualización: 24 de Julio de 2.000 - Lunes

Este documento describe el sistema de compresión utilizado entre los servidores de IRC-Hispano desde Mayo de 2.000. Esta propiedad del enlace se negocia de forma dinámica en cada enlace gracias a la infraestructura de negociación servidor <-> servidor descrita en otro documento.


Objetivos a Cumplir


Detalles de Diseño

Las librerías de compresión evaluadas durante el desarrollo de este proyecto proyecto fueron:


Características Finales


Configuración

Tal y como se explica en la página de negociación de enlaces, no es preciso realizar ninguna modificación en la configuración de los servidores para beneficiarse de la tecnología de compresión, ya que ésta estará típicamente activada por defecto.

Existen, no obstante, casos en los que interesa desactivar esta funcionalidad. El más evidente es cuando varios nodos están unidos a través de una red de alta velocidad (por ejemplo, una red local). En ese caso la compresión no mejora la ya de por sí rápida y holgada comunicación entre los nodos, y sólo consume CPU y memoria.

Como se explica en la página de negociación cada propiedad negociada se representa por una letra. En el caso de la compresión ZLIB (la actual), la letra asociada es ZETA ("z"). Su uso y configuración se detalla en la página indicada más arriba.

Una vez negociada compresión en un enlace, el sistema no admite deshabilitar dicha función mediante negociación. Es decir, una vez que se empieza a comprimir un enlace, no se puede dejar de comprimir.


Monitorización

Un IRCop puede verificar si un servidor soporta o no compresión, si un enlace está siendo comprimido y cuál es su nivel de compresión, utilizando el comando "stats l".

El comando "stats l" muestra ahora el nivel de compresión alcanzado en cada enlace del servidor, en ambos sentidos. Un nivel de compresión del 100% indica que no se está comprimiendo dicho enlace. Un nivel de compresión del 45%, por ejemplo, indica compresión 100:45.

Asimismo, los bytes enviados y recibidos son el tráfico comprimido. Es decir, si un enlace se está comprimiendo al 42%, y se indica que se han enviado 4561269 bytes, ese es el numero de bytes realmente enviado (comprimido); si no se emplease compresión, se hubieran enviado 10860164 bytes.


Microráfagas

Como ya se ha explicado con anterioridad, cada línea a enviar se comprime y se transmite de forma inmediata. Ello provoca un consumo de CPU elevado, y un nivel de compresión inferior al deseable. Este enfoque se justifica porque:

Tras analizar el problema detenidamente se decidió implementar un esquema de microráfagas explícito, en las que el código del servidor IRC señala explícitamente dónde empieza y dónde acaba un bloque de comandos que podemos permitirnos comprimir como un único bloque, sin los problemas anteriores.

En el momento actual, las microráfagas implementadas se producen:

Las microráfagas pueden anidarse y, aunque deberían cerrarse adecuadamente, el servidor es capaz de recuperarse si una microráfaga no se completa como debe (aunque esta opción es peligrosa y no debe abusarse de ella).

El empleo de microráfagas mejora notablemente la compresión, y contribuye a aligerar de forma considerable la carga de CPU en situaciones de "join" o de enlaces muy cargados (ya que llegan varios comandos juntos en un unico datagrama, que serán procesados dentro de una microráfaga). El siguiente gráfico ilustra los beneficios de esta tecnología:

En este gráfico se observa que el uso de microráfagas mejora la compresión del 47% al 36%, y que el consumo de CPU se reduce a algo menos de la mitad. El nivel de agrupamiento que se indica en el gráfico es el número de comandos que comprimimos juntos, como un bloque.

Para hacer uso de las microráfagas (como ya se ha explicado, es posible anidarlas) hay que invocar a la función "inicia_microburst()" al principio del bloque, y llamar a "completa_microburst()" cuando hayamos terminado con ella. Cuando se cierren todas las microráfagas en curso (se pueden anidar), el servidor hará "flush" de todos los búferes de compresión y de todos los enlaces TCP/IP involucrados en las microráfagas, de forma automática. El servidor se hace cargo automáticamente de aquellos enlaces involucrados en microráfagas que se cierren antes de haberlas completado.


Código Fuente

En esta sección se incluye parte del código fuente empleado para evaluar el sistema de compresión implementado:


Historia:



Firefox 4.0 Python Zope ©2000 jcea@jcea.es