Entorno social de Microsoft SharePoint Server 2010: Estudio de laboratorio

 

Se aplica a: SharePoint Server 2010

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

En este artículo se proporcionan recomendaciones acerca de la planeación de rendimiento y capacidad para un portal Mi sitio y de sistemas sociales basado en Microsoft SharePoint Server 2010. En este artículo se describe lo siguiente:

• Especificaciones del entorno de pruebas, como hardware, topología de conjunto o granja de servidores y configuración.

• Conjunto de datos de la granja de servidores de prueba.

• Datos de prueba y recomendaciones sobre cómo determinar el hardware, la topología y la configuración que se deben implementar en un entorno de prueba y cómo optimizar un entorno para las características adecuadas de capacidad y rendimiento.

Resumen ejecutivo

Estas son las conclusiones fundamentales de nuestra prueba del portal Mi sitio y de 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 (8×1×1). El aumento en el rendimiento fue prácticamente lineal todo el tiempo. No experimentamos ganancias adicionales en el rendimiento al agregar más de ocho servidores front-end web debido a que el cuello de botella en este caso era el uso de CPU del servidor de bases de datos.

• Incrementamos aún más la escalabilidad horizontal separando la base de datos de contenido y la base de datos de servicios en servidores de bases de datos independientes (8×1×2).

• Alcanzamos el rendimiento máximo mediante el uso de la topología 8x1x2. En este caso, el uso de los servidores front-end web y el uso de CPU del servidor de aplicaciones eran el cuello de botella. La conclusión es que, aparentemente, 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, consideramos que es posible obtener el mismo rendimiento con una granja de servidores correcta si se resuelven los cuellos de botella en el 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. 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. Sin embargo, no lo probamos el laboratorio.

• La latencia no está afectada por las variaciones de rendimiento o de hardware.

• Si tiene activado el recorte de seguridad, un servidor front-end web puede admitir de 8 a 10 RPS de tráfico de Outlook Social Connector. Esto significa que un servidor front-end web puede admitir aproximadamente de 28.000 a 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, necesitará tres servidores front-end web para admitir el tráfico correspondiente. Estos valores pueden variar en función del uso de etiquetas temáticas en su empresa. Si determina 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, es posible que el rendimiento por servidor front-end web exceda el intervalo de 8 a 10 RPS.

• El rastreo incremental de búsqueda de personas tiene poco efecto en el rendimiento de la granja de servidores siempre y cuando esta se mantenga en buen estado.

Introducción a este entorno

La metodología de prueba y los resultados incluidos en este artículo proporcionan recomendaciones para planear la capacidad de un portal de sistemas sociales. Un portal de sistemas sociales es una implementación de SharePoint Server 2010 en la que cada miembro de la empresa puede mantener un perfil de usuario, buscar expertos en la empresa, conectarse con otros empleados mediante suministros de noticias y mantener un sitio personal para el almacenamiento y uso compartido de documentos. Además del tráfico generado por las características de sistemas sociales, los usuarios que cargan, comparten, ven y actualizan documentos en sus sitios personales crean un tráfico de colaboración significativo. Estos resultados deberían ayudar a diseñar un portal independiente dedicado a Mis sitios y características sociales.

Cada escenario tiene distintos requisitos. Por lo tanto, debe complementar estas recomendaciones con pruebas adicionales en su propio hardware y en su propio entorno.

Después de leer este artículo, sabrá cómo:

• Evaluar el hardware necesario para incrementar la escalabilidad horizontal que necesita. Esta estimación debe incluir el número de usuarios, la carga y las características habilitadas.

• Diseñar la topología física y lógica para ofrecer una confiabilidad y eficiencia óptimas. La alta disponibilidad y la recuperación ante desastres no se cubren en este artículo.

• Tener en cuenta el efecto de rastreos continuos de búsqueda de personas y sincronizaciones de perfiles en las RPS de una implementación de portal de sistemas sociales.

Antes de leer este artículo, debe leer lo siguiente:

• Administración y ajuste de tamaño de la capacidad de SharePoint Server 2010

• Administración de capacidad de SharePoint Server 2010: Límites y límites máximos del software

