Estimación de los requisitos de rendimiento y capacidad de PerformancePoint Services

Se aplica a: SharePoint Server 2010

Última modificación del tema: 2017-01-18

En este artículo se describe el efecto que tiene PerformancePoint Services en las topologías que ejecutan Microsoft SharePoint Server 2010.

En este artículo:

• Prueba de las características de la granja de servidores

• Resultados de las pruebas

• Recomendaciones

Si desea obtener información general sobre el modo de planear y ejecutar la capacidad para SharePoint Server 2010, vea Administración y ajuste de tamaño de la capacidad de SharePoint Server 2010.

Prueba de las características de la granja de servidores

Conjunto de datos

El conjunto de datos constaba de un portal corporativo creado mediante SharePoint Server 2010 y PerformancePoint Services que contenía un solo panel de tamaño mediano. El panel contenía dos filtros vinculados a un cuadro de mandos, dos gráficos y una cuadrícula. El panel estaba basado en un solo origen de datos de Microsoft SQL Server 2008 Analysis Services (SSAS) que usaba las bases de datos de ejemplo AdventureWorks para el cubo de SQL Server 2008 Analysis Services.

En la tabla siguiente se describen el tipo y el tamaño de cada elemento del panel.

En el panel mediano se usó la plantilla de encabezado y dos columnas y los tamaños de los elementos del panel se establecieron en tamaño automático o en un porcentaje específico del panel. Cada elemento del panel se representó con un alto y ancho aleatorios de entre 400 y 500 píxeles para simular las diferencias existentes entre los tamaños de ventana del explorador web. Es importante cambiar el alto y el ancho de cada elemento del panel debido a que los gráficos se representan en función de los tamaños de ventana del explorador web.

Escenarios de prueba y procesos

En esta sección se definen los escenarios de prueba y se describe el proceso de prueba que se usó para cada escenario. En la sección Resultados de las pruebas, más adelante en este artículo, se proporciona información detallada, como los resultados de las pruebas y parámetros específicos.

Se usó una combinación de pruebas única que consistió en los siguientes porcentajes de las pruebas iniciadas.

Con las herramientas de prueba de carga de Microsoft Visual Studio 2008 se creó un conjunto de pruebas web y pruebas de carga que simularon cambios aleatorios en los filtros y la navegación por las cuadrículas y los gráficos por parte de los usuarios. Las pruebas usadas en este artículo contenían una distribución normal de pausas de 15 segundos entre las interacciones, también denominadas "tiempos de reflexión", y un tiempo de reflexión entre iteraciones de prueba de 15 segundos. Se aplicó la carga para producir un tiempo de respuesta promedio de dos segundos para representar un cuadro de mandos o un informe. Se midió el tiempo de respuesta promedio durante un período de 15 minutos después de un tiempo de preparación inicial de 10 minutos.

Cada nueva iteración de prueba selecciona una cuenta de usuario distinta de un grupo de cinco mil cuentas y una dirección IP aleatoria (mediante el uso de conmutación de IP de Visual Studio) de un grupo de aproximadamente 2.200 direcciones.

La combinación de pruebas se ejecutó dos veces respecto del mismo panel de tamaño mediano. En la primera ejecución, la autenticación del origen de datos se configuró para usar la cuenta de servicio desatendida, que usa una cuenta común para solicitar los datos. Los resultados de datos son idénticos para varios usuarios y PerformancePoint Services puede usar almacenamiento en caché para mejorar el rendimiento. En la segunda ejecución, la autenticación de origen de datos se configuró para usar la identidad de usuario y el cubo de SQL Server Analysis Services se configuró para usar seguridad dinámica. En esta configuración, PerformancePoint Services usa la identidad del usuario para solicitar los datos. Debido a que los resultados de datos podrían ser diferentes, no se puede compartir el almacenamiento en caché entre usuarios. En algunos casos, puede compartirse el almacenamiento en caché para identidad de usuario si no se configuró la seguridad dinámica de Analysis Services y los roles de Analysis Services asignados a los usuarios y grupos de Microsoft Windows son idénticos.

Configuración de hardware y topología

Hardware de laboratorio

Para proporcionar un alto nivel de detalle en los resultados de la prueba, se usaron varias configuraciones del conjunto o granja de servidores para las pruebas. Las configuraciones de granjas de servidores incluyeron de uno a tres servidores web, de uno a cuatro servidores de aplicaciones y un solo servidor de bases de datos que ejecutaba Microsoft SQL Server 2008. Se realizó una instalación empresarial predeterminada de SharePoint Server 2010.

En la tabla siguiente se enumera el hardware específico usado para realizar las pruebas.

Después de incrementar la escalabilidad horizontal de la granja de servidores a varios servidores web, se usó un equilibrador de carga de hardware para equilibrar la carga de usuarios entre varios servidores web mediante el uso de afinidad de dirección de origen. La afinidad de dirección de origen registra la dirección IP de origen de las solicitudes entrantes y el host de servicios en el que se equilibró la carga, y canaliza todas las transacciones futuras al mismo host.

