Estimar los requisitos de rendimiento y capacidad de entornos sociales (SharePoint Server 2013)
SE APLICA A:
2013 
2016 2019 Subscription Edition SharePoint en Microsoft 365
Este artículo contiene información sobre las siguientes áreas para crear un plan de capacidad y rendimiento de una solución de portal de Mi sitio y de informática social de una intranet de empresa:
Especificaciones de entorno de laboratorio, como hardware, topología de la granja de servidores y configuración de la granja de servidores
El conjunto de datos y la carga de trabajo de la granja de servidores que se usa para generar la carga de prueba
Análisis y resultados de pruebas que demuestran y explican las tendencias en el rendimiento, la latencia y la demanda de hardware bajo la carga en puntos de escala específicos.
Use la información de este artículo para asimilar los siguientes conceptos:
Características del escenario en condiciones de carga normal y máxima
Modo en que las tendencias de rendimiento cambian cuando se escalan horizontalmente servidores de la granja de servidores
Cómo calcular un punto de inicio adecuado para la arquitectura planeada
Factores importantes que tener en cuenta al planear los recursos que la granja de servidores necesitará para mantener un nivel de rendimiento aceptable en condiciones de carga máxima
Introducción a este entorno
Con frecuencia, las empresas usan SharePoint Server 2013 para publicar portales de Mi sitio y de informática social a los que los usuarios anónimos tienen acceso en una intranet. Este artículo contiene datos de capacidad y rendimiento que hacen que sea más fácil planear el número de equipos que usar y los tipos de equipos necesarios para publicar portales de Mi sitio y de informática social en SharePoint Server 2013.
Aquí encontrará más información orientativa sobre cómo escalar servidores en una solución de portal de Mi sitio y de informática social de SharePoint Server 2013. La planeación de capacidad informa de las decisiones acerca del hardware que hay que comprar y las configuraciones del sistema que optimizan su solución.
Como las granjas de servidores de SharePoint Server 2013 individuales son únicas, cada granja de servidores tiene diferentes requisitos que dependen del hardware, del comportamiento del usuario, de la configuración de las características instaladas y de otros muchos factores. Por tanto, complemente esta orientación con más pruebas en su propio hardware de su propio entorno. Si su carga de trabajo y diseño planeados son similares al entorno descrito en este artículo, puede usarlo para extraer conclusiones sobre cómo escalar su entorno.
Los resultados de las pruebas de este artículo se produjeron en un laboratorio de pruebas, con una carga de trabajo, un conjunto de datos y una arquitectura para simular un entorno de producción en condiciones muy controladas. Aunque se tuvo mucho cuidado al diseñar estas pruebas, las características de rendimiento de un laboratorio de pruebas nunca son las mismas que el comportamiento de un entorno de producción. Estos resultados de pruebas no representan las características de rendimiento y capacidad de una granja de servidores de producción. En su lugar, los resultados de la prueba muestran las tendencias observadas en el rendimiento, la latencia y la demanda de hardware. Use el análisis de los datos observados para ayudarle a planear la capacidad y administrar su propia granja de servidores.
Este artículo incluye lo siguiente:
Especificaciones, que incluyen hardware, topología y configuración
La carga de trabajo, que incluye un análisis de la demanda en la granja de servidores, el número de usuarios y las características de uso
El conjunto de datos, como el tamaño de las bases de datos y los tipos de contenido
Análisis y resultados de pruebas para escalar servidores web horizontalmente
Antes de leer este artículo, vea los siguientes artículos para asegurarse de que conoce los conceptos clave que hay tras la administración de capacidad en SharePoint Server 2013.
Estos artículos proporcionan la siguiente información:
El enfoque recomendado para la administración de capacidad
Como hacer un uso efectivo de la información de este artículo
Glosario
La lista siguiente contiene definiciones de algunos términos fundamentales que se usan en este artículo:
RPS: solicitudes por segundo. RPS hace referencia al número de solicitudes que un servidor o granja de servidores recibe en un segundo. Se trata de una medida común de la carga de servidores y granjas de servidores.
Importante
Tenga en cuenta que las solicitudes difieren de las cargas de página. Una página contiene varios componentes, cada uno de los cuales crea una o más solicitudes cuando un explorador carga la página. Por tanto, una carga de página crea varias solicitudes. Los eventos y las comprobaciones de autenticación que usan recursos insignificantes no se suelen contar en las mediciones RPS.
Zona verde: la zona verde representa un conjunto definido de características de carga bajo condiciones de funcionamiento normales, hasta las cargas máximas diarias esperadas. Una granja de servidores que opera en este intervalo debería poder sostener tiempos de respuesta y latencia que se encuentren dentro de parámetros aceptables.
Este es el estado en el que el servidor puede mantener el siguiente conjunto de criterios:
La latencia del servidor de al menos el 75 por ciento de las solicitudes es inferior a 0,5 segundos.
Todos los servidores mantienen un uso medio de la CPU de menos del 50 por ciento.
El porcentaje de errores es inferior al 0,1 por ciento.
Zona roja (máx.): la zona roja representa un conjunto definido de características de carga bajo condiciones de operación máxima. En la zona roja, la granja de servidores experimenta demandas muy elevadas de recursos transitorios que únicamente puede sostener durante períodos limitados antes de que se produzcan errores y otros problemas de rendimiento y fiabilidad.
Este es el estado en el que el servidor puede mantener el siguiente conjunto de criterios para una duración limitada:
La latencia del servidor de al menos el 75 por ciento de las solicitudes es inferior a 1 segundo.
El uso medio de CPU del servidor de bases de datos es inferior al 80 por ciento.
El porcentaje de errores es inferior al 0,1 por ciento.
Información general
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 el orden específico que seguimos para escalar nuestro entorno de laboratorio. Este método permite encontrar la mejor configuración para la carga de trabajo.
Dividimos los ciclos de pruebas de rendimiento en tres categorías de carga de trabajo. El parámetro principal que determinó el límite de las categorías fue el número de perfiles de usuario, que se estableció en 10.000, 100.000 y 500.000 pruebas de perfil de usuario. Otro parámetro fue el número de usuarios activos que estaban realizando alguna acción relacionada con el conjunto social de características. Teniendo el número de usuarios con un perfil y el número de usuarios activos, ejecutamos pruebas para simular el uso de la aplicación que sería similar al de una implementación real. En la siguiente tabla se recogen el conjunto de datos inicial y el número de usuarios activos.
Conjunto de datos inicial
| Entidad | % de usuarios con esta característica | Pequeño (10.000 usuarios) | Medio (100.000 usuarios) | Grande (500.000 usuarios) |
|---|---|---|---|---|
| Número de perfiles de usuario de los usuarios |
100% |
10 000 |
100 000 |
500 000 |
| Número de Mis sitios aprovisionados |
100% |
10 000 |
100 000 |
500 000 |
| Número de perfiles de usuario que tienen fotos de usuario |
50% |
5K |
50 000 |
250 000 |
| Número de perfiles de usuario que tienen entradas |
10% |
1K |
10 000 |
50 000 |
| Número de equipos |
1,860 |
18,600 |
93 000 |
|
| Número de usuarios activos por día |
10% |
1K |
10 000 |
50 000 |
| Número de usuarios activos por hora |
5% |
500 |
5K |
25 000 |
Las pruebas se centraron en los siguientes escenarios clave:
Acceso a páginas de suministro de noticias y otras acciones
Página de perfil
Acceso a páginas de fuente de sitio y otras acciones
Sincronización de fuente de actividades de Outlook Social Connector
Acceso a la página de OneDrive
Uso del cliente de OneDrive
Para simular un escenario de implementación realista, todas las pruebas se ejecutaron en una base de datos que ya contenía datos. El conjunto de datos fue un modelo de organización en árbol con una media de 4 a 6 usuarios por equipo y 3-4 niveles de profundidad. Para generar estos números, analizamos el tráfico de un sitio social interno. En la siguiente tabla se describe el conjunto de parámetros que usamos para crear el conjunto de datos inicial.
Modelo de datos de la base de datos inicial
| Descripción de la entidad de datos | Número |
|---|---|
| Número medio de usuarios en el equipo |
5 |
| Número medio de niveles por organización |
4 |
| Número de equipos por cada 1000 usuarios |
186 |
| Número medio de compañeros que un usuario sigue |
50 |
| Número de propiedades de perfil de usuario |
93 |
En la siguiente tabla se describe el conjunto de parámetros en términos de acciones que resultarían en un rellenado de datos:
Características de uso
| Parámetro | Número o porcentaje |
|---|---|
| Porcentaje de usuarios con 1 a 3 entradas |
10% |
| Número medio de entradas por usuario |
2 |
| Número medio de respuestas por entrada |
2 |
| Porcentaje de entradas que han gustado |
15% |
| Porcentaje de entradas con vínculos |
5% |
| Porcentaje de entradas con etiquetas |
12% |
| Porcentaje de entradas con menciones de usuario |
8% |
| Porcentaje de entradas con imágenes adjuntas |
5% |
Para crear cada una de nuestras pruebas de escala, realizamos la siguiente combinación de acciones en el conjunto de datos anterior y el número de usuarios activos:
Acciones de lectura del usuario
| Acción del usuario | % de usuarios que realizan esta acción | Escenario | Característica o dirección URL |
|---|---|---|---|
| Ir a la página principal de Mi sitio |
12% |
Suministro de noticias |
Página de suministro de noticias (http://my/default.aspx) |
| Ir a la página de perfil público del usuario |
8% |
Perfil |
Página perfil (http://my/person.aspx?accountname=<alias>) |
| Ir a la página de perfil privado del usuario |
4% |
Perfil |
Página de perfil (http://my/person.aspx) |
| Sincronizar automáticamente la fuente de actividades |
32% |
Conector social de Outlook |
ninguno |
| Ir a la página Personas a las que sigo |
3% |
Lista Seguir a personas |
http://my/MyPeople.aspx |
| Ir a la biblioteca de documentos predeterminada |
6% |
OneDrive |
https://msft-my.spoppe.com/personal/<user>/Documents |
| Ir a la página documentos que se han seguido |
3% |
OneDrive |
https://msft-my.spoppe.com/personal/<user>/Social/FollowedContent.aspx |
| Ir a la página documentos que se han seguido |
3% |
OneDrive |
https://msft-my.spoppe.com/personal/<user>/Social/FollowedContent.aspx |
| Ir a la página de fuente de sitio |
8% |
Feed del sitio |
Página de fuente de sitio (https://<dominio>/teams/<sitio>/newsfeed.aspx_ |
| Ver todas las respuestas de una conversación |
1% |
Suministro de noticias |
Página de suministro de noticias (http://my/default.aspx) |
| Ver la fuente Todos |
3% |
Suministro de noticias |
Página de suministro de noticias (http://my/default.aspx) |
| Ver más entradas en el suministro de noticias |
2% |
Suministro de noticias |
Página de suministro de noticias (http://my/default.aspx) |
| Ver la @mentions página |
1% |
Suministro de noticias |
Página de suministro de noticias (http://my/default.aspx) |
| Ver el suministro de noticias (móvil) |
1% |
Móvil |
Llamada REST |
| Ver el suministro de noticias clasificado |
3% |
Móvil |
Llamada REST móvil |
Acciones de escritura del usuario
| Acción del usuario | Porcentaje | Escenario | Característica o dirección URL |
|---|---|---|---|
| Crear una entrada raíz en la fuente |
0.5% |
Suministro de noticias |
Página de suministro de noticias (http://my/default.aspx) |
| Indicar «Me gusta» en una entrada de la fuente |
0.3% |
Suministro de noticias |
Página de suministro de noticias (http://my/default.aspx) |
| Responder a una entrada de la fuente |
0.7% |
Suministro de noticias |
Página de suministro de noticias (http://my/default.aspx) |
| Creación de una publicación en la fuente con @mention |
0.1% |
Suministro de noticias |
Página de suministro de noticias (http://my/default.aspx) |
| Crear una entrada raíz en la fuente de sitio |
0.5% |
Feed del sitio |
Página de fuente de sitio (https://<dominio>/teams/<sitio>/newsfeed.aspx) |
| Creación de una publicación en la fuente del sitio con @mention |
0.5% |
Feed del sitio |
Página de fuente de sitio (https://<dominio>/teams/<sitio>/newsfeed.aspx) |
| Responder a una entrada de la fuente de sitio |
0.15% |
Feed del sitio |
Página de fuente de sitio (https://<dominio>/teams/<sitio>/newsfeed.aspx) |
| Crear una entrada en la fuente de sitio con una etiqueta |
0.05% |
Feed del sitio |
Página de fuente de sitio (https://<dominio>/teams/<sitio>/newsfeed.aspx) |
Acciones de cliente de OneDrive
| Acción del usuario** | Porcentaje | Escenario | Característica o dirección URL |
|---|---|---|---|
| Sincronización inicial de OneDrive |
0.2% |
OneDrive |
Sincronización inicial |
| Sincronización incremental de OneDrive: descarga de un archivo |
0.88% |
OneDrive |
Sincronización incremental |
| Sincronización incremental de OneDrive: sin cambios |
8.1% |
OneDrive |
Sincronización incremental |
Metodología de las pruebas
Empezamos con una configuración de granja de servidores de SharePoint Server 2013 mínima para las características sociales. Aplicamos una carga social característica a la granja de servidores de prueba y fuimos aumentando la carga hasta que se observaron niveles de capacidad de servidor normal y máxima. Analizamos los cuellos de botella en cada uno de estos niveles de carga e incorporamos más equipos del rol con la sobrecarga para escalar la configuración de la granja de servidores. Esta adición alivió los cuellos de botella en cada caso y nos proporcionó una vista de las características de escalabilidad del servidor de un determinado conjunto de datos. Repetimos este proceso de escala horizontal con tres tamaños de implementación para poder proporcionar resúmenes que fueran representativos de las características de escalabilidad y directrices de una granja de servidores de SharePoint Server 2013 para planear la capacidad.
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.
Importante
Todos los servidores web y los servidores de aplicaciones del laboratorio de pruebas se virtualizaron usando hosts Hyper-V. Los servidores de base de datos no se virtualizaron. El hardware de host físico y el hardware virtual de máquina virtual se detallan por separado en las siguientes secciones.
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.
Hosts Hyper-V
La granja de servidores contiene un total de tres hosts Hyper-V con una configuración idéntica, y cada host ejecuta entre una y cuatro máquinas virtuales.
| Hardware de host | Valor |
|---|---|
|
Procesadores |
2 procesadores de cuatro núcleos de 2,27 GHz |
|
Memoria RAM |
64 GB |
|
Sistema operativo |
Windows Server 2008 R2 SP1 |
|
Número de adaptadores de red |
2 |
|
Velocidad del adaptador de red |
1 Gigabit |
Servidores web virtuales y servidores de aplicaciones
La granja de servidores tiene entre uno y ocho servidores web virtuales. Un servidor virtual dedicado extra ejecuta el servicio de caché distribuida.
Nota:
En un entorno de producción, los servidores dedicados que ejecutan el servicio de caché distribuida se suelen implementar en una configuración sumamente disponible. Con fines de pruebas, usamos un servidor único dedicado para caché distribuida porque la alta disponibilidad no es un factor crítico.
| Hardware de máquina virtual | Servidores web |
|---|---|
|
Procesadores |
4 procesadores virtuales |
|
RAM |
12 GB |
|
Sistema operativo |
Windows Server 2008 R2 SP1 |
|
Tamaño de la unidad de SharePoint |
100 GB |
|
Número de adaptadores de red |
2 |
|
Velocidad del adaptador de red |
1 Gigabit |
|
Autenticación |
Windows NTLM |
|
Tipo de equilibrador de carga |
F5 Big IP |
|
Servicios en ejecución local |
Aplicación web de Microsoft SharePoint Foundation, correo entrante de Microsoft SharePoint Foundation, servicio de temporizador de flujo de trabajo de Microsoft SharePoint Foundation, servicio web de metadatos administrado, servicio de perfiles de usuario |
| Hardware de máquina virtual | Caché |
|---|---|
|
Procesadores |
4 procesadores virtuales |
|
RAM |
12 GB |
|
Sistema operativo |
Windows Server 2008 R2 SP1 |
|
Tamaño de la unidad de SharePoint |
100 GB |
|
Número de adaptadores de red |
2 |
|
Velocidad del adaptador de red |
1 Gigabit |
|
Autenticación |
Windows NTLM |
|
Servicios en ejecución local |
Memoria caché distribuida, servicio de temporizador de flujo de trabajo de Microsoft SharePoint Foundation |
| Hardware de máquina virtual | Componente de consulta de búsqueda |
|---|---|
|
Procesadores |
4 procesadores virtuales |
|
RAM |
12 GB |
|
Sistema operativo |
Windows Server 2008 R2 SP1 |
|
Número de adaptadores de red |
2 |
|
Velocidad del adaptador de red |
1 Gigabit |
|
Autenticación |
Windows NTLM |
|
Servicios en ejecución local |
Aplicación web de Microsoft SharePoint Foundation, correo entrante de Microsoft SharePoint Foundation, servicio de temporizador de flujo de trabajo de Microsoft SharePoint Foundation, servicio web de configuración del sitio y consulta de búsqueda, búsqueda de SharePoint Server |
| Hardware de máquina virtual | Componente de índice de búsqueda |
|---|---|
|
Procesadores |
4 procesadores virtuales |
|
RAM |
12 GB |
|
Sistema operativo |
Windows Server 2008 R2 SP1 |
|
Número de adaptadores de red |
2 |
|
Velocidad del adaptador de red |
1 Gigabit |
|
Autenticación |
Windows NTLM |
|
Servicios en ejecución local |
Aplicación web de Microsoft SharePoint Foundation, correo entrante de Microsoft SharePoint Foundation, servicio de temporizador de flujo de trabajo de Microsoft SharePoint Foundation, búsqueda de SharePoint Server |
Servidores de bases de datos
Un servidor de base de datos físico ejecuta la instancia de SQL Server predeterminada que tiene las bases de datos de SharePoint. En este artículo no se realiza un seguimiento de la base de datos de registro.
Nota:
Si habilita los informes de uso, le aconsejamos que almacene la base de datos de registro en un número de unidad lógica (LUN) aparte. Las implementaciones grandes y algunas implementaciones medianas pueden requerir un servicio de base de datos de registro dedicado para adaptarse a la demanda en el procesador que genera un gran volumen de registro de eventos. > En este entorno de laboratorio, el registro estaba restringido y la base de datos de registro se almacenaba en una instancia independiente de SQL Server.
Servidor de base de datos - Instancia predeterminada
|
Procesadores |
2 procesadores de cuatro núcleos de 3,3 GHz |
|
Memoria RAM |
32 GB |
|
Sistema operativo |
Windows Server 2008 R2 SP1 |
|
Almacenamiento y geometría |
Almacenamiento directo (DAS) Matriz interna con 6 discos de 300 GB a 15.000 RPM Matriz externa con 15 discos de 450 GB a 15.000 RPM 50 de datos de contenido (RAID10 externo, ejes de 2x3 y 300 GB cada uno) 50 de registros de contenido (RAID10 interno, ejes de 2x2 y 300 GB cada uno) 1 de datos temporales (RAID10 interno, ejes de 2x2 y 300 GB cada uno) 1 de registros temporales (RAID10 interno, ejes de 2x2 y 300 GB cada uno) |
|
Número de adaptadores de red |
1 |
|
Velocidad del adaptador de red |
1 Gigabit |
|
Autenticación |
Windows NTLM |
|
Versión de software |
SQL Server 2008 R2 |
Topología
En la siguiente tabla se muestra la topología de este entorno de laboratorio:
Topología del entorno de laboratorio
| Role | Implementación pequeña (10.000 usuarios) | Implementación media (100.000 usuarios) | Implementación grande (500.000 usuarios) |
|---|---|---|---|
| Servidor web |
2-4 |
4-8 |
8 |
| Memoria caché |
1 |
1-2 |
3 |
| SQL Server |
1 |
1-2 |
2 |
Proceso de las pruebas
Importante
Las pruebas solo modelan el uso en horas laborables normales de un portal de informática social típico. No tuvimos en cuenta los cambios cíclicos en el tráfico generado por los usuarios que los ciclos de día/noche producen. Comprobamos los trabajos del temporizador, como la sincronización de perfiles y el rastreo de búsqueda de personas (que requieren muchos recursos), de forma independiente con la misma carga de trabajo de prueba para determinar su efecto. > Las pruebas se centran en operaciones sociales, como suministro de noticias, etiquetado social y lectura de perfiles de personas. La combinación de pruebas incluye una pequeña cantidad de tráfico de colaboración típico para simular un entorno de producción de mejor forma. Esperamos que estos resultados hagan que sea más fácil diseñar un portal independiente dedicado a Mis sitios y a las características sociales. > La combinación de pruebas no incluye el tráfico del rastreo de contenido de búsqueda. >
Realizamos las pruebas en implementaciones de tamaño pequeño, medio y grande para las características sociales. Para configurar el hardware del servidor, empezamos con las configuraciones mínimas para el tamaño más pequeño y rellenamos la base de datos de prueba con el conjunto de datos descrito en la sección Enfoque de escalado.
Usamos Visual Studio Team System (VSTS) para simular una carga de trabajo y aplicar una carga social característica, dirigiendo una pequeña carga al servidor en primer lugar. Fuimos aumentando esta carga de forma lenta, pero uniforme, y llevamos un registro de las métricas de rendimiento en todos los roles de servidor hasta que observamos el número máximo de RPS. Esto podía identificarse como el estado en el que un aumento de la carga aplicada a la granja de servidores no provocaba ningún aumento de la salida de RPS enviada debido a restricciones de cuello de botella del servidor.
A partir de estas métricas registradas, definimos los estados de zona verde y zona roja, que representan los estados de carga normal y completa del servidor de VM en una configuración de equipo determinada. Luego, aplicamos una carga constante en los niveles de zona verde y zona roja para analizar las métricas de rendimiento estable en estas cargas. Esto nos proporcionó una representación de rendimiento y estado del servidor de VM en estas condiciones de carga clave para cada configuración de la topología.
Tras comprender las características de carga verde y roja y la curva de escala de cada topología, identificamos el cuello de botella de escala que limitaba el número de RPS. En el caso de la carga de trabajo social, normalmente se trataba de la CPU del servidor web para los conjuntos de datos pequeños. En conjuntos de datos más grandes, también percibimos una presión de memoria en los nodos de caché distribuida. Agregamos servidores virtuales del rol con la sobrecarga a la configuración para eliminar los cuellos de botella en cada caso y continuar con el proceso de escalado. Luego, volvimos a analizar las tendencias de rendimiento y su conformidad con las definiciones de zona verde y zona roja en cada tamaño de configuración hasta que logramos los requisitos para un tamaño de implementación específico.
Tras comprender cada tamaño de implementación, reconfiguramos la granja de servidores de prueba en la configuración más pequeña del siguiente tamaño más grande, rellenamos el conjunto de datos como se describe en la sección Enfoque de escalado, repetimos el ciclo de proceso de análisis/escalado y medimos las características de escalado de cada tamaño de conjunto de datos.
Resultados y análisis
En esta sección se recogen los resultados obtenidos en los tres tamaños de implementación. En concreto, demuestra cómo escalar la granja de servidores agregando servidores web afecta al número de RPS de las zonas verde y roja, a la latencia y al uso medio de CPU.
Las siguientes tendencias fueron las mismas en los tres tamaños de implementación:
El número de RPS de las zonas verde y roja aumenta linealmente con respecto al número de servidores web virtuales.
El cuello de botella principal en todas las configuraciones probadas fue la CPU del servidor web.
En la zona roja, la latencia aumentaba ligeramente a medida que agregábamos servidores web y aumentábamos la carga. Esto se debe a la presión extra en SQL Server y el servicio de caché distribuida (que se ejecuta en todos los servidores web de la granja de servidores de prueba).
Además, el uso medio de CPU en los equipos de SQL Server y de caché distribuida aumentaba a medida que el número de servidores web aumentaba. Esto se debe a la carga de almacenamiento en caché adicional en SQL Server y el servicio de caché distribuida.
La latencia de la zona verde permanecía relativamente plana a medida que el número de servidores web aumentaba. Esto se debe a que los servidores web no están sobrecargados en los niveles de carga de zona verde.
Resultados a pequeña escala
En el siguiente gráfico se aprecia cómo aumentar el número de servidores web afecta al número de RPS de las zonas verde y roja.
En el siguiente gráfico se aprecia cómo aumentar el número de servidores web afecta a la latencia de los niveles de carga de las zonas verde y roja.
En el siguiente gráfico se aprecia cómo aumentar el número de servidores web afecta al uso de CPU medio de los niveles de carga de las zonas verde y roja.
Resultados a media escala
En el siguiente gráfico se aprecia cómo aumentar el número de servidores web afecta al número de RPS de las zonas verde y roja.
En el siguiente gráfico se aprecia cómo aumentar el número de servidores web afecta a la latencia de los niveles de carga de las zonas verde y roja.
En el siguiente gráfico se aprecia cómo aumentar el número de servidores web afecta al uso de CPU medio de los niveles de carga de las zonas verde y roja.
Resultados a gran escala
En el siguiente gráfico se aprecia cómo aumentar el número de servidores web afecta al número de RPS de las zonas verde y roja.
En el siguiente gráfico se aprecia cómo aumentar el número de servidores web afecta a la latencia de los niveles de carga de las zonas verde y roja.
En el siguiente gráfico se aprecia cómo aumentar el número de servidores web afecta al uso de CPU medio de los niveles de carga de las zonas verde y roja.
A medida que aumenta el número de servidores web, se producen los siguientes eventos:
El uso de CPU medio aumenta en los nodos de SQL Server y de caché distribuida, dada la carga extra en estos recursos compartidos.
El uso medio de CPU de servidor web en la zona roja disminuye ligeramente debido a que el cuello de botella se desplaza ligeramente a los equipos con SQL Server y caché distribuida.
El uso medio de CPU de servidor web en la zona verde permanece constante, ya que los servidores se mantienen en los niveles de carga recomendados.
Recomendaciones
Una implementación social de SharePoint Server 2013 correcta calibrada según el rendimiento depende de los siguientes factores:
El número de usuarios activos que quiere admitir
La combinación de transacciones prevista de operaciones de lectura y escritura
El modo en que la carga se distribuye por los servidores de la granja
El número previsto de usuarios activos es un factor clave para conocer el número de servidores que hay que tener previsto en la topología. El número de usuarios activos también determina la composición de hospedaje de los distintos servicios que es necesario tener habilitados para el escenario social en todos los servidores.
Aunque en nuestras pruebas usamos un conjunto de datos típico y aplicamos la complejidad de carga que podría esperarse de una implementación de clientes en la vida real, cada implementación es única. En sus esfuerzos de planeación de la capacidad tiene que tener en cuenta la disponibilidad de recursos de hardware, la configuración de características y las características de uso previstas. Algunos factores que pueden afectar o cambiar las cifras de capacidad de manera significativa son los siguientes:
Un patrón de uso de correo electrónico mayor podría aumentar la carga que Outlook Social Connector genera.
Un aumento significativo en el porcentaje de acciones de escritura (por ejemplo, un aumento en el etiquetado o @mention) en la combinación de transacciones podría aumentar la carga en el servidor de base de datos.
Puede agregar o quitar servidores web para equilibrar la carga de la CPU entre los servidores web, SQL Server y los nodos de caché distribuida.
Siga al pie de la letra las directrices estándar de configuración de SharePoint Server 2013 para lograr un rendimiento óptimo. Estas son algunas consideraciones importantes específicamente en las transacciones sociales:
Discos físicos distintos para la base de datos de perfiles: debido al intenso uso de disco que las transacciones sociales pueden tener en la base de datos de perfiles, recomendamos mantener la base de datos de perfiles en su propio conjunto de discos físicos en el servidor que ejecuta SQL Server.
Requisitos de memoria para la aplicación de servicio de perfiles de usuario la aplicación de servicio de perfiles de usuario está en los servidores front-end web y depende en gran medida de su caché en memoria. Asegúrese de que los servidores front-end web tienen suficiente memoria RAM para almacenar en caché la numerosas solicitudes de datos. Recomendamos una memoria RAM de 12 GB como mínimo por cada servidor front-end web.
Requisitos de memoria para los servidores de caché distribuida: las características sociales (particularmente, los microblogs) dependen en gran medida de que haya un almacenamiento en caché distribuida suficiente y sólido. Si se producen situaciones de memoria baja en estos equipos, la capacidad de la granja de servidores de SharePoint podría degradarse mientras esta memoria caché se vuelve a rellenar. Por lo tanto, recomendamos configurar los servidores que hospedan la memoria caché distribuida de forma que usen al menos 12 GB de RAM y se escalen según sea necesario en función del número total de usuarios en la implementación.
En la implementación social de SharePoint Server 2013 es obligatorio que haya un sitio personal por cada usuario que quiera usar las características sociales. En consecuencia, planee esta implementación teniendo en cuenta el incremento de creación de colecciones de sitios personales en el nivel de la base de datos de contenido. Para más información sobre cómo escalar colecciones de sitios personales, consulte Restricciones y límites del software de SharePoint 2013.
Vea también
Conceptos
Planeamiento del rendimiento en SharePoint Server 2013