Compartir a través de

Pruebas de rendimiento para SharePoint Server 2010

  • Artículo

 

Se aplica a: SharePoint Server 2010

Última modificación del tema: 2016-11-30

En este artículo se describe cómo probar el rendimiento de Microsoft SharePoint Server 2010. La fase de prueba y optimización es un componente esencial de la administración eficaz de la capacidad. Se recomienda probar las arquitecturas nuevas antes de implementarlas en producción y llevar a cabo pruebas de aceptación junto con los siguientes procedimientos recomendados de supervisión para garantizar que las arquitecturas que se diseñen alcancen los objetivos de rendimiento y capacidad. Esto permite identificar y optimizar los posibles cuellos de botella antes de que afecten a los usuarios en un entorno real. Si realiza una actualización desde un entorno de Microsoft Office SharePoint Server 2007 y planea efectuar cambios en la arquitectura, o si está estimando la carga de usuarios de las nuevas características de SharePoint Server 2010, las pruebas son especialmente importantes para garantizar que el nuevo entorno basado en SharePoint Server 2010 cumpla con los objetivos de rendimiento y capacidad.

Una vez que haya probado el entorno, puede analizar los resultados de las pruebas para determinar qué cambios debe realizar para alcanzar los objetivos de rendimiento y capacidad que estableció en el Paso 1: Modelo de Planeación de la capacidad para SharePoint Server 2010.

Estos son los pasos secundarios recomendados que se deben seguir para la preproducción:

  • Cree el entorno de prueba de modo que imite la arquitectura inicial que diseñó en Paso 2: Diseño.

  • Rellene el almacenamiento con el conjunto de datos o con la parte del conjunto de datos que identificó en Paso 1: Modelo.

  • Fuerce el sistema con una carga sintética que represente la carga de trabajo que identificó en Paso 1: Modelo.

  • Ejecute pruebas, analice los resultados y optimice la arquitectura.

  • Implemente la arquitectura optimizada en el centro de datos y lleve a cabo un piloto con un grupo más pequeño de usuarios.

  • Analice los resultados del piloto, identifique los posibles cuellos de botella y optimice la arquitectura. Vuelva a realizar la prueba si es necesario.

  • Implemente en el entorno de producción.

Antes de leer este artículo, debe leer Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server 2010.

En este artículo:

  • Creación de un plan de pruebas

  • Creación del entorno de prueba

  • Creación de pruebas y herramientas

Creación de un plan de pruebas

Compruebe que el plan incluye:

  • Hardware que esté diseñado para funcionar según los objetivos de rendimiento de producción previstos. Siempre mida el rendimiento de los sistemas de prueba de forma conservadora.

  • Si dispone de código personalizado o de un componente personalizado, es importante que primero pruebe el rendimiento de estos componentes por separado para validar su rendimiento y estabilidad. Una vez comprobada su estabilidad, es conviene probar el sistema con dichos componentes instalados y comparar el rendimiento con el conjunto o granja de servidores sin instalarlos. Los componentes personalizados suelen ser una causa importante de problemas de rendimiento y confiabilidad en los sistemas de producción.

  • Conozca el objetivo de la prueba. Asegúrese de entender cuáles son los objetivos de la prueba antes de realizarla. ¿Se trata de validar el rendimiento de componentes personalizados nuevos que se desarrollaron para la granja de servidores? ¿Se trata de ver cuánto tiempo llevará rastrear e indizar un conjunto de contenido? ¿Se trata de determinar cuántas solicitudes por segundo puede admitir la granja de servidores? Una prueba puede tener muchos objetivos diferentes y el primer paso para desarrollar un plan de pruebas adecuado consiste en decidir cuáles serán los objetivos.

  • Entienda cómo se mide el objetivo de las pruebas. Si está interesado en medir la capacidad de proceso de la granja de servidores por ejemplo, le conviene medir las solicitudes por segundo y la latencia de página. Si va a medir el rendimiento de búsqueda, le conviene medir el tiempo de rastreo y las tasas de indización de documentos. Entender bien el objetivo de la prueba le ayudará a definir claramente los indicadores clave de rendimiento que necesita validar para llevarla a cabo.

Creación del entorno de prueba