Topología

La topología inicial consistió en dos servidores físicos. Uno se usó como servidor web y de aplicaciones y el otro como servidor de bases de datos. Esta topología inicial se considera una topología de dos máquinas (2M) o una topología "1 por 0 por 1", en que el número de servidores web dedicados aparece al comienzo de la lista, seguido de los servidores de aplicaciones dedicados y, a continuación, los servidores de bases de datos.

Los servidores web también se denominan front-end web (WFE) más adelante en este documento. Se aplicó la carga hasta que se encontraron factores restrictivos. Por lo general, el factor restrictivo fue la CPU del servidor web o del servidor de aplicaciones y se agregaron recursos para solucionar ese límite. Los factores restrictivos y las topologías difirieron considerablemente en función de la configuración de la autenticación del origen de datos de cuenta de servicio desatendida o identidad de usuario con seguridad de cubo dinámico.

Resultados de las pruebas

Los resultados de las pruebas contienen tres medidas importantes que ayudan a definir la capacidad de PerformancePoint Services.

En las topologías de más de cuatro servidores de aplicaciones, es probable que el cuello de botella sea el servidor de Analysis Services. Considere supervisar la CPU y el tiempo de consulta del servidor de Analysis Services para determinar si debe incrementar la escalabilidad horizontal de Analysis Services a varios servidores. Cualquier retraso en el tiempo de consulta en el servidor de Analysis Services aumentará considerablemente el tiempo de respuesta promedio de PerformancePoint Services más allá del umbral deseado de dos segundos.

En las tablas siguientes se muestra un resumen de los resultados de las pruebas para autenticación de cuenta de servicio desatendida y autenticación de usuario al incrementar la escalabilidad horizontal de dos a siete servidores. Más adelante en este documento se incluyen resultados detallados con contadores de rendimiento adicionales.

Resumen de autenticación de cuenta de servicio desatendida

Resumen de autenticación de usuario

Topologías 2M y 3M

Para ayudar a explicar el costo de hardware por transacción y la curva de tiempo de respuesta, las pruebas de carga se ejecutaron con cuatro cargas de usuarios cada vez mayores, hasta alcanzar la carga máxima de usuarios para las topologías 2M y 3M.

Autenticación de la cuenta de servicio desatendida

Autenticación de usuario

Resultados de granja de servidores 3M (1x1x1)

Autenticación de la cuenta de servicio desatendida

Autenticación por usuario

Resultados para topologías de 4 o más máquinas para autenticación de cuenta de servicio desatendida

Comenzando con una topología de cuatro máquinas, se aplicó carga para producir un tiempo de respuesta promedio de dos segundos para representar un cuadro de mandos o un informe. A continuación, se agregó un servidor adicional para resolver el factor restrictivo (siempre CPU en el servidor web o el servidor de aplicaciones) y, a continuación, se volvió a ejecutar la combinación de pruebas. Esta lógica se repitió hasta que se alcanzó un total de siete servidores.

Resultados para topologías de 4 o más máquinas para autenticación de usuario

Se repitieron las mismas pruebas para un origen de datos configurado para autenticación de usuario. Tenga en cuenta que al agregar un servidor de aplicaciones para crear una topología de cuatro servidores de aplicaciones no se aumentó el número de usuarios ni las solicitudes por segundo que admitía PerformancePoint Services debido a los retrasos en las consultas que produjo Analysis Services.

Recomendaciones

Recomendaciones de hardware

Se recomienda usar los contadores de memoria y procesador de las tablas de prueba para determinar los requisitos de hardware para la instalación de PerformancePoint Services. En el caso de servidores web, PerformancePoint Services usa los requisitos de hardware de SharePoint Server 2010 recomendados. Es posible que sea necesario cambiar los requisitos de hardware de los servidores de aplicaciones si PerformancePoint Services consume una gran cantidad de memoria. Esto sucede cuando los orígenes de datos se configuran para autenticación de usuario o cuando el servidor de aplicaciones ejecuta muchos paneles con tiempos de espera de origen de datos largos.

El servidor de bases de datos no produjo un cuello de botella en las pruebas y tuvo un pico máximo de uso de CPU del 31% bajo el panel con autenticación de cuenta de servicio desatendida de 7M. PerformancePoint Services almacena las definiciones de contenido de PerformancePoint Services, como informes, cuadros de mandos y KPI, en listas de SharePoint y en la memoria caché, lo que reduce la carga del servidor de bases de datos.

Consumo de memoria

