Una de las principales dudas que tuvimos todos cuando SOAP y todos sus parientes hicieron aparición en escena fue el impacto en el rendimiento de estos protocolos tan pesados, XML era basicamente un formato de serialización muy chatty y no se comparaba con serializaciones binarias altamente optimizadas que utilizaban los protocolos de objetos distrbuidos (DCOM, CORBA).
Con el tiempo y entendiendo los conceptos que hoy conforman SOA se entendió que esto no impactaría tanto como se esperaba por el cambio en la programación de interfaces y contratos.
Sin embargo esto no quita que aún así XML sea una serialización muy cara, si hablamos de una red corporativa con LAN de 100 Mbps es manejable pero cuando se empiezan a construir soluciones que se se ejecutarán en enlaces bajos (dial-up, satelital, etc) y es en este punto donde mucha discusión se ha dado en el uso de compresión para la comunicación con servicios.
Si consideramos que las respuestas grandes de servicios serializados en XML son documentos con un conjunto de registros similares cualquier algoritmo de compresión puede hacer un muy buen trabajo para disminuir el tamaño de un archivo. Tomemos por ejemplo un servicio de búsqueda que devuelve un documento con los resultados de búsqueda. La estructura del mensaje sería la siguiente.
<resultados registros="100" inicio="0" total="1054">
<resultado>
<Titulo>Sitio 1</Titulo>
<Descripcion>Breve descripción del sitio</Descripcion>
<Url>http://sitio/</Url>
</resultado>
...
<resultado>
<Titulo>Sitio 100</Titulo>
<Descripcion>Breve descripción del sitio</Descripcion>
<Url>http://sitio34131</Url>
</resultado>
</resultados>
En este caso al existir tanto texto similar el grado de compresión puede ser muy alto, por ejemplo un archivo XML de 1.5 MB utilizando gzip como algoritmo de compresión (RFC 1952) se convierte en 120 KB es decir un 8% del archivo original. Es cierto que el archivo que utilice como ejemplo tiene otros textos repetidos pero sirve como referencia.
Obviamente nunca deberíamos retornar 1.5 MB como resultado de un servicio pero tomando la estructura de ejemplo al retornar 100 registros tenemos un archivo de 13750 bytes. la transmisión de este resultado a través de una linea de 56Kbps( aproximadamente 7KBps) sería de 1.91 segundos (tiempo ideal sin ruido y confiabilidad de 100%). Si se que suena a que no es nada pero siguamos analizando. Si este mismo archivo lo comprimimos con gzip nivel 3 se convierten en 327 bytes con un tiempo ideal de 0.04 segundos. SI se considera que este tiempo es uso de ancho de banda y red esto podría significar atender a unos cuantos cientos de usuarios más con el mismo ancho de banda.
Como siempre no todo puede ser miel y en este caso el costo es un tiempo adicional para la compresión, el uso de procesador y memoria del servidor. entonces el tiempo adicional de proceso debe sumarse para ver cual sería el tiempo real de proceso.
En nuestro caso el tiempo de compresión es de no más de 10 milisegundos (utilizando la clase GZipStream del .Net Framework 2.0), si sumamos este tiempo al tiempo de transmisión tenemos un total 0.05 segundos lo cual es aún un muy buen resultado.
Otro aspecto a considerar es el uso de procesador, tipicamente todos los algoritmos de compresión tienen niveles que permiten definir la carga en procesador y memoria de la tarea de compresión. En el ejemplo se ha utilizado gzip nivel 3 (el que provee el framework) que no tiene impacto mayor al de un proceso de servicio por lo cual es una extensión solo en tiempo
El último aspecto es el uso de memoria, dado que la mayoría de las especificaciones WS-* requieren el Infoset de respuesta completo para su proceso actualmente casi todas las soluciones de publicación y consumo de servicios manejan los mensajes en buffer por lo que el consumo de memoria adicional es el relacionado al tamaño de la versión compresa de los datos. De nuevo en nuestro ejemplo es un 2%. Este dato no es despreciable en servidores de muy alto uso porque puede llegar a convertirse en punto de contención.
Con todo lo anteriormente dicho cual sería el criterio para decidir si utilizar compresión en la publicación de servicios:
1. Si se conoce que los clientes disponen de bajo ancho de banda y el nivel de concurrencia no estima que la memoria de servidor sea saturada es recomendado utilizar compresión, el nivel de compresión será determinado por la capacidad de procesador del servidor.
2. Si en cambio tenemos mucha concurrencia y anchos de banda aceptables es mejor no utilizar mecanismos de compresión de datos.
Con este pseudo-análisis (si ya se que tiene muchos vacios y que no puede llamarse un análisis serio) veamos cuales son las alternativas que se han manejado para la compresión de datos en servicios.
