Optimización del rendimiento de MOSS:BLOB Cache

BLOB (Binary Large Object) son un conjunto de datos binarios almacenados como una única entidad en un servidor de base de datos, normalmente se trata de imágenes, audio u otros objeto multimedia.

BLOB Cache es una Cache para almacenar este tipo de objetos que está soportada por Microsoft SharePoint, básicamente almacena en cada servidor frontal los archivos de tipo BLOB y hace que cada descarga de este tipo de archivos al cliente incluyan en la cabecera HTTP un nuevo campo donde se indica el periodo de vida de este objeto, de manera que previamente a la solicitud de descarga de cada uno de estos objetos primero comprueba si el anterior ha caducado y si no es así evita la llamada HTTP.

El BLOB Cache no funciona cuando accedemos por primera vez a una página, o la recargamos mediante el botón del navegador de refrescar, lógicamente primero necesita descargar los archivos BLOB asociados a la carpeta de temporales de la máquina en que se ejecuta el navegador, y una vez que nos encontramos en el proceso de navegar por un conjunto de páginas para la cual ya tenemos archivos de este tipo descargados, prescinde de la descarga de estos archivos con la consiguiente optimización de rendimiento. Se puede resumir en que los beneficios del BLOB Cache empiezan a mostrarse cuando navegamos por un conjunto de páginas que guardan similitudes en su estructura, como normalmente es el caso de una aplicación SharePoint.

Éste sería el funcionamiento básico del Blob Cache, pero dependiendo de donde se ubiquen los ficheros en SharePoint, en una lista, biblioteca de documentos o por ejemplo el fichero este adjunto a un elemento de una lista, podemos decir que SharePoint los almacena de diferente manera.

Por un lado tendremos todos los ficheros almacenados en la estructura de SharePoint (listas de documentos, bibliotecas de estilos, librerías de páginas) y por el otro los ficheros almacenados en "otras estructuras"(fichero adjunto a un elemento de una lista), este último tipo de almacenamiento de ficheros se “almacenan” en una Carpeta Web, y automáticamente por el hecho de estar almacenados así tienen asociado un tiempo de caducidad por defecto, esto implica que el navegador siempre tendrá que estar haciendo peticiones al servidor para ver si este fichero ha cambiado desde la última descarga, este tipo de petición HTTP tiene asociado el código 304.

Entorno de pruebas

Para demostrar la utilidad de la BLOB Cache he creado un sitio de SharePoint bastante básico donde en la página por defecto se carga el contenido de dos listas mediante un WebPart, en cada uno de estos WebParts se muestra un icono asociado a cada uno de los elementos:

Respectivamente cada uno de los WebParts carga los datos de una lista, una donde los iconos son referencias a imágenes de la colección de sitios:

Y a otra lista donde las imágenes son ficheros adjuntos:

Este análisis se centra en las comunicaciones cliente-servidor, si bien es lógico pensar que la parte de comunicaciones servidor-servidor SQL también se verán optimizadas con la implementación del BLOB Cache. Pero esto lo dejo para otro post...

Tráfico HTTP sin BLOB Cache

Mediante el Fiddler capturo el tráfico HTTP generado por un acceso a la HOME comentada anteriormente:

Aquí se observan las peticiones HTTP 304 para cada una de las imágenes, el navegador del cliente ya tiene estas imágenes en local, pero necesita enviar una petición HTTP 304 al servidor para averiguar si estas imágenes han sido modificadas desde la última descarga.

Detalle de la carga:

Habilitar el BLOB Cache

Habilitar la BLOB Cache es muy sencillo, el Web.Config ya incluye una entrada para la BLOB Cache, es importante resaltar que la BLOB Cache debe ser activada en cada uno de los servidores frontales de la aplicación Web.

En este caso modifico la entrada del Web.Config para que habilitarla y establecemos el tipo de archivos BLOB que se cachearán, la ubicación de la carpeta donde se almacena y la caducidad en segundos(86400 segundos = 1 día)

Esta es la carpeta donde se almacenarán los archivos de tipo BLOB en cada uno de nuestros frontales:

Tráfico HTTP con el BLOB Cache habilitado

Si ahora volvemos a capturar el tráfico HTTP:

Si lo comparamos con la captura de tráfico sin la BLOB Cache se observa que las peticiones 304 al área de imágenes de la colección de sitios han desaparecido, ya que esos fichero ahora se encuentran  en el BLOB Cache y el propio navegador detecta que no han caducado por lo tanto evita realizar las peticiones 304 asociadas a la carga de estas imágenes.

Evidentemente el tráfico HTTP se ve reducido al ahorrarse las peticiones de imágenes relacionadas con la lista que contiene esas imágenes como referencias a imágenes de la colección de sitios.

Optimizando el rendimiento

Tal y como se ha mencionada la forma de almacenar las imágenes en SharePoint difiere de si estas están almacenadas en estructuras "propias" de SharePoint o si no lo están. Si modificamos la librería que tenía sus iconos como adjuntos y ahora los convertimos en referencias a imágenes de la librería de imágenes de la colección de sitios obviamente el rendimiento mejora ostensiblemente:

Ya no se produce ninguna petición HTTP de tipo 304 ya que ahora todas la imágenes están almacenadas en la BLOB Cache.

Comparativa de resultados

• Sin BLOB Cache:

• Con la optimización y el BLOB Cache habilitado:

Básicamente podemos resumirlo en que la carga de la página se ve reducida de 0,47 segundos a 0,21, evidentemente la mayor mejora se produce en los bytes enviados que se reducen de 60.508 a 3.327, los bytes recibidos no cambian mucho ya que las tramas HTTP que se evitan son solo de consulta y no producen respuesta.

En conclusión me parece que la BLOB Cache es un mecanismo muy interesante en conjunto con SharePoint, ya que normalmente la estructura de una Intranet o de un Portal es siempre la misma: masters layouts,... y esas imágenes difícilmente son modificadas, por lo tanto la reducción en el tráfico generada por cada petición de una página se ve mermada considerablemente optimizando los tiempos de carga. Esto en conjunto con la sencillez de su implementación lo convierte en una recomendación de uso muy común.

También he querido probar las diferencias en el modo de almacenaje de los ficheros en SharePoint lo que demuestra que parece mucho mas óptimo utilizar las estructuras que ofrece SharePoint, siempre que esto sea posible.