download.microsoft.com€¦ · web viewplanificación de la capacidad para . microsoft sharepoint...

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.

http://technet.microsoft.com/es-es/library/cc261716.aspx




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.

mailto:4px4c@%203.19GHz

mailto:4px4c@%203.19GHz

mailto:[email protected]






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


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.


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


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



Carga VSTS

% d

e us

o de

CPU

RPS



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.


- 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.


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


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



Carga VSTS

% d

e us

o de

CPU

RPS



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.


- 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.


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


260 385 510 635 760 8850

200

400

600

800

1000

1200

1400

0102030405060708090100



Carga VSTS

RPS

% d

e us

o de

CPU



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.



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


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



Carga VSTS

RPS

% d

e us

o de

CPU

s



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.



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


466666

8661066

12661416

0200400600800

100012001400160018002000

0102030

40506070

80


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

download.microsoft.com€¦ · web viewplanificación de la capacidad para . microsoft sharepoint...

Documents