Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
Planificación de la capacidad para Microsoft SharePoint 2010Características de Mis sitios y sistemas socialesEste documento se proporciona “tal cual”. Es posible que la información y los puntos de vista reflejados en este documento, incluidas las direcciones URL y otras referencias a sitios web de Internet, cambien sin previo aviso. El usuario asume el riesgo de su uso.
Algunos ejemplos descritos en este documento se proporcionan únicamente con fines ilustrativos y son ficticios. No se pretende indicar ni debe deducirse ninguna asociación ni conexión real.
Este documento no otorga ningún derecho legal sobre la propiedad intelectual e industrial de ningún producto de Microsoft. Este documento puede copiarse y usarse para fines internos y de referencia.
© 2010 Microsoft Corporation. Todos los derechos reservados.
Planificación de la capacidad para Microsoft SharePoint 2010Características de Mis sitios y sistemas sociales
Gaurav Doshi, Wenyu CaiMicrosoft CorporationSe aplica a: Microsoft SharePoint Server 2010Resumen: Estas notas del producto proporcionan recomendaciones acerca del rendimiento y de la planificación de la capacidad para un portal de Mis sitios y sistemas sociales basado en Microsoft® SharePoint® 2010. Estos documentos abarcan:
Especificaciones de entorno de pruebas como hardware, topología de conjunto o granja de servidores y configuración
Conjunto de datos de granja de servidores de prueba Datos de prueba y recomendaciones para determinar el hardware, la topología y la
configuración necesarios para implementar un entorno similar y para optimizar el entorno para las características de rendimiento y capacidad adecuadas.
Tabla de contenidoResumen ejecutivo …………………………………………………………………………………………………………………………….4
Introducción 5
Escenario 5
Suposiciones y requisitos previos 5
Glosario 5
Introducción 7
Enfoque de ajuste de escala 7
Correlación entre el entorno de laboratorio y un entorno de producción 7
Notas de pruebas 8
Configuración de pruebas…………………………………………………………………………………………………………………..9
Hardware 9
Software 9
Topología y configuración 10
Geometría de conjunto de datos y de disco 11
Mezcla transaccional 12
Resultados y análisis 15
Comparación de todas las iteraciones 15
Efecto del rastreo de búsqueda de personas 19
Análisis 20
Recomendaciones 23
Apéndice 24
Resumen ejecutivoEn general, aquí se presentan las conclusiones clave de nuestras pruebas para el portal de Mis sitios y sistemas sociales:
- Se incrementó la escalabilidad vertical del entorno hasta ocho servidores front-end web para un servidor de aplicaciones y un servidor de bases de datos; el aumento en el rendimiento fue prácticamente lineal todo el tiempo. Después de ocho servidores front-end web, no se obtuvo ninguna ganancia adicional en el rendimiento al agregar más servidores front-end web. Esto se debe a que el cuello de botella en ese momento era el uso de la CPU del servidor de bases de datos.
- Se puede alcanzar más escala si se separan la base de datos de contenido y la base de datos de servicios en dos servidores de bases de datos independientes.
- Se alcanzó el potencial máximo de la topología 8x1x2. En este caso, el uso del servidor front-end web y el uso de CPU del servidor de aplicaciones eran el cuello de botella. Esto nos lleva a pensar que, para el hardware, el conjunto de datos y la carga de trabajo de prueba especificados, el número máximo posible de solicitudes por segundo (RPS) está representado por las RPS de la zona roja para 8x1x2, que es aproximadamente 1.877 RPS.
- Al observar las tendencias, parece posible obtener el mismo rendimiento con una granja de servidores en buen estado si se resuelven los cuellos de botella del servidor front-end web y el servidor de aplicaciones. El cuello de botella del servidor front-end web se puede resolver agregando más servidores front-end web. A su vez, el cuello de botella del servidor de aplicaciones puede solucionarse mediante el uso de dos equipos que desempeñen el rol de servidor de aplicaciones. Pero no lo probamos en el laboratorio.
- La latencia no se ve afectada por las variaciones de rendimiento o de hardware. - Si tiene activado el recorte de seguridad, un servidor front-end web puede admitir unos 8 o 10
RPS de tráfico de Outlook Social Connector. Esto significa que un servidor front-end web puede admitir aproximadamente entre 28.000 y 36.000 empleados que usen Outlook Social Connector todo el día. Por lo tanto, si desea implementar Outlook Social Connector para 100.000 empleados, puede admitir el tráfico que se genere con tres servidores front-end web. Estos valores pueden variar en función del uso de etiquetas temáticas en su empresa. Si cree que su empresa tendrá menos actividad de etiquetas temáticas que la que se usó en el conjunto de datos de este trabajo de comprobación, puede que el rendimiento por servidor front-end web sea mejor.
- El rastreo incremental de búsqueda de personas no tiene un efecto considerable en el rendimiento de la granja de servidores siempre y cuando esta se mantenga en buen estado.
IntroducciónEscenario
En este documento se describe la metodología de prueba y los resultados para proporcionar asistencia para la planificación de la capacidad de un portal de sistemas sociales. Un portal de sistemas sociales es una implementación de Microsoft® SharePoint® 2010 en la que cada miembro de la empresa mantiene un perfil de usuario, busca expertos en la empresa, se conecta con otros empleados mediante suministros de noticias y mantiene un sitio personal para el almacenamiento y uso compartido de documentos. Además del tráfico provocado por las características de sistemas sociales, los usuarios que cargan, comparten, visualizan y actualizan documentos en sus sitios personales crean un tráfico de colaboración habitual significativo. Esperamos que estos resultados le ayuden a diseñar un portal independiente dedicado a características de Mis sitios y sociales.
Cada escenario tiene distintos requisitos, por lo que es importante complementar estas recomendaciones con pruebas adicionales en su propio hardware y en su propio entorno.
Cuando lea este documento, entenderá cómo:
Calcular el hardware necesario para admitir la escala que debe admitir: cantidad de usuarios, carga y características habilitadas.
Diseñar la topología física y lógica para ofrecer una fiabilidad y eficiencia óptimas. Este documento no trata sobre la disponibilidad alta ni la recuperación ante desastres.
Tener en cuenta el efecto del rastreo continuo de búsqueda de personas y sincronizaciones de perfiles en las RPS de una implementación similar al portal de sistemas sociales.
Antes de leer este documento, debe leer lo siguiente:
Planificación de la capacidad y ajuste del tamaño para los productos y las tecnologías de Microsoft SharePoint 2010
Restricciones del software de Office SharePoint Server 2010 Caso práctico técnico de SharePoint Server 2010: Entorno social, disponible en TechNet para
descargarlo
Si está interesado en leer recomendaciones para la planificación de la capacidad en escenarios de colaboración típicos, lea: Estudio de laboratorio sobre la capacidad de SharePoint Server 2010: Solución de colaboración en intranet empresarial
Suposiciones y requisitos previos No hay código personalizado que se ejecute en la implementación del portal de sistemas
sociales en este caso. No podemos garantizar el comportamiento del código personalizado ni de las soluciones de terceros que estén instalados en su portal Mi sitio y de sistemas sociales.
El modo de autenticación usado fue NTLM.
GlosarioEn este documento encontrará algunos términos especializados. Estos son algunos términos clave y sus definiciones:
RPS: solicitudes por segundo. El número de solicitudes que recibe un conjunto o granja de servidores o un servidor en un segundo. Se trata de una medida común de la carga de servidores y granjas de servidores. Tenga en cuenta que las solicitudes son diferentes de las cargas de página; cada página contiene varios componentes, cada uno de los cuales crea una o varias solicitudes cuando se carga la página. Por lo tanto, una carga de página crea varias solicitudes. Normalmente, los eventos y las comprobaciones de autenticación que consumen una cantidad desdeñable de recursos no se cuentan en las mediciones de RPS.
Zona verde: es el estado en el que el servidor puede mantener el siguiente conjunto de criterios. o La latencia del servidor de al menos el 75% de las solicitudes es menor que 0,5 segundos.
o Todos los servidores tienen un uso de CPU inferior al 50%. Nota: Como este entorno de laboratorio no tenía un rastreo de búsqueda activa en ejecución, el servidor de bases de datos mantuvo un uso de CPU del 40% o inferior para reservar el 10% para la carga del rastreo de búsqueda. Se supone que el regulador de recursos de Microsoft SQL Server® se usa en producción para limitar la carga del rastreo de búsqueda al 10% de CPU.
o La frecuencia de errores es inferior al 0,01%.
Zona roja: es el estado en el que el servidor puede mantener el siguiente conjunto de criterios.o La característica de limitación de solicitudes HTTP está habilitada, pero no se devuelve
ningún error 503 (servidor ocupado).
o La frecuencia de errores es inferior al 0,1%.
o La latencia del lado servidor es inferior a 1 segundo para al menos el 75% de las solicitudes.
o El servidor de bases de datos realiza un uso de CPU inferior al 80%, lo que permite reservar un 10% para la carga del rastreo de búsqueda, que se limita mediante el regulador de recursos de SQL Server.
AxBxC (notación gráfica): se trata del número de servidores web, servidores de aplicaciones y servidores de bases de datos presentes en una granja de servidores. Por ejemplo, 8x1x2 significa que este entorno tiene ocho servidores web, un servidor de aplicaciones y dos servidores de bases de datos.
Carga VSTS: subprocesos que Visual Studio Team System (VSTS) usa internamente para simular usuarios virtuales. Usamos el incremento de la carga VSTS para generar cada vez más RPS para la topología.
Información generalEnfoque de ajuste de escalaEn esta sección se describe el orden específico recomendado para escalar los equipos del entorno; es el mismo enfoque que se usó para la escala de este entorno de laboratorio. Este enfoque permitirá encontrar la mejor configuración para la carga de trabajo y puede describirse de la siguiente manera:
1. En primer lugar, aumentamos los servidores web. Se aumentaron al máximo posible bajo la carga de trabajo probada, hasta que el servidor de bases de datos se convirtió en el cuello de botella y no pudo dar cabida a más solicitudes de los servidores web.
2. Hasta ese momento, las bases de datos de contenido y las bases de datos de servicios (base de datos de perfiles, la base de datos social, etc.) estaban en el mismo servidor de bases de datos. Cuando observamos que el servidor de bases de datos era el cuello de botella, lo aumentamos desplazando las bases de datos de contenido a otro servidor de bases de datos. En ese momento, los servidores web no estaban creando una carga suficiente en los servidores de bases de datos, por lo que se incrementó aún más la escala horizontal.
3. En el entorno de laboratorio, no probamos una mayor escala horizontal. Pero, si necesita más escala, el siguiente paso lógico será hacer que dos equipos compartan responsabilidades de servidor de aplicaciones.
Comenzamos con una configuración de granja de servidores mínima de un servidor front-end web, un servidor de aplicaciones y un equipo basado en SQL Server. A través de varias iteraciones, nos detuvimos en ocho servidores front-end web, un servidor de aplicaciones y dos configuraciones de granja de servidores de SQL Server. En la sección “Resultados y análisis” encontrará una comparación de las características de rendimiento de la zona verde y la zona roja para distintas iteraciones. Los detalles de cómo detectamos la zona verde y la zona roja para cada iteración se explican en la sección “Apéndice”.
Correlación entre el entorno de laboratorio y un entorno de producciónEl entorno de laboratorio descrito en este documento es un modelo de escala más pequeña de un entorno de producción en Microsoft. Aunque hay diferencias significativas entre los dos entornos, puede ser útil examinarlos en paralelo, ya que ambos son entornos de Mi sitio y sistemas sociales en que los patrones observados deberían ser similares.
El entorno de laboratorio contiene un conjunto de datos que imita de cerca el conjunto de datos del entorno de producción. La carga de trabajo que se usa para las pruebas es bastante similar a la carga de trabajo que se ve en el entorno de producción, con pocas diferencias notables.
La diferencia más notable es que, en el entorno de laboratorio, usamos menos usuarios distintos para realizar las acciones y las llevamos a cabo en un número menor de perfiles de usuario en comparación con el entorno de producción. Además, las pruebas de laboratorio se realizan en un tiempo más corto.
Todo esto afecta al número de aciertos de caché que se producen para la memoria caché de perfiles de usuario que se mantiene en el servidor de aplicaciones. El servicio de perfiles de usuario almacena en caché los perfiles de usuario recientemente usados en el servidor de aplicaciones. El tamaño predeterminado de esta memoria caché es de 256 MB, lo que corresponde aproximadamente a 500.000 perfiles de usuario. Dado que el número de perfiles de usuario que se usó en las pruebas se limitó a 1.500 y que la duración de las pruebas fue menor que el tiempo de reciclaje de la memoria caché, casi siempre se produjeron aciertos de caché. Por lo tanto, los números de rendimiento que se presentan en este documento tienden a ser elevados. Sin duda, debe tener en cuenta los errores de caché en su entorno y, por lo tanto, esperar un rendimiento menor.
Para un caso práctico detallado de un portal Mi sitio y de sistemas sociales en producción en Microsoft, vea Caso práctico técnico de SharePoint 2010: Entorno social.
Notas de pruebasEn este documento se proporcionan resultados de un entorno de laboratorio de prueba. Puesto que este era un entorno de laboratorio y no un entorno de producción, se pudieron controlar ciertos factores para mostrar los aspectos específicos del rendimiento para esta carga de trabajo. Además, ciertos elementos del entorno de producción, que se indican en la lista siguiente, se dejaron fuera del entorno de laboratorio para simplificar la sobrecarga de pruebas. Tenga en cuenta que no es aconsejable omitir estos elementos en los entornos de producción.
Entre las ejecuciones de pruebas, se modificó solo una variable a la vez para simplificar la comparación de los resultados de las distintas ejecuciones de pruebas.
Los servidores de bases de datos que se usaron en este entorno de laboratorio no formaban parte de un clúster, porque la redundancia no era necesaria para los fines de estas pruebas.
El rastreo de búsqueda no estaba en ejecución durante las pruebas, mientras que es posible que sí esté en ejecución en un entorno de producción. Para tener esto en cuenta, se disminuyó el uso de CPU de SQL Server en la definición de la “zona verde” y la “zona roja” para dar cabida a los recursos que hubiera consumido un rastreo de búsqueda si se hubiera ejecutado al mismo tiempo que nuestras pruebas.
Configuración de pruebasHardware
En la siguiente tabla se presentan las especificaciones de hardware de los equipos que se usaron en esta prueba. Todos los servidores front-end web (WFE) que se agregaron a la granja de servidores durante varias iteraciones de la prueba cumplen con las mismas especificaciones.
Servidor front-end web
Servidor de aplicaciones
Servidor de bases de datos
Modelo de servidor PE 2950 PE 2950 Dell PE 6850
Procesadores 2 procesadores de núcleo cuádruple a 2,33 GHz
2 procesadores de núcleo cuádruple a 2,33 GHz
4 procesadores de 4 núcleos a 3,19 GHz
RAM 8 GB 8 GB 32 GB
Número de NIC 2 2 1
Velocidad de NIC 1 gigabit 1 gigabit 1 gigabit
Tipo de equilibrador de carga
F5: equilibrador de carga de hardware
N/D N/D
Nivel de registro de ULS Medio Medio N/D
Tabla 1: Especificaciones de hardware para los equipos de servidor
SoftwareEn la tabla siguiente se explica el software instalado y en ejecución en los servidores que se usaron en estas pruebas.
Servidor front-end web
Servidor de aplicaciones Servidor de bases de datos
Sistema operativo
Windows Server® 2008 R2 x64
Windows Server 2008 R2 x64
Windows Server 2008 x64
Versión de software
Microsoft SharePoint 4763.1000 (RTM), aplicaciones web de Office 4763.1000 (RTM)
Microsoft SharePoint 4763.1000 (RTM), WAC 4763.1000 (RTM)
SQL Server 2008 R2 CTP3
Tipo de equilibrador de carga
F5: equilibrador de carga de hardware
N/D N/D
Nivel de registro de ULS
Medio Medio N/D
Configuración del antivirus
Deshabilitado Deshabilitado Deshabilitado
Tabla 2: Especificaciones de software para los equipos de servidor
Topología y configuraciónEn el diagrama de topología siguiente se explica la configuración de hardware que se usó para las pruebas.
Diagrama 1: Configuración de granja de servidores
Consulte el diagrama 1 para los servicios que se aprovisionan en el entorno de prueba.
Geometría de conjunto de datos y de disco La granja de servidores de prueba se rellenó con un total de 166,5 GB de contenido de Mi sitio, distribuido a partes iguales en 10 bases de datos de contenido, 27,7 GB de contenido de bases de datos de perfiles, 3,7 GB de contenido de bases de datos sociales (GUID de etiquetas de sociales, notas y clasificaciones) y 0,14 GB de contenido de bases de datos de administración de metadatos (texto para las etiquetas sociales y los GUID correspondientes).
En la tabla siguiente se explica en detalle el conjunto de datos:
Número de perfiles de usuario ~150.000Número medio de pertenencias por usuario 74Número medio de informes directos por usuario 6
Número medio de compañeros por usuario 28Número total de propiedades de perfil 101Número de propiedades con varios valores 21Número de públicos 130Número de Mis sitios ~10.000Número de blogs ~600Número total de eventos en la fuente de actividades
798.000*
Número de etiquetas temáticas o clasificaciones 5,04 millones**
Tabla 3: Detalle del conjunto de datos
* Un estudio de etiquetas temáticas de del.icio.us sugiere que un usuario activo crea 4,2 etiquetas por mes. (Etiquetas, en este contexto, se refiere a cualquier actividad relacionada con la asignación de metadatos a direcciones URL. Por lo tanto, incluye etiquetas de palabras clave, clasificaciones y notas.) Esto significa que un usuario activo crea 4,2 etiquetas entre 30 días = 0,14 etiquetas por día. Suponiendo que un tercio de los usuarios del portal social cree etiquetas, hay 150.000/3 × 0,14 eventos de etiquetado por día. Las tablas de fuentes de actividades mantienen la actividad durante 14 días. Por lo tanto, el número total de la actividad de etiquetado de la tabla de fuentes de actividades es igual a 150.000/3 × 0,14 × 14. Además de eventos de etiquetado, si suponemos que los usuarios activos generan un evento adicional por día, como, por ejemplo, una actualización de las propiedades del perfil o una actualización del estado, tenemos 150.000/3 × 1 × 14 eventos agregados a las tablas de fuentes de actividades. Por lo tanto, el número total de eventos en las tablas de fuentes de actividades es igual a 150.000/3 × 1,14 × 14 = 798.000. De esos eventos, 98.000 son actividades de etiquetado que pueden activar el recorte de seguridad. El resto de los eventos se distribuirá aleatoriamente entre los cambios de actualización del estado y las propiedades del perfil.
** Se presupone que un tercio de la población son usuarios activos y que cada uno crea 4,2 etiquetas al mes; donde una etiqueta puede significar una etiqueta de palabra clave, una nota o una clasificación. Presuponiendo que la granja de servidores esté en uso durante 2 años, el total de etiquetas será 150.000/3 × 4,2 × 12 × 2 = 5,04 millones.
En la tabla siguiente se explica en detalle la geometría del disco:
Base de datos
Base de datos de
contenido 1, 2, 3, 4
Base de datos de
contenido 5, 6
Base de datos de
contenido 7, 8
Base de datos de
contenido 9, 10 Perfiles Social Metadatos
Tamaño de la base de datos 61,4 GB 39 GB 32,3 GB 33,7 GB
27,7 GB 3,7 GB 0.14
Configuración de RAID 0 0 0 0 0 0 0Número de ejes para MDF 1 1 1 1 6 1 1Número de ejes para LDF un eje físico compartido por todas las bases de datos
Tabla 4: Detalle de la geometría del disco
Combinación de transaccionesNotas importantes
Las pruebas solo modelan el uso en horas de máxima productividad de un portal de sistemas sociales típico. No se tuvieron en cuenta los cambios cíclicos en el tráfico generado por los usuarios que se observa en los ciclos de día/noche. Los trabajos del temporizador, que requieren muchos recursos (como la sincronización de perfiles y el rastreo de búsqueda de personas), se probaron de forma independiente con la misma carga de trabajo de prueba para identificar su efecto.
Esta prueba se centra más en las acciones sociales, como, por ejemplo, suministros de noticias, etiquetas temáticas y lectura de perfiles de personas. Tiene una pequeña cantidad de tráfico de colaboración habitual, pero no es el objetivo principal de las pruebas. Esperamos que estos resultados le ayuden a diseñar un portal independiente dedicado a características de Mis sitios y sociales.
La combinación de pruebas no incluye tráfico del rastreo de contenido de búsqueda. Pero esto se tuvo en cuenta en las pruebas al modificar la definición de la zona de verde para que fuera el 40% del uso de CPU de SQL Server en lugar del 50% estándar para permitir el 10% para el rastreo de la búsqueda. Del mismo modo, se usó el 80% de la CPU de SQL Server como criterio para el máximo de RPS.
Además de la combinación de pruebas que se enumera en la tabla siguiente, agregamos ocho RPS para cada servidor front-end web para el tráfico de Outlook Social Connector. Activamos el recorte de seguridad. El servicio de token de seguridad mostró importantes signos de esfuerzo a medida que nos acercamos a 8 RPS de tráfico de Outlook Social Connector en un único servidor front-end web al obtener actividades de compañeros. Esta es una función del conjunto de datos, la carga de trabajo de prueba y el hardware que usamos en el laboratorio para las pruebas. Es posible que observe un comportamiento totalmente diferente. Para evitar una mayor sobrecarga en el servicio de token de seguridad, decidimos agregar el tráfico de Outlook Social Connector como una función del número de servidores front-end web en cada iteración. Por lo tanto, para 1x1x1, tenemos ocho RPS de tráfico de Outlook Social Connector; mientras que para 2x1x1 tenemos 16 RPS de tráfico de Outlook Social Connector, etc.
La combinación de transacciones general se presenta en la tabla siguiente:
Descripción Lectura/escritura% de combinación
Agregar un compañero Escritura 2,11%Crear una clasificación en una dirección URL, escribir una nota o etiquetar una dirección URL Escritura 3,22%Enumerar documentos de acciones Lectura/escritura 2,36%Obtener vínculos publicados para modelar llamadas de clientes a PublishedLinksService.asmx Lectura 6,92%Obtener fuentes RSS de listas Lectura 3,72%Ver todos los elementos de las bibliotecas de Lectura 1,07%
documentos y listas en Mi sitioVer una entrada de blog Lectura 0,04%Ver varias páginas de Mi sitio (mi contenido, compañeros, suministro de noticias, mi perfil, perfil de otra persona, explorador de la organización, pertenencias, etiquetas y notas) Lectura 3,87%Sincronizar para archivos de OneNote compartidos Lectura 10,0%Editar mi página de perfil o mensaje de estado; actualizar la imagen Escritura 2,31%Aplicaciones web de Office: Abrir archivos y desplazarse por ellos (PowerPoint®, Word, Excel®) Lectura 0,13%
Sincronizar listas con Outlook® Lectura48,16%
Cargar un documento Escritura 0,09%Cargar páginas, bibliotecas de documentos y carpetas desde bases de datos de contenido Lectura 15,93%Co-autoría de documentos Lectura/escritura 0,17%
Tabla 5: Combinación de transacciones
Combinación de pruebas de escenarios de Outlook Social Connector adicionales que genera 8 RPS por servidor front-end web:
Sincronizar automáticamente mis compañerosLectura 4%
Sincronizar automáticamente los suministros de noticias de mis compañeros
Lectura 96%
Tabla 6: Combinación de pruebas de escenarios de Outlook Social Connector
Resultados y análisisComparación de todas las iteraciones
Como se mencionó anteriormente, comenzamos con una configuración de granja de servidores mínima de un servidor front-end web, un servidor de aplicaciones y un equipo basado en SQL Server. A través de varias iteraciones, nos detuvimos en ocho servidores front-end web, un servidor de aplicaciones y dos configuraciones de granja de servidores basadas en SQL Server. Para cada una de estas iteraciones, realizamos pruebas de carga gradual para identificar la zona verde y la zona roja. En el apéndice se proporcionan los detalles de las pruebas de carga gradual de cada iteración. En la tabla siguiente, encontrará una comparación de estas características de rendimiento de la zona verde y la zona roja en las distintas iteraciones.
En la tabla y gráficos siguientes se proporciona un resumen de análisis y comparación.
Resultados de la zona verde:
Primero veamos las características de rendimiento de la zona verde en las topologías. En la tabla siguiente se proporciona un resumen de los resultados:
Topología 1x1x1 2x1x1 3x1x1 5x1x1 8x1x1 8x1x2RPS de zona verde
137,25 278,08 440,72683,0
7793,6
7873,4
Latencia de percentil 75 de zona verde 0,12 0,16 0,14 0,16 0,31 0,32CPU de servidor front-end web de zona verde 47,84 46,88 48,68 46,13 31,79
36,90
CPU de servidor de aplicaciones de zona verde 9,45 18,88 26,91 35,58 48,73
47,20
CPU de SQL Server de zona verde
5,45 10,61 16,46 24,73 30,03
32,40 (17,9 para la base de
datos de contenido
y 14,5 para la base de
datos de servicios)
Tabla 7: Rendimiento de la zona verde
En el siguiente gráfico se presenta la variación en los usos de la CPU en función de las RPS y de las distintas topologías para los resultados de la zona verde.
1x1x12x1x13x1x15x1x18x1x18x1x20
100
200
300
400
500
600
700
800
900
1000
0
10
20
30
40
50
60
RPS de zona verde
CPU de WFE de zona verde
CPU de aplicación de zona verde
CPU de SQL de zona verde
Topología
RPS
% d
e us
o de
CPU
Del gráfico anterior:
- Las RPS aumentaron durante toda la prueba al agregar más equipos a las topologías.- Resulta evidente que la CPU del servidor front-end web fue el factor principal que llevó la
topología al límite de la zona verde hasta 5x1x1, y a 8x1x1, la CPU del servidor de aplicaciones alcanzó el límite correspondiente a la zona verde antes de que los servidores front-end web pudieran alcanzar los límites de la zona verde.
- Durante todo el proceso, la CPU de SQL Server se mantuvo en un territorio muy adecuado.
Resultados de la zona roja:
En la tabla siguiente se proporciona un resumen de los resultados correspondientes a distintas topologías para la zona roja.
1x1x1 2x1x1 3x1x1 5x1x1 8x1x1 8x1x2RPS de zona roja
203,28 450,75 615,00971,1
3 16551877
Latencia de la zona roja 0,22 0,23 0,22 0,22 0,31 0,32CPU de servidor front-end web de zona roja 75,13 78,17 70,00 67,02 67
71,6
CPU de servidor de aplicaciones de zona roja 12,97 27,07 28,40 48,28 67,1
73.4
CPU de SQL Server de zona roja
7,64 16,06 21,00 38,38 79,5
74,9(45,9 para la
base de datos de contenido y 29 para la base
de datos de servicios)
Tabla 8: Resultados en topologías para la zona roja
En el siguiente gráfico se presenta la variación en los usos de la CPU en función de las RPS y de las distintas topologías para los resultados de la zona roja.
1x1x1 2x1x1 3x1x1 5x1x1 8x1x1 8x1x20
200
400
600
800
1000
1200
1400
1600
1800
2000
0
10
20
30
40
50
60
70
80
90
RPS de zona roja
CPU de WFE de zona roja
CPU de aplicación de zona roja
CPU de SQL de zona roja
Topología
RPS
% d
e us
o de
CPU
A partir del gráfico anterior:
- Las RPS aumentaron durante toda la prueba al agregar más equipos a las topologías.- Está claro que la CPU del servidor front-end web fue el cuello de botella hasta 5x1x1, y que a
8x1x1, la CPU de SQL Server se convirtió en el cuello de botella.- En un primer momento, el uso de CPU del servidor de aplicaciones fue superior al uso de CPU de
SQL Server, pero, aparentemente, la tasa de crecimiento de uso de CPU de SQL Server es mayor que la tasa de crecimiento del uso de CPU del servidor de aplicaciones. En rendimientos mayores, el uso de CPU de SQL Server superó el uso de CPU del servidor de aplicaciones y se convirtió en el cuello de botella.
Zona verde frente a Zona roja:
En los siguientes gráficos se comparan el rendimiento y las latencias de la zona verde y la zona roja en diferentes topologías.
1x1x1 2x1x1 3x1x1 5x1x1 8x1x1 8x1x20
200
400
600
800
1000
1200
1400
1600
1800
2000
RPS de zona verdeRPS de zona roja
Topología
RPS
1x1x1 2x1x1 3x1x1 5x1x1 8x1x1 8x1x20
0.05
0.1
0.15
0.2
0.25
0.3
0.35
Latencia de percentil 75 de zona verdeLatencia de percentil 75 de zona roja
Topología
Late
ncia
(seg
undo
s)
De los gráficos anteriores:
- Las latencias no varían mucho con el rendimiento o las topologías. En nuestras pruebas observamos que todas las latencias eran inferiores a los 0,5 segundos, lo que es muy aceptable.
- El aumento del rendimiento es casi lineal.
Una nota sobre I/OPS:
En la tabla y gráfico siguientes se presenta la I/OPS que se observó en cada base de datos en distintas topologías. No nos encontramos la E/S de disco como un cuello de botella y, al observar la tendencia, no registramos los datos de topologías posteriores.
Zona roja 1x1x1
Zona roja 2x1x1
Zona roja 3x1x1
Zona roja 5x1x1
Lecturas/segundo (base de datos de contenido) 21,33 20,80 24,24 22,42Lecturas/segundo (base de datos de perfiles) 14,97 17,20 19,82 13,50Lecturas/segundo (base de datos de servicios sociales) 1,81 1,83 2,10 2,01Escrituras/segundo (base de datos de contenido) 50,12 76,24 80,02 99,16Escrituras/segundo (base de datos de perfiles) 9,01 24,31 23,35 38,29Escrituras/segundo (base de datos de servicios sociales) 4,12 9,47 10,63 19,45
Tabla 9: I/OPS observadas
1x1x1_Max 2x1x1_Max 3x1x1_Max 5x1x1_Max0.00
10.0020.0030.0040.0050.0060.0070.0080.0090.00
100.00
IOPS por topología
Lecturas/segundo (base de datos de contenido)Lecturas/segundo (base de datos de perfiles)Lecturas/segundo (base de datos de servicios sociales)Escrituras/segundo (base de datos de contenido)Escrituras/segundo (base de datos de perfiles)Escrituras/segundo (base de datos de servicios sociales)
Topología
Ope
racio
nes p
or se
gund
o
Efecto del rastreo de búsqueda de personas
Queríamos medir el efecto del rastreo de búsqueda de personas en el rendimiento ofrecido por una configuración y por las latencias de usuario final. Para esta prueba, usamos los resultados proporcionados por una configuración 8x1x1 como línea base e iniciamos el rastreo de búsqueda de personas incremental. El rastreo incremental indizó 49.375 elementos en 53 minutos.
En la tabla siguiente se presenta una comparación de las características de rendimiento que presentó la configuración 8x1x1 con y sin el rastreo incremental de búsqueda de personas:
Resultados de la zona verde 8x1x1 de línea base
Resultados de la zona verde 8x1x1 con rastreo de búsqueda de personas
Rendimiento [RPS] 1024,00 1026,00
CPU del servidor front-end web [%] 39,84 41,6
CPU del servidor de aplicaciones [%] 41,40 43,1
CPU de SQL Server de contenido/servicio [%] 36,63 39,5
CPU de indizador [%] 0,52 34,6
CPU de SQL de servicios [%] 3,62 14,8
Tabla 10: Comparación de las características de rendimiento
De la tabla anterior:
- Las RPS se mantuvieron prácticamente iguales. Como no había ningún cuello de botella de recursos en la zona verde 8x1x1, no hay ninguna razón para que las RPS se vean afectadas.
- El uso de CPU del servidor front-end web y de SQL Server de contenido/servicio fue solo apenas superior.
- Los usos de CPU del indizador de búsqueda y de SQL Server aumentaron de 0,5% a 34,6%, y de 3,6% a 14,8%.
Análisis
Escala del servidor de aplicaciones
Quizás haya notado que no observamos que el servidor de aplicaciones fuera el cuello de botella en ninguna de las configuraciones. Además, si se observa el uso de CPU del servidor de aplicaciones para
diferentes cargas VSTS en cualquier configuración, se puede ver que crece y, a continuación, se estabiliza. Puede verse un ejemplo idóneo de esto en la configuración 8x1x1 (los resultados detallados se presentan en el apéndice):
Carga VSTS 416 616 816 1016 1216 1416 1616CPU del servidor de aplicaciones 37,6 49,4 57,9 61,9 67,1 65,3 63,10
Esto es normal. En el caso de un portal social, la mayoría de las acciones requiere trabajar con un servicio de SharePoint llamado servicio de perfiles de usuario. La mayoría de las acciones requiere obtener el perfil de un usuario en la base de datos de perfiles que se aprovisiona cuando se crea el servicio de perfiles de usuario.
Para evitar frecuentes idas y vueltas de SQL Server, el servidor de aplicaciones del servicio de perfiles de usuario mantiene una memoria caché de perfiles de usuario. Inicialmente, mientras se prepara el entorno de prueba, esta memoria caché está vacía y el servidor de aplicaciones responde a las solicitudes entrantes del servidor front-end web obteniendo constantemente los perfiles de usuario de SQL Server. A continuación, estos perfiles se almacenan en la memoria caché y, por lo tanto, todas las solicitudes del servidor front-end web se pueden responder mediante el servidor de aplicaciones sin causar una ida y vuelta de SQL Server, solo con buscar en la memoria caché.
Puesto que el número de perfiles de usuario usado en las pruebas fue limitado, el servidor de aplicaciones se preparó para almacenar en caché todos esos perfiles de usuario, por lo que mostró un uso creciente. Cuando todos los perfiles se encontraban en caché, fue una acción continua de búsquedas de caché. Por lo tanto, observamos que el uso de CPU del servidor de aplicaciones se estabiliza.
Tráfico de Outlook Social Connector y recorte de seguridad
Outlook Social Connector es un complemento que se incluye con Office 2010 y que muestra las actividades de sus compañeros de SharePoint en Outlook. Este complemento también está disponible como descarga gratuita para Office 2007 y Office 2003.
Outlook Social Connector hace ping en el servidor de SharePoint cada hora para obtener actividades de los compañeros del usuario que lo esté usando. Almacena en caché dichas actividades para la hora. La hora siguiente, solo solicita una diferencia de las actividades que han ocurrido desde la última vez que llamó a SharePoint. Por lo tanto, sigue un modelo de tráfico muy predecible. Para una implementación de 100.000 usuarios de Outlook Social Connector y SharePoint, suponiendo que todos los usuarios lo usen todo el día, genera 100.000 solicitudes por hora, que se traducen en 27,77 solicitudes por segundo.
Si se muestran las actividades de otras personas, existe la posibilidad de divulgar información; si la dirección URL que un compañero etiqueta es confidencial y otro usuario no tiene acceso, el usuario puede averiguar sobre la existencia de esa parte confidencial del contenido viéndolo en Outlook Social Connector. Para evitar la divulgación de esta información, SharePoint filtra todas las actividades y
muestra solo las direcciones URL de las actividades a las que el usuario tiene acceso. Este filtrado es lo que llamamos “recorte de seguridad”. Está activado de forma predeterminada, pero se puede desactivar.
No todas las actividades requieren recorte de seguridad. De los 16 tipos de actividad que son compatibles con SharePoint, solo hay 4 (etiquetado, comentario en el panel de notas, clasificación y cambios de pertenencia en las listas de distribución) que hagan necesario el recorte de seguridad. Además, como Outlook Social Connector solo solicita una diferencia de las actividades que han ocurrido desde la última vez que se sincronizó, el número de actividades por usuario que necesitaría el recorte de seguridad sería razonablemente bajo.
Todas las solicitudes de Outlook Social Connector que hacen necesario el recorte de seguridad dan como resultado una llamada de Windows Communication Foundation (WCF) autenticada al servidor de aplicaciones para el servicio de búsqueda. Para lograr el token de autenticación para hacer esta llamada, primero se realiza una llamada WCF al servicio de token de seguridad.
Descubrimos que, si las RPS de Outlook Social Connector excedían las ocho RPS por servidor front-end web, el servicio de token de seguridad se encontraba bajo esfuerzo. Esto quizá no ocurra con cada usuario, porque depende del número total de usuarios y la cantidad total de etiquetas temáticas que se cree en las actividades de los compañeros del usuario. En el conjunto de datos que creamos y con los usuarios que empleamos, probablemente tuvimos suficientes actividades que hacían necesario el recorte de seguridad y que provocaron que observáramos este comportamiento. Por lo tanto, incrementamos el tráfico de Outlook Social Connector en función del número de servidores front-end web disponibles. Para la configuración 1x1x1, generamos ocho RPS de tráfico de Outlook Social Connector; mientras que para la configuración 2x1x1 generamos 16 RPS de tráfico de Outlook Social Connector, etc.
Esto significa que, para el conjunto de datos, la combinación de pruebas y el hardware que teníamos para las pruebas, pudimos admitir aproximadamente 8×60×60, es decir, 28.800 solicitudes por hora. Con el funcionamiento de Outlook Social Connector, esto significa que podríamos haber admitido 28.800 empleados que usaran Outlook Social Connector en un único servidor front-end web con el recorte de seguridad activado. De igual forma, podríamos haber admitido 28.800 × 3, es decir, 86.400 empleados que usaran Outlook Social Connector en tres servidores front-end web con el recorte de seguridad activado.
Esto le ayudará a evaluar el hardware necesario para admitir el tráfico de Outlook Social Connector, pero tenga en cuenta que los resultados que vimos son específicos para el conjunto de datos, la combinación de pruebas y el hardware que usamos para las pruebas. Además, no olvide que tiene la opción de desactivar el recorte de seguridad mediante el uso de PowerShell o cambiando la frecuencia de sincronización de Outlook Social Connector con SharePoint. Ambas opciones tienen un efecto considerable en los requisitos de hardware.
RecomendacionesEstas son las conclusiones generales que sacamos de las pruebas:
- Se incrementó la escalabilidad vertical del entorno hasta ocho servidores front-end web para un servidor de aplicaciones y un servidor de bases de datos; el aumento en el rendimiento fue prácticamente lineal todo el tiempo. Después de ocho servidores front-end web, no se obtuvo ninguna ganancia adicional en el rendimiento al agregar más servidores front-end web. Esto se debe a que el cuello de botella en ese momento era el uso de la CPU del servidor de bases de datos.
- Se puede alcanzar más escala si se separan la base de datos de contenido y la base de datos de servicios en dos servidores de bases de datos independientes.
- Se alcanzó el potencial máximo de la topología 8x1x2. En este caso, el uso del servidor front-end web y el uso de CPU del servidor de aplicaciones eran el cuello de botella. Esto nos lleva a pensar que, para el hardware, el conjunto de datos y la carga de trabajo de prueba especificados, el número máximo posible de solicitudes por segundo (RPS) está representado por las RPS de la zona roja para 8x1x2, que es aproximadamente 1.877 RPS.
- Al observar las tendencias, parece posible obtener el mismo rendimiento con una granja de servidores en buen estado si se resuelven los cuellos de botella del servidor front-end web y el servidor de aplicaciones. El cuello de botella del servidor front-end web se puede resolver agregando más servidores front-end web. A su vez, el cuello de botella del servidor de aplicaciones puede solucionarse mediante el uso de dos equipos que desempeñen el rol de servidor de aplicaciones. Pero no lo probamos en el laboratorio.
- La latencia no se ve afectada por las variaciones de rendimiento o de hardware. - Si tiene activado el recorte de seguridad, un servidor front-end web puede admitir unos 8 o 10
RPS de tráfico de Outlook Social Connector. Esto significa que un servidor front-end web puede admitir aproximadamente entre 28.000 y 36.000 empleados que usen Outlook Social Connector todo el día. Por lo tanto, si desea implementar Outlook Social Connector para 100.000 empleados, puede admitir el tráfico que se genere con tres servidores front-end web. Estos valores pueden variar en función del uso de etiquetas temáticas en su empresa. Si cree que su empresa tendrá menos actividad de etiquetas temáticas que la que se usó en el conjunto de datos de este trabajo de comprobación, puede obtener mejor rendimiento por servidor front-end web.
- El rastreo incremental de búsqueda de personas no tiene un efecto considerable en el rendimiento de la granja de servidores siempre y cuando esta se mantenga en buen estado.
ApéndiceResultados de iteraciones Topología 1 x 1 x 1
Resumen de resultados- Además de la combinación de pruebas presentada anteriormente, esta granja de servidores tenía
un tráfico de ocho RPS de Outlook Social Connector que pedía eventos de fuentes de un usuario.- En una granja de servidores de un servidor front-end web, un servidor de aplicaciones y un
equipo basado en SQL Server, estaba claro que el servidor front-end web era el cuello de botella. Como se muestra en los datos de la tabla siguiente, la CPU del servidor front-end web alcanzó un uso de aproximadamente el 90% cuando la granja de servidores se sometió a 238 RPS mediante el uso de la combinación transaccional que se describió anteriormente en este documento.
- Esta configuración proporcionó un valor RPS de zona verde de 137,25, con una latencia del 75 de 0,12 segundos y una CPU del servidor front-end web que osciló en torno al 47,8% de uso. Esto indica que esta granja de servidores puede proporcionar en buen estado un valor RPS de aproximadamente 137,25. Las RPS de zona roja proporcionadas por esta granja de servidores fueron 203,2 con latencias de 0,22 segundos y una CPU de servidor front-end web que osciló en torno al 85%.
- Puesto que el servidor front-end web estaba sometido al cuello de botella, para la siguiente iteración agregamos otro servidor front-end web a la granja de servidores.
Contadores de rendimiento y gráficos
A continuación se presentan varios contadores de rendimiento capturados durante las pruebas de la granja de servidores 1x1x1, en etapas diferentes de la carga VSTS.
Carga VSTS 52 77 102 127 152 177RPS 99,8 147 188 218 238 243CPU del servidor front-end web 33,9 50 71,8 81,1 90,8 89CPU del servidor de aplicaciones 7,92 11,7 13,5 14,1 13,9 13,3CPU de SQL Server 4,7 6,48 7,99 8,21 8,41 8,88Percentil 75 [segundos] 0,13 0,16 0,17 0,25 0,3 0,45Percentil 95 [segundos] 0,29 0,47 0,41 0,55 0,55 0,77
Tabla 1: Contadores de rendimiento en una configuración de granja de servidores 1X1X1
52 77 102 127 152 1770
0.050.1
0.150.2
0.250.3
0.350.4
0.450.5
0
50
100
150
200
250
300
RPS y latencia en 1X1X1
RPSLatencia de percentil 75
Carga VSTS
Late
ncia
de
perc
entil
75
(s)
RPS
52 77 102 127 152 1770
50
100
150
200
250
300
0
10
20
30
40
50
60
70
80
90
100
Uso de RPS y CPU en 1X1X1
RPSCPU de WFECPU de APPCPU de SQL
Carga VSTS
RPS
% d
e us
o de
CPU
Configuración de granja de servidores 2 x 1 x 1
Resumen de resultados- Además de la combinación de pruebas presentada anteriormente, esta granja de servidores tenía
un tráfico de 16 RPS de Outlook Social Connector que pedía eventos de fuentes de un usuario.- En una granja de servidores de dos servidores front-end web, un servidor de aplicaciones y un
equipo basado en SQL Server, el servidor front-end web era el cuello de botella. Tal como se
presenta en los datos siguientes, la CPU del servidor front-end web alcanzó aproximadamente el 89% de uso cuando la granja de servidores se sometió a un valor RPS de 520 mediante el uso de la combinación transaccional que se describió anteriormente en este documento.
- Esta configuración proporcionó un valor RPS de zona verde de 278, con una latencia del 75 de 0,16 segundos y una CPU del servidor front-end web que osciló en torno al 47% de uso. Esto indica que esta granja de servidores puede proporcionar en buen estado un valor RPS de aproximadamente 278 con la combinación de pruebas y el hardware que se usaron para las pruebas. Las RPS de zona roja proporcionadas por esta granja de servidores fueron 450 con latencias de 0,23 segundos y la CPU del servidor front-end web osciló en torno al 78%.
- Como la CPU del servidor front-end web era el cuello de botella en esta iteración, aliviamos el cuello de botella agregando otro servidor front-end web a la siguiente iteración.
Contadores de rendimiento y gráficos
En la tabla y el gráfico siguientes se presentan varios contadores de rendimiento capturados durante las pruebas de la granja de servidores 2x1x1, en etapas diferentes de la carga VSTS.
Carga VSTS 104 154 204 254 304 354RPS 190 278 390 455 500 520CPU del servidor front-end web 36 50,9 71,9 86,9 87,1 89,5CPU del servidor de aplicaciones 16 24,9 28,3 26,5 26,5 24,9CPU de SQL Server 8,06 10,6 14,2 16,4 17,9 18,9Percentil 75 [segundos] 0,16 0,22 0,22 0,33 0,42 0,53Percentil 95 [segundos] 0,42 0,64 0,51 0,69 0,73 0,89
Tabla 2: Contadores de rendimiento durante una configuración 2 x 1 x 1
104 154 204 254 304 3540
0.1
0.2
0.3
0.4
0.5
0.6
0
100
200
300
400
500
600
RPS y latencia en 2X1X1
RPSLatencia 75
Carga VSTS
Late
ncia
de
perc
entil
75
(s)
RPS
104 154 204 254 304 3540
102030405060708090
100
0
100
200
300
400
500
600
Uso de RPS y CPU en 2X1X1
RPSCPU de WFECPU de APPCPU de SQL
Carga VSTS
% d
e us
o de
CPU
RPS
Configuración de granja de servidores 3 x 1 x 1
Resumen de resultados- Además de la combinación de pruebas presentada anteriormente, esta granja de servidores tenía
un tráfico de 24 RPS de Outlook Social Connector que pedía eventos de fuentes de un usuario.- En una granja de servidores de tres servidores front-end web, un servidor de aplicaciones y un
equipo basado en SQL Server, el servidor front-end web era el cuello de botella. Tal como se presenta en los datos siguientes, la CPU del servidor front-end web alcanzó aproximadamente el 76% de uso cuando la granja de servidores se sometió a un valor RPS de 629 mediante el uso de la combinación transaccional que se describió anteriormente en este documento.
- Esta configuración proporcionó un valor RPS de zona verde de 440, con una latencia del 75 de 0,14 segundos y una CPU del servidor front-end web que osciló en torno al 48% de uso. Esto indica que esta granja de servidores puede proporcionar en buen estado un valor RPS de aproximadamente 440 con la combinación de pruebas y el hardware que se usaron para las pruebas. Las RPS de zona roja proporcionadas por esta granja de servidores fueron 615 con latencias de 0,22 segundos y la CPU del servidor front-end web osciló en torno al 70%.
- Como la CPU del servidor front-end web era el cuello de botella en esta iteración, decidimos agregar más servidores front-end web. Teniendo en cuenta la diferencia entre las iteraciones observada anteriormente al agregar un servidor front-end web, decidimos agregar dos servidores front-end web. De esta manera, esperábamos observar el servidor de aplicaciones o SQL Server como cuello de botella.
Contadores de rendimiento y gráficos
En la tabla y los gráficos siguientes se presentan varios contadores de rendimiento capturados durante las pruebas de la granja de servidores 3x1x1, en etapas diferentes de la carga VSTS.
Carga VSTS 156 231 306 381 456 531RPS 264 393 532 624 634 629CPU del servidor front-end web 30,5 46,3 62,55 72,95 75,4 76CPU del servidor de aplicaciones 22,7 35,6 34,2 32,5 32,5 29,4CPU de SQL Server 10,4 14,8 20,8 22,5 22,8 22,4Percentil 75 [segundos] 0,17 0,26 0,27 0,28 0,31 0,40Percentil 95 [segundos] 0,63 1,08 0,76 0,68 0,88 0,98
Tabla 3: Contadores de rendimiento durante una configuración 3x1x1
156 231 306 381 456 5310
100
200
300
400
500
600
700
0.00
0.05
0.10
0.15
0.20
0.25
0.30
0.35
0.40
0.45
RPS y latencia en 3X1X1
Latencia 75RPS
Carga VSTS
RPS
Late
ncia
de
perc
entil
75
(s)
156 231 306 381 456 5310
10
20
30
40
50
60
70
80
0
100
200
300
400
500
600
700
Uso de RPS y CPU en 3X1X1
RPSCPU de WFECPU de APPCPU de SQL
Carga VSTS
% d
e us
o de
CPU
RPS
Configuración de granja de servidores 5 x 1 x 1
Resumen de resultados- Además de la combinación de pruebas presentada anteriormente, esta granja de servidores tenía
un tráfico de 40 RPS de Outlook Social Connector que pedía eventos de fuentes de un usuario.- En una granja de servidores con cinco servidores front-end web, un servidor de aplicaciones y un
equipo basado en SQL Server, se observó un aumento significativo de la CPU de SQL Server y del uso de CPU del servidor de aplicaciones, pero, aún así, la CPU del servidor front-end web era el cuello de botella. Tal como se presenta en los datos siguientes, la CPU del servidor front-end web alcanzó aproximadamente el 88% de uso cuando la granja de servidores se sometió a un valor RPS de 1315 mediante el uso de la combinación transaccional que se describió anteriormente en este documento.
- Esta configuración proporcionó un valor RPS de zona verde de 683, con una latencia del 75 de 0,16 segundos y una CPU del servidor front-end web que osciló en torno al 46% de uso. Esto indica que esta granja de servidores puede proporcionar en buen estado un valor RPS de aproximadamente 683 con la combinación de pruebas y el hardware que se usaron para las pruebas. Las RPS de zona roja proporcionadas por esta granja de servidores fueron 971 con latencias de 0,22 segundos y la CPU del servidor front-end web osciló en torno al 68%.
- Al observar la tendencia, decidimos agregar tres servidores front-end web y probar la configuración 8x1x1. Con esta configuración, esperábamos observar el servidor de aplicaciones o SQL Server como cuello de botella.
Contadores de rendimiento y gráficos
A continuación se presentan varios contadores de rendimiento capturados durante las pruebas de la granja de servidores 5x1x1, en etapas diferentes de la carga VSTS. Como no se observó ningún efecto significativo de cambios de configuración o de la carga VSTS en la latencia, dejamos de registrar los datos.
Carga VSTS 260 385 510 635 760 885RPS 359 560 901 1188 1281 1315CPU del servidor front-end web 20,5 34 56,2 77,5 86,1 88CPU del servidor de aplicaciones 40,2 50,6 66,9 71,3 66,3 58,7CPU de SQL Server 13,9 20,3 34,9 53,6 58,4 64
Tabla 4: Contadores de rendimiento durante una configuración 5x1x1
260 385 510 635 760 8850
200
400
600
800
1000
1200
1400
0102030405060708090100
Uso de RPS y CPU en 5X1X1
RPSCPU de WFECPU de APPCPU de SQL
Carga VSTS
RPS
% d
e us
o de
CPU
Configuración de granja de servidores 8 x 1 x 1
Resumen de resultados- Además de la combinación de pruebas presentada anteriormente, esta granja de servidores tenía
un tráfico de 64 RPS de Outlook Social Connector que pedía eventos de fuentes de un usuario.- Finalmente, en una granja de servidores con ocho servidores front-end web, un servidor de
aplicaciones y un equipo basado en SQL Server, la CPU de SQL Server era el cuello de botella. Tal como se presenta en los datos siguientes, la CPU de SQL Server alcanzó aproximadamente el 80% del uso cuando la granja de servidores se sometió a un valor RPS de 1664 mediante el uso de la combinación transaccional que se describió anteriormente en este documento.
- Esta configuración proporcionó un valor RPS de zona verde de 793, con una latencia de percentil 75 de 0,31 segundos y una CPU de SQL Server que osciló en torno al 30% de uso, mientras que la CPU del servidor de aplicaciones fue de un 48%. Esto indica que esta granja de servidores puede proporcionar en buen estado un valor RPS de aproximadamente 793 con la combinación de pruebas y el hardware que se usaron para las pruebas. Las RPS de la zona roja proporcionadas por esta granja de servidores fueron 1655 con latencias de 0,31 segundos y una CPU de SQL Server que osciló en torno al 80%.
- Como la CPU de SQL Server era el cuello de botella en esta iteración, aliviamos el cuello de botella separando la base de datos de contenido y la base de datos de servicios en dos instancias diferentes de SQL Server para la siguiente iteración.
Contadores de rendimiento y gráficos
En la tabla y el gráfico siguientes se presentan varios contadores de rendimiento capturados durante las pruebas de la granja de servidores 8x1x1, en etapas diferentes de la carga VSTS.
Carga VSTS 416 616 816 1016 1216 1416 1616RPS 664 1101 1359 1530 1655 1664 1617,00CPU del servidor front-end web 26,7 44,4 54,7 61,5 67 65,9 65,10CPU del servidor de aplicaciones 37,6 49,4 57,9 61,9 67,1 65,3 63,10CPU de SQL Server 23,2 42 57,9 69,5 79,5 80,8 77,30
Tabla 5: Contadores de rendimiento durante una configuración 8x1x1
416 616 816 1016 1216 1416 16160
200
400
600
800
1000
1200
1400
1600
1800
0
10
20
30
40
50
60
70
80
90
Uso de RPS y CPU en 8X1X1
RPSCPU de WFECPU de APPCPU de SQL
Carga VSTS
RPS
% d
e us
o de
CPU
s
Configuración de granja de servidores 8 x 1 x 2
Resumen de resultados- Además de la combinación de pruebas presentada anteriormente, esta granja de servidores tenía
un tráfico de 64 RPS de Outlook Social Connector que pedía eventos de fuentes de un usuario.- En una granja de servidores con ocho servidores front-end web, un servidor de aplicaciones y
dos equipos basados en SQL Server, pudimos llevar la configuración a su extremo. El servidor front-end web y el servidor de aplicaciones se encontraban en cuellos de botella, mientras que el uso de SQL Server combinado también estaba en la parte superior de los 70. La granja de servidores presentó un valor RPS de 1.817 al máximo.
- Esta fue la última iteración que probamos. Pero es claro que, si necesita más escala, el siguiente paso sería usar dos equipos para realizar tareas de servidor de aplicaciones. Esto le permitiría tener muchos más servidores front-end web y, por lo tanto, la carga en cada servidor front-end web será menor.
Contadores de rendimiento y gráficos
En la tabla y el gráfico siguientes se presentan varios contadores de rendimiento capturados durante las pruebas de la granja de servidores 8x1x2, en etapas diferentes de la carga VSTS.
Carga VSTS 466 666 866 1066 1266 1416RPS 466,00 873,40 1431,00 1703,00 1766,00 1817,00CPU del servidor front-end web 19,90 36,90 57,60 68,00 71,40 71,60CPU del servidor 29,80 47,20 63,50 71,40 71,90 73,40
de aplicacionesCPU de SQL Server total 19,61 32,40 55,20 63,60 68,50 74,90CPU de SQL Server de contenido 9,93 17,90 31,90 40,10 42,30 45,90CPU de SQL Server de servicios 9,68 14,50 23,30 23,50 26,20 29,00
Tabla 6: Contadores de rendimiento durante una configuración 8x1x2
466666
8661066
12661416
0200400600800
100012001400160018002000
0102030
40506070
80
Uso de RPS y CPU en 8X1X2
RPS
CPU de WFECPU de APPCPU de SQL totalCPU de SQL de contenidoCPU de SQL de servicios
Carga VSTS
RPS
% d
e us
o de
CPU