Estudio de laboratorio del entorno de portal de departamento (SharePoint Server 2010)
Se aplica a: SharePoint Server 2010
Última modificación del tema: 2016-11-30
Este documento proporciona asistencia sobre planeación de capacidad y rendimiento para un portal de departamento basado en Microsoft SharePoint Server 2010. Se incluye lo siguiente:
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 que se necesitan para implementar un entorno similar y para optimizar el entorno para las características de rendimiento y capacidad adecuadas.
En este artículo:
Introducción a este entorno
Glosario
Descripción general
Especificaciones
Resultados y análisis
Introducción a este entorno
En este documento se describe la metodología de prueba y los resultados para proporcionar asistencia para la planeación de la capacidad de un portal de departamento típico. Un portal de departamento es una implementación de SharePoint Server 2010 donde los equipos realizan principalmente actividades de colaboración y publicación de contenido. En este documento se presupone que un "departamento" es una organización dentro de una empresa de entre 1.000 y 10.000 empleados.
Según el escenario, los requisitos serán distintos. Por tanto, es importante complementar esta guía con pruebas adicionales en su propio hardware y en su propio entorno. Si la carga de trabajo y el diseño previsto se parecen al entorno descrito en este documento, puede usar este documento para sacar conclusiones sobre el escalado horizontal y vertical del entorno.
Cuando lea este documento, sabrá cómo hacer lo siguiente:
Estimar el hardware que es necesario para admitir la escala que debe admitir: número de usuarios, carga y las características habilitadas.
Diseñar la topología física y lógica para lograr una confiabilidad y eficacia óptimas. Este documento no trata sobre la disponibilidad alta ni la recuperación ante desastres.
Comprender el efecto de los rastreos de búsqueda constantes en RPS para una implementación de portal de departamento.
El entorno de SharePoint Server 2010 descrito en este documento es un entorno de laboratorio que simula un entorno de producción en una compañía grande. Para obtener más información acerca del entorno de producción, vea Caso práctico técnico de entorno de colaboración del departamento (SharePoint Server 2010).
Antes de leer este documento, asegúrese de comprender los conceptos clave sobre la administración de capacidad en SharePoint Server 2010. La siguiente documentación le proporcionará información acerca del método recomendado para administrar la capacidad y sobre cómo usar eficazmente la información de este documento. También se definen los términos usados en todo el documento.
Además, le recomendamos que lea lo siguiente:
Glosario
En este documento encontrará algunos términos especializados. Estos son algunos términos clave y sus definiciones:
RPS: solicitudes por segundo. La cantidad de solicitudes recibidas por una granja o un servidor en un segundo. Esta es una medición común de carga del servidor y de la granja de servidores.
Observe que las solicitudes difieren 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 no tienen un uso intensivo de recursos no se cuentan en las mediciones de RPS.
Zona verde: es el estado en 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 0,5 segundos.
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 se mantuvo en un 40% del uso de CPU o inferior, a fin de reservar un 10% para la carga de rastreo de búsqueda. Se da por sentado que el regulador de recursos de Microsoft SQL Server se usa en la producción para limitar la carga de rastreo de búsqueda al 10% de CPU.
- La frecuencia de error es inferior a 0,01%.
Zona roja (máx): es el estado en que el servidor puede mantener el siguiente conjunto de criterios:
La característica de limitación de solicitudes HTTP está habilitada, pero no se devuelven errores 503 (servidor ocupado).
La frecuencia de error es inferior a 0,1%.
La latencia del 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 menor o igual que el 75%, lo que permite que el 10% se reserve para la carga de rastreo de búsqueda, limitada por el uso del regulador de recursos de SQL Server.
Todos los servidores web tienen un uso de CPU menor o igual que el 75%.
AxBxC (notación gráfica): se trata del número de servidores web, servidores de aplicaciones y servidores de bases de datos respectivamente en una granja de servidores. Por ejemplo, 2x1x1 significa que este entorno tiene 2 servidores web, 1 servidor de aplicaciones y 1 servidor de bases de datos.
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.
Descripción general
En esta sección se proporciona una descripción general de los supuestos y la metodología de prueba.
Supuestos
Para realizar la prueba, partimos de los siguientes supuestos:
En el ámbito de esta prueba, no se consideró E/S de disco como un factor limitante. Se presupone que hay disponible un número infinito de cilindros.
Las pruebas del modelo solo alcanzan el punto máximo de uso de tiempo en un portal de departamento típico. No se tuvieron en cuenta los cambios cíclicos en el tráfico observados con ciclos de día y noche. Eso también significa que los trabajos del temporizador que generalmente requieren ejecuciones nocturnas programadas no se incluyen en la combinación.
No hay código personalizado que se ejecute en la implementación del portal de departamento en este caso. No se puede garantizar el comportamiento de soluciones de terceros o código personalizado que estén instalados y se ejecuten en el portal de departamento.
En el caso de estas pruebas, todas las bases de datos de servicios y las bases de datos de contenido se colocaron en la misma sesión de Microsoft SQL Server. La base de datos de uso se mantuvo en una sesión independiente de SQL Server.
En el caso de estas pruebas, la memoria caché de objetos binarios está habilitada.
El tráfico de rastreo de búsqueda no se tomó en consideración para estas pruebas. Pero a fin de tener en cuenta los efectos de un rastreo de búsqueda constante, se modificaron las definiciones de una granja en buen estado. (La definición de la zona verde debe ser del 40% para SQL Server para permitir el impuesto del 10% de los rastreos de búsqueda. Del mismo modo, se usó el 80% de CPU de SQL Server como criterio para el máximo de RPS).
Metodología de prueba
Se usó Visual Studio Team System para Test 2008 SP2 a fin de realizar las pruebas de rendimiento. El objetivo de las pruebas era encontrar la característica de rendimiento de la zona verde, la zona máxima y las diversas fases del sistema entre cada topología. En el Glosario se ofrecen definiciones detalladas de "zona máxima" y "zona verde", según las mediciones de valores específicos para los contadores de rendimiento. No obstante, se suele considerar que una configuración de granja se encuentra bajo estrés cuando su rendimiento se encuentra próximo a la "zona máxima", mientras que una configuración de granja se considera en buen estado si su rendimiento se encuentra en la "zona verde".
El método empleado en las pruebas consistió en usar primero la configuración de granja más básica y ejecutar una serie de pruebas. La primera prueba consistió en aumentar gradualmente la carga en el sistema y supervisar su característica de rendimiento. De esta prueba se derivó el rendimiento y la latencia a varias cargas de usuarios, y también se identificó el cuello de botella del sistema. Con estos datos, se identificó la carga de usuarios en la que la granja de servidores presentaba características de zona verde y zona máxima. Se realizaron pruebas independientes en aquellas cargas de usuario constantes identificadas previamente durante un tiempo mayor. Estas pruebas garantizaron que la configuración de la granja de servidores podía ofrecer un rendimiento constante de zona verde y zona máxima en las cargas de usuarios respectivas, durante un período más largo de tiempo.
Posteriormente, al realizar las pruebas para la configuración siguiente, se escaló horizontalmente el sistema para eliminar los cuellos de botella identificados en la ejecución anterior. Se prosiguió con la iteración de esta manera hasta alcanzar el cuello de botella de CPU de SQL Server.
Empezamos con una configuración mínima de granja de un servidor web o servidor de aplicaciones y un servidor de bases de datos. A través de varias iteraciones, finalmente terminamos con una configuración de granja de tres servidores web, un servidor de aplicaciones y un servidor de bases de datos, donde se aprovechó al máximo la CPU del servidor de bases de datos. Más abajo se ofrece un resumen rápido y gráficos de las pruebas que se realizaron en cada iteración para establecer la zona verde y la zona máxima de esa configuración. A continuación, se realiza una comparación de la zona verde y la zona de máxima para las distintas iteraciones, a partir de las cuales se derivan nuestras recomendaciones.
El equipo del kit de herramientas de administración de SharePoint desarrolló la herramienta Load Test Toolkit (LTK, Kit de herramientas de prueba de carga) que está disponible públicamente para que los clientes la descarguen y usen.
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 laboratorio.
Hardware
En la siguiente tabla se presentan las especificaciones de hardware para los equipos que se usaron en esta prueba. Todos los servidores web que se agregaron a la granja de servidores durante varias iteraciones de la prueba cumplen con las mismas especificaciones.
| Servidor web | Servidor de aplicaciones | Servidor de bases de datos | |
|---|---|---|---|
Procesadores |
2px4c a 2,33 GHz |
2px4c a 2,33 GHz |
4px4c a 3,19GHz |
RAM |
8 GB |
8 GB |
32 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 tabla siguiente se explica el software instalado y en ejecución en los servidores que se usaron en estas pruebas.
| Servidor 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 |
SharePoint Server 2010 y Office Web Applications, versiones preliminares |
SharePoint Server 2010 y Office Web Applications, versiones preliminares |
SQL Server 2008 R2 CTP3 |
Autenticación |
Windows NTLM |
Windows NTLM |
Windows NTLM |
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 que se ejecutan localmente |
Correo electrónico entrante de Microsoft SharePoint Foundation Aplicación web de Microsoft SharePoint Foundation Servicio de temporizador de flujo de trabajo de Microsoft SharePoint Foundation Servicio de configuración del sitio y consulta de búsqueda Búsqueda de SharePoint Server |
Administración central Servicios de Excel Servicio web de metadatos administrados Correo electrónico entrante de Microsoft SharePoint Foundation Aplicación web de Microsoft SharePoint Foundation Servicio de temporizador de flujo de trabajo de Microsoft SharePoint Foundation Servicios de PowerPoint Servicio de configuración del sitio y consulta de búsqueda Búsqueda de SharePoint Server Servicios de gráficos de Visio Servicio de visualización de Word |
No aplicable |
La tabla indica los servicios que se aprovisionan en el entorno de prueba. No se aprovisionan otros servicios como, por ejemplo, el servicio de perfiles de usuario y Web Analytics.
Topología y configuración
En el siguiente diagrama se muestra la topología utilizada en las pruebas. Cambiamos el número de servidores web de 1 a 2 y 3, mientras nos desplazamos entre las iteraciones, pero por lo demás, la topología sigue siendo la misma.
.gif "Diagrama de topología de conjunto o granja de servidores para este entorno")
Geometría de disco y conjunto de datos
La granja de servidores de prueba se rellenó con aproximadamente 1,62 terabytes de contenido, distribuidos en cinco bases de datos de contenido de tamaños diferentes. En la siguiente tabla se explica esta distribución:
| Base de datos de contenido | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
Tamaño de base de datos de contenido |
36 GB |
135 GB |
175 GB |
1,2 terabytes |
75 GB |
Número de sitios |
44 |
74 |
9 |
9 |
222 |
Número de sitios web |
1544 |
2308 |
2242 |
2041 |
1178 |
Configuración de RAID |
0 |
0 |
0 |
0 |
0 |
Número de cilindros para MDF |
1 |
1 |
5 |
3 |
1 |
Número de cilindros para LDF |
1 |
1 |
1 |
1 |
1 |
Combinación de transacciones
A continuación se ofrecen notas importantes acerca de la combinación de transacciones:
No hay ningún sitio de Mis sitios aprovisionado en el portal de departamento. Además, el servicio de perfiles de usuario, que es compatible con Mis sitios, no se está ejecutando en la granja de servidores. La combinación de transacciones no incluye ninguna visita de servicio web o página de Mi sitio o tráfico relacionado con Outlook Social Connector.
La combinación de pruebas no incluye el tráfico generado por la co-autoría de documentos.
La combinación de pruebas no incluye tráfico de rastreo de la búsqueda. Sin embargo 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.
En la tabla siguiente se describe la combinación global de transacciones. El total de los porcentajes es 100.
| Característica o servicio | Operación | Lectura o escritura | Porcentaje de combinación |
|---|---|---|---|
ECM |
Obtener archivos estáticos |
l |
8,93% |
Ver página principal |
l |
1,52% |
|
Microsoft InfoPath |
Mostrar o editar elementos de lista y nuevos formularios |
l |
0,32% |
Descargar el archivo mediante la opción "Guardar como" |
l |
1,39% |
|
Microsoft OneNote 2010 |
Abrir archivo de Microsoft Office OneNote 2007 |
l |
13,04% |
Búsqueda |
Buscar en OSSSearch.aspx o SearchCenter |
l |
4,11% |
Flujo de trabajo |
Iniciar el flujo de trabajo de inicio automático |
e |
0,35% |
Microsoft Visio |
Representar archivo de Visio en PNG/XAML |
l |
0,90% |
Office Web Applications - PowerPoint |
Representar Microsoft PowerPoint, desplazarse a 6 diapositivas |
l |
0,05% |
Office Web Applications - Word |
Representar y desplazar documento de Microsoft Word en PNG/Silverlight |
l |
0,24% |
Microsoft SharePoint Foundation |
Lista: desproteger y, a continuación, proteger un elemento |
e |
0,83% |
Lista: obtener lista |
l |
0,83% |
|
Lista: sincronización de Outlook |
l |
1,66% |
|
Lista: obtener cambios de elemento de lista |
l |
2,49% |
|
Lista: actualizar elementos de lista y agregar nuevos elementos |
e |
4,34% |
|
Obtener vista y ver colección |
l |
0,22% |
|
Obtener sitios web |
l |
1,21% |
|
Ir a la página de acceso denegado |
l |
0,07% |
|
Ver Examinar fuentes de lista |
l |
0,62% |
|
Ir a listas de vista |
l |
0,03% |
|
Ir a default.aspx (página principal) |
l |
1,70% |
|
Ir a Cargar documento en biblioteca de documentos |
e |
0,05% |
|
Ir a la vista predeterminada de la biblioteca o lista |
l |
7,16% |
|
Eliminar documento en biblioteca de documentos con DAV |
e |
0,83% |
|
Obtener documento de biblioteca de documentos con DAV |
l |
6,44% |
|
Bloquear y desbloquear un documento en biblioteca de documentos con DAV |
e |
3,32% |
|
Lista Propfind mediante DAV |
l |
4,16% |
|
Sitio Propfind mediante DAV |
l |
4,16% |
|
Documento de lista mediante FPSE |
l |
0,91% |
|
Cargar documento mediante FPSE |
e |
0,91% |
|
Ir a la página Todo el contenido del sitio |
l |
0,03% |
|
Ver fuentes RSS de listas o wikis |
l |
2,03% |
|
Servicios de Excel |
Representar archivos pequeños o grandes de Excel |
l |
1,56% |
Áreas de trabajo |
WXP: protocolo interno de Cobalt |
l |
23,00% |
Carga de archivo completo mediante WXP |
e |
0,57% |
Resultados y análisis
En esta sección se describe la metodología de prueba y los resultados para proporcionar asistencia para planear la capacidad de un portal de departamento típico.
Resultados de la configuración de la granja de 1x1
Resumen de resultados
En un servidor web y una granja de servidores de bases de datos, además de las tareas del servidor web, el mismo equipo también funcionaba como servidor de aplicaciones. Claramente este equipo (aún denominado servidor web) era el cuello de botella. Como se presenta en los datos en este caso, la CPU del servidor web alcanzó alrededor de 86% de su uso cuando la granja de servidores se sometió a la carga de usuarios de 125 usuarios mediante la combinación de transacciones descrita anteriormente en este documento. En ese momento, la granja de servidores presentó un máximo de 101,37 RPS.
Incluso en una carga de usuarios pequeña, el uso del servidor web siempre fue demasiado alto para poder considerar esta granja de servidores como una granja en buen estado. Debido a la carga de trabajo y el conjunto de datos utilizados en la prueba, no se recomienda esta configuración como implementación real.
Si nos basamos en la definición de "zona verde", no hay realmente una "zona verde" en esta granja de servidores. Siempre está bajo presión, incluso con una pequeña carga. En cuanto a la "zona máxima", con la carga más pequeña, en la que la granja de servidores estaba en la "zona máxima", hubo 75 RPS.
Dado que el servidor web era el cuello de botella debido a su rol dual como servidor de aplicaciones, para la siguiente iteración, separamos el rol del servidor de aplicaciones en su propio equipo.
Gráficos y contadores de rendimiento
En la siguiente tabla se presentan varios contadores de rendimiento capturados durante las pruebas de una granja de servidores de 1x1 en distintos pasos de la carga de usuarios.
| Carga de usuarios | 50 | 75 | 100 | 125 |
|---|---|---|---|---|
RPS |
74,958 |
89,001 |
95,79 |
101,37 |
Latencia |
0,42 |
0,66 |
0,81 |
0,81 |
CPU del servidor web |
79,6 |
80,1 |
89,9 |
86 |
CPU del servidor de aplicaciones |
No disponible |
No disponible |
No disponible |
No disponible |
CPU del servidor de bases de datos |
15,1 |
18,2 |
18,6 |
18,1 |
75º percentil (s) |
0,3 |
0,35 |
0,55 |
0,59 |
95º percentil (s) |
0,71 |
0,77 |
1,03 |
1 |
En el siguiente gráfico se muestran los resultados de latencia y RPS para una configuración de 1x1.
.gif "Gráfico con RPS y latencia en escala 1x1")
En el siguiente gráfico se muestran los datos del contador de rendimiento en una configuración de 1x1.
.gif "Gráfico con contadores de rendimiento en escala 1x1")
Resultados de la configuración de la granja de 1x1x1
Resumen de resultados
En un servidor web, un servidor de aplicaciones y una granja de servidores de bases de datos, el servidor web era el cuello de botella. Como se presenta en los datos de esta sección, la CPU del servidor web alcanzó alrededor del 85% de su uso cuando la granja de servidores se sometió a la carga de 150 usuarios mediante la combinación de transacciones descrita anteriormente en este documento. En ese momento, la granja de servidores presentó un máximo de 124,1 RPS.
Esta configuración obtuvo un RPS de "zona verde" de 99, con una latencia de 75º percentil a 0,23 segundos, y la CPU del servidor web rondó alrededor del 56% de su uso. Esto indica que esta granja de servidores puede obtener alrededor de 99 RPS en buen estado. El número de RPS de "zona máxima" obtenidas por esta granja de servidores fue de 123 con latencias de 0,25 segundos y la CPU del servidor web rondó aproximadamente el 85%.
Dado que la CPU del servidor web era el cuello de botella en esta iteración, aliviamos el cuello de botella mediante la adición de otro servidor web en la siguiente iteración.
Gráficos y contadores de rendimiento
En la siguiente tabla se presentan varios contadores de rendimiento capturados durante las pruebas de una granja de servidores de 1x1x1 en distintos pasos de la carga de usuarios.
| Carga de usuarios | 25 | 50 | 75 | 100 | 125 | 150 |
|---|---|---|---|---|---|---|
RPS |
53,38 |
91,8 |
112,2 |
123,25 |
123,25 |
124,1 |
Latencia |
34,2 |
56 |
71,7 |
81,5 |
84,5 |
84,9 |
CPU del servidor web |
23,2 |
33,8 |
34,4 |
32 |
30,9 |
35,8 |
CPU del servidor de aplicaciones |
12,9 |
19,7 |
24,1 |
25,2 |
23,8 |
40,9 |
CPU del servidor de bases de datos |
0,22 |
0,23 |
0,27 |
0,32 |
0,35 |
0,42 |
75º percentil (s) |
0,54 |
0,52 |
0,68 |
0,71 |
0,74 |
0,88 |
En el siguiente gráfico se muestran los resultados de latencia y RPS para una configuración de 1x1x1.
.gif "Gráfico con RPS y latencia en escala 1x1x1")
En el siguiente gráfico se muestran los datos del contador de rendimiento en una configuración de 1x1x1.
.gif "Gráfico con contadores de rendimiento en escala 1x1x1")
Resultados de la configuración de la granja de 2x1x1
Resumen de resultados
En dos servidores web, un servidor de aplicaciones y una granja de servidores de bases de datos, el servidor web era el cuello de botella. Como se presenta en los datos de esta sección, la CPU del servidor web alcanzó alrededor del 76% de su uso cuando la granja de servidores se sometió a una carga de 200 usuarios mediante la combinación de transacciones descrita anteriormente en este documento. En ese momento, la granja de servidores presentó un máximo de 318 RPS.
Esta configuración obtuvo 191 RPS de "zona verde", con una latencia de 75º percentil a 0,37 segundos, y la CPU del servidor web rondó alrededor del 47 % de su uso. Esto indica que esta granja de servidores puede obtener alrededor de 191 RPS en buen estado. Las RPS de "zona máxima" obtenidas por esta granja de servidores fueron de 291 con latencias de 0,5 segundos y la CPU del servidor web rondó aproximadamente el 75%.
Dado que la CPU del servidor web era el cuello de botella en esta iteración, aliviamos el cuello de botella mediante la adición de otro servidor web en la siguiente iteración.
Gráficos y contadores de rendimiento
En la siguiente tabla se presentan varios contadores de rendimiento capturados durante las pruebas de una granja de servidores de 2x1x1 en distintos pasos de la carga de usuarios.
| Carga de usuarios | 40 | 80 | 115 | 150 | 175 | 200 |
|---|---|---|---|---|---|---|
RPS |
109 |
190 |
251 |
287 |
304 |
318 |
Latencia |
0,32 |
0,37 |
0,42 |
0,49 |
0,54 |
0,59 |
CPU del servidor web |
27,5 |
47,3 |
61,5 |
66,9 |
73,8 |
76,2 |
CPU del servidor de aplicaciones |
17,6 |
29,7 |
34,7 |
38 |
45 |
45,9 |
CPU del servidor de bases de datos |
21,2 |
36,1 |
43,7 |
48,5 |
52,8 |
56,2 |
75º percentil (s) |
0,205 |
0,23 |
0,27 |
0,3 |
0,305 |
0,305 |
95º percentil (s) |
0,535 |
0,57 |
0,625 |
0,745 |
0,645 |
0,57 |
En el siguiente gráfico se muestran los resultados de latencia y RPS para una configuración de 2x1x1.
.gif "Gráfico con RPS y latencia en escala 2x1x1")
En el siguiente gráfico se muestran los datos del contador de rendimiento en una configuración de 2x1x1.
.gif "Gráfico con contadores de rendimiento en escala 2x1x1")
Resultados de la configuración de la granja de 3x1x1
Resumen de resultados
En tres servidores web, un servidor de aplicaciones y una granja de servidores de bases de datos, finalmente, la CPU del servidor de bases de datos era el cuello de botella. Como se presenta en los datos de esta sección, la CPU del servidor de bases de datos alcanzó alrededor del 76% de su uso cuando la granja de servidores se sometió a una carga de 226 usuarios mediante la combinación de transacciones descrita anteriormente en este documento. En ese momento, la granja de servidores presentó un máximo de 310 RPS.
Esta configuración obtuvo 242 RPS de "zona verde", con una latencia de 75º percentil a 0,41 segundos, y la CPU del servidor de bases de datos rondó alrededor del 44% de su uso. Esto indica que esta granja de servidores puede entregar en buen estado alrededor de 242 RPS. Las RPS de "zona máxima" entregadas por esta granja de servidores fueron de 318 con latencias de 0,5 segundos y la CPU del servidor de bases de datos rondó alrededor del 75%.
Esta fue la última configuración de la serie.
Gráficos y contadores de rendimiento
En la siguiente tabla se presentan varios contadores de rendimiento capturados durante las pruebas de una granja de servidores de 3x1x1 en distintos pasos de la carga de usuarios.
| Carga de usuarios | 66 | 103 | 141 | 17 | 202 | 226 |
|---|---|---|---|---|---|---|
RPS |
193,8 |
218,5 |
269,8 |
275,5 |
318,25 |
310 |
Latencia |
0,3 |
0,41 |
0,47 |
0,58 |
0,54 |
0,78 |
CPU del servidor web |
33 |
38,3 |
45,8 |
43,3 |
51 |
42,5 |
CPU del servidor de aplicaciones |
28 |
32,6 |
46,5 |
40 |
45,1 |
43,7 |
CPU del servidor de bases de datos |
41,6 |
44,2 |
52,6 |
48 |
61,8 |
75 |
75º percentil (s) |
0,22 |
0,24 |
0,30 |
0,65 |
0,78 |
0,87 |
95º percentil (s) |
0,49 |
0,57 |
0,72 |
1,49 |
0,51 |
1,43 |
En el siguiente gráfico se muestran los resultados de latencia y RPS en una configuración de 3x1x1.
.gif "Gráfico con RPS y latencia en escala 3x1x1")
En el siguiente gráfico se muestran los datos del contador de rendimiento para una configuración de 3x1x1.
.gif "Gráfico con contadores de rendimiento en escala 3x1x1")
Comparación
A partir de las pruebas iterativas realizadas, descubrimos los puntos en los que una configuración entra en la zona máxima o la zona verde. A continuación, presentamos una tabla con esos puntos.
La tabla y los gráficos de esta sección proporcionan un resumen de todos los resultados que se presentaron anteriormente en este artículo.
| Topología | 1x1 | 1x1x1 | 2x1x1 | 3x1x1 |
|---|---|---|---|---|
Máximo de RPS |
75 |
123 |
291 |
318 |
RPS en zona verde |
No aplicable |
99 |
191 |
242 |
Latencia máxima |
0,29 |
0,25 |
0,5 |
0,5 |
Latencia en zona verde |
0,23 |
0,23 |
0,37 |
0,41 |
En el siguiente gráfico se muestra un resumen de RPS en distintas configuraciones.
.gif "Gráfico con comparación de RPS en cada escala")
En el siguiente gráfico se muestra un resumen de latencia en distintas configuraciones.
.gif "Comparación de la latencia en todas las escalas")
Una nota sobre E/S de disco
Los cuellos de botella basados en E/S de disco no se tuvieron en cuenta al prescribir las recomendaciones de este documento. No obstante, aún es interesante observar la tendencia. Estos son los números:
| Configuración | 1x1 | 1x1x1 | 2x1x1 | 3x1x1 |
|---|---|---|---|---|
Máximo de RPS |
75 |
154 |
291 |
318 |
Lecturas/s |
38 |
34 |
54 |
58 |
Escrituras/s |
135 |
115 |
230 |
270 |
Dado que la duración de las pruebas es de 1 hora y la prueba usa solo un conjunto fijo de bibliotecas de documentos, sitios web, sitios, etc., SQL Server pudo almacenar en caché todos los datos. Por lo tanto, las pruebas produjeron muy poca E/S de lectura. Se observan más operaciones de E/S de escritura que de lectura. Es importante tener en cuenta que se trata de un artefacto de la metodología de prueba y que no es una buena representación de las implementaciones reales. La mayoría de los portales de departamento típicos tendrían más operaciones de lectura en una proporción de 3 a 4 veces más que las operaciones de escritura.
El siguiente gráfico muestra IOPS en distintas RPS.
.gif "Gráfico con IOPS en todas las escalas")
Pruebas con rastreo incremental de búsqueda
Como se mencionó antes, todas las pruebas hasta ahora se ejecutaron sin tráfico de rastreo de búsqueda. A fin de proporcionar información acerca de cómo el rastreo de búsqueda constante puede afectar al rendimiento de una granja de servidores, decidimos averiguar el máximo de RPS de usuario y las latencias de usuario correspondientes con tráfico de rastreo de búsqueda en la combinación. Se agregó un servidor web independiente a una granja de 3x1x1, designado como un destino de rastreo. Se observó una caída del 17% en RPS en comparación con el valor de RPS original mostrado por 3x1x1.
En una prueba independiente, en la misma granja, se usó el regulador de recursos para limitar los recursos disponibles al 10% del rastreo de búsqueda. Se observó que a medida que la búsqueda usa menos recursos, el máximo de RPS de la granja de servidores alcanza hasta un 6%.
| Línea base 3x1x1 | Solo rastreo incremental | Sin regulador de recursos | 10% de regulador de recursos | |
|---|---|---|---|---|
RPS |
318 |
No disponible |
276 |
294,5 |
Diferencia de porcentaje de RPS con respecto a línea base |
0% |
No disponible |
83% |
88% |
CPU del servidor de bases de datos (%) |
83,40 |
8,00 |
86,60 |
87,3 |
CPU del servidor de bases de datos SA (%) |
3,16 |
2,13 |
3,88 |
4,2 |
CPU del servidor web (%) |
53,40 |
0,30 |
47,00 |
46,5 |
CPU del servidor de aplicaciones (%) |
22,10 |
28,60 |
48,00 |
41,3 |
CPU del servidor web de rastreo (%) |
0,50 |
16,50 |
15,00 |
12,1 |
El siguiente gráfico muestra los resultados de pruebas con el rastreo de búsqueda incremental activado.
.gif "Solicitudes por segundo con la búsqueda en ejecución")
Importante
Aquí solo estamos hablando sobre rastreo incremental, en una granja de servidores donde no hay muchos cambios en el contenido. Es importante tener en cuenta que el uso del 10% de los recursos no será suficiente para un rastreo de búsqueda completo. También puede resultar ser menor si hay demasiados cambios. Definitivamente no es recomendable limitar el uso de recursos al 10% si se va a ejecutar un rastreo de búsqueda completo o si la granja de servidores suele tener un gran volumen de cambios de contenido entre rastreos.
Resumen de resultados y recomendaciones
Para resumir los resultados de todas las configuraciones que se probaron:
Con la configuración, el conjunto de datos y la carga de trabajo de prueba seleccionados para las pruebas, pudimos escalar horizontalmente a un máximo de tres servidores web antes de alcanzar un cuello de botella de SQL Server en la CPU. El máximo absoluto de RPS que pudimos alcanzar fue de aproximadamente 318.
Con cada servidor web adicional, el aumento de RPS fue casi lineal. Podemos extrapolar que mientras que SQL Server no alcance un cuello de botella, se pueden agregar más servidores web y es posible obtener un aumento adicional de RPS.
Las latencias no se vieron muy afectadas al acercarnos al cuello de botella en SQL Server.
El rastreo de búsqueda incremental afecta directamente a las RPS ofrecidas por una configuración. Se puede minimizar el efecto mediante el regulador de recursos.
Mediante los resultados, estas son algunas recomendaciones sobre cómo lograr incluso una mayor escala si es necesario tener más RPS en el portal de departamento:
La granja de 1x1 puede entregar hasta 75 RPS. Sin embargo, normalmente se somete a mucho esfuerzo. No es una configuración recomendada para un portal de departamento en producción.
Separe las bases de datos de contenido y las bases de datos de servicios en sesiones independientes de SQL Server: en la carga de trabajo de prueba utilizada en las pruebas, cuando SQL Server presentaba un cuello de botella en la CPU, solo el 3% del tráfico era para las bases de datos de servicios. Por lo tanto, este paso habría logrado un mejor escalado del que se observó. Sin embargo, en general, el aumento del escalado mediante la separación de las bases de datos de contenido y las bases de datos de servicios de contenido es directamente proporcional al tráfico en las base de datos de servicios de la granja de servidores.
Separe bases de datos de contenido individuales en sesiones independientes de SQL Server. En el conjunto de datos utilizado para las pruebas, teníamos 5 bases de datos de contenido, ubicadas todas en la misma sesión de SQL Server. Al separarlas en equipos diferentes, se extenderá el uso de CPU en varios equipos. Por lo tanto, se observarán números de RPS mucho más grandes.
Por último, cuando SQL Server presenta un cuello de botella en la CPU, la adición de más CPU a SQL Server puede aumentar el potencial de RPS de la granja de servidores casi linealmente.
Cómo traducir estos resultados en la implementación
En este artículo, se explicaron los resultados según lo medido por latencia y RPS, pero ¿cómo se puede aplicar esto en el mundo real? A continuación presentamos algunos cálculos basados en nuestra experiencia con el portal de departamento interno de Microsoft.
Un portal de departamento en Microsoft, que admite aproximadamente 8.000 empleados que colaboran de manera intensiva, experimenta un promedio de 110 RPS. Esto proporciona a los usuarios una relación de ~72 RPS (es decir, 8.000/110). Mediante la relación y los resultados descritos anteriormente en este artículo, podemos estimar cuántos usuarios puede admitir en buen estado una configuración de granja determinada:
| Configuración de granja de servidores | RPS de "zona verde" | Número aproximado de usuarios que puede admitir |
|---|---|---|
1x1x1 |
99 |
7.128 |
2x1x1 |
191 |
13.452 |
3x1x1 |
242 |
17.424 |
Por supuesto, esto solo se aplica directamente si el hardware y la combinación de transacciones son exactamente iguales que los utilizados para estas pruebas. Puede que su portal de departamento tenga un patrón de uso diferente. Por lo tanto, es posible que la relación no se aplique directamente. Sin embargo, esperamos que se aplique de manera aproximada.
Acerca de los autores
Gaurav Doshi es jefe de programa de SharePoint Server en Microsoft.
Raj Dhrolia es ingeniero de pruebas de software de SharePoint Server en Microsoft.
Wayne Roseberry es jefe de pruebas de SharePoint Server en Microsoft.
See Also
Other Resources
Centro de recursos: Administración de capacidad para SharePoint Server 2010