Una vez que haya decidido cuáles son los objetivos de la prueba y definido las medidas, y después de establecer cuáles son los requisitos de capacidad de la granja de servidores (en los pasos 1 y 2 de este proceso), el siguiente objetivo es diseñar y crear el entorno de prueba. A menudo se subestima el esfuerzo necesario para crear un entorno de prueba. Debería intentar reproducir el entorno de producción con la mayor fidelidad posible. Algunas de las características y funcionalidad que debería tener en cuenta al diseñar el entorno de prueba son:

  • Autenticación: decida si la granja de servidores usará Servicios de dominio de Active Directory (AD DS), autenticación basada en formularios (y, en ese caso, con qué directorio), autenticación basada en notificaciones, etc. Independientemente del directorio que use, ¿cuántos usuarios necesita en el entorno de prueba y cómo va a crearlos? ¿Cuántos grupos o roles va a necesitar y cómo los creará y rellenará? También deberá asegurarse de que tiene suficientes recursos asignados a los servicios de autenticación para que no produzcan un cuello de botella durante la prueba.

  • DNS: sepa qué espacios de nombres necesitará durante las pruebas. Identifique qué servidores responderán a dichas solicitudes y asegúrese de contar con un plan que especifique las direcciones IP que usará cada servidor y qué entradas de DNS deberá crear.

  • Equilibrio de carga: si usa más de un servidor (lo cual es normal ya que de lo contrario no tendría suficiente carga para justificar una prueba de carga), necesitará algún tipo de solución de equilibrio de carga. Podría usar un hardware de equilibrio de carga, o bien algún software de equilibrio de carga, como Windows NLB. Decida qué usará y escriba toda la información de configuración que necesitará para configurar la solución con rapidez y eficacia. Otro punto que debe recordar es que los agentes de prueba de carga normalmente intentan resolver una dirección URL una sola vez cada 30 minutos. Esto significa que no le conviene usar un archivo de hosts local ni round robin DNS para equilibrar la carga ya que es probable que los agentes de prueba terminen recurriendo al mismo servidor para cada solicitud, en vez de equilibrar la carga entre todos los servidores disponibles.

  • Servidores de prueba: cuando planee el entorno de prueba, no solo deberá planear los servidores para la granja de servidores de SharePoint Server 2010 sino también las máquinas necesarias para ejecutar las pruebas. Por lo general, necesitará como mínimo tres servidores, aunque en algunos casos pueden necesitarse más. Si usa Visual Studio Team System (Team Test Load Agent) para realizar las pruebas, una máquina se usará como controlador de prueba de carga. Por lo general, se usan dos o más máquinas como agentes de prueba de carga. Los agentes son las máquinas que reciben las instrucciones del controlador de prueba sobre qué probar y emiten las solicitudes a la granja de servidores de SharePoint Server 2010. Los resultados de las pruebas se almacenan en un equipo basado en SQL Server. No le conviene usar el mismo equipo basado en SQL Server que usa para la granja de servidores de SharePoint Server 2010, ya que la escritura de los datos de prueba sesgará los recursos de SQL Server disponibles para la granja de servidores de SharePoint Server 2010. También debe supervisar los servidores de prueba durante su ejecución de la misma forma en que supervisaría los servidores de la granja de servidores de SharePoint Server 2010 o los controladores de dominio, etc. para asegurarse de que los resultados de las pruebas son representativos de la granja de servidores que está configurando. En algunos casos, los agentes de carga o el controlador pueden convertirse en cuellos de botella. En ese caso, la capacidad de proceso que se observa en la prueba normalmente no es la capacidad de proceso máxima que puede admitir la granja de servidores.

  • SQL Server: en el entorno de prueba, siga las recomendaciones de las secciones "Configuración de SQL Server" y "Validación y supervisión del almacenamiento y el rendimiento de SQL Server" del artículo Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010).

  • Validación de conjuntos de datos: al decidir qué contenido va a someter a prueba, recuerde que en el mejor de los casos usará datos de un sistema de producción existente. Por ejemplo, puede hacer una copia de seguridad de las bases de datos de contenido de una granja de servidores de producción y restaurarlas en el entorno de prueba y, a continuación, adjuntar las bases de datos para llevar el contenido a la granja de servidores. Cada vez que ejecute pruebas con datos inventados o de ejemplo, corre el riesgo de que los resultados sean sesgados a causa de las diferencias en el cuerpo de contenido.