• Caso práctico técnico de entorno social (SharePoint Server 2010)

Si está interesado en leer recomendaciones para la planeación de capacidad en escenarios de colaboración típicos, vea Caso práctico técnico de entorno de colaboración de intranet de empresa (SharePoint Server 2010)

Nota

No se ejecuta ningún código personalizado en la implementación del portal de sistemas sociales en este estudio de laboratorio. No podemos garantizar el comportamiento del código personalizado ni de las soluciones de terceros que puedan estar instaladas en su portal Mi sitio y de sistemas sociales.

Nota

En este estudio de laboratorio se usó autenticación NTLM.

Glosario

La lista siguiente contiene definiciones de algunos términos fundamentales que se usan en este artículo:

• RPS: solicitudes por segundo. RPS es el número de solicitudes que recibe una granja de servidores o un servidor en un segundo. Esta es una medición común de la carga del servidor y de la granja de servidores.

  Tenga en cuenta que las solicitudes difieren de las cargas de página. Cada página contiene varios componentes, cada uno de los cuales crea una o más solicitudes cuando se carga una página. Por lo tanto, una carga de página crea varias solicitudes. Las comprobaciones de autenticación y los eventos que usan recursos insignificantes normalmente 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:

  • La latencia del servidor de al menos el 75% de las solicitudes es menor que 1 segundo.

  • Todos los servidores tienen un uso de CPU menor que el 50%.

  Nota

  Debido a que 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. Esto supone que se usa el regulador de recursos de Microsoft SQL Server en producción para limitar la carga de rastreo de búsqueda a un uso de CPU del 10%.

  • La frecuencia de errores es menor que el 0,01%.

• Zona roja (máx.):   es el estado en el que el servidor puede mantener el siguiente conjunto de criterios:

  • La característica de limitación de solicitudes HTTP está habilitada, pero se devuelven errores 503 (servidor ocupado).

  • La tasa de errores para las solicitudes HTTP es inferior al 0,1%.

  • La latencia del lado servidor es inferior a 1 segundo para al menos el 75% de las solicitudes.

  • El uso de CPU del servidor de bases de datos es inferior al 80%. Esto permite reservar un 10% del uso para la carga de rastreo de búsqueda y se limita mediante el uso del regulador de recursos de SQL Server.

• AxBxC (notación gráfica): es el número de servidores front-end web, servidores de aplicaciones y servidores de bases de datos de una granja de servidores. Por ejemplo, 8x1x2 significa que este entorno tiene ocho servidores front-end web, un servidor de aplicaciones y dos servidores de bases de datos.

• Carga VSTS: se trata de subprocesos que usa internamente Visual Studio Team System (VSTS) para simular usuarios virtuales. Incrementamos la carga VSTS para generar cada vez más RPS para la topología.

• MDF y LDF: archivos físicos de SQL Server. Para obtener más información, vea el tema sobre arquitectura de archivos y grupos de archivos.

Introducción

En esta sección se resume nuestro enfoque de escalado, la relación entre este entorno de laboratorio y un entorno de casos prácticos similar y nuestra metodología de prueba.

Enfoque de escalado

Recomendamos escalar los equipos del entorno en un orden específico. Es el mismo enfoque que usamos para escalar nuestro entorno de laboratorio. Este enfoque permite encontrar la mejor configuración para la carga de trabajo. El enfoque que adoptamos es el siguiente:

1. En primer lugar, incrementamos la escalabilidad horizontal de los servidores front-end web. Incrementamos la escalabilidad lo más posible bajo la carga de trabajo probada hasta que el servidor de bases de datos no pudo dar cabida a más solicitudes de los servidores front-end web.

2. Hasta este momento, las bases de datos de contenido y las bases de datos de servicios (como, por ejemplo, la base de datos de perfiles y la base de datos social) estaban en el mismo servidor de bases de datos. Cuando observamos que el servidor de bases de datos era el cuello de botella, incrementamos su escalabilidad horizontal moviendo las bases de datos de contenido a otro servidor de bases de datos. Una vez hecho esto, la carga en los servidores de bases de datos que creaban los servidores front-end web disminuyó hasta el punto en que pudimos incrementar aún más la escalabilidad horizontal de los servidores front-end web.

