Siguiendo con el anterior artículo «Page Templates con ayuda del Sharepoint Designer«, he caído en la cuenta de la cantidad de personsalizaciones que se hacen sobre sharepoint sobre entornos de producción sin que seamos conscientes de cómo afecta esto a nuestros sistema.
Esta claro que una personalización para un sitio con una relativa carga de usuarios es incluso hasta aconsejable ya que el coste en desarrollo podría penalizarnos demasiado. Pero si lo que nos estamos planteando es el desarrollo de una página corporativa o extranet, deberíamos tener en cuenta que una gran volumen de usuarios podría provocar una denegación del servicio.
Para ver como afecta al rendimiento la forma de diseñar la solución he estado realizando una serie de pruebas sobre un wss3. Para ello he creado un aplicación web con una colección y dos listas con unos mil elementos y varios campos con valores aleatorios. Una vez creadas las listas, realicé varias pruebas:
- Una página ghosted, sin editar ni customizar
- Una página ghosted con edición de contenido
- Y una página unghosted
La prueba de carga consistía en realizar una consulta a todos los elementos de la lista llamando a AllItems, y después consultar un elemento de la lista distinto en cada test, con un incremento de carga progresivo de 50 usuario cada 30 segundos por un tiempo máximo de 10 minutos. Estas pruebas se han repetido varias veces cada una y reiniciando el servidor en cada paso.
No os fijéis en los resultados numéricos absolutos, sino en las diferencias entre cada escenario. Esto se debe a que las pruebas están realizadas sobre un wss3 contra una bbdd alojada en la misma máquina, por lo que he tenido que bajarle los hilos del workerprocess para que deje tiempo de proceso al SqlServer.
Una página ghosted, sin editar ni customizar
Podemos observar como el proceso se ha comportado relativamente bien hasta el minuto 6’45, donde ha empezado a aumentar el tiempo de respuesta producirse errores de denegación de servicio.También se aprecia como ha conseguido mantener los tiempos de respuesta aun con una carga elevada. Aunque los errores han ido creciendo poco a poco no han adquirido un número elevado teniendo en cuenta que tenía una carga de unos 800 usuarios, por lo que la respuesta a los usuarios sería relativamente aceptable.
Una página ghosted con edición de contenido
Vemos como en este caso los errores de solicitud se empiezan a producir mucho antes, justo a partir del minuto 5’50» con una carga total de unos 560 usuarios. Además el tiempo de respuesta y los errores han seguido creciendo.
Ya podemos observar como este tipo páginas tiene un rendimiento 30% inferior y una media de solicitudes por segundoinferior al anterior.
Y una página unghosted
En este caso se ha customizado con Sharepoint Designer la página AllItems de la lista y su masterpage.
Este escenario, ha resultado ser muy parecido al anterior pero fijaros que con tiempos de respuesta más elevados y con una carga de cpu muy superior. Si observáis la línea azul (tiempo de respuesta) existe un salto que coincide con la falta de respsuesta del servidor al VisualStudio debido a un consumo elevado..
En este caso ha conseguido un rendimiento aceptable con una carga de unos 600 usuarios, un 25% inferior al primer caso.
Conclusiones
Aunque los ejemplos han sido casos muy sencillos, en un entorno real con muchas personalizaciones habríamos visto como la diferencia habría sido mucho mayor. Tener en cuenta además que esto se ha realizado en una granja con un solo servidor, si hubiéramos tenido varios frontales el rendimiento de las páginas ghosted se incrementaría de forma proporcional al incremento de servidores, pero en el caso de las unghosted crecería en una menor medida debido a que la mayor parte del procesamiento se invertiría en consultar la bbdd de contenidos.