Si debe crear datos de ejemplo, hay algunas consideraciones que debe tener en cuenta para crear dicho contenido:

  • Se deben publicar todas las páginas; no debe desprotegerse nada.

  • La navegación debe ser realista; no cree más que lo que espera usar razonablemente en producción.

  • Debe tener una idea de las personalizaciones que usará el sitio de producción. Por ejemplo, las páginas maestras, las hojas de estilos, JavaScript, etc. deben implementarse en el entorno de prueba de la forma más parecida posible al entorno de producción.

  • Determine cuántos grupos de SharePoint y niveles de permisos va a necesitar y cómo va a asociar a los usuarios con ellos.

  • Averigüe si necesitará importar perfiles y cuánto tiempo llevará el proceso.

  • Determine si va a necesitar audiencias y cómo va a crearlas y rellenarlas.

  • Determine si necesita orígenes de contenido de búsqueda adicionales y qué necesitará para crearlos. Si no necesitará crear ninguno, determine si tendrá acceso a la red para poder rastrearlos.

  • Determine si dispone de suficientes datos de ejemplo: documentos, listas, elementos de lista, etc. Si no es así, cree un plan que especifique el modo en que creará este contenido.

  • Tenga un plan para contar con suficiente contenido único para probar la búsqueda correctamente. Un error habitual es cargar el mismo documento (cientos o incluso miles de veces) a distintas bibliotecas de documentos con nombres diferentes. Esto puede afectar al rendimiento de búsqueda ya que el procesador de consultas pasará una cierta cantidad de tiempo detectando duplicados, lo cual no haría en un entorno de producción con contenido real.

Creación de pruebas y herramientas