3. En el entorno de laboratorio, no probamos la escalabilidad horizontal más allá de esto. Sin embargo, si necesita más escala, el siguiente paso lógico sería 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 más adelante en este artículo, encontrará una comparación de las características de rendimiento de la zona verde y la zona roja para distintas iteraciones. Cómo detectamos la zona verde y la zona roja para cada iteración se explica en la sección Resultados de iteraciones.

Correlación del entorno de laboratorio con un entorno de producción

El entorno de laboratorio que se describe en este artículo es un modelo en menor escala de un entorno de producción de Microsoft. Aunque hay diferencias significativas entre los dos entornos, puede resultar útil verlos en paralelo ya que ambos son entornos de Mi sitio y sistemas sociales. En consecuencia, los patrones observados deberían ser similares.

El entorno de laboratorio contiene un conjunto de datos que imita estrechamente 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 significativas. La diferencia más importante es que, en el entorno de laboratorio, usamos menos usuarios distintos para realizar las operaciones y llevamos a cabo operaciones 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 a aproximadamente 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 como la duración de las pruebas fue menor que el tiempo de reciclaje de la memoria caché, se produjeron normalmente aciertos de caché. Por lo tanto, los números de rendimiento que se presentan en este artículo son más elevados. Sin duda, debe tener en cuenta los errores de caché en su entorno y 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 entorno social (SharePoint Server 2010).

Notas sobre la metodología y prueba

En este artículo se proporcionan los resultados de un entorno de laboratorio de pruebas. Debido a que se trataba de un entorno de laboratorio, pudimos controlar ciertos factores para mostrar aspectos específicos del rendimiento correspondiente a esta carga de trabajo. Además, se excluyeron algunos elementos del entorno de producción del entorno de laboratorio para simplificar la prueba de sobrecarga. Tenga en cuenta que no es aconsejable omitir estos elementos en los entornos de producción:

• Entre las ejecuciones de pruebas, modificamos solo una variable a la vez para que sea fácil comparar los resultados entre ejecuciones de pruebas.

• Los servidores de bases de datos que se usaron en este entorno de laboratorio no eran parte de un clúster porque no se necesitaba redundancia a efectos de estas pruebas.

No se ejecutó rastreo de búsqueda durante las pruebas, aunque podría ejecutarse en un entorno de producción. Para tener esto en cuenta, redujimos el uso de CPU de SQL Server en nuestra definición de zona verde y zona roja (máx.) para dar cabida a los recursos que habría consumido un rastreo de búsqueda si se hubiera ejecutado durante nuestras pruebas.

Especificaciones

En esta sección se ofrece información detallada sobre el hardware, el software, la topología y la configuración del entorno de prueba.

Hardware

En la siguiente tabla se enumeran las especificaciones de hardware de los equipos que se usaron en esta prueba. Los servidores front-end web que se agregaron a la granja de servidores durante varias iteraciones de la prueba también cumplen con estas especificaciones.

	Servidor front-end web	Servidor de aplicaciones	Servidor de bases de datos
Procesador	2 procesadores de núcleo cuádruple a 2,33 GHz	2 procesadores de núcleo cuádruple a 2,33 GHz	4px4c 3,10 GHz
RAM	8 Gigabytes (GB)	8 Gigabytes (GB)	32 Gigabytes (GB)
Número de adaptadores de red	2	2	1
Velocidad del adaptador de red	1 gigabit	1 gigabit	1 gigabit
Tipo de equilibrador de carga	F5: equilibrador de carga de hardware	No aplicable	No aplicable
Nivel de registro de ULS	Medio	Medio	No aplicable

Software

En la siguiente tabla se enumeran las especificaciones de software de los equipos que se usaron en esta prueba. Los servidores front-end web que se agregaron a la granja de servidores durante varias iteraciones de la prueba también cumplen con estas especificaciones.

	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), Office Web Applications 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	No aplicable	No aplicable
