Pruebas de rendimiento para SharePoint Server 2013
SE APLICA A:
2013 
2016 2019 Subscription Edition SharePoint en Microsoft 365
En este artículo se describe la manera de probar el rendimiento de SharePoint Server 2013. La fase de pruebas y optimización es un componente fundamental de administración de capacidad efectiva. Debe probar nuevas arquitecturas antes de implementarlas en producción y debe realizar pruebas de aceptación con los siguientes procedimientos recomendados de supervisión para asegurarse de que las arquitecturas que diseña logran los objetivos de rendimiento y capacidad. Esto le permite identificar y optimizar posibles cuellos de botella antes de que tengan un impacto en los usuarios en una implementación en directo. Si va a actualizar desde un entorno de Office SharePoint Server 2007 y planea realizar cambios en la arquitectura, o está estimando la carga del usuario de las nuevas características de SharePoint Server 2013, las pruebas son importantes para asegurarse de que el nuevo entorno basado en SharePoint Server 2013 cumplirá los objetivos de rendimiento y capacidad.
Una vez que haya probado el entorno, puede analizar los resultados de las pruebas para determinar qué cambios se deben realizar para lograr los objetivos de rendimiento y capacidad que estableció en Paso 1: Planeamiento del modelo de capacidad para SharePoint Server 2013.
Estos son los pasos secundarios recomendados que debe seguir para la preproducción:
Cree el entorno de prueba que imita la arquitectura inicial que ha diseñado en el Paso 2: diseñar.
Rellenar el almacenamiento con el conjunto de datos o con una parte del conjunto de datos que ha identificado en el Paso 1: modelar.
Realizar una prueba de esfuerzo en el sistema con una carga sintética que represente la carga de trabajo que ha identificado en el Paso 1: modelar.
Ejecutar pruebas, analizar los resultados y optimizar la arquitectura.
Implemente la arquitectura optimizada en el centro de datos y aplique un piloto con un conjunto menor de usuarios.
Analice los resultados de piloto, identifique los posibles cuellos de botella y optimice la arquitectura. Vuelva a probar en caso necesario.
Implemente en el entorno de producción.
Antes de leer este artículo, debe leer Información general sobre el ajuste de tamaño y la administración de la capacidad de SharePoint Server 2013.
Crear un plan de prueba
Compruebe que su plan incluye:
Hardware diseñado para operar en destinos de rendimiento de producción esperados. Mida siempre el rendimiento de los sistemas de prueba de manera más conservadora.
Si tiene código personalizado o componente personalizado, es importante probar primero el rendimiento de esos componentes de forma aislada para validar su rendimiento y estabilidad. Una vez que son estables, debe probar el sistema con esos componentes instalados y comparar el rendimiento con la granja sin que estén instalados. Los componentes personalizados a menudo son la causa de problemas de rendimiento y fiabilidad en sistemas de producción.
Conozca el objetivo de sus pruebas. Comprenda de antemano cuáles son sus objetivos de las pruebas. ¿Es validar el rendimiento de algunos componentes personalizados nuevos que se desarrollaron para la granja de servidores? ¿Es ver cuánto tiempo tardará en rastrear e indizar un conjunto de contenido? ¿Es determinar cuántas solicitudes por segundo puede admitir su granja de servidores? Puede haber diferentes objetivos durante una prueba y el primer paso en el desarrollo de un buen plan de pruebas de artículo es decidir cuáles son sus objetivos.
Comprenda la manera de medir para su objetivo de prueba. Si está interesado en medir la capacidad de rendimiento de la granja de servidores, por ejemplo, querrá medir el RPS y la latencia de página. Si va a medir el rendimiento de la búsqueda, querrá medir el tiempo de rastreo y las tasas de indexación de documentos. Si su objetivo de prueba se comprende bien, eso le ayudará a definir con claridad qué indicadores de rendimiento clave necesita validar para completar sus pruebas.
Crear el entorno de prueba
Una vez que se han decidido sus objetivos de prueba, se han definido sus medidas y ha determinado cuáles son los requisitos de capacidad para su granja de servidores (de los pasos 1 y 2 de este proceso), el siguiente objetivo será diseñar y crear el entorno de prueba. A menudo se subestima el esfuerzo de crear un entorno de prueba. Debería duplicar el entorno de producción tan cuidadosamente como sea posible. Entre las características y funcionalidad que debe tener en cuenta al diseñar su entorno de prueba se incluyen las siguientes:
Autenticación: decida si la granja de servidores usará Active Directory Domain Services (AD DS), la autenticación basada en formularios (y si es así con qué directorio), la autenticación basada en notificaciones, etc. Independientemente del directorio que use, ¿cuántos usuarios necesita en el entorno de prueba y cómo los va a crear? ¿Cuántos grupos o roles va a necesitar y cómo va a crearlos y rellenarlos? También tiene que asegurarse de que dispone de suficientes recursos asignados a sus servicios de autenticación que no se convierten en un cuello de botella durante las pruebas.
DNS: sepa cuáles son los espacios de nombres que necesitará durante las pruebas. Identifique qué servidores responderán a esas solicitudes y asegúrese de que ha incluido un plan que tiene qué direcciones IP usarán los servidores y qué entradas DNS necesitará crear.
Equilibrio de carga: suponiendo que usa más de un servidor (que normalmente lo haría o que probablemente no tendría suficiente carga para garantizar las pruebas de carga), necesitará algún tipo de solución de equilibrador de carga. Podría ser un dispositivo de equilibrio de carga de hardware o podría usar el equilibrio de carga de software como Windows NLB. Averigüe lo que usará y anote toda la información de configuración que necesitará para configurarla de forma rápida y eficaz. Otra cosa que hay que recordar es que los agentes de prueba de carga suelen intentar resolver la dirección en una dirección URL solo una vez cada 30 minutos. Esto significa que no debe usar un archivo de hosts local o un DNS round robin para el equilibrio de carga, ya que es probable que los agentes de prueba terminen yendo al mismo servidor para cada solicitud única, en lugar de equilibrar todos los servidores disponibles.
Servidores de prueba: al planear el entorno de prueba, no solo debe planear los servidores para la granja de servidores de SharePoint Server 2013, sino que también debe planear las máquinas necesarias para ejecutar las pruebas. Normalmente, incluirá tres servidores como mínimo; más puede ser necesario. Si usa Visual Studio Team System (Agente de carga de pruebas en equipo) para realizar las pruebas, se usará una máquina como controlador de prueba de carga. Por lo general, hay dos o más máquinas que se usan como agentes de prueba de carga. Los agentes son las máquinas que toman las instrucciones del controlador de prueba sobre qué probar y emitir las solicitudes a la granja de servidores de SharePoint Server 2013. Los propios resultados de la prueba se almacenan en un equipo basado en SQL Server. No debe usar el mismo equipo basado en SQL Server que se usa para la granja de servidores de SharePoint Server 2016, ya que escribir los datos de prueba sesgará los recursos de SQL Server disponibles para la granja de servidores de SharePoint Server 2013. También debe supervisar los servidores de prueba al ejecutar las pruebas, de la misma manera que supervisaría los servidores de la granja de servidores de SharePoint Server 2013, o controladores de dominio, etc., para asegurarse de que los resultados de la prueba son representativos de la granja que está configurando. A veces, los agentes de carga o el controlador pueden convertirse en el cuello de botella. Si esto sucede, el rendimiento que verá en la prueba no suele ser el máximo compatible con la granja de servidores.
SQL Server: en el entorno de prueba, siga las instrucciones de las secciones "Configurar SQL Server" y "Validar y supervisar el almacenamiento y el rendimiento de SQL Server" en el artículo Planeamiento y configuración de capacidad de Almacenamiento y SQL Server (SharePoint Server).
Validación del conjunto de datos: a medida que decida en qué contenido va a ejecutar pruebas, recuerde que, en el mejor de los casos, usará datos de un sistema de producción existente. Por ejemplo, puede realizar una copia de seguridad de las bases de datos de contenido de una granja de servidores de producción y restaurarlas en su entorno de prueba y, a continuación, adjuntar las bases de datos para incorporar el contenido en la granja de servidores. En cualquier momento que ejecute las pruebas frente a datos inventados o de ejemplo, corre el riesgo de tener los resultados sesgados debido a las diferencias en el corpus del contenido.
Si no tiene que crear datos de ejemplo, hay algunas cuestiones que debe tener en cuenta mientras crea dicho contenido:
Se deben publicar todas las páginas; no se debe desproteger nada
La navegación debe ser realista; no compile más allá de lo que esperaría de manera razonable usar en producción.
Debe tener una idea de las personalizaciones que el sitio de producción estará usando. Por ejemplo, páginas maestras, hojas de estilos, JavaScript, etc., todas ellas se deben implementar en el entorno de prueba de la manera más cuidadosa posible en el entorno de producción.
Determine cuántos grupos de SharePoint o niveles de permisos va a necesitar y cómo va a asociar usuarios a ellos.
Resuelva si necesitará realizar importaciones de perfiles y cuánto tiempo tardará esa operación.
Determine si necesitará Audiencias y cómo las creará y rellenará.
Determine si necesita más orígenes de contenido de búsqueda y qué necesitará para crearlos. Si no necesita crearlos, determine si tendrá acceso a red para poder rastrearlos.
Determine si tiene suficientes datos de ejemplo: documentos, listas, elementos de lista, etc. Si no es así, cree un plan para crear este contenido.
Tenga un plan para que suficiente contenido único realice de manera adecuada la búsqueda de prueba. Un error habitual es cargar el mismo documento, puede que cientos e incluso miles de veces, en diferentes bibliotecas de documentos con nombres distintos. Eso puede tener un impacto en el rendimiento de la búsqueda porque el procesador de consultas pasará un cantidad ordenada de tiempo realizando detección duplicada que de otra manera no tendría que hacerla en un entorno de producción con contenido real.
Crear pruebas y herramientas
Una vez que el entorno de prueba es funcional, es el momento de crear y ajustar las pruebas que se usarán para medir la capacidad de rendimiento de la granja de servidores. Esta sección a veces hará referencias de manera específica a Visual Studio Team System (agente de carga de prueba de equipo), pero muchos de los conceptos son aplicables con independencia de qué herramienta de prueba de carga utilice. Para obtener más información sobre las herramientas de prueba disponibles para Azure DevOps (anteriormente VSTS), consulte Información general sobre las herramientas de DevOps para Azure DevOps.
También puede usar el Kit de pruebas de carga (LTK) de SharePoint con VSTS para pruebas de carga de granjas de Servidores de SharePoint 2010. El kit de prueba de carga genera una prueba de carga de Visual Studio Team System 2008 en los registros de Windows SharePoint Services 3.0 y Microsoft Office SharePoint Server 2007 IIS. La prueba de carga de VSTS se puede usar para generar carga sintética en SharePoint Foundation 2010 o SharePoint Server 2010 como parte de un ejercicio de planeamiento de la capacidad o una prueba de esfuerzo pregrade.
El kit de prueba de carga se incluye en microsoft SharePoint 2010 Administration Toolkit v2.0, disponible en el Centro de descarga de Microsoft.
Un criterio clave para el éxito de las pruebas es poder simular de manera efectiva una carga realista generando solicitudes en una amplia gama de datos de sitios de pruebas, de la misma manera que los usuarios obtendrían acceso a una amplia gama de contenido en una granja de servidores de SharePoint Server 2013 de producción. Para ello, normalmente tendrá que construir las pruebas de forma que se controlen los datos. En lugar de crear cientos de pruebas individuales que están codificadas de forma rígida para obtener acceso a una página específica, debería usar solo algunas pruebas que usen orígenes de datos que contengan las direcciones URL para que esos elementos obtengan acceso dinámicamente a ese conjunto de páginas.
En Visual Studio Team System (Team Test Load Agent), un origen de datos puede aparecer en varios formatos, pero un formato de archivo CSV suele ser más fácil de administrar y transportar entre entornos de desarrollo y pruebas. Tenga presente 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 2013 y registrar las distintas direcciones URL que se están usando.
Puede que necesite utilizar herramientas para tareas como las siguientes:
Creación de usuarios y grupos en Active Directory u otro almacén de autenticación si está usando autenticación basada en formularios
Enumeración de direcciones URL para sitios, listas y bibliotecas, elementos de lista, documentos, etc. e inclusión de ellos en archivos CSV para pruebas de carga
Carga de documentos de muestra en una gama de sitios y bibliotecas de documentos
Creación de colecciones de sitios, páginas web, listas, bibliotecas, carpetas y elementos de lista
Creación de Mis sitios
Creación de archivos CSV con nombres de usuario y contraseñas para usuarios de prueba; estas son las cuentas de usuario con las que se ejecutarán las pruebas de carga. Podría haber varios archivos de manera que, por ejemplo, algunos contengan únicamente usuarios de administrador, otros usuarios contengan otros usuarios con privilegios elevados (como autor/colaborador, administrador de jerarquías, etc.) y otros son solo lectores, etc.
Creación de una lista de frases y palabras clave de búsqueda de muestra
Rellenar grupos y niveles de permisos de SharePoint con usuarios y grupos de Active Directory (o roles si usa la autenticación basada en formularios)
Al crear las pruebas web, hay otros procedimientos recomendados que debería observar e implementar. Entre ellos se incluyen:
Registre las pruebas web sencillas como punto de partida. Esas pruebas tendrán valores codificados de forma rígida en ellos para parámetros como url, identificadores, etc. Reemplace esos valores codificados de forma rígida por vínculos de los archivos CSV. El enlace de datos de esos valores en Visual Studio Team System (Agente de carga de pruebas de equipo) es fácil.
Tenga siempre reglas de validación para su prueba. Por ejemplo, al solicitar una página, si se produce un error, a menudo obtendrá la página error.aspx en respuesta. Desde una perspectiva de prueba web, aparece como otra respuesta positiva, ya que se obtiene un código de estado HTTP de 200 (correcto) en los resultados de la prueba de carga. Obviamente, se ha producido un error por lo que se debería realizar un seguimiento de ese asunto de manera diferente. La creación de una o más reglas de validación le permite capturar cuando se envía determinado texto como respuesta de manera que se produce un error en la validación y la solicitud se marca como error. Por ejemplo, en Visual Studio Team System (Agente de carga de pruebas de equipo) una regla de validación simple podría ser una validación ResponseUrl: 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 FindText que registrará un error si encuentra la palabra "acceso denegado", por ejemplo, en la respuesta.
Use varios usuarios en diferentes roles para pruebas. Determinados comportamientos como el almacenamiento del resultado funcionan de manera diferente en función de los derechos del usuario actual. Por ejemplo, un administrador de la colección de sitios o un usuario autenticado con derechos de aprobación o de creación no obtendrán resultados almacenados en caché porque siempre queremos que vean la versión más actual del contenido. Sin embargo, los usuarios anónimos, obtendrán el contenido almacenado en caché. Tiene que asegurarse de que los usuarios de prueba se encuentran en una mezcla de estos roles que aproximadamente coincide con la mezcla de usuarios del entorno de producción. Por ejemplo, en producción probablemente solo haya dos o tres administradores de colecciones de sitios, por lo que no debe crear pruebas en las que el 10 % de las solicitudes de página las realizan cuentas de usuario que son administradores de colecciones de sitios a través del contenido de prueba.
Las solicitudes dependientes de análisis son un atributo de un Visual Studio Team System (agente de carga de prueba de equipo) que determina si el agente de prueba debe tratar de recuperar solo la página o bien, la página y todas las solicitudes asociadas que forman parte de ella, como imágenes, hojas de estilos, scripts, etc. Al realizar las pruebas de la carga, solemos omitir estos elementos por algunos motivos:
Después de que un usuario visite un sitio por primera vez, estos elementos se almacenan a menudo en caché por el navegador local
Estos elementos no suelen proceder de SQL Server en un entorno basado en SharePoint Server 2013. Con el almacenamiento en caché de BLOB activado, en su lugar los atienden los servidores web para que no generen la carga de SQL Server.
Si habitualmente tiene un alto porcentaje de usuarios que visitan su sitio por primera vez, o ha deshabilitado el almacenamiento en caché del explorador o bien, por algún motivo no pretende usar la memoria caché BLOB, puede que tenga sentido habilitar las solicitudes dependientes de análisis en sus pruebas. Sin embargo, esto realmente es la excepción y no la regla general para la mayoría de las implementaciones. Tenga en cuenta que si activa esto puede inflar de manera significativa los números de RPS notificados por el controlador de prueba. Estas solicitudes se atienden tan rápidamente que puede inducirle a pensar que hay más capacidad disponible en la granja de servidores de la que realmente existe.
Recuerde modelar también la actividad de la aplicación del cliente. Las aplicaciones cliente, como Microsoft Word, PowerPoint, Excel y Outlook, también generan solicitudes a granjas de servidores de SharePoint Server 2013. Agregan carga al entorno enviando las solicitudes de servidor como recuperando fuentes RSS, adquiriendo información social, solicitando datos sobre la estructura de la lista y el sitio, sincronizando datos, etc. Estos tipos de solicitudes deben incluirse y modelarse si tiene dichos clientes en su implementación.
En la mayoría de los casos una prueba web solo debe contener una solicitud única. Es más sencillo ajustar y solucionar problemas de su agente de pruebas y solicitudes individuales si la prueba solo contiene una solicitud única. Las pruebas web normalmente tendrán que 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: extraer 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 protegerlo, realizar las ediciones y volverlo a proteger. Esas operaciones de varios pasos que requieren que el estado se avance entre cada paso se atienden mejor por varias solicitudes en una prueba web única.
Pruebe cada prueba web de manera individual. Asegúrese de que cada prueba puede completarse de manera correcta antes de que se ejecute en una prueba de carga mayor. Compruebe que se resuelven todos los nombres para aplicaciones web y que las cuentas de usuario utilizadas en la prueba tienen derechos suficientes para ejecutar la prueba.
Las pruebas web constan de las solicitudes para páginas individuales, carga de documentos, elementos de listas de vistas, etc. Todos ellos se reúnen en pruebas de carga. Una prueba de carga es donde conecta todas las diferentes pruebas web que se van a ejecutar. A cada prueba web se le puede dar un porcentaje de tiempo que se ejecutará; por ejemplo, si encuentra que el 10 % de las solicitudes de una granja de servidores de producción son consultas de búsqueda, en la prueba de carga configuraría una prueba web de consulta para ejecutar el 10 % del tiempo. En Visual Studio Team System (agente de carga de prueba de equipo), las pruebas de carga también son la manera en que configura aspectos como la mezcla del explorador, la mezcla de red, los patrones de carga y la configuración de la ejecución.
Estos son algunos procedimientos recomendados adicionales que se deben observar e implementar para las pruebas de carga:
Use una relación entre lectura y escritura razonable en sus pruebas. La sobrecarga del número de escrituras en una prueba puede producir un impacto importante en el rendimiento general de una prueba. Incluso en granjas de servidores de colaboración, las relaciones entre lectura/escritura tienden a tener muchas más lecturas que escrituras.
Piense en el impacto de otras operaciones intensivas de recursos y decida si deberían estar produciéndose durante la prueba de carga. Por ejemplo, las operaciones como las copias de seguridad y la restauración no se suelen realizar durante una prueba de carga. Puede que un rastreo de búsqueda completo no se suela ejecutar durante una prueba de carga, mientras que un rastreo incremental puede ser normal. Tiene que pensar cómo se programarán esas tareas en producción: ¿se ejecutarán en momentos de cargas máximas? Si no es así, es probable que se excluyan durante las pruebas de carga, cuando se intenta determinar la carga de estado estable máxima que puede admitir para el tráfico máximo.
No utilice los tiempos de reflexión. Los tiempos de reflexión son una característica de Visual Studio Team System (agente de carga de prueba de equipo) que le permite simular el tiempo en que los usuarios realizan pausas entre los momentos en que hacen clic en una página. Por ejemplo, un usuario típico podría cargar una página, pasar tres minutos leyéndola y, a continuación, hacer clic en un vínculo de la página para visitar otro sitio. Tratar de crear un modelo de esto en un entorno de prueba es casi imposible de lograr de manera correcta, y hacerlo de manera eficaz no agrega valor a los resultados de la prueba. Resulta difícil crear un modelo ya que la mayoría de las organizaciones no disponen de una manera de supervisar a diferentes usuarios y el tiempo que pasa entre los momentos que hacen clic en diferentes tipos de sitios de SharePoint (como publicación frente a búsqueda frente a colaboración, etc.). Tampoco agrega realmente valor porque, aunque un usuario pueda pausar entre solicitudes de página, los servidores basados en SharePoint Server 2013 no lo hacen. Simplemente obtienen un flujo constante de solicitudes que pueden tener picos y valles a lo largo del tiempo, pero no están esperando de forma indesginada, ya que cada usuario se pausa entre hacer clic en los vínculos de una página.
Comprenda la diferencia entre usuarios y solicitudes. Visual Studio Team System (agente de carga de prueba de equipo) tiene patrón de carga donde le pide especificar el número de usuarios que desea simular. Esto no tiene nada que ver con los usuarios de la aplicación, es solo cuántos subprocesos se van a usar en los agentes de prueba de carga para generar solicitudes. Un error común es pensar que si la implementación tendrá 5 000 usuarios, por ejemplo, 5000 es el número que se debe usar en Visual Studio Team System (Agente de carga de pruebas en equipo), no lo es. Esa es una de las numerosas razones por las que cuando estimamos 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 (Agente de carga de pruebas de equipo), encontrará que a menudo puede generar cientos de solicitudes por segundo con solo "usuarios" de prueba de carga de 50 a 75.
Use un patrón de carga constante para los resultados de prueba más fiables y reproducibles. En Visual Studio Team System (Agente de carga de pruebas de equipo), tiene la opción de basar la carga en un número constante de usuarios (subprocesos, como se explicó en el punto anterior), un patrón de carga intensificado de usuarios o una prueba de uso basada en objetivos. Un patrón de carga escalonado es cuando empieza con un número menor de usuarios y después "escalona" agregando más usuarios cada pocos minutos. La prueba de uso basada en objetivos es cuando establece un umbral para un contador de diagnóstico determinado, como el uso de la CPU, y los intentos de la prueba de dirigir la carga para conservar ese contador entre un umbral mínimo y máximo que defina para ello. Sin embargo, si solo está intentando determinar el rendimiento máximo que puede mantener la granja de SharePoint Server 2013 durante la carga máxima, es más eficaz y preciso elegir un patrón de carga constante. Eso le permite identificar con mayor facilidad cuánta carga puede asumir el sistema antes de empezar a superar de manera habitual los umbrales que se deben mantener en una granja de servidores con un estado correcto.
Cada vez que ejecute una prueba de carga, recuerde que cambia los datos de la base de datos. Ya esté cargando documento, editando elementos de lista o simplemente registrando la actividad de la base de datos de uso, habrá datos que se escriban en SQL Server. Para garantizar un conjunto coherente y legítimo de resultados de prueba de cada prueba de carga, debe tener una copia de seguridad disponible antes de ejecutar la primera prueba de carga. Una vez completada cada prueba de carga, se debe usar la copia de seguridad para restaurar el contenido de nuevo de la manera, antes de que se iniciara la prueba.
Vea también
Conceptos
Planeación de capacidad para SharePoint Server 2013
Supervisión y mantenimiento de SharePoint Server 2013
Restricciones y límites del software de SharePoint Server 2016