Después de comprobar el funcionamiento del entorno de prueba, es momento de crear y ajustar las pruebas que se usarán para medir la capacidad de rendimiento de la granja de servidores. En esta sección a veces se hará referencia específicamente a Visual Studio Team System (Team Test Load Agent), pero muchos de los conceptos son aplicables a cualquier herramienta de prueba de carga que se use. Para obtener información acerca de Visual Studio Team System, vea el tema sobre Visual Studio Team System en MSDN (https://msdn.microsoft.com/es-es/library/fda2bad5.aspx").

También puede usar el Kit de pruebas de carga de SharePoint (LTK) junto con VSTS para realizar las pruebas de carga de las granjas de servidores de SharePoint 2010. El Kit de pruebas de carga genera una prueba de carga de Visual Studio Team System 2008 basada en Windows SharePoint Services 3.0 y registros IIS de Microsoft Office SharePoint Server 2007. La prueba de carga de VSTS se puede usar para generar carga sintética respecto de SharePoint Foundation 2010 o SharePoint Server 2010 como parte de un ejercicio de planeación de capacidad o de una prueba de esfuerzo previa a la actualización.

El Kit de pruebas de carga se incluye en el kit de herramientas de administración Microsoft SharePoint 2010 Administration Toolkit v1.0, disponible en el Centro de descarga de Microsoft (https://www.microsoft.com/downloads/en/details.aspx?FamilyId=718447d8-0814-427a-81c3-c9c3d84c456e\&displaylang=en).

Un criterio clave para el éxito de las pruebas es poder simular de forma eficaz una carga de trabajo realista generando solicitudes para una amplia gama de los datos del sitio de prueba, de la misma forma en que los usuarios tendrían acceso a una amplia gama de contenido en una granja de servidores de SharePoint Server 2010 de producción. Para ello, normalmente deberá crear las pruebas de forma tal que sean controladas por datos. En vez de crear cientos de pruebas individuales codificadas de forma rígida para obtener acceso a una página específica, debe usar tan solo unas pocas pruebas que usen orígenes de datos que contengan las direcciones URL de dichos elementos para obtener acceso dinámico a ese conjunto de páginas.

En Visual Studio Team System (Team Test Load Agent), un origen de datos puede proceder de una gran variedad de formatos, pero a menudo es más fácil administrar y transportar un formato de archivo CSV entre los entornos de desarrollo y de prueba. Tenga en cuenta que la creación de archivos CSV con dicho contenido puede requerir la creación de herramientas personalizadas para enumerar el entorno basado en SharePoint Server 2010 y registrar las distintas direcciones URL que se usan.

Es posible que deba usar herramientas para realizar tareas como las siguientes:

  • Crear usuarios y grupos en Active Directory u otro almacén de autenticación si usa autenticación basada en formularios

  • Enumerar las direcciones URL de sitios, listas y bibliotecas, elementos de lista, documentos, etc. y colocarlos en archivos CSV para las pruebas de carga

  • Cargar documentos de ejemplo en una gran variedad de bibliotecas de documentos y sitios

  • Crear colecciones de sitios, sitios web, listas, bibliotecas, carpetas y elementos de lista

  • Crear Mis sitios

  • Crear archivos CSV con nombres de usuario y contraseñas para usuarios de prueba; éstas son las cuentas de usuario con las que se ejecutarán las pruebas de carga. Debe haber varios archivos de forma tal que, por ejemplo, algunos contengan solo los usuarios administradores, algunos contengan otros usuarios con privilegios elevados (como autor o colaborador, administrador de jerarquía, etc.), y otros contengan solo lectores, etc.

  • Crear una lista de frases y palabras clave de búsqueda de ejemplo

  • Rellenar los grupos y niveles de permisos de SharePoint con usuarios y grupos de Active Directory (o roles si usa autenticación basada en formularios)

Al crear pruebas web, existen otros procedimientos recomendados que debería observar e implementar, como por ejemplo:

  • Registre pruebas web simples para empezar. Estas pruebas contendrán valores codificados de forma rígida para parámetros como dirección URL, identificador, etc. Reemplace los valores codificados de forma rígida con vínculos de los archivos CSV. Enlazar los datos de dichos valores en Visual Studio Team System (Team Test Load Agent) es muy sencillo.

  • Siempre tenga reglas de validación para la prueba. Por ejemplo, cuando solicite una página, si se produce un error, normalmente obtendrá la página error.aspx como respuesta. Desde la perspectiva de una prueba web aparece como si fuera una respuesta positiva más, ya que obtendrá un código de estado HTTP 200 (correcto) en la carga de los resultados de pruebas. Pero obviamente se ha producido un error, por lo que debería seguirse de manera diferente. Crear una o varias reglas de validación permite interceptar cuando cierto texto se envía como respuesta de forma tal que la validación produzca un error y la solicitud se marque como error también. Por ejemplo, en Visual Studio Team System (Team Test Load Agent), una regla de validación simple podría ser una validación ResponseUrl, que registra un error si la página que se representa después de los redireccionamientos no es la misma página de respuesta que se registró en la prueba. También puede agregar una regla de FindText que registre un error si encuentra la palabra "acceso denegado", por ejemplo, en la respuesta.

  • Use varios usuarios en distintos roles en las pruebas. Algunos comportamientos, como el almacenamiento en caché de los resultados, funcionan de forma diferente según los derechos del usuario actual. Por ejemplo, un administrador de una colección de sitios o un usuario autenticado con derechos de aprobación o de creación no obtendrán resultados almacenados en caché ya que siempre deseamos que vean la versión más reciente del contenido. Sin embargo, los usuarios anónimos obtendrán el contenido almacenado en caché. Debe asegurarse de que los usuarios de prueba representen una combinación de estos roles que coincida aproximadamente con la combinación de usuarios en el entorno de producción. Por ejemplo, en producción hay probablemente solo dos o tres administradores de colecciones de sitios, por lo que no es aconsejable crear pruebas en las que el 10% de las solicitudes de páginas son realizadas por cuentas de usuarios que son administradores de colecciones de sitios sobre el contenido de la prueba.

  • El análisis de las solicitudes dependientes es un atributo de Visual Studio Team System (Team Test Load Agent) que determina si el agente de prueba debería intentar recuperar solo la página, o la página y todas las solicitudes asociadas que forman parte de la página, como imágenes, hojas de estilos, scripts, etc. Durante una prueba de carga, estos elementos se suelen ignorar por varias razones:

    • Cuando un usuario visita un sitio por primera vez, el explorador local suele almacenar estos elementos en la memoria caché

    • Normalmente, estos elementos no proceden de SQL Server en un entorno basado en SharePoint Server 2010. Si el almacenamiento en caché BLOB está activado, estos elementos son procesados por los servidores web, por lo que no generan carga para SQL Server.

Si tiene regularmente un alto porcentaje de usuarios nuevos en el sitio, o si ha deshabilitado el almacenamiento en caché del explorador, o si por alguna razón no va a usar la memoria caché BLOB, entonces podría convenirle habilitar el análisis de solicitudes dependientes en las pruebas. Sin embargo, esto es realmente una excepción y no la regla general para la mayoría de las implementaciones. Tenga en cuenta que si se activa, puede inflar significativamente los números de RPS notificados por el controlador de prueba. Estas solicitudes se atienden tan rápidamente que pueden inducirle a pensar de forma errónea que hay más capacidad disponible en la granja de servidores que la que hay realmente.

  • Recuerde modelar la actividad de las aplicaciones cliente también. Las aplicaciones cliente, como Microsoft Word, PowerPoint, Excel y Outlook, generan solicitudes a granjas de servidores de SharePoint Server 2010 también. Agregan carga al entorno enviando a los servidores solicitudes tales como recuperar fuentes RSS, adquirir información social, solicitar detalles sobre la estructura de sitios y listas, sincronizar datos, etc. Estos tipos de solicitudes deben incluirse y modelarse si tiene estos clientes en su implementación.

  • En la mayoría de los casos, una prueba web debe contener una única solicitud. Es más fácil ajustar y solucionar los problemas del arnés de prueba y las solicitudes individuales si la prueba contiene una sola solicitud. Normalmente, las pruebas web deben contener varias solicitudes si la operación que está simulando se compone de varias solicitudes. Por ejemplo, para probar este conjunto de acciones necesitará una prueba con varios pasos: desproteger un documento, editarlo, protegerlo y publicarlo. También requiere la reserva de estado entre los pasos, por ejemplo, se debe usar la misma cuenta de usuario para desprotegerlo, realizar las modificaciones y volver a protegerlo. Estas operaciones de varios pasos que requieren transportar el estado de un paso al otro se atienden mejor mediante varias solicitudes en una sola prueba web.

  • Pruebe cada prueba web de forma individual. Asegúrese de que cada prueba puede completarse correctamente antes de ejecutarla en una prueba de carga más grande. Compruebe que todos los nombres de las aplicaciones web se resuelven y que las cuentas de usuario que se usan en la prueba tienen derechos suficientes para ejecutar la prueba.

Las pruebas web incluyen las solicitudes de páginas individuales, carga de documentos, visualización de elementos de lista, etc. Todo esto se combina en las pruebas de carga. Una prueba de carga es donde se conectan las diferentes pruebas web que se van a ejecutar. A cada prueba web se le puede dar un porcentaje de tiempo para ejecutarse, por ejemplo, si comprueba que el 10% de las solicitudes de una granja de servidores de producción son consultas de búsqueda, entonces en la prueba de carga debería configurar una prueba web de consulta que se ejecute el 10% del tiempo. En Visual Studio Team System (Team Test Load Agent), las pruebas de carga son también la forma en que se configuran elementos como la combinación de exploradores, la combinación de redes, los modelos de carga y la configuración de ejecución.

Hay algunos procedimientos adicionales que debería tener en cuenta e implementar para las pruebas de carga:

  • Use una proporción de lectura y escritura razonable en las pruebas. Si se sobrecarga el número de escrituras en una prueba, puede verse considerablemente afectada la capacidad de proceso general. Incluso en granjas de servidores de colaboración, las proporciones de lectura y escritura suelen incluir muchas más lecturas que escrituras. Para obtener más información, vea Casos prácticos técnicos de rendimiento y capacidad (SharePoint Server 2010).

  • Tenga en cuenta el impacto de otras operaciones con uso intensivo de recursos y decida si deberían estar realizándose durante la prueba de carga. Por ejemplo, operaciones como la copia de seguridad y restauración no se realizan normalmente durante una prueba de carga. Es posible que un rastreo de búsqueda completo no se ejecute durante una prueba de carga, mientras que un rastreo incremental puede ser normal. Debe considerar cómo se programarán estas tareas en producción: ¿se ejecutarán en los momentos de máxima carga? Si no es así, entonces deberían excluirse durante las pruebas de carga, cuando se intenta determinar la carga de estado de equilibrio máxima que puede admitir para el tráfico pico.

  • No use tiempos de reflexión. Los tiempos de reflexión son una característica de Visual Studio Team System (Team Test Load Agent) que permite simular el tiempo de la pausa que hacen los usuarios entre clics en una página. Por ejemplo, un usuario típico puede cargar una página, pasar tres minutos leyéndola y después hacer clic en un vínculo de la página para visitar otro sitio. Tratar de modelar esto en un entorno de prueba es prácticamente imposible de hacer de forma correcta y eficaz y no agrega valor a los resultados de las pruebas. Es difícil de modelar porque la mayoría de las organizaciones no tiene una forma de supervisar los diferentes usuarios y el tiempo que pasan entre clics en diferentes tipos de sitios de SharePoint (como sitios de publicación, de búsqueda, de colaboración, etc.). En realidad, tampoco agrega valor debido a que aunque un usuario pueda hacer una pausa entre las solicitudes de página, los servidores basados en SharePoint Server 2010 no lo hacen. Simplemente reciben un flujo sostenido de solicitudes que pueden tener picos y valles a lo largo del tiempo, pero no esperan inactivos mientras cada usuario hace una pausa antes de hacer clic en los diferentes vínculos de una página.

  • Comprenda la diferencia entre usuarios y solicitudes. Visual Studio Team System (Team Test Load Agent) tiene un modelo de carga que le pide que escriba el número de usuarios que desea simular. Esto no tiene nada que ver con los usuarios de las aplicaciones. En realidad, se trata simplemente del número de subprocesos que se van a usar en los agentes de prueba de carga para generar las solicitudes. Un error común es pensar que si la implementación tendrá, por ejemplo, 5.000 usuarios, 5.000 es el número que se debe usar en Visual Studio Team System (Team Test Load Agent). Esto es incorrecto. Es una de las muchas razones por las que al calcular los requisitos de planeación de capacidad, los requisitos de uso deben basarse en el número de solicitudes por segundo y no en el número de usuarios. En una prueba de carga de Visual Studio Team System (Team Test Load Agent), verá que suelen generarse cientos de solicitudes por segundo usando solo 50 a 75 "usuarios" de prueba de carga.

  • Use un modelo de carga constante para obtener resultados más reproducibles y confiables en las pruebas. En Visual Studio Team System (Team Test Load Agent) tiene la opción de basar la carga en un número constante de usuarios (subprocesos, como se explicó en el punto anterior), un modelo de carga de usuarios incremental o una prueba de uso basada en objetivos. Un modelo de carga incremental es cuando comienza con un número de usuarios menor y lo va incrementando agregando más usuarios cada pocos minutos. Una prueba de uso basada en objetivos es cuando se establece un umbral para un determinado contador de diagnóstico, como utilización de CPU, y la prueba intenta controlar la carga para mantener dicho contador entre un umbral mínimo y máximo definidos. Sin embargo, si solo desea determinar la capacidad de proceso máxima que puede admitir la granja de servidores de SharePoint Server 2010 durante los picos de carga, es más eficaz y preciso simplemente elegir un modelo de carga constante. Esto permite identificar más fácilmente la cantidad de carga que el sistema puede admitir antes de comenzar a exceder regularmente los umbrales que deberían mantenerse en una granja de servidores en buen estado.

Cada vez que ejecute una prueba de carga no olvide que se modifican datos en la base de datos. Ya sea que se trate de cargar documentos, editar elementos de listas o simplemente registrar actividad en la base de datos de uso, se escribirán algunos datos en SQL Server. Para garantizar un conjunto de resultados coherente y legítimo en cada prueba de carga, debe tener una copia de seguridad disponible antes de ejecutar la primera prueba de carga. Una vez finalizada cada prueba de carga, se debe usar la copia de seguridad para restaurar el contenido al estado en que se encontraba antes de iniciar la prueba.

See Also

Concepts

Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server 2010
Planeación de la capacidad para SharePoint Server 2010
Supervisión y mantenimiento de SharePoint Server 2010
Seguimiento de estado (SharePoint Server 2010)
Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010)