Nivel de registro de ULS	Medio	Medio	No aplicable
Configuración del antivirus	Deshabilitado	Deshabilitado	Deshabilitado
Servicios en ejecución	Correo electrónico entrante de SharePoint Foundation Aplicación web de SharePoint Foundation Servicio del temporizador de flujo de trabajo de SharePoint Foundation	Administración central Excel Calculation Services Servicio web de metadatos administrados Correo electrónico entrante de SharePoint Foundation Aplicación web de SharePoint Foundation Servicio del temporizador del flujo de trabajo de SharePoint Foundation Servicio de PowerPoint Servicio de perfiles de usuario Servicio de sincronización de perfiles de usuario Servicio de visualización de Word

Topología

En el siguiente diagrama se muestra la topología de este entorno de laboratorio:

Geometría de conjunto de datos y de disco

La granja de servidores de prueba se rellenó con:

• 166,5 GB de contenido de Mi sitio, distribuido uniformemente entre 10 bases de datos de contenido

• 27,7 GB de contenido de la base de datos de perfiles

• 3,7 GB de contenido de base de datos social (GUID para etiquetas temáticas, notas y clasificaciones)

• 0,14 GB de contenido de base de datos de metadatos administrados (texto de etiquetas temáticas y las GUID correspondientes)

En la tabla siguiente se explica en detalle el conjunto de datos.

Número de perfiles de usuario	~150K
Número medio de pertenencias por usuario	74
Número medio de subordinados directos por usuario	6
Número medio de compañeros por usuario	28
Número total de propiedades de perfil	101
Número de propiedades de múltiples valores	21
Número de públicos	130
Número de Mis sitios	~10.000
Número de blogs	~600
Número total de eventos en la fuente de actividades	798.000*
Número de etiquetas temáticas y clasificaciones	5,04 millones**

* 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. Esto incluye etiquetas de palabras clave, clasificaciones y notas y significa que un usuario activo crea 4,2 etiquetas por 30 días = 0,14 etiquetas por día. Suponiendo que un tercio de los usuarios del portal social crea 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 eventos 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 supone que un tercio de la población son usuarios activos y cada uno crea 4,2 etiquetas por mes. Etiqueta puede referirse a una etiqueta de palabras clave, una nota o una clasificación. Suponiendo que la granja de servidores exista durante dos años, el número total de etiquetas será 150.000/3 × 4,2 × 12 × 2 = 5,04 MB.

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 GB
Configuración de RAID	0	0	0	0	0	0	0
Número de ejes para MDF	1	1	1	1	6	1	1
Número de ejes para LDF	un eje físico compartido por todas las bases de datos

Combinación de pruebas

Notas importantes:

• Las pruebas solo modelan el uso en horas pico 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, como la sincronización de perfiles y el rastreo de búsqueda de personas, que requieren muchos recursos, se probaron de forma independiente con la misma carga de trabajo de prueba para determinar su efecto.

• Las pruebas se centran más en las operaciones 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 Mis sitios y características sociales.

• La combinación de pruebas no incluye el tráfico del rastreo de búsqueda de contenido. No obstante, dicho tráfico lo hemos factorizado en nuestras pruebas mediante la modificación de la definición de la zona verde a un uso de la CPU de SQL Server del 40%, en lugar del 50% estándar, para permitir un uso de la CPU del 10% para el rastreo de búsqueda. Del mismo modo, usamos una CPU de SQL Server del 80% como criterio para RPS máx.

• Además de la combinación de pruebas que se enumeran 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. Esto fue 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 la sobrecarga adicional 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 8 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 pruebas general se presenta en la tabla siguiente.

Prueba	Lectura/escritura	Porcentaje 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
Listar documentos de operaciones.	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 documentos y listas en Mi sitio.	Lectura	1,07
Ver 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
Office Web Apps: abrir y desplazarse por los archivos (PowerPoint, Word y Excel).	Lectura	0,13
Sincronizar listas con Outlook.	Lectura	48,16
Cargar un documento.	Escritura	0,09
Cargar páginas, bibliotecas de documentos y carpetas desde la base de datos de contenido.	Lectura	15,93
Co-crear documentos.	Lectura/escritura	0,17

En la tabla siguiente se describe la 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ñeros.	Lectura	4%
Sincronizar automáticamente los suministros de noticias de mis compañeros.	Lectura	96%

Resultados y análisis

