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 está actualizando desde un plan y entorno de Office SharePoint Server 2007 para realizar cambios en la arquitectura, o está estimando la carga del usuario de las nuevas características de SharePoint Server 2013, las pruebas tienen una especial importancia para garantizar que su 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 deben realizarse 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 subpasos recomendados que debe seguir para 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 que pruebe el rendimiento de dichos componentes en aislamiento primero para validar su rendimiento y estabilidad. Una vez que sean estables, debe probar el sistema con esos componentes instalados y comparar el rendimiento con la granja de servidores sin instalarlos. 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á Servicios de dominio de Active Directory (AD DS), la autenticación basada en formularios (y de ser así, con qué directorio), la autenticación basada en notificaciones, etc. Con independencia de qué directorio esté usando, ¿cuántos usuarios necesita en su entorno de prueba y cómo va a crearlos? ¿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 tenga qué direcciones IP se usarán por qué servidores, y qué entradas DNS tendrá que 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 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 de 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 de servidores 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 normalmente no es el máximo que puede admitir la granja de servidores.
SQL Server: en el entorno de prueba, siga las instrucciones de las secciones "Configure SQL Server" (Configurar SQL Server) y "Validate and monitor storage and SQL Server performance" (Validar y supervisar el almacenamiento y el rendimiento de SQL Server) en el artículo Storage and SQL Server capacity planning and configuration (SharePoint Server).
Validación del conjunto de datos: mientras decide con qué contenido va a ejecutar las pruebas, recuerde que en el mejor escenario de caso 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 y/o niveles de permiso va a necesitar, y cómo va a asociar a los usuarios con 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 orígenes de contenido de búsqueda adicionales y qué necesitará para crearlos. Si no necesita crearlos, determine si tendrá acceso a red para poder rastrearlos.
Determine si dispone de suficientes datos de ejemplo: documentos, listas, elementos de lista, etc. De no ser así, cree un plan para la manera en que creará este documento.
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 hora 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 la carga sintética frente a SharePoint Foundation 2010 o SharePoint Server 2010 como parte de un ejercicio de planificación de capacidad o una prueba de esfuerzo anterior a la actualización.
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ía que construir sus pruebas de manera que estén controladas por 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 (agente de carga de prueba), un origen de datos puede incluirse en varios formatos pero un formato de archivo CSV a menudo es más sencillo de administrar y transportar entre entornos de prueba y desarrollo. 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 de SharePoint y niveles de permiso con usuarios y grupos de Active Directory (o roles si está usando 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. Estas pruebas contendrán valores codificados de forma rígida para parámetros como direcciones URL, id., etc. Reemplace esos valores codificados de forma rígida por vínculos de sus archivos CSV. El enlace de datos de esos valores en Visual Studio Team System (agente de carga de prueba de equipo) es extremadamente sencillo.
Tenga siempre reglas de validación para su prueba. Por ejemplo, al solicitar una página, si se produce un error, obtendrá a menudo la página error.aspx como 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 prueba de equipo) una regla de validación simple podría ser una validación de ResponseUrl; registra un error si la página que se representa tras las redirecciones no es la misma página de respuesta que se registró en la prueba. También podría agregar una regla FindText que registrará un error si encuentra "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 colección de sitios o un usuario autenticado con derechos de aprobación o autoría no obtendrán resultados almacenados en caché porque siempre queremos que ellos 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 solo hay probablemente dos o tres administradores de colecciones de sitios, de manera que no debería crear pruebas en las que el 10% de las solicitudes de página se realicen por cuentas de usuario que son administradores de colecciones de sitios sobre el 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 blobs activado, usan en su lugar los servidores web de manera que no generan 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 usan con tanta rapidez que puede llevarle a pensar de manera equivocada que hay más capacidad disponible en la granja de servidores que lo que hay en realidad.
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 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: desprotección de un documento, su edición, protección y publicación. 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? De no ser así, probablemente deberían excluirse durante las pruebas de carga cuando esté tratando de determinar la carga máxima de momento estable que puede admitir para el tráfico de mayor actividad.
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.). Realmente no agrega valor porque aunque un usuario puede realizar pausas entres las solicitudes de página, los servidores basados en SharePoint Server 2013 no lo hacen. Solo obtienen una secuencia estable de solicitudes que puede tener máximos y mínimos a lo largo del tiempo, pero no esperan en inactividad cuando cada usuario realiza pausas entre los momentos en que hace clic en 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 usuarios de aplicaciones; solo se trata de 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, 5 000 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 Visual Studio Team System (agente de carga de prueba de equipo), descubrirá que a menudo puede generar cientos de solicitudes por segundo usando únicamente de 50 a 75 "usuarios" de prueba de carga.
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 ascendente 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á tratando de determinar el rendimiento máximo que su granja de servidores de SharePoint Server 2013 puede soportar durante la carga máxima, resulta más eficaz y preciso elegir únicamente un patrón de carga. 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 ejecuta una prueba de carga recuerde que está cambiando 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, la copia de seguridad debe usarse para restaurar el contenido de nuevo de la manera, antes de que se iniciara la prueba.
Consulte 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