PerformancePoint Services puede consumir grandes cantidades de memoria en determinadas configuraciones y es importante supervisar el uso de memoria del grupo de aplicaciones de PerformancePoint Services. PerformancePoint Services almacena varios elementos en la memoria caché, incluidos los resultados de Analysis Services y otros resultados de consultas de origen de datos, por la duración de la memoria caché de origen de datos (tiempo predeterminado de 10 minutos). Cuando se usa un origen de datos que está configurado para la autenticación de cuenta de servicio desatendida, los resultados de estas consultas solo se almacenan una vez y se comparten entre varios usuarios. Sin embargo, cuando se usa un origen de datos que está configurado para autenticación de usuario y seguridad de cubo dinámico de Analysis Services, los resultados de las consultas se almacenan una vez por cada usuario por cada vista (es decir, una combinación "por filtro").

La API de caché subyacente que usa PerformancePoint Services es la API de caché de ASP.NET. La ventaja significativa de usar esta API es que ASP.NET administra la memoria caché y quita (o recorta) elementos en función de los límites de la memoria para evitar errores de falta de espacio en memoria. El límite de memoria predeterminado es del 60 por ciento de la memoria física. Después de alcanzar este límite, PerformancePoint Services continuó representando vistas pero los tiempos de respuesta aumentaron considerablemente durante el breve período en que ASP.NET quitó las entradas almacenadas en la memoria caché.

El contador de rendimiento "Aplicaciones ASP.NET\Recortes API de caché" del grupo de aplicaciones que hospeda PerformancePoint Services se puede usar para supervisar los recortes de la memoria caché de ASP.NET que se producen debido a la presión de memoria. Si este contador es mayor que cero, revise la siguiente tabla para ver posibles soluciones.

Un origen de datos que se ha configurado para usar autenticación de usuario puede compartir los resultados de las consultas y las entradas de la memoria caché si los conjuntos de pertenencias a roles de Analysis Services de los usuarios son idénticos y si no se ha configurado la seguridad de cubo dinámico. Se trata de una nueva característica de PerformancePoint Services en Microsoft SharePoint Server 2010. Por ejemplo, si el usuario A está en el rol 1 y 2, el usuario B en el rol 1 y 2 y el usuario C en el rol 1, 2 y 3, solo el usuario A y el usuario B compartirán las entradas de caché. Si no hay seguridad de cubo dinámico, los usuarios A y B, así como el usuario C, no compartirán las entradas de la memoria caché.

Analysis Services

Durante la prueba de PerformancePoint Services con autenticación de usuario, se cambiaron dos propiedades de Analysis Services para mejorar el rendimiento multiusuarios. En la siguiente tabla se muestran las propiedades que se cambiaron y el nuevo valor de cada propiedad.

Estas dos opciones de memoria configuran Analysis Services para usar el montón de Windows en lugar del montón de Analysis Services. Antes de cambiar estas propiedades y, mientras se aumentaba la carga de usuarios, los tiempos de respuesta aumentaron significativamente de 0,2 segundos a más de 30 segundos mientras que la CPU de los servidores web, de aplicaciones y de Analysis Services se mantenía baja. Para solucionar el problema, se recopiló el tiempo de consulta usando vistas de administración dinámica (DMV) de Analysis Services, que mostraron un aumento de los tiempos de consulta individuales de 10 milisegundos a 5000 milisegundos. Estos resultados llevaron a la modificación de la configuración de memoria anterior.

Es importante tener en cuenta que aunque esto mejoró notablemente la capacidad de proceso, según el equipo de Analysis Services, la modificación de esta configuración tiene un costo pequeño pero perceptible en las consultas de usuario único.

Antes de cambiar cualquier propiedad de Analysis Services, vea el tema sobre la guía de rendimiento de Analysis Services de las notas del producto de SQL Server 2008 (https://go.microsoft.com/fwlink/?linkid=165486&clcid=0xC0A) para conocer los procedimientos recomendados sobre cómo mejorar el rendimiento multiusuario.

Cuellos de botella comunes y sus causas

Durante las pruebas de rendimiento, se detectaron varios cuellos de botella habituales. Un cuello de botella es una situación en la que se alcanza la capacidad máxima de un componente determinado de una granja de servidores. Esto produce un estancamiento o una disminución en el rendimiento la granja de servidores. En los casos en que el intenso uso del procesador producía un cuello de botella, se agregaron servidores para resolver el problema. En la siguiente tabla se enumeran algunos cuellos de botella comunes, y las posibles soluciones, en los que se supone que el uso del procesador es reducido y que no produce ningún cuello de botella.

Supervisión del rendimiento

Para ayudarle a determinar cuándo es necesario incrementar la escalabilidad vertical y horizontal del sistema, supervise el estado del sistema mediante el uso de contadores de rendimiento. PerformancePoint Services es un servicio de WCF de ASP.NET y puede supervisarse mediante el uso de los mismos contadores de rendimiento que se usan para supervisar cualquier otro servicio de WCF de ASP.NET. Además, puede usar la información incluida en las tablas siguientes para determinar los contadores de rendimiento adicionales que se deben supervisar y a qué proceso se deben aplicar los contadores de rendimiento.

See Also

Concepts

Planeación de PerformancePoint Services (SharePoint Server 2010)