Comparació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, finalmente terminamos con una granja de ocho servidores front-end web, un servidor de aplicaciones y dos equipos SQL Server. Para cada una de estas iteraciones, realizamos pruebas de carga gradual para determinar la zona verde y la zona roja. En la tabla siguiente, encontrará una comparación de estas características de rendimiento de la zona verde y la zona roja para las distintas iteraciones.

En la siguiente tabla y gráficos se proporciona un resumen de análisis y comparación.

Resultados de la zona verde

En la tabla siguiente, se resumen las características de rendimiento de la zona verde en distintas topologías.

Topología	1x1x1	2x1x1	3x1x1	5x1x1	8x1x1	8x1x2
RPS de zona verde	137,25	278,08	440,72	683,07	793,67	873,4
Latencia de percentil 75 de zona verde	0,12	0,16	0,14	0,16	0,31	0,32
CPU 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

En el siguiente gráfico se muestran las variaciones en el uso de la CPU en función de las RPS y de las distintas topologías para los resultados de la zona verde.

Como se ilustró en el 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 factor principal que llevó la topología al límite de la zona verde hasta 5x1x1. 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 toda la prueba, 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	8x1x2
RPS de zona roja	203,28	450,75	615,00	971,13	1.655	1.877
Latencia de la zona roja	0,22	0,23	0,22	0,22	0,31	0,32
CPU 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)

En el siguiente gráfico se presentan las variaciones en el uso de la CPU en función de las RPS y de las distintas topologías para los resultados de la zona roja.

Como se ilustró en el 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. A 8x1x1, la CPU de SQL Server se convirtió en el cuello de botella.

• Inicialmente, el uso de CPU del servidor de aplicaciones fue superior al uso de CPU de SQL Server. Sin embargo, aparentemente, la tasa de crecimiento de uso de CPU de SQL Serveres mayor que la tasa de crecimiento del uso de CPU del servidor de aplicaciones. En los niveles superiores de rendimiento, 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 para diferentes topologías.

Como se ilustró en los gráficos anteriores:

• Las latencias no varían mucho con el rendimiento o las topologías. En nuestras pruebas, las latencias fueron todas inferiores a los 0,5 segundos, lo que es muy aceptable.

• El aumento del rendimiento es casi lineal.

E/S de disco

En la siguiente tabla y gráfico se presenta la E/S de disco que se observó en cada base de datos en distintas topologías. No experimentamos 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 por segundo (base de datos de contenido)	21,33	20,80	24,24	22,42
Lecturas por segundo (base de datos de perfiles)	14,97	17,20	19,82	13,50
Lecturas por segundo (base de datos social)	1,81	1,83	2,10	2,01
Escrituras por segundo (base de datos de contenido)	50,12	76,24	80,02	99,16
Escrituras por segundo (base de datos de perfiles)	9,01	24,31	23,35	38,29
Escrituras por segundo (base de datos social)	4,12	9,47	10,63	19,45

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 de 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 de base	Resultados de la zona verde 8x1x1 con rastreo de búsqueda de personas
Rendimiento (RPS)	1.024,00	1.026,00
CPU de servidor front-end web (%)	39,84	41,6
CPU de servidor de aplicaciones (%)	41,40	43,1
CPU de SQL Server de contenido/servicio (%)	36,63	39,5
CPU de servidor de rastreo (%)	0,52	34,6
CPU de SQL Server para búsqueda (%)	3,62	14,8

Como se describe en esta tabla:

• Las RPS se mantuvieron prácticamente iguales. Debido a que 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 mejor.

• La CPU del servidor de rastreo y de SQL Server para la búsqueda se incrementó de 0,5% a 34,6% y de 3,6% a 14,8%.

Análisis

Escala del servidor de aplicaciones

El servidor de aplicaciones no fue un 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, como se muestra en la tabla siguiente.

Carga VSTS	416	616	816	1.016	1.216	1.416	1.616
Uso de CPU 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 operaciones requiere trabajar con el servicio de perfiles de usuario de SharePoint Server. La mayoría de las operaciones requiere capturar 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 capturando constantemente los perfiles de usuario de SQL Server. Estos perfiles se almacenan en la memoria caché y, a continuación, todas las solicitudes del servidor front-end web se pueden responder mediante el servidor de aplicaciones sin causar un ida y vuelta de SQL Server. Para ello, busca el perfil en la memoria caché.

