Performance - Memoria Caché en SharePoint 2010
Saludos comunidad,
Esta vez vamos a platicar de un tema que en mi experiencia es poco conocido y que los administradores de SharePoint o el equipo de trabajo que colabora con ellos no está pendiente de las problemáticas que pueden enfrentar. Resulta que estuve trabajando en un cliente que por necesidades muy particulares tiene implementado un Portal público en SharePoint usando plantillas de Colaboración en lugar de usar plantillas de Publicación, pero bueno al final no es este el problema, estuvieron teniendo un problema bastante peculiar relacionado a la carga del sitio principal, pues demoraba demasiado al rededor de 30 segundos, pero cuando éste estaba ya cargado todo parecía fluir de una forma bastante rápida y no concordaba con el primer conteo de segundos.
Los servidores son virtuales y a pesar de que no hubo un plan de capacidades o guías para virtualizar SharePoint existen bastantes recursos para asignar a los servidores, una granja compuesta por 2 WFE y 1 APP y adicional el servidor de base de datos, cada servidor de SharePoint tiene 2 CPU's y 16 GB de RAM, el portal solo contiene información estática y por ahí algunos videos que son extraidos de otra aplicación que se encarga de hacer el procesamiento, no es parte del trabajo que hace SharePoint, el punto es que no había ninguna razón para que la carga del sitio principal demorara tanto.
Recordemos que SharePoint desde su versión WSS 3.0 maneja 3 tipos de caché: Perfiles de memoria caché de resultados de página, caché de objetos y caché BLOB (Binary Large Objects) , cada uno con una función en particular:
Memoria caché BLOB
SharePoint Server 2010 proporciona una memoria caché basada en disco que almacena los archivos que usan las páginas web para que se carguen más rápidamente en el explorador y reduce la carga en el servidor de bases de datos cuando usa dichos archivos. Estos archivos se denominan objetos binarios grandes (BLOB) y la memoria caché se denomina memoria caché BLOB. La memoria caché BLOB se almacena directamente en la unidad de disco duro de un equipo servidor front-end web. La primera vez que se llama a una página web, estos archivos se copian de la base de datos a la memoria caché de la unidad de disco duro del servidor y todas las solicitudes posteriores de dichos archivos se atienden desde la memoria caché de la unidad de disco duro del servidor. De forma predeterminada, la memoria caché BLOB está desactivada y debe habilitarse para poder usar la funcionalidad que proporciona. Cuando se habilita la memoria caché BLOB en el servidor front-end web, se reduce la carga del servidor de bases de datos de SharePoint Server 2010 generada por las solicitudes leídas de los exploradores web.
Nota: El caché BLOB no es obligatorio, solo si existen objetos mutlimedia en el sitio. Si tenemos una granja de varios WFE se recomienda que el caché se aloje en una partición distinta a C y que todos los WFE tengan la misma unidad lógica. |
Perfiles de memoria caché de resultados de página
La memoria caché de resultados de página almacena el resultado presentado de una página determinada y almacena también distintas versiones de la página almacenada en la memoria caché según los permisos de los usuarios que solicitan la página. La memoria caché de resultados de página se puede configurar en el nivel de la colección de sitios, en el nivel de sitio y para los diseños de página. La memoria caché de resultados de página está desactivada de forma predeterminada.
La memoria caché de resultados de página usa perfiles de memoria caché que especifican durante cuánto tiempo deben conservarse los elementos en la memoria caché. Es posible especificar diferentes perfiles de memoria caché para usuarios anónimos y autenticados, lo que optimiza el uso de la memoria caché según los métodos de autenticación permitidos en el sitio.
Y finalmente:
Memoria caché de objetos
La memoria caché de objetos reduce la cantidad de tráfico entre el servidor web y la base de datos de SQL mediante el almacenamiento de los objetos, como listas y bibliotecas, configuración de sitios y diseños de página, en la memoria del equipo servidor front-end web. Por consiguiente, las páginas que requieren estos elementos se pueden presentar rápidamente, lo que aumenta la velocidad a la que se entregan las páginas en el explorador del cliente. La memoria caché de objetos está activada de forma predeterminada.
Para optimizar la memoria caché de objetos de una aplicación web, especifique su tamaño. Si se especifica un número alto, se puede aumentar el rendimiento de algunos sitios de gran tamaño, aunque esto reduce la memoria en cada servidor front-end web. Puede establecer otra configuración para la memoria caché de objetos en el nivel de la colección de sitios.
Nota: El caché de objetos solo esta disponible en las plantillas de Publicación o bien cuando las características de publicación están habilitadas, por otro lado éste caché requiere de 2 cuentas de usuario para poder habilitarse: la cuenta de usuario súper del portal y la cuenta de lector súper del portal |
Conclusión
Una vez explicado lo anterior en un breve resumen, es importante decir que el caché de objetos de forma por defecto utiliza la cuenta de sistema del sitio y la cuenta NT AuthorityServicio local, pero existen algunos problemas conocidos con esta configuración, problema que este cliente presentó:
A) El primer problema es que algunos elementos se desprotegen para la cuenta del sistema, por lo que cuando se realice una consulta que incluya estos elementos, se devolverá la versión desprotegida del elemento en lugar de la última versión publicada. Esto es un problema debido a que no es lo que un usuario espera que se devuelva, por lo que la memoria caché debe realizar una segunda consulta para recuperar la versión correcta del archivo. Esto tiene un efecto negativo en el rendimiento del servidor en cada solicitud que incluya estos elementos. Se produciría el mismo problema con cualquier usuario que tenga elementos desprotegidos, si la cuenta de dicho usuario se configuró como la cuenta de usuario súper del portal. Por esta razón, las cuentas configuradas como cuenta de usuario súper del portal y cuenta de lector súper del portal no deben ser cuentas que se usan para iniciar sesión en el sitio. Esto garantiza que el usuario no desproteja de forma accidental elementos y ocasiones problemas en el rendimiento.
B) La cuenta de lector súper del portal predeterminada es NT AuthorityServicio local, que no se resuelve correctamente en una aplicación de la autenticación de notificaciones. Por lo tanto, si la cuenta de lector súper del portal no está configurada explícitamente para una aplicación de autenticación de notificaciones, al buscar las colecciones de sitios en esta aplicación se obtendrá un error de acceso denegado, incluso para el administrador del sitio. Este error se producirá en los sitios que usen cualquier característica que use explícitamente la caché de objetos, como la Infraestructura de publicación de SharePoint Server, la navegación de metadatos, el elemento web de consulta de contenido o la navegación.
Cuando se configuró apropiadamente el caché de objetos y las cuentas se crearon de acuerdo a las mejores prácticas el tiempo de carga se redujó de 30 segundos a 3 segundos, esto debido a las aplicaciones que son mandadas llamar para hacer el rendering de los videos publicados en la página principal.
Tengan mucho cuidado cuando trabajen con la memoria Caché de SharePoint y presten especial atención en el principal objetivo de sus Colecciones de Sitios y Sitios para que utilicen las plantillas apropiadas y la configuración de caché correcta.
Para mayor referencia sobre los temas expuestos anteriormente consulten:
Cache settings operations (SharePoint Server 2010) - https://technet.microsoft.com/en-us/library/cc261797.aspx
Configure object cache user accounts - https://technet.microsoft.com/en-us/library/ff758656.aspx
Saludos