Puesto que el número de perfiles de usuario usado en las pruebas fue limitado, el servidor de aplicaciones almacenó en caché todos los perfiles de usuario. Posteriormente, mostró un uso creciente. Cuando se encontraban en caché todos los perfiles, fue una operació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 2007 Microsoft Office system y Microsoft Office 2003.

Outlook Social Connector comprueba SharePoint Server una vez por hora para obtener las actividades de aquellos usuarios que se muestran como compañeros de un usuario en particular. Almacena en caché dichas actividades cada hora. En posteriores comprobaciones de las actividades de compañeros, Outlook Social Connector solo pide las actividad nuevas desde la última comprobación de SharePoint Server. 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 Server, suponiendo que todos los usuarios lo usan todo el día, Outlook Social Connector genera 100.000 solicitudes por hora, que se traduce a 27,77 RPS.

Mostrar las actividades de compañeros podría provocar la divulgación de información. Por ejemplo, una dirección URL que está etiquetada por un compañero puede ser algo confidencial a lo que otro usuario no tiene acceso. En este caso, 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 Server filtra todas las actividades y muestra solo las direcciones URL a las que el usuario tiene acceso en las fuentes de actividades. Este filtrado es lo que llamamos recorte de seguridad . De manera predeterminada, el recorte de seguridad está activado. Sin embargo, puede desactivarlo un administrador de SharePoint Server.

No todas las actividades requieren recorte de seguridad. De los dieciséis tipos de actividad que SharePoint Server 2010 admite, solo cuatro (etiquetado, comentarios en panel de notas, clasificaciones y cambios de pertenencia a listas de distribución) requieren recorte de seguridad. Además, debido a que 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 requeriría el recorte de seguridad sería razonablemente bajo.

Todas las solicitudes de Outlook Social Connector que requieren 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 que el token de autenticación haga esta llamada, primero se realiza una llamada WCF al servicio de token de seguridad.

Nos encontramos con 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. El esfuerzo sobre el servicio de token de seguridad quizá no ocurra con cada usuario, debido a que depende del número total de usuarios y la cantidad total de etiquetas temáticas que se creen 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 requerían recorte de seguridad y por eso vimos que ocurría esto. Por lo tanto, incrementamos el tráfico de Outlook Social Connector en función del número de servidores front-end web. Para la configuración 1x1x1, generamos 8 RPS de tráfico de Outlook Social Connector. Sin embargo, para una 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 recorte de seguridad activado. De forma similar, podríamos haber admitido 28.800 × 3, es decir, 86.400 empleados que usaran Outlook Social Connector en tres servidores front-end web con 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, recuerde que tiene la opción de desactivar el recorte de seguridad mediante el uso de Windows PowerShell 2,0, o cambiando la frecuencia de sincronización de Outlook Social Connector con SharePoint Server. Ambas opciones tienen un efecto significativo en los requisitos de hardware.

Resultados de iteraciones

Los siguientes resultados se ordenan según el enfoque de escalado que se describió en Información general, anteriormente en este artículo.

Topología 1x1x1

En esta sección se describen los resultados de las pruebas que se obtuvieron con un servidor web, un servidor de aplicaciones y un servidor de bases de datos.

Resumen de resultados

• Además de la combinación de pruebas presentada anteriormente en este artículo, esta granja de servidores tenía un tráfico de 8 RPS desde Outlook Social Connector que pedía eventos de fuentes por un usuario.

• En una granja de servidores con un servidor front-end web, un servidor de aplicaciones y un equipo SQL Server, era claro que el servidor front-end web era el cuello de botella. Como se muestra en 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 correctamente 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ó aproximadamente en torno al 85%.

• Puesto que el servidor front-end web era el cuello de botella, agregamos otro servidor front-end web a la granja de servidores para la próxima iteración.

Contadores de rendimiento y gráficos

En la tabla siguiente 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	177
RPS	99,8	147	188	218	238	243
CPU del servidor front-end web	33,9	50	71,8	81,1	90,8	89
CPU del servidor de aplicaciones	7,92	11,7	13,5	14,1	13,9	13,3
CPU de SQL Server	4,7	6,48	7,99	8,21	8,41	8,88
Percentil 75 [segundos]	0,13	0,16	0,17	0,25	0,3	0,45
Percentil 95 [segundos]	0,29	0,47	0,41	0,55	0,55	0,77

Topología 2x1x1

En esta sección se describen los resultados de las pruebas que se obtuvieron con dos servidores web, un servidor de aplicaciones y un servidor de bases de datos.

Resumen de resultados

• Además de la combinación de pruebas presentada anteriormente en este artículo, esta granja de servidores tenía un tráfico de 16 RPS desde Outlook Social Connector que pedía eventos de fuentes por un usuario.

• En una granja de servidores con dos servidores front-end web, un servidor de aplicaciones y un equipo SQL Server, los servidores front-end web eran el cuello de botella. Tal como se presenta en estos datos, la CPU del servidor front-end web alcanzó aproximadamente el 89% de uso cuando la granja de servidores se sometió a 520 RPS usando 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 la CPU del servidor front-end web osciló en torno a un uso del 47%. Esto indica que esta granja de servidores puede proporcionar correctamente un valor de RPS de aproximadamente 278 con la combinación de pruebas y el hardware que se usó 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%.

• Debido a que 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 próxima 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	354
RPS	190	278	390	455	500	520
CPU del servidor front-end web	36	50,9	71,9	86,9	87,1	89,5
CPU del servidor de aplicaciones	16	24,9	28,3	26,5	26,5	24,9
CPU de SQL Server	8,06	10,6	14,2	16,4	17,9	18,9
Percentil 75 [segundos]	0,16	0,22	0,22	0,33	0,42	0,53
Percentil 95 [segundos]	0,42	0,64	0,51	0,69	0,73	0,89

Topología 3x1x1

En esta sección se describen los resultados de las pruebas que se obtuvieron con tres servidores web, un servidor de aplicaciones y un servidor de bases de datos.

Resumen de resultados

• Además de la combinación de pruebas presentada anteriormente en este artículo, esta granja de servidores tenía un tráfico de 24 RPS desde Outlook Social Connector que pedía eventos de fuentes por un usuario.

• En una granja de servidores con tres servidores front-end web, un servidor de aplicaciones y un equipo de SQL Server, los servidores front-end web eran el cuello de botella. Tal como se presenta en estos datos, la CPU del servidor front-end web alcanzó aproximadamente el 76% de uso cuando la granja de servidores se sometió a 629 RPS usando 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 la CPU del servidor front-end web osciló en torno a un uso del 48%. Esto indica que esta granja de servidores puede proporcionar correctamente un valor RPS de aproximadamente 440 con la combinación de pruebas y el hardware que se usó 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%.

• Debido a que 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 con el agregado de un servidor front-end web, decidimos agregar dos servidores front-end web. De esta manera, esperábamos determinar si el servidor de aplicaciones o el equipo SQL Server era el 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	531
RPS	264	393	532	624	634	629
CPU del servidor front-end web	30,5	46,3	62,55	72,95	75,4	76
CPU del servidor de aplicaciones	22,7	35,6	34,2	32,5	32,5	29,4
CPU de SQL Server	10,4	14,8	20,8	22,5	22,8	22,4
Percentil 75 [segundos]	0,17	0,26	0,27	0,28	0,31	0,40
Percentil 95 [segundos]	0,63	1,08	0,76	0,68	0,88	0,98

Topología 5x1x1

En esta sección se describen los resultados de las pruebas que se obtuvieron con cinco servidores web, un servidor de aplicaciones y un servidor de bases de datos.

Resumen de resultados

• Además de la combinación de pruebas presentada anteriormente en este artículo, esta granja de servidores tenía un tráfico de 40 RPS desde Outlook Social Connector que pedía eventos de fuentes por un usuario.

• En una granja de servidores con cinco servidores front-end web, un servidor de aplicaciones y un equipo 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 estos datos, 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 de 75% de 0,16 segundos, y la CPU del servidor front-end web osciló en torno a un uso del 46%. Esto indica que esta granja de servidores puede proporcionar correctamente un valor RPS de aproximadamente 683 con la combinación de pruebas y el hardware que se usó para las pruebas. Las RPS de zona roja que proporcionó 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. Esperábamos determinar si el servidor de aplicaciones o el equipo SQL Server era el cuello de botella con esa configuración.

Contadores de rendimiento y gráficos

Aquí se presentan varios contadores de rendimiento capturados durante la prueba de la granja de servidores 5x1x1, en etapas diferentes de la carga de usuarios. Debido a que 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	885
RPS	359	560	901	1.188	1.281	1.315
CPU del servidor front-end web	20,5	34	56,2	77,5	86,1	88
CPU del servidor de aplicaciones	40,2	50,6	66,9	71,3	66,3	58,7
CPU de SQL Server	13,9	20,3	34,9	53,6	58,4	64

Topología 8x1x1

En esta sección se describen los resultados de las pruebas que se obtuvieron con ocho servidores web, un servidor de aplicaciones y un servidor de bases de datos.

Resumen de resultados

• Además de la combinación de pruebas presentada anteriormente en este artículo, esta granja de servidores tenía un tráfico de 64 RPS desde Outlook Social Connector que pedía eventos de fuentes por un usuario.

• En una granja de servidores con ocho servidores front-end web, un servidor de aplicaciones y un equipo SQL Server, la CPU de SQL Server resultó, en última instancia, el cuello de botella. Tal como se presenta en estos datos, 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 75% de 0,31 segundos, y la CPU de SQL Server osciló en torno a un uso del 30%. Sin embargo, la CPU del servidor de aplicaciones fue aproximadamente 48%. Esto indica que esta granja de servidores puede proporcionar correctamente un valor RPS de aproximadamente 793 con la combinación de pruebas y el hardware que se usó 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%.

• Debido a que 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 de SQL Server para la próxima 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	1.016	1.216	1.416	1.616
RPS	664	1.101	1.359	1.530	1.655	1.664	1.617,00
CPU del servidor front-end web	26,7	44,4	54,7	61,5	67	65,9	65,10
CPU del servidor de aplicaciones	37,6	49,4	57,9	61,9	67,1	65,3	63,10
CPU de SQL Server	23,2	42	57,9	69,5	79,5	80,8	77,30

Topología 8x1x2

En esta sección se describen los resultados de las pruebas que se obtuvieron con ocho servidores web, un servidor de aplicaciones y dos servidores de bases de datos.

Resumen de resultados

• Además de la combinación de pruebas presentada anteriormente en este artículo, esta granja de servidores tenía un tráfico de 64 RPS desde Outlook Social Connector que pedía eventos de fuentes por un usuario.

• En una granja de servidores con ocho servidores front-end web, un servidor de aplicaciones y dos equipos SQL Server, pudimos llevar la configuración a su extremo. El servidor front-end web y el servidor de aplicaciones eran ambos cuellos de botella, mientras que el uso de SQL Server combinada también estaba en la parte superior de los 70. La granja de servidores presentó un valor RPS de 1.817 con carga máxima.

• 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, reducir la carga en cada servidor front-end web.

Contadores de rendimiento y gráficos

En la siguiente tabla y el siguiente gráfico 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	1.066	1.266	1.416
RPS	466,00	873,40	1.431,00	1.703,00	1.766,00	1.817,00
CPU del servidor front-end web	19,90	36,90	57,60	68,00	71,40	71,60
CPU del servidor de aplicaciones	29,80	47,20	63,50	71,40	71,90	73,40
CPU de SQL Server total	19,61	32,40	55,20	63,60	68,50	74,90
CPU de SQL Server de contenido	9,93	17,90	31,90	40,10	42,30	45,90
CPU de SQL Server de servicios	9,68	14,50	23,30	23,50	26,20	29,00

Acerca de los autores

Gaurav Doshi es administrador de programas de Microsoft

Wenyu Cai es ingeniero de software de prueba de Microsoft

See Also

Other Resources

Centro de recursos: Administración de la capacidad para SharePoint Server 2010