Planeación de la capacidad para Microsoft SharePoint Server 2010 Resumen

Transcripción

1 Planeación de la capacidad para Microsoft SharePoint Server 2010 Microsoft Corporation Publicado: enero de 2011 Autor: Equipo de Microsoft Office System and Servers Resumen Este libro ofrece información acerca de la planeación de los requisitos de capacidad y de rendimiento para la implementación de Microsoft SharePoint Server Entre los temas se incluyen el cambio de tamaño, la prueba de rendimiento, los límites de software y los estudios de casos de capacidades. Está dirigido a especialistas en aplicaciones empresariales, especialistas en líneas de negocio, arquitectos de la información, profesionales generales de TI, administradores de programa y especialistas en infraestructuras que planean una solución basada en SharePoint Server Este libro forma parte de un conjunto de cuatro guías de planeación que ofrecen información completa sobre la planeación de TI para SharePoint Server. Para obtener información acerca de la planeación de la arquitectura de una implementación de SharePoint Server 2010, vea el tema sobre la guía de planeación de entornos y granjas de servidores para Microsoft SharePoint Server 2010 ( Para obtener información acerca de la planeación de sitios y soluciones creados mediante SharePoint Server, vea el tema sobre la guía de planeación de sitios y soluciones para Microsoft SharePoint Server 2010, Parte 1 ( y el tema sobre la guía de planeación de sitios y soluciones para Microsoft SharePoint Server 2010, Parte 2 ( El contenido de este libro es una copia del contenido seleccionado en la biblioteca técnica de SharePoint Server 2010 ( en la fecha de publicación. Para obtener la información más actual, vea la biblioteca técnica en Internet.

2 Este documento se proporciona tal cual. Es posible que la información y los puntos de vista reflejados en este documento, incluidas la dirección URL y otras referencias a sitios web de Internet, cambien sin previo aviso. El usuario asume el riesgo de su uso. Algunos ejemplos que se detallan en este documento se proporcionan solo con fines ilustrativos y son ficticios. No se pretende establecer, ni debe deducirse, una asociación o conexión real. Este documento no proporciona ningún derecho legal sobre la propiedad intelectual e industrial de ningún producto de Microsoft. Este documento puede copiarse y usarse para fines internos y de referencia Microsoft Corporation. Reservados todos los derechos. Microsoft, Access, Active Directory, Backstage, Excel, Groove, Hotmail, InfoPath, Internet Explorer, Outlook, PerformancePoint, PowerPoint, SharePoint, Silverlight, Windows, Windows Live, Windows Mobile, Windows PowerShell, Windows Server y Windows Vista son marcas comerciales o marcas registradas de Microsoft Corporation en Estados Unidos y otros países.

3 Contenido Planeación de la capacidad para Microsoft SharePoint Server Cómo obtener ayuda Administración del rendimiento y de la capacidad (SharePoint Server 2010) Capacity management and sizing for SharePoint Server 2010 (en inglés) Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server Glosario Quién debería leer los artículos de administración de capacidad? Cuatro aspectos básicos de rendimiento Administración de capacidad frente a planeación de capacidad Sobreasignación frente a subasignación de capacidad Restricciones y límites del software Diferencias clave entre SharePoint Server 2010 y Office SharePoint Server Diferenciadores clave de implementación de SharePoint Server Arquitecturas de referencia Vea también Planeación de la capacidad para SharePoint Server Paso 1: Modelo... 47

4 Paso 2: Diseño Paso 3: Piloto, prueba y optimización Paso 4: Implementación Paso 5: Supervisión y mantenimiento Vea también Pruebas de rendimiento para SharePoint Server Creación de un plan de pruebas Creación del entorno de prueba Creación de pruebas y herramientas Vea también Supervisión y mantenimiento de SharePoint Server Configuración de la supervisión Eliminación de cuellos de botella Vea también Administración de la capacidad de SharePoint Server 2010: restricciones y límites del software Información general de límites máximos y límites Límites y límites máximos Performance and capacity technical case studies (SharePoint Server 2010) (en inglés) Entorno de publicación de intranet de empresa de Microsoft SharePoint Server 2010: caso práctico técnico Información de requisitos previos

5 Introducción a este entorno Especificaciones Carga de trabajo Conjunto de datos Datos de mantenimiento y rendimiento Enterprise intranet collaboration environment technical case study (SharePoint Server 2010) (en inglés) Prerequisite information Introduction to this environment Specifications Health and Performance Data Enterprise intranet collaboration environment lab study (SharePoint Server 2010) (en inglés) Introduction to this environment Glossary Overview Specifications Results and Analysis Departmental collaboration environment technical case study (SharePoint Server 2010) (en inglés) Prerequisite information Introduction to this environment Specifications Workload

6 Dataset Health and Performance Data Divisional portal environment lab study (SharePoint Server 2010) (en inglés) Introduction to this environment Glossary Overview Specifications Results and analysis About the authors Social environment technical case study (SharePoint Server 2010) (en inglés) Prerequisite information Introduction to this environment Specifications Workload Dataset Health and Performance Data Recomendaciones y resultados de pruebas de rendimiento y capacidad (SharePoint Server 2010) Estimate performance and capacity requirements for Access Services in SharePoint Server 2010 (en inglés) Test farm characteristics Test results Recommendations

7 Troubleshooting Estimate performance and capacity requirements for Excel Services in SharePoint Server 2010 (en inglés) Test farm characteristics Test Results Recommendations Estimación de los requisitos de rendimiento y capacidad de PerformancePoint Services Prueba de las características del conjunto o granja de servidores Escenarios de prueba y procesos Configuración de hardware y topología Resultados de las pruebas Topologías 2M y 3M Resultados para topologías de 4 o más máquinas para autenticación de cuenta de servicio desatendida Resultados para topologías de 4 o más máquinas para autenticación de usuario Recomendaciones Analysis Services Cuellos de botella comunes y sus causas Supervisión del rendimiento Vea también Capacity requirements for Web Analytics Shared Service in SharePoint Server 2010 (en inglés) Introduction Hardware specifications and topology

8 Capacity requirements Vea también Estimación de los requisitos de rendimiento y capacidad para la administración de contenido web en SharePoint Server Información de requisitos previos Método y detalles de las pruebas Implementaciones de administración de contenido web Optimizaciones necesarias Resultados de las pruebas y recomendaciones Acerca de los autores Estimate performance and capacity planning for workflow in SharePoint Server 2010 (en inglés) Test farm characteristics Test results Recommendations Troubleshooting Vea también Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010) Proceso de diseño y configuración del nivel de base de datos y almacenamiento de productos de SharePoint Recopilación de los requisitos de espacio y E/S para almacenamiento y SQL Server Elección de la versión y edición de SQL Server Diseño de la arquitectura de almacenamiento en función de la capacidad y los requisitos de E/S Estimación de los requisitos de memoria

9 Descripción de los requisitos de la topología de red Configuración de SQL Server Validación y supervisión del almacenamiento y rendimiento de SQL Server

10 Cómo obtener ayuda Se ha hecho todo lo posible para garantizar la máxima precisión en este libro. Este contenido también está disponible en línea en la biblioteca TechNet de Office System, por lo que, si tuviera algún problemas, puede comprobar si hay actualizaciones en: Si no encuentra la respuesta en nuestros contenidos en línea, puede enviar un mensaje de correo electrónico al equipo de contenidos de Microsoft Office System and Servers a la dirección de correo electrónico: itspdocs@microsoft.com Si tiene alguna pregunta acerca de los productos de Microsoft Office, y no acerca del contenido de este libro, realice una búsqueda en Ayuda y soporte técnico de Microsoft o en Microsoft Knowledge Base en: 10

11 Administración del rendimiento y de la capacidad (SharePoint Server 2010) La planeación de la capacidad y del rendimiento es el proceso de asignar el diseño de la solución de Microsoft SharePoint Server 2010 a un tamaño del conjunto o granja de servidores y un conjunto de hardware que admitirá los objetivos empresariales. Puede encontrar artículos relevantes sobre rendimiento y planeación de capacidad para Project Server 2010 en la biblioteca de documentos de Project Server en Plan for performance and capacity (Project Server 2010). Los artículos de esta sección incluyen: Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server 2010 En este artículo se le guiará a través de los conceptos relacionados con la administración de la capacidad y el ajuste del tamaño de las granjas de SharePoint 2010 y se proporciona información general sobre el proceso de planeación. Planeación de la capacidad para SharePoint Server 2010 En este artículo se proporcionan pasos detallados y procedimientos para planear la capacidad de las granjas de SharePoint de Supervisión y mantenimiento de SharePoint Server 2010 En este artículo se proporciona información acerca de cómo mantener y supervisar el rendimiento de las granjas de SharePoint de Pruebas de rendimiento para SharePoint Server 2010 En este artículo se proporcionan instrucciones para probar el rendimiento de las granjas de SharePoint de Administración de la capacidad de SharePoint Server 2010: restricciones y límites del software En este artículo se proporciona un punto de partida para planear el rendimiento y la capacidad de su sistema. También se incluyen resultados de pruebas de rendimiento y capacidad e instrucciones para obtener un rendimiento aceptable. Performance and capacity technical case studies (SharePoint Server 2010) (en inglés) En este artículo se proporcionan vínculos a artículos de casos prácticos técnicos claves que contienen detalles de rendimiento y capacidad para entornos específicos que ejecuten SharePoint Server

12 Recomendaciones y resultados de pruebas de rendimiento y capacidad (SharePoint Server 2010) En este artículo se proporcionan vínculos a artículos que contienen resultados de pruebas y recomendaciones para conjuntos de características específicos en SharePoint Server Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010) En este artículo, se describe un proceso para planear el almacenamiento y la capacidad de SQL Server para una implementación de SharePoint Server Los siguientes recursos también pueden ser útiles para planear la capacidad: Determine hardware and software requirements (SharePoint Server 2010) Diagramas técnicos: Topologías para SharePoint Server 2010 Arquitecturas de búsqueda para Microsoft SharePoint Server 2010 Diseño de arquitecturas de búsqueda para Microsoft SharePoint Server 2010 Planeación de entorno de búsqueda para Microsoft SharePoint Server 2010 Para descargar estos modelos, vea Technical diagrams (SharePoint Server 2010). 12

13 Capacity management and sizing for SharePoint Server 2010 (en inglés) The articles in this section help you to make the following decisions regarding the appropriate capacity for your Microsoft SharePoint Server 2010 environment: Understand the concepts behind effective capacity management. Define performance and capacity targets for your environment. Select the appropriate data architecture. Choose hardware to support the number of users and the features you intend to deploy. Test, validate, and adjust your environment to achieve your performance and capacity targets. Monitor and adjust your environment to match demand. In this section: Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server 2010 Planeación de la capacidad para SharePoint Server 2010 Pruebas de rendimiento para SharePoint Server 2010 Supervisión y mantenimiento de SharePoint Server

14 Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server 2010 En este artículo se proporciona información general acerca de cómo planear y administrar la capacidad de los entornos de Microsoft SharePoint Server 2010 de forma eficaz. También se describe cómo comprender las características y necesidades de capacidad de la implementación, mediante el análisis de datos de rendimiento y volumen. Además, revisa los impactos principales de la aplicación que afectan a la capacidad, incluidas las características de contenido y el uso. La administración de capacidad es un proceso continuo, ya que ninguna implementación permanece estática con respecto al contenido y el uso. Debe planear el crecimiento y el cambio, de modo que el entorno basado en SharePoint Server 2010 pueda seguir ofreciendo una solución de negocios eficaz. La planeación de capacidad es solo una parte del ciclo de administración de capacidad. Es el conjunto inicial de actividades que coloca al arquitecto de diseño en el punto donde existe una arquitectura inicial que el arquitecto considera que servirá mejor para la implementación de SharePoint Server El modelo de administración de capacidad incluye pasos adicionales que ayudan a validar y optimizar la arquitectura inicial. También proporciona un bucle de realimentación para volver a planear y optimizar el entorno de producción hasta que pueda admitir los objetivos de diseño con las opciones óptimas de hardware, topología y configuración. En este artículo: Glosario Quién debería leer los artículos de administración de capacidad? Cuatro aspectos básicos de rendimiento Administración de capacidad frente a planeación de capacidad Sobreasignación frente a subasignación de capacidad Restricciones y límites del software Diferencias clave entre SharePoint Server 2010 y Office SharePoint Server 2007 Diferenciadores clave de implementación de SharePoint Server 2010 Arquitecturas de referencia 14

15 Glosario En la documentación de administración de capacidad de SharePoint Server 2010 se usan los siguientes términos especializados. RPS Solicitudes por segundo. El número de solicitudes que recibe un conjunto o granja de servidores o un servidor en un segundo. Se trata de una medida común de la carga de servidores y granjas de servidores. El número de solicitudes que procesa una granja de servidores es mayor que el número de cargas de páginas y de interacciones del usuario final. Esto se debe a que cada página contiene varios componentes, cada uno de los cuales crea una o varias solicitudes cuando se carga la página. Algunas solicitudes son más ligeras que otras con respecto a los costos de transacción. En nuestras pruebas de laboratorio y documentos de casos prácticos, quitamos 401 solicitudes y respuestas (protocolos de enlace de la autenticación) de las solicitudes que se usaron para calcular RPS porque tienen un impacto insignificante en los recursos de la granja de servidores. Horas de mayor demanda La hora u horas del día en que la carga de la granja de servidores alcanza su nivel máximo. Carga máxima El promedio de carga máxima diaria de la granja de servidores, medido en RPS. Pico de carga Los puntos de carga máxima temporaria que tienen lugar fuera de las horas de mayor demanda habituales. Pueden deberse a aumentos de tráfico de usuario no planeados, disminuciones del rendimiento de la granja de servidores debido a operaciones administrativas o combinaciones de estos factores. Incremento de la escalabilidad vertical El incremento de la escalabilidad vertical significa agregar recursos, como memoria o procesadores a un servidor. Incremento de la escalabilidad horizontal El incremento de la escalabilidad horizontal implica agregar más servidores a una granja de servidores. Quién debería leer los artículos de administración de capacidad? Tenga en cuenta las siguientes preguntas para determinar si debería leer este contenido. Evaluación de SharePoint Server 2010 Soy un profesional de TI o responsable de decisiones empresariales y estoy buscando una solución para problemas empresariales específicos. SharePoint Server 2010 es una opción para la implementación. Puede proporcionar características y escalabilidad que cumplan mis requisitos específicos? Para obtener información acerca de cómo SharePoint Server 2010 se ajusta para satisfacer las demandas de soluciones específicas y cómo determinar el hardware necesario para admitir los requisitos, consulte las secciones que aparecen más adelante en este artículo: Diferencias clave entre SharePoint Server 2010 y Office SharePoint Server

16 Restricciones y límites del software Para obtener información acerca de cómo evaluar SharePoint Server 2010 para sus requisitos de negocio específicos, vea los siguientes artículos: Product evaluation for SharePoint Server 2010 Administración de la capacidad de SharePoint Server 2010: restricciones y límites del software Actualización desde Office SharePoint Server 2007 Actualmente uso Office SharePoint Server Qué ha cambiado en SharePoint Server 2010 y qué debo tener en cuenta si actualizo? Qué efecto tendrá la actualización en el rendimiento y la escala de mi topología? Para obtener información acerca de las diferencias entre los factores de rendimiento y capacidad en Office SharePoint Server 2007 y SharePoint Server 2010, vea la sección siguiente: Diferencias clave entre SharePoint Server 2010 y Office SharePoint Server 2007 Para obtener información acerca de las consideraciones de actualización generales e instrucciones acerca de cómo planear y ejecutar una actualización de Office SharePoint Server 2007, consulte el siguiente artículo: Upgrading to SharePoint Server 2010 Ajuste y optimización de un entorno real basado en SharePoint He implementado SharePoint Server 2010 y deseo asegurarme de que dispongo de la topología y el hardware adecuados. Cómo valido la arquitectura y la mantengo correctamente? Para obtener información acerca de los contadores de supervisión y rendimiento para granjas de servidores de Microsoft SharePoint Server 2010, vea el artículo siguiente: Supervisión y mantenimiento de SharePoint Server 2010 Para obtener información acerca de cómo usar las herramientas de seguimiento de estado integradas a la interfaz de Administración central, vea el artículo siguiente: Health Monitoring (SharePoint Server 2010) He implementado SharePoint Server 2010 y surgieron problemas de rendimiento. Cómo soluciono los problemas y optimizo mi entorno? Para obtener información acerca de los contadores de supervisión y rendimiento para granjas de servidores de Microsoft SharePoint Server 2010, vea el artículo siguiente: Supervisión y mantenimiento de SharePoint Server

17 Para obtener información acerca de cómo solucionar problemas mediante las herramientas de seguimiento de estado integradas a la interfaz de Administración central, vea el artículo siguiente: Solving Problems and Troubleshooting (SharePoint Server 2010) Para ver una lista de los artículos de administración de capacidad disponibles para varios servicios y características de SharePoint Server 2010 específicos (se agregarán más artículos a medida que se encuentren a disposición), vea el artículo siguiente: Recomendaciones y resultados de pruebas de rendimiento y capacidad (SharePoint Server 2010) Para obtener información acerca del rendimiento y el ajuste de tamaño de la base de datos, vea el artículo siguiente: Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010) Para obtener información acerca del almacenamiento remoto de blobs (RBS), vea el artículo siguiente: Plan for remote BLOB storage (RBS) (SharePoint Server 2010) De principio a fin Deseo conocer todo sobre la administración de capacidad de SharePoint Server Por dónde debo empezar? Para obtener información acerca de los conceptos generales detrás de la administración de capacidad y vínculos a recursos y documentación adicionales, vea el artículo siguiente: Administración del rendimiento y de la capacidad (SharePoint Server 2010) Para obtener información adicional acerca de la administración de capacidad, consulte los siguientes artículos complementarios de este artículo de información general: Planeación de la capacidad para SharePoint Server 2010 Pruebas de rendimiento para SharePoint Server 2010 Supervisión y mantenimiento de SharePoint Server 2010 Ahora debería comprender mejor los conceptos. Para obtener información acerca de las restricciones y los límites de SharePoint Server 2010, vea el siguiente artículo: Administración de la capacidad de SharePoint Server 2010: restricciones y límites del software Cuando esté preparado para identificar una topología de punto de inicio para el entorno basado en SharePoint Server 2010, puede buscar en la biblioteca de casos prácticos técnicos disponibles el que mejor se ajuste a sus necesidades. Para ver una lista de casos prácticos (se agregarán más casos prácticos a medida que se encuentren a disposición), vea el siguiente artículo: Performance and capacity technical case studies (SharePoint Server 2010) (en inglés) 17

18 Para ver una lista de los artículos de administración de capacidad disponibles para varios servicios y características de SharePoint Server 2010 específicos (se agregarán más artículos a medida que se encuentren a disposición), vea el artículo siguiente: Recomendaciones y resultados de pruebas de rendimiento y capacidad (SharePoint Server 2010) Para obtener información acerca del rendimiento y el ajuste de tamaño de la base de datos, vea el artículo siguiente: Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010) Para obtener información acerca del almacenamiento remoto de blobs (RBS), vea el artículo siguiente: Plan for remote BLOB storage (RBS) (SharePoint Server 2010) Para obtener información acerca de cómo solucionar problemas y hacer un seguimiento de estado mediante las herramientas de seguimiento de estado integradas a la interfaz de Administración central, vea los artículos siguientes: Health Monitoring (SharePoint Server 2010) Solving Problems and Troubleshooting (SharePoint Server 2010) Para obtener información acerca de las instrucciones para optimizar el rendimiento general y diversos temas específicos de rendimiento y capacidad (se agregarán más artículos a medida que se encuentren a disposición), vea el artículo siguiente: Use search administration reports (SharePoint Server 2010) Para obtener más información acerca de cómo virtualizar servidores basados en SharePoint Server 2010, vea el siguiente artículo: Virtualization planning (SharePoint Server 2010) Cuatro aspectos básicos de rendimiento La administración de capacidad se centra en los siguientes cuatro aspectos principales del ajuste de tamaño de la solución: Latencia Para los fines de la administración de capacidad, la latencia se define como la duración entre el momento en que un usuario inicia una acción, como al hacer clic en un hipervínculo, y el momento en que se transmite el último byte a la aplicación cliente o el explorador web. Rendimiento El rendimiento se define como el número de solicitudes simultáneas que puede procesar un servidor o una granja de servidores. Escala de datos La escala de datos se define como el conjunto de datos y el tamaño del contenido que el sistema puede hospedar. La estructura y la distribución de las bases de datos de contenido tienen un efecto considerable sobre el tiempo que tarda el sistema para procesar las solicitudes (latencia) y el número de solicitudes simultáneas que puede servir (rendimiento). 18

19 Confiabilidad La confiabilidad es una medida de la capacidad del sistema para cumplir los objetivos establecidos de latencia y rendimiento a lo largo del tiempo. El objetivo principal de la administración de capacidad del entorno es establecer y mantener un sistema que cumpla los objetivos de latencia, rendimiento, escala de datos y confiabilidad de la organización. Latencia La latencia, también conocida como latencia percibida por el usuario final, consta de tres componentes principales: El tiempo que tarda el servidor en recibir y procesar la solicitud. El tiempo que tardan la solicitud y la respuesta del servidor en transferirse a través de la red. El tiempo que tarda la respuesta en representarse en la aplicación cliente. Cada organización define objetivos de latencia diferentes, según los requisitos empresariales y las expectativas del usuario. Algunas organizaciones pueden permitir una latencia de algunos segundos, mientras que otras requieren que las transacciones sean muy rápidas. Generalmente, la optimización para obtener transacciones muy rápidas es más costosa y suele requerir clientes y servidores más eficaces, versiones más recientes de aplicaciones cliente y exploradores, soluciones de red de ancho de banda alto y, posiblemente, inversiones en desarrollo y optimización de páginas. En la lista siguiente se describen algunos de los principales factores que contribuyen a la obtención de latencias percibidas por el usuario final de mayor duración y ejemplos de algunos problemas comunes. Estos factores son especialmente relevantes en escenarios donde los clientes están geográficamente lejos de la granja de servidores o tienen acceso a ella a través de una conexión de red de ancho de banda bajo. Las características, los servicios o los parámetros de configuración que no están optimizados podrían retrasar el procesamiento de solicitudes y tener un impacto sobre la latencia para los clientes remotos y locales. Para obtener más información, vea Rendimiento y Confiabilidad, más adelante en este artículo. Las páginas web que generan solicitudes innecesarias al servidor para descargar los datos y recursos necesarios. La optimización incluiría la descarga del número mínimo de recursos para dibujar la página, la disminución del tamaño de las imágenes, el almacenamiento de los recursos estáticos en carpetas que permitan el acceso anónimo, la agrupación en clústeres de las solicitudes y la habilitación de la interactividad de páginas mientras se descargan los recursos de forma asincrónica del servidor. Estas optimizaciones son importantes para lograr una experiencia de exploración aceptable en la primera visita. Un volumen de datos excesivo que se transmite a través de la red contribuye a la degradación de la latencia y el rendimiento. Por ejemplo, las imágenes y otros objetos binarios de una página deben usar un formato comprimido, como.png o.jpg, en lugar de mapas de bits, siempre que sea posible. 19

20 Las páginas web que no están optimizadas para cargas de página de segundo acceso. El tiempo de carga de página (PLT) mejora para las cargas de página de segundo acceso, debido a que algunos recursos de la página se almacenan en la memoria caché del cliente; de esta manera, el explorador solo debe descargar el contenido dinámico que no está almacenado en la memoria caché. Normalmente, las latencias de carga de página de segundo acceso inaceptables se deben a la configuración incorrecta de la memoria caché de objetos binarios grandes (BLOB) o a que el almacenamiento en caché del explorador local está deshabilitado en los equipos cliente. Las optimizaciones incluyen el almacenamiento en caché correcto de los recursos del cliente. Las páginas web que tienen código no optimizado personalizado de JavaScript. Esto podría retrasar la representación de la página en el cliente. La optimización podría provocar un retraso en el procesamiento de JavaScript en el cliente hasta que se haya cargado el resto de la página y, preferiblemente, debería hacer una llamada a script en lugar de agregar JavaScript alineado. Rendimiento El rendimiento se describe en base al número de solicitudes que una granja de servidores puede procesar en una unidad de tiempo. Además, se usa a menudo para medir la escala de las operaciones que se espera que el sistema soporte en función del tamaño de la organización y sus características de uso. Cada operación tiene un costo específico en los recursos de la granja de servidores. La comprensión de la demanda y la implementación de una arquitectura de granja de servidores que pueda satisfacer la demanda de forma coherente requiere la estimación de la carga esperada y la prueba de la arquitectura bajo una carga para comprobar que la latencia no se encuentre por debajo del objetivo cuando la simultaneidad es alta y el sistema está sobrecargado. Algunos ejemplos comunes de las condiciones de bajo rendimiento incluyen: Recursos de hardware inadecuados Cuando la granja de servidores recibe más solicitudes de las que puede procesar simultáneamente, algunas de ellas se ponen en cola, lo cual hace que se acumulen y retrasa el procesamiento de cada una de las solicitudes posteriores, hasta que la demanda se reduzca lo suficiente como para que la cola se termine. A continuación se muestran algunos ejemplos de optimización de una granja de servidores para que soporte un mayor rendimiento: Asegúrese de que los procesadores de los servidores de la granja no se estén usando en exceso. Por ejemplo, si el uso de CPU durante las horas de mayor demanda o en los picos de carga supera siempre el 80 por ciento, agregue más servidores o redistribuya los servicios a otros servidores de la granja. Asegúrese de que haya suficiente memoria en los servidores de aplicaciones y los servidores web que contienen la memoria caché completa. Esto ayudará a evitar las llamadas a la base de datos para servir las solicitudes de contenido no almacenado en caché. Asegúrese de que los servidores de bases de datos no tengan cuellos de botella. Si no hay suficientes E/S de disco por segundo (IOPS) disponibles para cubrir la demanda máxima, agregue más discos o redistribuya las bases de datos a discos 20

21 infrautilizados. Consulte la sección "Quitar los cuellos de botella" del artículo sobre supervisión y mantenimiento de Productos y Tecnologías de SharePoint Server 2010 para obtener más información. Si la adición de recursos a los equipos existentes no es suficiente para resolver los problemas de rendimiento, agregue servidores y redistribuya las características y los servicios afectados a los nuevos servidores. Páginas web personalizadas no optimizadas Una causa común de los problemas de rendimiento es la adición de código personalizado a las páginas usadas con frecuencia en un entorno de producción. La adición de código personalizado puede generar más idas y vueltas a los servidores de bases de datos o servicios web para atender las solicitudes de datos. La personalización de las páginas que no se usan con frecuencia no afecta al rendimiento de forma significativa, pero incluso el código bien optimizado puede disminuir el rendimiento de la granja de servidores si se solicita miles de veces por día. Los administradores de SharePoint Server pueden habilitar el panel del programador para que identifique el código personalizado que requiera optimización. A continuación se proporcionan algunos ejemplos de optimización de código personalizado: Minimizar el número de solicitudes de servicio web y consultas SQL. Capturar los mínimos datos necesarios en cada recorrido al servidor de bases de datos, a la vez que se minimiza el número de idas y vueltas necesarias. Evitar agregar código personalizado a las páginas usadas con frecuencia. Usar índices al recuperar una cantidad filtrada de datos. Soluciones que no son de confianza La implementación de código personalizado en carpetas Bin podría ralentizar el rendimiento del servidor. Cada vez que se solicita una página que contiene código que no es de confianza, SharePoint Server 2010 debe realizar comprobaciones de seguridad antes de que se cargue la página. A menos que exista una razón específica para implementar código que no es de confianza, debe instalar ensamblados personalizados en GAC para evitar que se realicen comprobaciones de seguridad innecesarias. Escala de datos La escala de datos es el volumen de datos que puede almacenar el servidor o la granja de servidores, a la vez que cumple los objetivos de rendimiento y latencia. Por lo general, cuanto mayor sea el volumen de datos de la granja de servidores, mayor será el impacto en el rendimiento general y la experiencia del usuario. El método que se usa para distribuir datos en los discos y servidores de bases de datos también puede afectar al rendimiento y a la latencia de la granja de servidores. El tamaño de las bases de datos, la arquitectura de datos y la existencia de suficiente hardware de servidor de bases de datos son muy importantes para obtener una solución de base de datos óptima. En una implementación ideal, se ajusta el tamaño de las bases de datos de contenido en función de las instrucciones de límites y se las distribuye en discos físicos, de modo que no se ponen en cola las 21

22 solicitudes debido a la sobreutilización del disco. Además, los servidores de bases de datos pueden admitir las cargas máximas y los picos inesperados sin superar los umbrales de uso de recursos. Además, ciertas operaciones pueden bloquear determinadas tablas durante la operación. Un ejemplo de esto es la eliminación de un sitio de gran tamaño, lo que puede hacer que las tablas relacionadas de la base de datos de contenido donde se encuentra el sitio se bloqueen hasta que se complete la operación de eliminación. A continuación se muestran algunos ejemplos de optimización del rendimiento de datos y almacenamiento de una granja de servidores: Asegúrese de que las bases de datos se distribuyan correctamente en todos los servidores de bases de datos y que los recursos del servidor de bases de datos sean suficientes para admitir el volumen y la distribución de datos. Separe los volúmenes de la base de datos en unidades lógicas (LUN) únicas, que consisten en ejes únicos de disco físico. Use varios discos con tiempo de búsqueda bajo y opciones de configuración RAID adecuadas para satisfacer las demandas de almacenamiento del servidor de bases de datos. Si el conjunto contiene muchos objetos binarios grandes (BLOB), puede usar almacenamiento remoto de blobs (RBS). RBS puede ofrecer los siguientes beneficios: Los datos BLOB pueden almacenarse en dispositivos menos costosos configurados para almacenamiento simple. La administración del almacenamiento de blobs se controla mediante un sistema diseñado específicamente para trabajar con datos BLOB. Los recursos del servidor de bases de datos se liberan para operaciones de base de datos. Estos beneficios no son gratuitos. Antes de implementar RBS con SharePoint Server 2010, debe evaluar si estos beneficios potenciales invalidan los costos y las limitaciones de implementar y mantener RBS. Para obtener más información, vea Plan for remote BLOB storage (RBS) (SharePoint Server 2010). Para obtener más información acerca de cómo planear la escala de datos, vea Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010). Confiabilidad La confiabilidad es la medida agregada de la capacidad de la granja de servidores para satisfacer los objetivos establecidos de latencia, rendimiento y capacidad de datos con el tiempo. Una granja de servidores confiable es aquella para la cual el tiempo límite, la capacidad de respuesta, la tasa de errores, y la frecuencia y amplitud de los picos de latencia están dentro de los requisitos operativos y objetivos establecidos. Una granja de servidores confiable también puede soportar de forma coherente los objetivos de rendimiento y latencia durante la carga máxima y las horas de mayor demanda o al realizar operaciones del sistema, como copias de seguridad diarias o rastreos. 22

23 Un factor importante para mantener la confiabilidad es el efecto que tienen las operaciones administrativas comunes en los objetivos de rendimiento. Durante determinadas operaciones, como volver a generar los índices de base de datos, los trabajos del temporizador de mantenimiento o la eliminación de varios sitios con gran volumen de contenido, es posible que el sistema no pueda procesar las solicitudes de usuario muy rápidamente. En estos casos, la latencia y el rendimiento de las solicitudes del usuario final pueden verse afectados. El impacto en la granja de servidores depende del costo de transacción y la frecuencia de dichas operaciones menos comunes y de si se ejecutan durante las horas de operación normales. A continuación se muestran algunos ejemplos de cómo mantener un sistema más confiable: Programar trabajos del temporizador con uso intensivo de recursos y tareas administrativas fuera de las horas de mayor demanda. Incrementar la escalabilidad vertical de hardware en los servidores de la granja existentes o incrementar la escalabilidad horizontal mediante la adición de servidores web, servidores de aplicaciones o servidores de bases de datos adicionales. Distribuir servicios y características con uso intensivo de recursos en los servidores dedicados. También puede usar un equilibrador de carga de hardware para dirigir el tráfico específico de característica a un servidor web dedicado a determinadas características o servicios. Administración de capacidad frente a planeación de capacidad La administración de la capacidad amplía el concepto de la planeación de la capacidad para expresar un enfoque cíclico en el que la capacidad de una implementación de SharePoint Server 2010 se supervisa y optimiza continuamente para adaptarla a las condiciones y los requisitos cambiantes. SharePoint Server 2010 ofrece mayor flexibilidad y se puede configurar para soportar escenarios de uso en una amplia variedad de puntos de escala diferentes. No existe una arquitectura de implementación única. Por lo tanto, los diseñadores de sistemas y los administradores deben comprender los requisitos para sus entornos específicos. 23

24 Modelo de administración de capacidad de SharePoint Server

25 Paso 1: modelo El modelado es el proceso mediante el cual decide qué soluciones clave desea que su entorno admita y establece todos los parámetros y métricas importantes. El resultado del ejercicio de modelado debe ser una lista de todos los datos clave que necesita para diseñar el entorno. Comprenda la carga de trabajo esperada y el conjunto de datos. Establezca los objetivos de rendimiento y confiabilidad de la granja de servidores. Analice los registros de IIS de SharePoint Server Paso 2: diseño Una vez que haya recopilado los datos del paso 1, puede diseñar la granja de servidores. Los resultados son arquitectura de datos detallada, y topologías físicas y lógicas. Determine la arquitectura de punto de inicio. Seleccione el hardware. Paso 3: piloto, prueba y optimización Si ha diseñado una implementación nueva, debe implementar un entorno piloto para probar la carga de trabajo y las características de uso esperadas. Para una granja de servidores existente, se recomienda hacer pruebas cuando se realicen cambios importantes en la infraestructura. Sin embargo, es posible que se necesite optimizar regularmente en función de los resultados de supervisión, para mantener los objetivos de rendimiento. El resultado de esta fase es el análisis de los resultados de pruebas en función de los objetivos y una arquitectura optimizada capaz de soportar los objetivos establecidos de rendimiento y capacidad. Piloto Implemente un entorno piloto. Prueba Realice una prueba con los objetivos de latencia y rendimiento. Optimización Recopile los resultados de pruebas y realice los cambios necesarios en los recursos de la granja de servidores y la topología. Paso 4: implementación Este paso describe la implementación de la granja de servidores o la realización de cambios en una granja de servidores existente. El resultado para un nuevo diseño es una implementación completa de producción en directo, incluidas todas las migraciones de contenido y usuario. El resultado para una granja de servidores existente son asignaciones de granja de servidores revisadas y actualizaciones de planes de mantenimiento. Paso 5: supervisión y mantenimiento Este paso describe cómo configurar la supervisión y cómo predecir e identificar cuellos de botella, así como realizar periódicamente actividades de mantenimiento y mitigación de cuellos de botella. 25

26 Sobreasignación frente a subasignación de capacidad La sobreasignación de capacidad describe un enfoque de diseño de granja de servidores en que los objetivos se logran sin un uso completo del hardware y los recursos de la granja de servidores de SharePoint Server se infrautilizan considerable y coherentemente. En una implementación con sobreasignación de capacidad, la memoria, CPU y otros indicadores de recursos de la granja de servidores muestran que también se puede servir la demanda con menos recursos. La desventaja de la sobreasignación de capacidad es un mayor gasto en hardware y mantenimiento. Además, se podrían imponer mayores demandas de potencia y espacio. La subasignación describe un enfoque de diseño de granja de servidores en que los objetivos de rendimiento y capacidad no se pueden alcanzar, debido a que los recursos de hardware de la granja de servidores de SharePoint Server se sobreutilizan. A veces se subasigna la capacidad de una granja de servidores para reducir los costos de hardware pero, por lo general, el resultado es una latencia alta que conduce a una mala experiencia de usuario, bajo nivel de satisfacción, escalaciones frecuentes, costos de soporte técnico altos y gastos innecesarios para solucionar problemas y optimizar el entorno. Al diseñar la granja de servidores, asegúrese de que esta pueda satisfacer los objetivos establecidos de rendimiento y capacidad, tanto en cargas máximas normales como en picos inesperados. El diseño, las pruebas y la optimización permiten asegurarse de que la granja de servidores tenga el hardware adecuado. Para mantener los objetivos de rendimiento y adaptarse al crecimiento, siempre es mejor tener más recursos que los necesarios para cumplir los objetivos. El costo de invertir excesivamente en hardware es, generalmente, mucho menor que los gastos acumulados relacionados con la solución de problemas ocasionados por la subasignación. Siempre se debe ajustar el tamaño de un sistema para que responda de forma adecuada durante niveles de demanda máximos, lo cual puede variar para distintos servicios en momentos específicos. Para estimar los requisitos de capacidad de forma eficaz, debe identificar el peor período de demanda posible para todos los recursos. Puede que haya un aumento de la carga en diversas características y servicios a determinadas horas del día, como a primera hora de la mañana o después de la comida. La granja de servidores también debe ser capaz de admitir los picos no planeados, como cuando se realizan anuncios en toda la organización y un número inusualmente elevado de usuarios accede a un sitio al mismo tiempo. Durante estos períodos de demanda alta, los usuarios experimentan una latencia alta o no obtienen una respuesta de la granja de servidores en absoluto, a menos que haya suficientes recursos de granja de servidores para satisfacer el aumento de la carga en la granja de servidores. También debería revisarse la capacidad de la granja de servidores cuando se aprovisionen usuarios adicionales a la empresa. En escenarios como una fusión o adquisición caracterizada por el acceso de nuevos empleados o integrantes a la granja de servidores, se podrían obtener efectos negativos sobre el rendimiento si no se planea y estima esta situación por adelantado. 26

27 Estados operativos: zona verde y zona roja Cuando se describe la carga de un sistema de producción, se hace referencia a dos estados operativos principales: el estado "Zona verde", en el que el sistema funciona de acuerdo al intervalo de carga normal y esperado; y el estado "Zona roja", en que la granja de servidores experimenta una demanda de recursos temporal muy alta que solo se puede soportar durante períodos limitados, hasta que se produzcan errores u otros problemas de rendimiento y confiabilidad. Zona verde Se trata del estado en que el servidor o la granja de servidores opera entre condiciones de carga normal y cargas máximas diarias esperadas. Una granja de servidores que opera en este intervalo debe ser capaz de soportar tiempos de respuesta y latencia dentro de parámetros aceptables. Zona roja Se trata del intervalo operativo en que la carga es mayor que la carga máxima normal, pero aún puede servir las solicitudes durante un período limitado. Este estado se caracteriza por una latencia mayor que la normal y posibles errores causados por saturación de cuellos de botella del sistema. El objetivo fundamental del diseño de la granja de servidores es la implementación de un entorno que pueda soportar coherentemente la carga de la zona roja sin errores de servicio y dentro de objetivos de rendimiento y latencia aceptables. Restricciones y límites del software En SharePoint Server 2010, hay ciertos límites que son de diseño y que no se pueden exceder y otros límites que se establecen en valores predeterminados que el administrador de la granja de servidores puede modificar. También hay ciertos límites que no están representados por un valor configurable, como el número de colecciones de sitios por aplicación web. Los límites son límites absolutos que no se pueden exceder por diseño. Es importante entender estos límites para no hacer suposiciones incorrectas al diseñar una granja de servidores. Un ejemplo de límite es el límite de tamaño de documento de 2 GB. No se puede configurar SharePoint Server 2010 para que almacene documentos de más de 2 GB. Éste es un valor absoluto integrado y no se puede exceder por diseño. Los umbrales son límites que tienen un valor predeterminado que no se puede exceder a menos que se modifique el valor. En ciertos casos, los umbrales se pueden exceder para dar cabida a desviaciones en el diseño de la granja de servidores. Sin embargo, es importante entender que al hacerlo se pueden ver afectados el rendimiento de la granja y el valor efectivo de otros límites. El valor predeterminado de ciertos umbrales solo se puede exceder hasta un valor máximo absoluto. Un buen ejemplo, nuevamente, es el límite de tamaño de documento. De forma predeterminada, el límite de tamaño de documento se establece en 50 MB, pero se puede cambiar a un valor máximo de 2 GB. 27

28 Los límites admitidos definen el valor probado de un parámetro específico. Los valores predeterminados de estos límites se definen mediante pruebas y representan las limitaciones conocidas del producto. Si se exceden los límites admitidos, se pueden producir resultados inesperados, una degradación considerable del rendimiento u otros efectos perjudiciales. Algunos límites admitidos son parámetros configurables que se establecen de forma predeterminada en el valor recomendado, mientras que otros están relacionados con parámetros no representados por un valor configurable. Un ejemplo de un límite admitido es el número de colecciones de sitios por aplicación web. El límite admitido es de 500,000, que es la cantidad máxima de colecciones de sitios por aplicación web que alcanzó los niveles de referencia de rendimiento durante las pruebas. Es importante tener en cuenta que muchos de los valores límite que se proporcionan en este documento representan un punto en una curva que describe una carga de recursos creciente y una degradación concomitante del rendimiento a medida que aumenta el valor. Por lo tanto, si se exceden ciertos límites, como el número de colecciones de sitios por aplicación web, solo podría obtenerse una reducción fraccional del rendimiento de la granja de servidores. No obstante, en la mayoría de los casos, el funcionamiento a un límite establecido o a un nivel próximo no es un procedimiento recomendado, ya que es más fácil alcanzar los objetivos aceptables de rendimiento y confiabilidad cuando el diseño de una granja de servidores proporciona un equilibrio razonable de los valores límite. Las directrices de umbrales y límites admitidos están determinadas por el rendimiento. En otras palabras, se pueden exceder los valores predeterminados de los límites, pero a medida que se aumenta el valor límite, el rendimiento de la granja de servidores y el valor efectivo de otros límites pueden verse afectados. Muchos de los límites de SharePoint Server 2010 pueden modificarse. No obstante, es importante entender cómo se verán afectadas otras partes de la granja de servidores al modificar un determinado límite. Si se pone en contacto con los servicios de soporte al cliente de Microsoft acerca de un sistema de producción que no cumple las especificaciones mínimas de hardware publicadas descritas en Hardware and software requirements (SharePoint Server 2010), el soporte técnico estará limitado hasta que se actualice el sistema con los requisitos mínimos. Establecimiento de los límites En SharePoint Server 2010, los umbrales y límites admitidos se establecen mediante pruebas y la observación del comportamiento de la granja de servidores bajo cargas en aumento hasta el punto en que los servicios y operaciones de la granja de servidores alcancen sus límites de funcionamiento efectivos. Algunos servicios y componentes de la granja de servidores pueden admitir una carga mayor que otros. Por lo tanto, en algunos casos debe asignarse un valor límite basado en un promedio de varios factores. Por ejemplo, las observaciones del comportamiento de la granja de servidores bajo carga cuando se agregan colecciones de sitios indican que ciertas características presentan una latencia inaceptablemente alta mientras que otras características siguen funcionando con parámetros aceptables. Por lo tanto, el valor máximo asignado a la cantidad de colecciones de sitios no es absoluto, sino que se calcula en función de un conjunto esperado de características de uso en el que el rendimiento de la granja de servidores en general sería aceptable en el límite especificado en la mayoría de los casos. 28

29 Si otros servicios funcionan con parámetros más altos que los usados en las pruebas de límites, los límites efectivos máximos de otros servicios se reducirán. Por lo tanto, es importante ejecutar rigurosos ejercicios de pruebas de administración de capacidad y de escala para implementaciones específicas, a fin de establecer límites efectivos para dicho entorno. Para obtener más información acerca de las restricciones y los límites, así como sobre el modo en que estos afectan al proceso de administración de la capacidad, vea Administración de la capacidad de SharePoint Server 2010: restricciones y límites del software. Diferencias clave entre SharePoint Server 2010 y Office SharePoint Server 2007 SharePoint Server 2010 ofrece un conjunto más rico de características y un modelo de topología más flexible que en las versiones anteriores. Antes de usar esta arquitectura más compleja para ofrecer una funcionalidad y características más eficaces a los usuarios, debe considerar cuidadosamente su efecto sobre la capacidad y el rendimiento de la granja de servidores. En Office SharePoint Server 2007, había cuatro servicios principales que se podían habilitar en los proveedores de servicios compartidos (SSP): servicio de búsqueda, servicio de Excel Calculation, servicio de perfiles de usuario y servicio de catálogo de datos profesionales. Además, existía un conjunto de clientes relativamente más pequeño que podía interactuar directamente con Office SharePoint Server En SharePoint Server 2010 hay más servicios disponibles, conocidos como aplicaciones de servicio de SharePoint (SSA). Además, SharePoint Server 2010 ofrece una variedad mucho mayor de aplicaciones cliente que pueden interactuar con la granja de servidores, incluidas varias aplicaciones de Office nuevas, dispositivos móviles, herramientas para diseñadores y exploradores. A continuación se proporcionan algunos ejemplos del impacto que tienen las interacciones del cliente expandidas sobre las consideraciones de capacidad: SharePoint Server 2010 incluye aplicaciones sociales que se integran con Outlook y permiten que los clientes de Outlook 2010 muestren información acerca de los destinatarios de correo electrónico que se extrae de la granja de servidores de SharePoint Server cuando se ven los mensajes de correo electrónico en el cliente de Outlook. Esto presenta un nuevo conjunto de patrones de tráfico y una carga del servidor que deben tenerse en cuenta. Algunas de las nuevas características de los clientes de Microsoft Office 2010 actualizan automáticamente los datos con la granja de servidores de SharePoint Server, incluso cuando las aplicaciones cliente se abren pero no se usan activamente. Dichos clientes, como SharePoint Workspace y OneNote, también presentan algunos patrones de tráfico nuevos y una carga del servidor que deben tenerse en cuenta. 29

30 Las nuevas características de interactividad de SharePoint Server 2010, como Office Web Apps, que habilitan la edición de archivos de Office directamente desde el explorador, usan llamadas de AJAX que presentan algunos patrones de tráfico nuevos y una carga del servidor que deben tenerse en cuenta. En Office SharePoint Server 2007, el cliente principal que se usaba para interactuar con el servidor era el explorador web. Debido al conjunto de características más completo de SharePoint Server 2010, se espera que crezca el número general de solicitudes por segundo (RPS). Además, se espera que el porcentaje de solicitudes provenientes del explorador sea más pequeño que en Office SharePoint Server 2007, lo cual deja espacio para el porcentaje creciente de tráfico nuevo procedente de otros clientes, a medida que las características se adopten ampliamente en toda la organización. Además, SharePoint Server 2010 presenta nuevas características, como admisión nativa de vídeo incrustado, que puede agregar un esfuerzo a la granja de servidores. Algunas de las características también se han ampliado para admitir una escala mayor que en las versiones anteriores. La siguiente sección describe estas interacciones de cliente, servicios y características, así como su rendimiento general e implicaciones de capacidad en el sistema, que se deben tener en cuenta al diseñar la solución. Para obtener más información acerca de cómo actualizar a SharePoint Server 2010, vea Upgrading to SharePoint Server Servicios y características En la tabla siguiente se proporciona una descripción simplificada de nivel alto de los requisitos de recursos para los distintos servicios de cada nivel. Las celdas en blanco indican que el servicio no se ejecuta en ese nivel o no lo afecta. X: indica un costo mínimo o insignificante en el recurso. El servicio puede compartir este recurso con otros servicios. XX: indica un costo medio en el recurso. El servicio podría compartir este recurso con otros servicios que tengan un impacto mínimo. XXX: indica un costo alto en el recurso. Por lo general, el servicio no debería compartir este recurso con otros servicios. Para obtener más información acerca de cómo planear las bases de datos de SQL Server, vea Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010). Para ver una lista de los artículos de administración de capacidad disponibles para varios servicios y características de SharePoint Server 2010 específicos (se agregarán más artículos a medida que se encuentren a disposición), vea Recomendaciones y resultados de pruebas de rendimiento y capacidad (SharePoint Server 2010). 30

31 Aplicación de servicio CPU del servidor web RAM del servidor web Servicio de SharePoint Foundation Servicio de Administración central CPU del servidor de aplicaciones 31 RAM del servidor de aplicaciones CPU de SQL Server IOPS de SQL Server XXX XXX XX XXX XXX XX XX X X X Servicio de registro * XX XX XX XXX XXX Servicio de búsqueda de SharePoint Aplicación del Servicio de visualización de Word * XXX XXX XXX XXX XXX XXX XXX X X XXX XX Servicio de PowerPoint * XX XX XXX XX Servicio de Excel Calculation XX X XX XXX Servicio de Visio * X X XXX XXX X X X Servicio de Access * X X XXX XX X X X Servicio de perfiles de usuario Servicio de metadatos administrados * Servicio de Web Analytics * Servicios de conectividad empresarial * X XX XX XX XXX XXX XX X XX XX XX X X XX X X XXX XXX XXX XX XX XXX XXX Almacenamiento de SQL Server

32 Aplicación de servicio CPU del servidor web RAM del servidor web CPU del servidor de aplicaciones RAM del servidor de aplicaciones CPU de SQL Server IOPS de SQL Server Almacenamiento de SQL Server InfoPath Forms Services XX XX XX XX X X X Word Automation Services X X XXX XX X X X Aplicación de Servicio PerformancePoint * XX XX XXX XXX X X X Servicio de Project * X X X X XXX XXX XX Soluciones de espacio aislado * X X XXX XXX Características de flujo de trabajo * XXX XXX Servicio de temporizador XX XX XX XX PowerPivot * X X XXX XXX XX XX XXX Nota: Un asterisco (*) indica un nuevo servicio en SharePoint Server Servicio de SharePoint Foundation El servicio de SharePoint principal de colaboración de contenido. En implementaciones de SharePoint Server de gran tamaño, se recomienda asignar servidores web redundantes en función de la carga de tráfico esperada, ajustar correctamente el tamaño de los equipos basados en SQL Server que sirven las bases de datos de contenido y asignar correctamente el almacenamiento en función del tamaño de la granja de servidores. Servicio de Administración central El servicio de administración. Este servicio tiene requisitos de capacidad relativamente pequeños. Se recomienda habilitar este servicio en varios servidores de la granja para asegurar la redundancia. 32

33 Servicio de registro El servicio que registra los indicadores de estado y de uso para fines de supervisión. Se trata de un servicio de escritura intensiva, que puede requerir espacio en disco relativamente grande en función del número de indicadores y la frecuencia con la que estos se registran. En implementaciones de SharePoint Server 2010 de gran tamaño, se recomienda aislar la base de datos de uso de las bases de datos de contenido de diferentes equipos basados en SQL Server. Aplicación de servicio de búsqueda de SharePoint La aplicación de servicios compartidos que proporciona funciones de indización y consulta. Por lo general, se trata de un servicio con uso de recursos relativamente intensivo, que se puede escalar para servir implementaciones de contenido muy grandes. En implementaciones de SharePoint Server de gran tamaño, en que el motor de búsqueda Enterprise Search es muy importante, se recomienda usar una "granja de servidores de servicio" independiente para hospedar aplicaciones de servicio de búsqueda con recursos de base de datos dedicados, usar varios servidores de aplicaciones que sirvan funciones de búsqueda específicas (rastreo o consulta) y servidores web de destino dedicados de las granjas de servidores de contenido, para asegurar un rendimiento aceptable para el rastreo y las consultas. También puede habilitar las aplicaciones de servicio FAST como la aplicación de servicio de búsqueda. Elija crear uno o más conectores de FAST Search para indizar contenido con FAST Search Server 2010 for SharePoint y cree otra consulta de FAST Search (SSA) para consultar el contenido que se rastrea mediante los conectores de FAST Search. Aplicación del Servicio de visualización de Word Al habilitar este servicio podrá ver documentos de Word directamente desde el explorador. Este servicio se agrega al instalar Office Web Apps junto con SharePoint Server Este servicio requiere un servidor de aplicaciones para preparar los archivos originales para la visualización en el explorador. En implementaciones de SharePoint Server de gran tamaño, se recomienda incrementar la escalabilidad horizontal del servicio en varios servidores de aplicaciones para la redundancia y el rendimiento. Nota: La edición en el explorador para Word y OneNote se habilita al instalar Office Web Apps en la granja de servidores de SharePoint Server Sin embargo, esta característica se ejecuta en los servidores web de la granja de servidores y no usa ninguna aplicación de servicio. Aplicación de servicio de PowerPoint Este servicio muestra archivos de PowerPoint y permite que los usuarios los editen directamente en el explorador. Además, permite difundir y compartir presentaciones de PowerPoint en directo. Este servicio se agrega al instalar Office Web Apps en SharePoint Server Este servicio requiere un servidor de aplicaciones para preparar los archivos originales para la visualización en el explorador. En implementaciones de SharePoint Server de gran tamaño, en que el servicio se convierte en una función que se usa con frecuencia, se recomienda implementar varios servidores de aplicaciones para asegurar una redundancia y una capacidad de proceso aceptables, y agregar más servidores web cuando la difusión de PowerPoint también se use con frecuencia. 33

34 Aplicación de Excel Calculation Services Este servicio muestra hojas de cálculo de Excel directamente en el explorador y realiza cálculos de Excel en el servidor. Además, permite la edición de hojas de cálculo directamente desde el explorador cuando se instala Office Web Apps en SharePoint Server En implementaciones de SharePoint Server de gran tamaño, en que el servicio se convierte en una función que se usa con frecuencia, se recomienda asignar un número suficiente de servidores de aplicaciones que tengan suficiente RAM para garantizar un rendimiento y una capacidad de proceso aceptables. PowerPivot para SharePoint El servicio para mostrar hojas de cálculo de Excel habilitadas para PowerPivot directamente desde el explorador. En implementaciones de SharePoint Server de gran tamaño, en que el servicio se convierte en una función que se usa con frecuencia, se recomienda asignar un número suficiente de servidores de aplicaciones que tengan suficiente RAM y CPU para garantizar un rendimiento y una capacidad de proceso aceptables. Para obtener más información, vea el tema sobre los requisitos de hardware y software (PowerPivot para SharePoint). Aplicación de Servicios de Visio El servicio para mostrar diagramas dinámicos de Visio directamente en el explorador. Este servicio tiene una dependencia de la aplicación de servicio de estado de sesión, lo cual requiere una base de datos de SQL Server relativamente pequeña. El servicio de Visio requiere un servidor de aplicaciones para preparar los archivos originales de Visio para la visualización en el explorador. En implementaciones de SharePoint Server de gran tamaño, en que el servicio se convierte en una función que se usa con frecuencia, se recomienda incrementar la escalabilidad horizontal del servicio en varios servidores de aplicaciones que tengan suficiente CPU y RAM para garantizar un rendimiento y una capacidad de proceso aceptables. Aplicación de los Servicios de Access El servicio para hospedar soluciones de Access en SharePoint Server En implementaciones de SharePoint Server de gran tamaño, en que el servicio se convierte en una función que se usa con frecuencia, se recomienda incrementar la escalabilidad horizontal en varios servidores de aplicaciones que tengan suficiente RAM para conseguir un rendimiento y una capacidad de proceso aceptables. El servicio de Access usa SQL Reporting Services, lo cual requiere una base de datos de SQL Server que se pueda co-localizar con otras bases de datos. Aplicación de servicio de perfiles de usuario El servicio que potencia los escenarios sociales en SharePoint Server 2010 y habilita Mis sitios, el etiquetado, las notas, la sincronización de perfiles con los directorios y otras funciones sociales. El servicio de perfiles requiere tres bases de datos con uso de recursos relativamente intensivo: las bases de datos de sincronización, perfiles y etiquetado social. Este servicio depende de la aplicación de servicio de metadatos administrados. En implementaciones de SharePoint Server de gran tamaño, debe tener en cuenta la posibilidad de distribuir este servicio a una granja de servidores de servicios compartidos y ajustar correctamente el tamaño del nivel de servidor de bases de datos para garantizar un rendimiento aceptable de las transacciones comunes y los trabajos de sincronización de directorios. Aplicación de servicio de metadatos administrados El servicio que potencia el repositorio de metadatos central y permite la redifusión de los tipos de contenido en toda la empresa. El servicio se puede federar en una granja de servidores de servicios dedicados. Requiere una base de datos que se pueda colocalizar con otras bases de datos. 34

35 Aplicación de servicio de Web Analytics El servicio que agrega y almacena estadísticas sobre las características de uso de la granja de servidores. Este servicio tiene una demanda relativamente alta de almacenamiento y recursos de SQL Server. El servicio se puede federar en una granja de servidores de servicios dedicados. En implementaciones de SharePoint Server de gran tamaño se recomienda aislar las bases de datos de Web Analytics de otras bases de datos muy importantes o con uso intensivo de recursos al hospedarlas en distintos servidores de bases de datos. Aplicación de Servicios de conectividad empresarial El servicio que permite la integración de varias aplicaciones de línea de negocio de la organización junto con SharePoint Server Este servicio requiere un servicio de aplicación para mantener las conexiones de datos con recursos externos. En implementaciones de SharePoint Server de gran tamaño, en que este servicio es una función que se usa con frecuencia, se recomienda asignar un número suficiente de servidores de aplicaciones que tengan suficiente RAM para obtener un rendimiento aceptable. Aplicación de InfoPath Forms Services El servicio que habilita los formularios basados en el explorador en SharePoint Server 2010 y la integración con la aplicación cliente de InfoPath para la creación de formularios. Este servicio requiere un servidor de aplicaciones y tiene una dependencia con la aplicación de servicio de estado de sesión, lo que requiere una base de datos relativamente pequeña. Este servicio se puede colocalizar con otros servicios y tiene requisitos de capacidad relativamente pequeños, que pueden aumentar en función de la frecuencia de uso de esta función. Aplicación de Word Automation Services El servicio que permite la conversión de archivos de Word de un formato, como.doc, a otro como.docx o.pdf. Este servicio requiere un servidor de aplicaciones. En implementaciones de SharePoint Server de gran tamaño, en que el servicio se convierte en una función que se usa con frecuencia, se recomienda incrementar la escalabilidad horizontal del servicio en varios servidores de aplicaciones que tengan suficientes recursos de CPU para obtener un rendimiento de conversión aceptable. Este servicio también requiere una base de datos relativamente pequeña para mantener la cola de los trabajos de conversión. Aplicación de Servicio PerformancePoint El servicio que habilita las funciones de BI de PerformancePoint en SharePoint Server 2010 y permite crear visualizaciones analíticas. Este servicio requiere un servidor de aplicaciones y una base de datos. En implementaciones de SharePoint Server de gran tamaño, en que el servicio se convierte en una función que se usa con frecuencia, se recomienda asignar suficiente RAM para los servidores de aplicaciones para conseguir un rendimiento y una capacidad de proceso aceptables. Aplicación de servicio de Project El servicio que habilita todas las características de planeación y seguimiento de Microsoft Project Server 2010 además de SharePoint Server Este servicio requiere un servidor de aplicaciones y una base de datos con uso de recursos relativamente intensivo. En implementaciones de SharePoint Server de gran tamaño, en que el servicio es una característica que se usa con frecuencia, debe dedicar un servidor de bases de datos para la base de datos de Project Server e 35

36 incluso tener en cuenta una granja de servidores de SharePoint Server dedicada para las soluciones de administración de Project Server. Servicio de temporizador El proceso encargado de la ejecución de las distintas tareas programadas en los diferentes servidores de la granja. El sistema ejecuta varios trabajos del temporizador; algunos que se ejecutan en todos los servidores de la granja y otros que se ejecutan solo en servidores específicos, según el rol del servidor. Algunos de estos trabajos del temporizador hacen un uso intensivo de recursos y podrían crear carga en el servidor local y en los servidores de bases de datos, en función de su actividad y de la cantidad de contenido con la que operan. En implementaciones de SharePoint Server de gran tamaño, en que los trabajos del temporizador podrían tener consecuencias sobre la latencia del usuario final, se recomienda dedicar un servidor para aislar la ejecución de los trabajos con uso más intensivo de recursos. Flujo de trabajo La característica que habilita los flujos de trabajo integrados en SharePoint Server 2010 y ejecuta los flujos de trabajo en el servidor web. El uso de recursos depende de la complejidad de los flujos de trabajo y el número total de eventos que controlan. En implementaciones de SharePoint Server de gran tamaño, en que los flujos de trabajo son una característica que se usa con frecuencia, debe considerar la posibilidad de agregar servidores web o aislar un servidor para controlar solo el servicio de temporizador de flujo de trabajo para asegurar que el tráfico de usuario final no se vea afectado y que las operaciones de flujo de trabajo no se retrasen. Soluciones de espacio aislado El servicio que habilita el aislamiento de código personalizado en recursos de la granja de servidores dedicados. En implementaciones de SharePoint Server de gran tamaño, en que el servicio es una característica usada frecuentemente, debe considerar la posibilidad de dedicar servidores web adicionales si el código personalizado comienza a tener consecuencias en el rendimiento del servidor. Nuevas interacciones de aplicaciones cliente con SharePoint Server 2010 En esta sección se describen algunas nuevas interacciones de cliente y servidor que admite SharePoint Server 2010 y sus implicaciones en la planeación de capacidad. En la tabla siguiente se proporciona una descripción simplificada de nivel alto de la carga típica que estas nuevas características introducen en el sistema: X: indica una carga mínima o insignificante en los recursos del sistema XX: indica una carga media en los recursos del sistema XXX: indica una carga alta en los recursos del sistema 36

37 Cliente Tráfico Carga Office Web Apps XXX XX Difusión de PowerPoint XXX X Aplicación cliente de Word y PowerPoint 2010 XX X Aplicación cliente de OneNote XXX XXX Outlook Social Connector XX XX SharePoint Workspace XXX XX Office Web Apps La visualización y edición web de archivos de Word, PowerPoint, Excel y OneNote es un subconjunto de solicitudes del explorador con características de tráfico ligeramente diferentes. Este tipo de interacción presenta una carga de tráfico relativamente alta, necesaria para habilitar ciertas características, como la coautoría. En implementaciones de SharePoint Server de gran tamaño, en que se habilitan estas características, se debe esperar una carga adicional en los servidores web. Difusión de PowerPoint El conjunto de solicitudes asociadas con la visualización en directo de presentaciones de PowerPoint en el explorador web es otro subconjunto de solicitudes del explorador. Durante las sesiones de difusión en directo de PowerPoint, los clientes que participan solicitan cambios desde el servicio. En implementaciones de SharePoint Server de gran tamaño, en que se trata de una característica que se usa con frecuencia, se debe esperar una carga adicional en los servidores web. Aplicaciones cliente de Word y PowerPoint 2010 Los clientes de Word y PowerPoint 2010 tienen nuevas características que aprovechan la granja de servidores de SharePoint Server. Un ejemplo es la coautoría de documentos, en la que todas las aplicaciones cliente que participan en una sesión de coautoría cargan y descargan con frecuencia actualizaciones desde y hacia el servidor. En implementaciones de SharePoint Server de gran tamaño, en que se trata de una característica que se usa con frecuencia, se debe esperar una carga adicional en los servidores web. Aplicación cliente de OneNote 2010 El cliente de OneNote 2010 interactúa con la granja de servidores de SharePoint Server de forma similar que en la versión anterior de OneNote y usa SharePoint Server 2010 para compartir blocs de notas de OneNote y habilitar la coautoría en ellos. Este escenario introduce una carga en SharePoint Server 2010 aún cuando el cliente está abierto, pero no se lo usa activamente. En implementaciones de SharePoint Server de gran tamaño, en que se trata de una característica que se usa con frecuencia, se debe esperar una carga adicional en los servidores web. 37

38 Aplicación cliente de Outlook 2010 Outlook 2010 tiene una característica nueva, Outlook Social Connector, que aprovecha la granja de servidores de SharePoint Server (este componente también puede agregarse a versiones anteriores de Outlook). Esta característica permite ver la actividad social solicitada desde la granja de servidores de SharePoint Server directamente en los mensajes de correo electrónico. En implementaciones de SharePoint Server de gran tamaño, en que se habilita esta característica, se debe esperar una carga adicional en los servidores web. SharePoint Workspace Los clientes de SharePoint Workspace 2010 tienen nuevas características que aprovechan la granja de servidores de SharePoint Server y permiten sincronizar sitios web, listas y bibliotecas de documentos con el cliente para su uso sin conexión. SharePoint Workspace 2010 se sincroniza periódicamente con los objetos de servidor adjuntos cuando se ejecuta el cliente, independientemente de si se usa activamente o no. En implementaciones de SharePoint Server de gran tamaño, en que se trata de una característica que se usa con frecuencia, se puede esperar una carga adicional en los servidores web. Diferenciadores clave de implementación de SharePoint Server 2010 Cada implementación de SharePoint Server 2010 tiene un conjunto clave de características que la hacen única y la diferencian de otras granjas de servidores. Estos diferenciadores clave se pueden describir a través de las siguientes cuatro categorías principales: Especificación Describe el hardware de la granja de servidores, así como la topología y configuración de la misma. Carga de trabajo Describe la demanda de la granja de servidores, incluido el número de usuarios y las características de uso. Conjunto de datos Describe los tamaños y la distribución del contenido. Estado y rendimiento Describe el rendimiento de la granja de servidores en cuanto a los objetivos de rendimiento y latencia. Especificaciones Hardware El hardware son los recursos físicos del equipo, como procesadores, memoria y discos duros. El hardware también incluye componentes de red física, como tarjetas de interfaz de red (NIC), cables, conmutadores, enrutadores y equilibradores de carga de hardware. Se pueden resolver muchos problemas de rendimiento y capacidad al asegurarse de usar el hardware adecuado. Por otro lado, una única mala utilización de un recurso de hardware, como memoria insuficiente en un servidor, puede afectar el rendimiento de toda la granja de servidores. Topología La topología es la distribución y las relaciones entre el hardware de la granja de servidores y los componentes. Existen dos tipos de topologías: 38

39 Topología lógica La asignación de componentes de software, como servicios y características de una granja de servidores. Topología física La asignación de servidores y recursos físicos. Normalmente, el número de usuarios y las características de uso determinan la topología física de una granja de servidores y los requisitos empresariales, de la misma manera que la necesidad de admitir características específicas para la carga esperada controla la topología lógica. Configuración La configuración de términos se usa para describir la configuración de software y el modo en que se establecen los parámetros. Además, la configuración hace referencia al almacenamiento en caché, RBS, el modo en que se establecen los límites configurables y cualquier parte del entorno de software que se pueda configurar o modificar para satisfacer los requisitos específicos. Carga de trabajo La carga de trabajo define las características operativas clave de la granja de servidores, incluida la base de usuarios, la simultaneidad, las características que se usan y los agentes de usuario o las aplicaciones cliente que se usan para conectarse con la granja de servidores. Distintas características de SharePoint Server tienen diferentes costos asociados en los recursos de la granja de servidores. La popularidad de las características más costosas podría tener un impacto significativo en el rendimiento y el estado del sistema. Si comprende la demanda prevista y las características de uso, podrá ajustar correctamente el tamaño de la implementación y reducir el riesgo de ejecutar constantemente el sistema en una situación de mal estado. Base de usuarios La base de usuarios de una aplicación basada en SharePoint Server es una combinación del número total de usuarios y el modo en que se distribuyen geográficamente. Además, dentro de la base de usuarios total, hay subgrupos de usuarios que pueden usar ciertas características o servicios más intensivamente que otros grupos. La simultaneidad de usuarios se define como el porcentaje total de usuarios que usan el sistema activamente en un momento dado. Los indicadores que definen la base de usuarios incluyen el número de usuarios únicos totales y el número de usuarios simultáneos. Características de uso El rendimiento de una granja de servidores puede verse afectado no solo por el número de usuarios que interactúan con el sistema, sino también por sus características de uso. Dos organizaciones que tengan el mismo número de usuarios pueden tener requisitos muy diferentes en función de la frecuencia con que los usuarios obtengan acceso a los recursos de la granja de servidores y de acuerdo a si se habilitan características y servicios con uso intensivo de recursos en la granja de servidores. Los indicadores que describen las características de uso incluyen la frecuencia de operaciones únicas, la combinación de funcionamiento general (la relación entre 39

40 operaciones administrativas y operaciones de lectura y escritura), y los patrones de uso y carga con respecto a las nuevas características que se habilitan en la granja de servidores (por ejemplo, los sitios web de Mi sitio, la búsqueda, los flujos de trabajo y Office Web Apps). Conjunto de datos El volumen de contenido que se almacena en el sistema y las características de la arquitectura en que se almacena pueden tener un efecto importante sobre el estado y el rendimiento generales del sistema. Comprender el tamaño, la frecuencia de acceso y la distribución de datos permitirá ajustar correctamente el tamaño del almacenamiento en el sistema y evitar que se convierta en un cuello de botella que reduzca la velocidad de las interacciones del usuario con los servicios de la granja de servidores y afecte a la experiencia del usuario final. Para estimar y diseñar correctamente la arquitectura de almacenamiento de una solución basada en SharePoint Server, debe conocer el volumen de datos que almacenará en el sistema y el número de usuarios que solicitan datos de distintos orígenes de datos. El volumen del contenido es un elemento importante del tamaño de la capacidad de disco, ya que puede influir en el rendimiento de otras características y podría afectar también el ancho de banda disponible y la latencia de red. Los indicadores que definen el conjunto de datos incluyen el tamaño total del contenido, el número total de documentos, el número total de colecciones de sitios y los tamaños máximo y medio de la colección de sitios. Estado y rendimiento El estado de la granja de servidores de SharePoint Server es básicamente una medida o puntuación simplificada que refleja la confiabilidad, estabilidad y el rendimiento del sistema. El rendimiento de la granja de servidores con respecto a los objetivos depende básicamente de los tres primeros diferenciadores. Se puede realizar un seguimiento y describir la puntuación de estado y rendimiento mediante una destilación de un conjunto de indicadores. Para obtener más información, vea Supervisión y mantenimiento de SharePoint Server Estos indicadores son el tiempo límite del sistema, la latencia percibida por el usuario final, las tasas de errores de página y los indicadores de uso de recursos (CPU, RAM). Cualquier cambio significativo en el hardware, la configuración, topología, carga de trabajo o el conjunto de datos puede modificar considerablemente la confiabilidad y la capacidad de respuesta del sistema. La puntuación del estado se puede usar para hacer un seguimiento a través del tiempo y para evaluar el modo en que los cambios de las condiciones de funcionamiento o las modificaciones del sistema afectan la confiabilidad de la granja de servidores. Arquitecturas de referencia SharePoint Server 2010 es un producto complejo y eficaz, y no hay ninguna arquitectura que se ajuste a todas las soluciones. Cada implementación de SharePoint Server es única y se define mediante sus características de uso y datos. Cada organización debe realizar 40

41 un proceso de administración de capacidad exhaustivo y aprovechar con eficacia la flexibilidad que ofrece el sistema de SharePoint Server 2010 para personalizar una solución de tamaño correcto que mejor satisfaga las necesidades organizativas. El concepto de arquitecturas de referencia se usa para describir e ilustrar las diferentes categorías principales de las implementaciones de SharePoint Server y no para proporcionar una receta que los arquitectos puedan usar para diseñar sus soluciones. Esta sección se centra en describir los vectores que se usan normalmente para escalar las implementaciones de SharePoint Server. Las arquitecturas que se enumeran a continuación se proporcionan como una manera útil para comprender los diferenciadores generales entre estas categorías genéricas y para diferenciarlos mediante los factores de costos generales y la escala de esfuerzo. Implementación de servidor único La arquitectura de implementación de servidor único consiste en un servidor que ejecuta SharePoint Server 2010 y una versión compatible de SQL Server. Esta arquitectura podría ser apropiada para fines de evaluación, para los programadores o para una implementación de departamento aislada, que no es crítica y tiene solo unos pocos usuarios. Sin embargo, no se recomienda su uso en un entorno de producción. Implementación de una granja de servidores pequeña Una implementación de una granja de servidores pequeña se compone de un único servidor de base de datos o clúster y uno o dos equipos basados en SharePoint Server Las características principales de la arquitectura son redundancia y conmutación por error limitadas, y un conjunto mínimo de características de SharePoint Server habilitadas. Una granja de servidores pequeña es útil para servir solo las implementaciones limitadas, con un conjunto mínimo de aplicaciones de servicio habilitadas, una base de usuarios relativamente pequeña, una carga de uso relativamente baja (algunas pocas solicitudes por minuto hasta muy pocas solicitudes por segundo) y un volumen relativamente pequeño de datos (10 o más gigabytes). 41

42 Implementación de una granja de servidores mediana Esta arquitectura presenta el desglose de la topología en tres niveles: servidores web dedicados, servidores de aplicaciones dedicados y uno o varios servidores de bases de datos o clústeres. La separación del nivel de servidor front-end del nivel de servidor de aplicaciones permite mayor flexibilidad en el aislamiento de servicios y ayuda a equilibrar la carga en el sistema. Se trata de la arquitectura más común, que incluye un amplio espectro de tamaños de granja de servidores y topologías de servicio. Una implementación de una granja de servidores mediana es útil para servir los entornos que tienen los siguientes elementos: Varias aplicaciones de servicio distribuidas en varios servidores. Un conjunto típico de características podría incluir el servicio de Office Web Apps, servicio de perfiles de usuario, servicio de metadatos administrados y servicio de Excel Calculation. Una base de usuarios de decenas de miles de usuarios y una carga de 10 a 50 solicitudes por segundo. Un almacén de datos de uno o dos terabytes. 42

43 43

44 Implementación de una granja de servidores grande Las implementaciones de granjas de servidores grandes presentan un desglose de servicios y soluciones en varias granjas de servidores y un mayor incremento de la escalabilidad horizontal de los niveles de una única granja de servidores. Varios servicios de SharePoint Server se pueden implementar en una granja de servidores de servicios dedicados que sirve solicitudes de varias granjas de servidores de consumo. En estas arquitecturas de gran tamaño, normalmente hay servidores web, varios servidores de aplicaciones, según la característica de uso de cada uno de los servicios locales (no compartidos), y varios servidores basados en SQL Server o clústeres de SQL Server, dependiendo del tamaño del contenido y las bases de datos de servicios de la aplicación que están habilitadas en la granja de servidores. Se espera que las arquitecturas de granjas de servidores grandes sirvan las implementaciones que tienen los siguientes elementos: Varias aplicaciones de servicio federadas y consumidas desde la granja de servidores de servicios dedicados; normalmente, el servicio de perfiles de usuario, la búsqueda, el servicio de metadatos administrados y Web Analytics. La mayoría de las demás aplicaciones de servicios habilitadas localmente. Una base de usuarios en el intervalo de cientos de miles de usuarios. Una carga de uso en el intervalo de cientos de solicitudes por segundo. Un conjunto de datos en el intervalo de diez o más terabytes. 44

45 45

46 Vea también Conceptos Planeación de la capacidad para SharePoint Server 2010 Pruebas de rendimiento para SharePoint Server 2010 Supervisión y mantenimiento de SharePoint Server 2010 Administración de la capacidad de SharePoint Server 2010: restricciones y límites del software Recomendaciones y resultados de pruebas de rendimiento y capacidad (SharePoint Server 2010) Performance and capacity technical case studies (SharePoint Server 2010) (en inglés) Otros recursos Hardware and software requirements (SharePoint Server 2010) 46

47 Planeación de la capacidad para SharePoint Server 2010 En este artículo se describe cómo planear la capacidad de un conjunto o granja de servidores de Microsoft SharePoint Server Cuando tenga una apreciación y comprensión adecuadas de la planeación y administración de la capacidad, podrá aplicar sus conocimientos para realizar el ajuste de tamaño del sistema. Se entiende por ajuste de tamaño el proceso de elegir y configurar de manera adecuada la arquitectura de datos, la topología lógica y física, y el hardware para una plataforma de solución. Deben tenerse en cuenta varias consideraciones sobre administración y uso de la capacidad a la hora de determinar las opciones de hardware y de configuración más apropiadas. Antes de leer este artículo, debe leer Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server En este artículo se describen los pasos que se deben seguir para la administración eficaz de la capacidad de un entorno. Cada paso requiere cierta información para su correcta ejecución e incluye un conjunto de entregas que se usarán en el paso siguiente. En las tablas que siguen se describen los requisitos y objetivos correspondientes a cada paso. En este artículo: Paso 1: Modelo Paso 2: Diseño Paso 3: Piloto, prueba y optimización Paso 4: Implementación Paso 5: Supervisión y mantenimiento Paso 1: Modelo Para crear un modelo de un entorno basado en SharePoint Server 2010, es necesario empezar con un análisis de las soluciones existentes y estimar la demanda y los objetivos previstos para la implementación que se desea configurar. Primero, debe recopilar información acerca de la base de usuarios, los requisitos de datos, la latencia y los objetivos de rendimiento, y documentar las características de SharePoint Server que desea implementar. En esta sección aprenderá qué datos debe recopilar, cómo recopilarlos y cómo se pueden usar en los pasos siguientes. 47

48 Determinación de la carga de trabajo y el conjunto de datos previstos Para calcular correctamente el tamaño de una implementación de SharePoint Server 2010 debe analizar y conocer las características de demanda que se espera que la solución pueda controlar. Para conocer la demanda, debe poder describir las características de la carga de trabajo, como el número de usuarios y las operaciones que se usan con más frecuencia, así como las características del conjunto de datos, como el tamaño y la distribución del contenido. Esta sección le ayudará a conocer algunos de los datos métricos y parámetros específicos que deberá recopilar y los mecanismos que puede usar para hacerlo. Carga de trabajo La carga de trabajo describe la demanda que el sistema deberá atender, la base de usuarios y las características de uso. En la tabla siguiente se proporcionan algunos datos métricos esenciales que resultan útiles para determinar la carga de trabajo. Puede usar esta tabla para registrar estos datos métricos a medida que los recopila. Características de la carga de trabajo Valor Promedio de RPS por día Promedio de RPS en horas pico Número total de usuarios únicos por día Promedio de usuarios simultáneos por día Pico de usuarios simultáneos en horas pico Número total de solicitudes por día Distribución de carga de trabajo prevista Número de solicitudes por día % Explorador web: rastreo de búsqueda Explorador web: interacción general de colaboración Explorador web: interacción social Explorador web: interacción general 48

49 Características de la carga de trabajo Valor Explorador web: Office Web Apps Clientes de Office Cliente de OneNote SharePoint Workspace Sincronización de RSS de Outlook Outlook Social Connector Otras interacciones (aplicaciones/servicios web personalizados) Usuarios simultáneos: es más común medir la simultaneidad de las operaciones que se ejecutan en la granja de servidores, como el número de usuarios distintos que generan solicitudes en una cantidad de tiempo determinada. Los datos métricos esenciales son el promedio diario y la cantidad de usuarios simultáneos con carga pico. Solicitudes por segundo (RPS): RPS es un indicador que se usa comúnmente para describir la demanda en la granja de servidores expresada según el número de solicitudes que la granja de servidores procesa por segundo, sin distinguir entre el tipo o el tamaño de las solicitudes. La base de usuarios de cada organización genera la carga del sistema a una velocidad que depende de las características de uso únicas de la organización. Vea la sección Glosario en Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server 2010 para obtener más información acerca de este término. Total de solicitudes diarias: el total de solicitudes diarias es un buen indicador de la carga general que deberá administrar el sistema. De manera habitual, se miden todas las solicitudes, salvo las solicitudes de protocolo de enlace de autenticación (estado HTTP 401), durante un período de 24 horas. Total de usuarios diarios: el total de usuarios es otro indicador clave de la carga general que el sistema deberá administrar. Esta medida es el número real de usuarios únicos en un período de 24 horas y no el número total de empleados de la organización. 49

50 Nota: El número total de usuarios diarios puede indicar el potencial de crecimiento de la carga en la granja de servidores. Por ejemplo, si el número de usuarios posibles es de empleados, una cantidad de usuarios diarios significa que la carga puede aumentar considerablemente con el tiempo a medida que aumenta la adopción de usuarios. Distribución de la carga de trabajo: conocer la distribución de las solicitudes en función de las aplicaciones cliente que interactúan con la granja de servidores puede ayudar a predecir la tendencia y los cambios de carga después de migrar a SharePoint Server A medida que los usuarios realicen la transición a versiones de clientes más recientes, como Office 2010, y comiencen a usar los nuevos modelos de carga y las nuevas capacidades, se estima que las RPS y el total de solicitudes aumentarán. Se puede describir el número de usuarios distintos que usan cada cliente en un período de un día y la cantidad total de solicitudes que el cliente o la característica genera en el servidor en cada caso. Por ejemplo, el gráfico siguiente muestra una instantánea de un entorno interno real de Microsoft para una solución social típica. En este ejemplo, se puede ver que la mayor parte de la carga se genera por el rastreador de búsqueda y el uso típico de los exploradores web por parte de los usuarios finales. También se puede observar que la nueva característica de Outlook Social Connector introduce una carga considerable (6,2% de las solicitudes). 50

51 51

52 52

53 Estimación de la carga de trabajo de producción Para calcular el rendimiento que la granja de servidores tendrá que mantener, calcule primero la combinación de transacciones que se usarán en la granja de servidores. Céntrese en analizar las transacciones más frecuentes que el sistema tendrá que atender y en determinar con qué frecuencia se usarán y cuántos usuarios las usarán. Esto le ayudará a validar más adelante si la granja de servidores puede mantener dicha carga en pruebas de preproducción. En el siguiente diagrama se describe la relación entre la carga de trabajo y la carga del sistema: 53

54 54

55 Para calcular la carga de trabajo prevista, recopile la información siguiente: Identifique las interacciones de los usuarios, como por ejemplo, páginas web que suelen visitar, descargas y cargas de archivos, vistas y ediciones de Office Web Application en el explorador, interacciones de co-autoría, sincronizaciones de sitios de SharePoint Workspace, conexiones sociales de Outlook, sincronización de RSS (en Outlook o en otros visores), difusiones de PowerPoint, blocs de notas compartidos de OneNote, libros compartidos de Servicios de Excel, aplicaciones compartidas de Servicios de Access, etc. Vea la sección sobre servicios y características del artículo Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server 2010 para obtener más información. Céntrese en identificar las interacciones que pueden ser únicas para la implementación y determine el impacto previsto de dicha carga; por ejemplo, un uso considerable de formularios de InfoPath, cálculos de Servicios de Excel y soluciones dedicadas similares. Identifique operaciones del sistema, como rastreos incrementales de búsqueda, copias de seguridad diarias, trabajos del temporizador de sincronización de perfiles, procesamiento de Web Analytics, registro de trabajos del temporizador, etc. Calcule el número total de usuarios por día que estima que usarán cada capacidad, derive la cantidad estimada de usuarios simultáneos y de solicitudes de alto nivel por segundo. Deberá plantear algunos supuestos, como la simultaneidad presente y el factor RPS por usuarios simultáneos, que difiere entre las distintas capacidades. Se recomienda usar la tabla de carga de trabajo incluida anteriormente en esta sección para realizar los cálculos. Es importante que se fije en las horas pico, en lugar del rendimiento promedio. Si planea la actividad pico, podrá ajustar correctamente el tamaño de la solución basada en SharePoint Server Si dispone de una solución de Office SharePoint Server 2007, puede extraer los archivos de registro de IIS o recurrir a otras herramientas de supervisión web que tenga para entender mejor algunos de los comportamientos previstos de la solución existente. También puede ver las instrucciones que se proporcionan en la sección siguiente para obtener más detalles. Si no va a migrar de una solución existente, debe rellenar la tabla con estimaciones aproximadas. En los pasos posteriores deberá validar los supuestos planteados y optimizar el sistema. Análisis de los registros de IIS de SharePoint Server 2010 Para obtener datos métricos esenciales acerca de una implementación de SharePoint Server 2010 existente, como cuántos usuarios están activos, con qué intensidad usan el sistema, qué tipo de solicitudes entran y de qué tipo de clientes proceden, es necesario extraer datos de los registros de ULS e IIS. Una de las formas más sencillas de obtener este tipo de datos consiste en usar Log Parser, una eficaz herramienta que se puede descargar de forma gratuita a través de Microsoft. Log Parser puede leer y escribir en una serie de formatos de texto y binarios, incluidos todos los formatos IIS. Para obtener más información acerca de cómo analizar el uso de SharePoint Server 2010 con Log Parser, lea el tema sobre el análisis de uso de Productos y Tecnologías de Microsoft SharePoint ( c3a3-413c-a3f7-2e0be6d5532e&displaylang=en&tm). 55

56 Puede descargar Log Parser 2.2 en F8D975CF8C07&displaylang=en. Conjunto de datos El conjunto de datos describe el volumen de contenido almacenado en el sistema y cómo puede distribuirse en el almacén de datos. En la tabla siguiente se proporcionan algunos datos métricos esenciales que resultan útiles para determinar el conjunto de datos. Puede usar esta tabla para registrar estos datos métricos a medida que los recopila. Objeto Tamaño de la base de datos (en GB) Número de bases de datos de contenido Número de colecciones de sitios Número de aplicaciones web Número de sitios Tamaño de índice de búsqueda (número de elementos) Número de documentos Número de listas Tamaño promedio de los sitios Sitio de mayor tamaño Número de perfiles de usuario Valor Tamaño del contenido: es importante conocer el tamaño del contenido que calcula que se almacenará en el sistema SharePoint Server 2010 para planear y diseñar la arquitectura del almacenamiento de sistema y también para ajustar correctamente el tamaño de la solución de búsqueda que va a rastrear e indizar este contenido. El tamaño del contenido se describe en el espacio total en 56

57 disco. Si va a migrar contenido de una implementación existente, puede que le resulte sencillo identificar el tamaño total que moverá; durante la planeación, debería dejar espacio para el crecimiento a lo largo del tiempo en función de la tendencia prevista. Número total de documentos: aparte del tamaño del cuerpo de datos, es importante realizar un seguimiento del número total de elementos. El sistema reacciona de forma diferente si 100 GB de datos se compone de 50 archivos de 2 GB cada uno, en lugar de archivos de 1 KB cada uno. En las implementaciones de gran tamaño, cuanto menor esfuerzo haya en un solo elemento, documento o área de documentos, mejor será el rendimiento. El contenido que está muy distribuido, como varios archivos pequeños en muchos sitios y la colección de sitios, es más fácil de atender que una única biblioteca de documentos de gran tamaño con archivos muy grandes. Tamaño máximo de la colección de sitios: es importante identificar cuál es la unidad más grande de contenido que se va a almacenar en SharePoint Server 2010; normalmente no se puede dividir esa unidad de contenido debido a una necesidad de la organización. El tamaño promedio de todas las colecciones de sitios y el número total estimado de colecciones de sitios son indicadores adicionales que le ayudarán a identificar cuál es la arquitectura de datos preferida. Características de datos de aplicaciones de servicio: además de analizar las necesidades de almacenamiento del almacén de contenido, deber analizar y calcular los tamaños de otros almacenes de SharePoint Server 2010, incluidos: Tamaño total del índice de búsqueda El tamaño total de base de datos de perfiles en función del número de usuarios en el almacén de perfiles El tamaño total de la base de datos social en función del número esperado de etiquetas, compañeros de trabajo y actividades El tamaño del repositorio de metadatos El tamaño de la base de datos de uso El tamaño de la base de datos de Web Analytics Para obtener más información acerca de cómo calcular los tamaños de las bases de datos, vea Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010). Establecimiento de los objetivos de rendimiento y confiabilidad de la granja de servidores Mediante el Paso 1: Modelo se puede lograr conocer bien los objetivos de rendimiento y confiabilidad más adecuados para las necesidades de la organización. Una solución de SharePoint Server que esté diseñada adecuadamente debe ser capaz de lograr un tiempo de actividad del 99,99% con una capacidad de respuesta del servidor de fracciones de segundos. Los indicadores que se usan para describir el rendimiento y la confiabilidad de la granja de servidores incluyen, entre otros: Disponibilidad del servidor: normalmente, se describe en función del porcentaje de tiempo de actividad general del sistema. Se debe realizar un seguimiento del tiempo de inactividad inesperado y comparar la disponibilidad general con el objetivo de la 57

58 organización que se ha establecido. Los objetivos se describen normalmente mediante una serie de "nueves" (por ejemplo, 99%, 99,9%, 99,99%). Capacidad de respuesta del servidor: el tiempo que tarda la granja de servidores en atender las solicitudes es un buen indicador para realizar un seguimiento del estado de la granja de servidores. Este indicador se denomina normalmente latencia del servidor y es habitual usar el promedio o la mediana (percentil de 50) de latencia de las solicitudes diarias que se atienden. Normalmente, los objetivos se describen en fracciones de segundo o en segundos. Tenga en cuenta que si la organización tiene como objetivo atender páginas de SharePoint Server 2010 en menos de dos segundos, el objetivo del servidor debe ser de fracciones de segundo para dar tiempo a la página a que obtenga acceso al cliente a través de la red y para que se represente en el explorador. También, en general, los tiempos de respuesta del servidor más largos indican que la granja de servidores está en mal estado, ya que esto normalmente afecta al rendimiento y rara vez las RPS pueden mantener el rendimiento si se dedica más de un segundo en el servidor para la mayoría de las solicitudes. Picos del servidor: otro indicador de latencia del servidor adecuado del que vale la pena realizar un seguimiento es el comportamiento del 5% más lento de todas las solicitudes. Las solicitudes más lentas son normalmente las solicitudes que llegan al sistema cuando este se encuentra sometido a una carga más alta o, con más frecuencia, las solicitudes que se ven afectadas por la actividad menos frecuente que se produce mientras los usuarios interactúan con el sistema; un sistema en buen estado es aquel que también tiene bajo control las solicitudes más lentas. En este caso, el objetivo es similar a la capacidad de respuesta del servidor, pero para lograr una respuesta de fracciones de segundo en picos del servidor, deberá incluir en el sistema una gran cantidad de recursos de reserva para controlar los picos de carga. Uso de recursos del sistema: otros indicadores comunes que se usan para realizar un seguimiento del estado del sistema son una colección de contadores del sistema que indican el estado de cada servidor en la topología de la granja de servidores. Los indicadores que se usan con más frecuencia para realizar un seguimiento son el uso porcentual de CPU y la memoria disponible; sin embargo, hay varios contadores adicionales que pueden ayudar a identificar un sistema que no está en buen estado; puede encontrar más detalles en el Paso 5: Supervisión y mantenimiento. Paso 2: Diseño Una vez que se han recopilado algunos datos o cálculos sobre la solución, puede continuar con el paso siguiente que consiste en diseñar una propuesta de arquitectura que pueda mantener la demanda prevista según sus cálculos. Al finalizar este paso, deberá tener un diseño para la topología física y otro para la topología lógica, así que seguramente podrá proseguir con las compras necesarias. 58

59 Las especificaciones de hardware y el número de máquinas que incluya en el diseño están estrechamente relacionados. Para administrar una carga específica se puede elegir entre varias soluciones para implementarlas. Es habitual usar un conjunto pequeño de máquinas eficaces (incremento de la escalabilidad vertical) o bien un conjunto mayor de máquinas más pequeñas (incremento de la escalabilidad horizontal). Cada solución tiene sus ventajas e inconvenientes en cuanto a capacidad, redundancia, eficacia, costo, espacio y otras consideraciones. Se recomienda que para iniciar este paso determine la arquitectura y la topología. Decida cómo tiene previsto diseñar las diferentes granjas de servidores y los distintos servicios en cada granja y, a continuación, elija las especificaciones de hardware para cada uno de los servidores del diseño. Para realizar este proceso, también puede identificar las especificaciones de hardware que espera implementar (muchas organizaciones están limitadas a un determinado estándar de la compañía) y, a continuación, definir la arquitectura y la topología. Use la siguiente tabla para registrar los parámetros de diseño. Los datos que se incluyen son datos de ejemplo y no deben usarse para calcular el tamaño de la granja de servidores, ya que están diseñados para mostrar cómo usar esta tabla con sus propios datos. Rol Tipo (estándar o virtual) Número de máquinas Procedimientos RAM E/S por segundo necesaria Tamaño de disco SO + registro Servidores web Virtual 4 4 núcleos 8 N/A 400 GB N/A Servidor de bases de datos de contenido Estándar 1 clúster 4 procesadores de núcleo cuádruple a 2,33 (GHz) Unidad de datos 48 2k 400 GB 20 discos de 300 GB a RPM Servidores de aplicaciones Virtual 4 4 núcleos 16 N/A 400 GB N/A Servidor web de destino de rastreo de búsqueda Virtual 1 4 núcleos 8 N/A 400 GB N/A Servidor de consultas de Estándar 2 2 procesadores de 32 N/A 400 GB 500 GB núcleo cuádruple a 59

60 Rol Tipo (estándar o virtual) Número de máquinas búsqueda Servidor de rastreador de búsqueda Servidor de bases de datos de rastreo de búsqueda Base de datos de almacén de propiedades de búsqueda + Servidor de bases de datos de administración Procedimientos 2,33 (GHz) Estándar 2 2 procesadores de núcleo cuádruple a 2,33 (GHz) Estándar 1 clúster 4 procesadores de núcleo cuádruple a 2,33 (GHz) Estándar 1 clúster 4 procesadores de núcleo cuádruple a 2,33 (GHz) RAM E/S por segundo necesaria Tamaño de disco SO + registro GB N/A Unidad de datos 48 4 k (optimizado 100 GB 16 para lectura) discos de 150 GB a RPM 48 2 k (optimizado 100 GB 16 para escritura) discos de 150 GB a RPM Determinación de la arquitectura inicial En esta sección se describe cómo seleccionar una arquitectura inicial. Cuando implemente SharePoint Server 2010, puede elegir entre una amplia gama de topologías para implementar la solución. Puede implementar un solo servidor o incrementar la escalabilidad horizontal de muchos servidores a una granja de servidores de SharePoint Server con servidores de bases de datos en clúster o reflejados y servidores de aplicaciones discretos para varios servicios. Después, puede seleccionar las configuraciones de hardware en función de los requisitos de cada uno de los roles, según sus necesidades de capacidad, disponibilidad y redundancia. 60

61 Comience por revisar las diferentes arquitecturas de referencia y determine la estructura de la granja de servidores. Decida si debe dividir la solución en varias granjas de servidores, o federar algunos servicios, como la búsqueda, en una granja de servidores dedicada. Vea la sección sobre arquitectura de referencia en Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server 2010 para obtener más información. Casos prácticos técnicos de SharePoint Server 2010 Las directrices de administración de la capacidad de SharePoint Server 2010 contienen una serie de casos prácticos técnicos de los entornos de producción existentes que presentan una descripción detallada de los entornos de producción actuales basados en SharePoint Server. Más adelante se publicarán más casos prácticos técnicos para que sirvan de referencia sobre cómo diseñar un entorno basado en SharePoint Server con fines específicos. Puede usar estos casos prácticos como una referencia al diseñar la arquitectura de las soluciones de SharePoint Server, especialmente si encuentra la descripción de estos factores diferenciadores clave específicos de la implementación similares a las demandas y objetivos de la arquitectura de la solución que está diseñando. En estos documentos se proporciona la información siguiente para cada caso práctico documentado: Especificaciones, como hardware, topología de la granja de servidores y configuración; Carga de trabajo, incluida la base de usuarios y las características de uso; Conjunto de datos, incluidos los tamaños del contenido, las características del contenido y la distribución del contenido; Mantenimiento y rendimiento, incluido un conjunto de indicadores registrados que describen las características de confiabilidad y rendimiento de la granja de servidores. Para obtener más información, descargue los documentos relevantes de la página sobre casos prácticos técnicos de rendimiento y capacidad ( Selección del hardware La selección de las especificaciones adecuadas para las máquinas de la granja de servidores es un paso esencial para garantizar la confiabilidad y el rendimiento adecuados de la implementación. Unas de las consideraciones clave es que debe realizar la planeación teniendo en cuenta el pico de carga y las horas pico; es decir, cuando la granja de servidores está funcionando en condiciones de carga media, debería haber suficientes recursos disponibles para controlar la máxima demanda esperada y, al mismo tiempo, cumplir con los objetivos de latencia y rendimiento. Las características principales del hardware de capacidad y rendimiento de los servidores reflejan cuatro categorías principales: potencia de procesamiento, rendimiento del disco, capacidad de la red y capacidades de memoria de un sistema. 61

62 Otro aspecto que se debe tener en cuenta es el uso de máquinas virtualizadas. Una granja de servidores de SharePoint Server se puede implementar mediante máquinas virtuales. Aunque no se haya comprobado que esto proporcione más beneficios de rendimiento, sí proporciona beneficios de capacidad de administración. Por lo general, no se recomienda la virtualización de equipos basados en SQL Server, pero puede haber ciertos beneficios en la virtualización de los niveles de servidores web y servidores de aplicaciones. Para obtener más información, vea el tema sobre la planeación de la virtualización ( Instrucciones para la selección del hardware Elección de procesadores SharePoint Server 2010 solo está disponible para procesadores de 64 bits. Normalmente, un número mayor de procesadores le permitirá atender una mayor demanda. En SharePoint Server 2010, a medida que se agregan más núcleos (hemos probado hasta 24 núcleos) se incrementará la escalabilidad de los servidores web individuales; cuantos más núcleos tenga el servidor, más carga podrá mantener, considerando que todas las demás características sean las mismas. En grandes implementaciones de SharePoint Server, se recomienda asignar varios servidores web de 4 núcleos (que se pueden virtualizar) o menos servidores web más eficaces (de 8, 16 ó 24 núcleos). Los requisitos de capacidad del procesador de los servidores de aplicaciones varían según el rol del servidor y los servicios que ejecuta. Algunas características de SharePoint Server exigen mayor potencia de procesamiento que otras. Por ejemplo, el servicio de búsqueda de SharePoint es sumamente dependiente de la capacidad de procesamiento del servidor de aplicaciones. Para obtener más información acerca de los requisitos de recursos de las características y servicios de SharePoint Server, vea el tema sobre servicios y características anteriormente en este documento. Los requisitos de capacidad de procesador para SQL Server también dependen de las bases de datos de servicio que hospeda un equipo basado en SQL Server. Para obtener más información acerca del comportamiento típico y los requisitos de cada base de datos, vea Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010). Elección de la memoria Los servidores requieren distintas cantidades de memoria, según la función de servidor y su rol. Por ejemplo, los servidores que ejecutan los componentes de rastreo de búsqueda procesan datos con más rapidez si tienen una gran cantidad de memoria debido a que los documentos se leen en la memoria para su procesamiento. Los servidores web que aprovechan muchas de las características de almacenamiento en caché de SharePoint Server 2010 pueden requerir más memoria también. En general, los requisitos de memoria del servidor web dependen considerablemente del número de grupos de aplicaciones habilitadas en la granja de servidores y del número de solicitudes simultáneas que se atienden. En la mayoría de las implementaciones de SharePoint Server de producción, se recomienda asignar al menos 8 GB de RAM a cada servidor web y 16 GB en el caso de servidores con más tráfico o implementaciones con varios grupos de aplicaciones configurados para su aislamiento. 62

63 Los requisitos de memoria de los servidores de aplicaciones también son diferentes; algunas características de SharePoint Server requieren más memoria en el nivel de aplicaciones que otras. En la mayoría de las implementaciones de SharePoint Server en producción se recomienda asignar al menos 8 GB de RAM a cada servidor de aplicaciones; los servidores de aplicaciones de 16 GB, 32 GB y 64 GB son comunes cuando se habilitan muchos servicios de aplicaciones en el mismo servidor, o cuando se habilitan servicios que dependen en gran medida de la memoria, como el Servicio de cálculo de Excel y el Servicio de búsqueda de SharePoint Server. Los requisitos de memoria de los servidores de bases de datos son muy dependientes de los tamaños de las bases de datos. Para obtener más información acerca de la elección de la memoria para los equipos basados en SQL Server, vea Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010). Elección de las redes Además del beneficio que ofrecen a los usuarios los clientes que tienen acceso rápido a los datos a través de la red, una granja de servidores distribuida debe tener acceso rápido para la comunicación entre servidores, especialmente al distribuir los servicios entre varios servidores o al federar algunos de los servicios a otras granjas de servidores. Hay un tráfico considerable en una granja de servidores en el nivel de los servidores web, el nivel de los servidores de aplicaciones y el nivel de los servidores de bases de datos, y la red puede convertirse fácilmente en un cuello de botella en determinadas situaciones, por ejemplo al trabajar con archivos muy grandes o con cargas muy altas. Los servidores web y los servidores de aplicaciones deben configurarse con al menos dos tarjetas de interfaz de red (NIC): una NIC para controlar el tráfico de usuarios finales y la otra para controlar la comunicación entre servidores. La latencia de red entre los servidores puede tener un impacto significativo en el rendimiento, por lo que es importante mantener menos de 1 milisegundo de latencia de red entre el servidor web y los equipos basados en SQL Server que hospedan las bases de datos de contenido. Los equipos basados en SQL Server que hospedan cada base de datos de la aplicación de servicio deben estar lo más cerca posible del servidor de aplicaciones de consumo también. La red entre los servidores de la granja de servidores debe tener al menos de 1 Gbps de ancho de banda. Elección de los discos y el almacenamiento La administración de discos no consiste solamente en proporcionar espacio suficiente para los datos. Debe evaluar la demanda y el crecimiento continuo y asegurarse de que la arquitectura de almacenamiento no ralentiza el sistema. Siempre debe asegurarse de que tiene al menos un 30% de capacidad adicional en cada disco, por encima de la estimación de requisitos de datos más alta, para permitir el crecimiento futuro. Además, en la mayoría de los entornos de producción, la velocidad de disco (E/S por segundo) es crucial para proporcionar suficiente rendimiento para satisfacer las exigencias de almacenamiento de los servidores. Debe estimar la cantidad de tráfico (E/S por segundo) que requerirán las bases de datos principales en la implementación y asignar suficientes discos para satisfacer ese tráfico. Para obtener más información acerca de cómo elegir los discos para los servidores de bases de datos, vea Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010). 63

64 Los servidores web y los servidores de aplicaciones también tienen requisitos de almacenamiento. En la mayoría de los entornos de producción, se recomienda asignar al menos 200 GB de espacio en disco para el sistema operativo y archivos temporales, y 150 GB de espacio en disco para los registros. Paso 3: Piloto, prueba y optimización La fase de pruebas y optimización es un componente esencial de la administración eficaz de la capacidad. Debe probar las arquitecturas nuevas antes de implementarlas en producción y llevar a cabo pruebas de aceptación junto con los siguientes procedimientos recomendados de supervisión para garantizar que las arquitecturas que diseñe alcancen los objetivos de rendimiento y capacidad. Esto permite identificar y optimizar los posibles cuellos de botella antes de que afecten a los usuarios en una implementación real. Si realiza una actualización de un entorno de Office SharePoint Server 2007 y planea realizar modificaciones en la arquitectura, o si está calculando la carga de usuarios de las nuevas características de SharePoint Server, es especialmente importante realizar pruebas para garantizar que el nuevo entorno basado en SharePoint Server cumpla con los objetivos de rendimiento y capacidad. Una vez que haya probado el entorno, puede analizar los resultados de las pruebas para determinar qué cambios deben realizarse para alcanzar los objetivos de rendimiento y capacidad que estableció en el Paso 1: Modelo. Estos son los pasos secundarios recomendados que se deben seguir para la preproducción: Cree el entorno de prueba de modo que imite la arquitectura inicial que diseñó en el Paso 2: Diseño. Llene el almacenamiento con el conjunto de datos o con la parte del conjunto de datos que identificó en el Paso 1: Modelo. Fuerce el sistema con una carga sintética que represente la carga de trabajo que identificó en el Paso 1: Modelo. Ejecute pruebas, analice los resultados y optimice la arquitectura. Implemente la arquitectura optimizada en el centro de datos y lleve a cabo una prueba piloto con un grupo más pequeño de usuarios. Analice los resultados de la prueba piloto, identifique los posibles cuellos de botella y optimice la arquitectura. Vuelva a realizar la prueba si es necesario. Realice la implementación en el entorno de producción. Prueba Las pruebas son un factor esencial para determinar si el diseño del sistema es capaz de admitir la carga de trabajo y las características de uso. Vea Pruebas de rendimiento para SharePoint Server 2010 para obtener más información acerca de cómo probar la implementación de SharePoint Server Creación de un plan de pruebas 64

65 Creación del entorno de prueba Creación de pruebas y herramientas Implementación del entorno piloto Antes de implementar SharePoint Server 2010 en un entorno de producción, es importante que implemente primero un entorno piloto y pruebe minuciosamente la granja de servidores para asegurarse de que puede cumplir con los objetivos de capacidad y rendimiento para la carga máxima esperada. En primer lugar, se recomienda probar el entorno piloto con una carga sintética, especialmente en las implementaciones de gran tamaño, y, a continuación, someterlo al esfuerzo de un pequeño conjunto de usuarios activos y contenido en directo. La ventaja de analizar un entorno piloto con un pequeño grupo de usuarios en directo es la oportunidad de validar algunos de los supuestos planteados acerca de las características de uso y el crecimiento del contenido antes de usarlo plenamente en el entorno de producción. Optimización Si no puede cumplir con los objetivos de rendimiento y capacidad mediante el incremento de la escalabilidad del hardware de la granja de servidores o cambios en la topología, es posible que deba revisar la solución. Por ejemplo, si sus requisitos iniciales fueron para una sola granja de servidores para colaboración, búsqueda y social, es posible que deba federar algunos de los servicios, como búsqueda, a una granja de servidores de servicios dedicados, o dividir la carga de trabajo entre más granjas de servidores. Una alternativa consiste en implementar una granja de servidores dedicada para la actividad social y otra para la colaboración en equipo. Paso 4: Implementación Una vez que haya ejecutado la ronda final de pruebas y comprobado que la arquitectura que se ha seleccionado puede alcanzar los objetivos de rendimiento y capacidad que estableció en el Paso 1: Modelo, puede implementar el entorno basado en SharePoint Server 2010 en un entorno de producción. La estrategia de implementación apropiada variará en función del entorno y la situación. Si bien por lo general la implementación de SharePoint Server está fuera del alcance de este documento, el ejercicio de planeación de la capacidad puede plantear ciertas actividades sugeridas. A continuación se describen algunos ejemplos: Implementación de una nueva granja de servidores de SharePoint Server: el ejercicio de planeación de la capacidad debería haber guiado y confirmado los planes para el diseño y la implementación de SharePoint Server En este caso, la implementación será la primera implementación amplia de SharePoint Server Habrá que mover o volver a generar los servidores y servicios que se usaron durante los ejercicios de planeación de la capacidad en el entorno de producción. Este es el escenario más sencillo ya que no es necesario realizar actualizaciones ni modificaciones en una granja de servidores existente. 65

66 Actualización de una granja de servidores de Office SharePoint Server 2007 a SharePoint Server 2010: el ejercicio de planeación de la capacidad debería haber validado el diseño de una granja de servidores capaz de satisfacer las demandas existentes e incrementar la escalabilidad vertical para satisfacer la creciente demanda y el uso de una granja de servidores de SharePoint Server Parte del ejercicio de planeación de la capacidad debería haber incluido migraciones de prueba para validar el tiempo que llevará el proceso de actualización, si es necesario modificar o reemplazar código personalizado, si las herramientas de terceros necesitan actualizarse, etc. Al finalizar la planeación de la capacidad, debería tener un diseño validado y una idea de cuánto tiempo llevará la actualización, así como un plan para implementar el proceso de actualización de forma óptima, por ejemplo, una actualización en contexto, o la migración de las bases de datos de contenido a una nueva granja de servidores. Si realiza una actualización en contexto, durante la planeación de la capacidad es posible que haya descubierto que necesitará hardware adicional o actualizado y que deberá tener en cuenta el tiempo de inactividad. Parte del resultado del ejercicio de planeación debería ser una lista de los cambios de hardware necesarios y un plan detallado para la implementación de los cambios de hardware en la granja de servidores. Una vez implementada la plataforma de hardware que se validó durante la planeación de la capacidad, puede continuar con el proceso de actualización a SharePoint Server Mejora del rendimiento de una granja de servidores de SharePoint Server 2010 existente: el ejercicio de planeación de la capacidad debería haberle ayudado a identificar los cuellos de botella de la implementación actual, diseñar formas de reducir o eliminar dichos cuellos de botellas y validar una implementación mejorada que cubra sus necesidades empresariales de servicios de SharePoint Server. Se han mostrado distintas formas de resolver los problemas de rendimiento, desde algo tan simple como reasignar los servicios entre el hardware existente, actualizar el hardware existente o agregar hardware adicional y agregarle servicios adicionales. Los diferentes enfoques deben probarse y validarse durante el ejercicio de planeación de la capacidad y, a continuación, debe formularse un plan de implementación según los resultados de las pruebas. Paso 5: Supervisión y mantenimiento Para mantener el rendimiento del sistema, debe supervisar el servidor para identificar los posibles cuellos de botella. Para poder supervisarlo de forma eficaz, debe conocer los indicadores clave que indican si una parte específica de la granja de servidores requiere atención y saber cómo interpretar dichos indicadores. Si comprueba que la granja de servidores está funcionando fuera de los objetivos que ha definido, puede ajustarla al agregar o quitar recursos de hardware, modificar la topología o cambiar la forma en que se almacenan los datos. Vea Supervisión y mantenimiento de SharePoint Server 2010 para obtener una lista de las opciones de configuración que se pueden modificar para supervisar el entorno en sus primeras etapas, lo que le ayudará a determinar si es necesario realizar cambios. Tenga en cuenta que al aumentar las capacidades de supervisión, se verá afectada la cantidad de espacio en disco que requiere la base de datos 66

67 de uso. Una vez que el entorno sea estable y esta supervisión detallada ya no sea necesaria, se aconseja revertir la configuración a los valores predeterminados. Para obtener más información acerca de cómo supervisar el estado y solucionar problemas usando las herramientas de seguimiento de estado integradas en la interfaz de Administración central de SharePoint Server, lea los siguientes temas: Health Monitoring (SharePoint Server 2010) Solución de problemas ( Vea también Conceptos Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server 2010 Pruebas de rendimiento para SharePoint Server 2010 Supervisión y mantenimiento de SharePoint Server 2010 Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010) Otros recursos Health Monitoring (SharePoint Server 2010) 67

68 Pruebas de rendimiento para SharePoint Server 2010 En este artículo se describe cómo probar el rendimiento de Microsoft SharePoint Server La fase de prueba y optimización es un componente esencial de la administración eficaz de la capacidad. Se recomienda probar las arquitecturas nuevas antes de implementarlas en producción y llevar a cabo pruebas de aceptación junto con los siguientes procedimientos recomendados de supervisión para garantizar que las arquitecturas que se diseñen alcancen los objetivos de rendimiento y capacidad. Esto permite identificar y optimizar los posibles cuellos de botella antes de que afecten a los usuarios en un entorno real. Si realiza una actualización desde un entorno de Microsoft Office SharePoint Server 2007 y planea efectuar cambios en la arquitectura, o si está estimando la carga de usuarios de las nuevas características de SharePoint Server 2010, las pruebas son especialmente importantes para garantizar que el nuevo entorno basado en SharePoint Server 2010 cumpla con los objetivos de rendimiento y capacidad. Una vez que haya probado el entorno, puede analizar los resultados de las pruebas para determinar qué cambios debe realizar para alcanzar los objetivos de rendimiento y capacidad que estableció en el Paso 1: Modelo de Planeación de la capacidad para SharePoint Server Estos son los pasos secundarios recomendados que se deben seguir para la preproducción: Cree el entorno de prueba de modo que imite la arquitectura inicial que diseñó en Paso 2: Diseño. Rellene el almacenamiento con el conjunto de datos o con la parte del conjunto de datos que identificó en Paso 1: Modelo. Fuerce el sistema con una carga sintética que represente la carga de trabajo que identificó en Paso 1: Modelo. Ejecute pruebas, analice los resultados y optimice la arquitectura. Implemente la arquitectura optimizada en el centro de datos y lleve a cabo un piloto con un grupo más pequeño de usuarios. Analice los resultados del piloto, identifique los posibles cuellos de botella y optimice la arquitectura. Vuelva a realizar la prueba si es necesario. Implemente en el entorno de producción. Antes de leer este artículo, debe leer Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server En este artículo: Creación de un plan de pruebas 68

69 Creación del entorno de prueba Creación de pruebas y herramientas Creación de un plan de pruebas Compruebe que el plan incluye: Hardware que esté diseñado para funcionar según los objetivos de rendimiento de producción previstos. Siempre mida el rendimiento de los sistemas de prueba de forma conservadora. Si dispone de código personalizado o de un componente personalizado, es importante que primero pruebe el rendimiento de estos componentes por separado para validar su rendimiento y estabilidad. Una vez comprobada su estabilidad, es conviene probar el sistema con dichos componentes instalados y comparar el rendimiento con el conjunto o granja de servidores sin instalarlos. Los componentes personalizados suelen ser una causa importante de problemas de rendimiento y confiabilidad en los sistemas de producción. Conozca el objetivo de la prueba. Asegúrese de entender cuáles son los objetivos de la prueba antes de realizarla. Se trata de validar el rendimiento de componentes personalizados nuevos que se desarrollaron para la granja de servidores? Se trata de ver cuánto tiempo llevará rastrear e indizar un conjunto de contenido? Se trata de determinar cuántas solicitudes por segundo puede admitir la granja de servidores? Una prueba puede tener muchos objetivos diferentes y el primer paso para desarrollar un plan de pruebas adecuado consiste en decidir cuáles serán los objetivos. Entienda cómo se mide el objetivo de las pruebas. Si está interesado en medir la capacidad de proceso de la granja de servidores por ejemplo, le conviene medir las solicitudes por segundo y la latencia de página. Si va a medir el rendimiento de búsqueda, le conviene medir el tiempo de rastreo y las tasas de indización de documentos. Entender bien el objetivo de la prueba le ayudará a definir claramente los indicadores clave de rendimiento que necesita validar para llevarla a cabo. Creación del entorno de prueba Una vez que haya decidido cuáles son los objetivos de la prueba y definido las medidas, y después de establecer cuáles son los requisitos de capacidad de la granja de servidores (en los pasos 1 y 2 de este proceso), el siguiente objetivo es diseñar y crear el entorno de prueba. A menudo se subestima el esfuerzo necesario para crear un entorno de prueba. Debería intentar reproducir el entorno de producción con la mayor fidelidad posible. Algunas de las características y funcionalidad que debería tener en cuenta al diseñar el entorno de prueba son: 69

70 Autenticación: decida si la granja de servidores usará Servicios de dominio de Active Directory (AD DS), autenticación basada en formularios (y, en ese caso, con qué directorio), autenticación basada en notificaciones, etc. Independientemente del directorio que use, cuántos usuarios necesita en el entorno de prueba y cómo va a crearlos? Cuántos grupos o roles va a necesitar y cómo los creará y rellenará? También deberá asegurarse de que tiene suficientes recursos asignados a los servicios de autenticación para que no produzcan un cuello de botella durante la prueba. DNS: sepa qué espacios de nombres necesitará durante las pruebas. Identifique qué servidores responderán a dichas solicitudes y asegúrese de contar con un plan que especifique las direcciones IP que usará cada servidor y qué entradas de DNS deberá crear. Equilibrio de carga: si usa más de un servidor (lo cual es normal ya que de lo contrario no tendría suficiente carga para justificar una prueba de carga), necesitará algún tipo de solución de equilibrio de carga. Podría usar un hardware de equilibrio de carga, o bien algún software de equilibrio de carga, como Windows NLB. Decida qué usará y escriba toda la información de configuración que necesitará para configurar la solución con rapidez y eficacia. Otro punto que debe recordar es que los agentes de prueba de carga normalmente intentan resolver una dirección URL una sola vez cada 30 minutos. Esto significa que no le conviene usar un archivo de hosts local ni round robin DNS para equilibrar la carga ya que es probable que los agentes de prueba terminen recurriendo al mismo servidor para cada solicitud, en vez de equilibrar la carga entre todos los servidores disponibles. Servidores de prueba: cuando planee el entorno de prueba, no solo deberá planear los servidores para la granja de servidores de SharePoint Server 2010 sino también las máquinas necesarias para ejecutar las pruebas. Por lo general, necesitará como mínimo tres servidores, aunque en algunos casos pueden necesitarse más. Si usa Visual Studio Team System (Team Test Load Agent) para realizar las pruebas, una máquina se usará como controlador de prueba de carga. Por lo general, se usan dos o más máquinas como agentes de prueba de carga. Los agentes son las máquinas que reciben las instrucciones del controlador de prueba sobre qué probar y emiten las solicitudes a la granja de servidores de SharePoint Server Los resultados de las pruebas se almacenan en un equipo basado en SQL Server. No le conviene usar el mismo equipo basado en SQL Server que usa para la granja de servidores de SharePoint Server 2010, ya que la escritura de los datos de prueba sesgará los recursos de SQL Server disponibles para la granja de servidores de SharePoint Server También debe supervisar los servidores de prueba durante su ejecución de la misma forma en que supervisaría los servidores de la granja de servidores de SharePoint Server 2010 o los controladores de dominio, etc. para asegurarse de que los resultados de las pruebas son representativos de la granja de servidores que está configurando. En algunos casos, los agentes de carga o el controlador pueden convertirse en cuellos de botella. En ese caso, la capacidad de proceso que se observa en la prueba normalmente no es la capacidad de proceso máxima que puede admitir la granja de servidores. SQL Server: en el entorno de prueba, siga las recomendaciones de las secciones "Configuración de SQL Server" y "Validación y supervisión del almacenamiento y el rendimiento de SQL Server" del artículo Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010). 70

71 Validación de conjuntos de datos: al decidir qué contenido va a someter a prueba, recuerde que en el mejor de los casos usará datos de un sistema de producción existente. Por ejemplo, puede hacer una copia de seguridad de las bases de datos de contenido de una granja de servidores de producción y restaurarlas en el entorno de prueba y, a continuación, adjuntar las bases de datos para llevar el contenido a la granja de servidores. Cada vez que ejecute pruebas con datos inventados o de ejemplo, corre el riesgo de que los resultados sean sesgados a causa de las diferencias en el cuerpo de contenido. Si debe crear datos de ejemplo, hay algunas consideraciones que debe tener en cuenta para crear dicho contenido: Se deben publicar todas las páginas; no debe desprotegerse nada. La navegación debe ser realista; no cree más que lo que espera usar razonablemente en producción. Debe tener una idea de las personalizaciones que usará el sitio de producción. Por ejemplo, las páginas maestras, las hojas de estilos, JavaScript, etc. deben implementarse en el entorno de prueba de la forma más parecida posible al entorno de producción. Determine cuántos grupos de SharePoint y niveles de permisos va a necesitar y cómo va a asociar a los usuarios con ellos. Averigüe si necesitará importar perfiles y cuánto tiempo llevará el proceso. Determine si va a necesitar audiencias y cómo va a crearlas y rellenarlas. Determine si necesita orígenes de contenido de búsqueda adicionales y qué necesitará para crearlos. Si no necesitará crear ninguno, determine si tendrá acceso a la red para poder rastrearlos. Determine si dispone de suficientes datos de ejemplo: documentos, listas, elementos de lista, etc. Si no es así, cree un plan que especifique el modo en que creará este contenido. Tenga un plan para contar con suficiente contenido único para probar la búsqueda correctamente. Un error habitual es cargar el mismo documento (cientos o incluso miles de veces) a distintas bibliotecas de documentos con nombres diferentes. Esto puede afectar al rendimiento de búsqueda ya que el procesador de consultas pasará una cierta cantidad de tiempo detectando duplicados, lo cual no haría en un entorno de producción con contenido real. Creación de pruebas y herramientas Después de comprobar el funcionamiento del entorno de prueba, es momento de crear y ajustar las pruebas que se usarán para medir la capacidad de rendimiento de la granja de servidores. En esta sección a veces se hará referencia específicamente a Visual Studio Team System (Team Test Load Agent), pero muchos de los conceptos son aplicables a cualquier herramienta de prueba de carga que se use. Para obtener información acerca de Visual Studio Team System, vea el tema sobre Visual Studio Team System en MSDN ( 71

72 También puede usar el Kit de pruebas de carga de SharePoint (LTK) junto con VSTS para realizar las pruebas de carga de las granjas de servidores de SharePoint El Kit de pruebas de carga genera una prueba de carga de Visual Studio Team System 2008 basada en Windows SharePoint Services 3.0 y registros IIS de Microsoft Office SharePoint Server La prueba de carga de VSTS se puede usar para generar carga sintética respecto de SharePoint Foundation 2010 o SharePoint Server 2010 como parte de un ejercicio de planeación de capacidad o de una prueba de esfuerzo previa a la actualización. El Kit de pruebas de carga se incluye en el kit de herramientas de administración Microsoft SharePoint 2010 Administration Toolkit v1.0, disponible en el Centro de descarga de Microsoft ( 81c3-c9c3d84c456e&displaylang=en). Un criterio clave para el éxito de las pruebas es poder simular de forma eficaz una carga de trabajo realista generando solicitudes para una amplia gama de los datos del sitio de prueba, de la misma forma en que los usuarios tendrían acceso a una amplia gama de contenido en una granja de servidores de SharePoint Server 2010 de producción. Para ello, normalmente deberá crear las pruebas de forma tal que sean controladas por datos. En vez de crear cientos de pruebas individuales codificadas de forma rígida para obtener acceso a una página específica, debe usar tan solo unas pocas pruebas que usen orígenes de datos que contengan las direcciones URL de dichos elementos para obtener acceso dinámico a ese conjunto de páginas. En Visual Studio Team System (Team Test Load Agent), un origen de datos puede proceder de una gran variedad de formatos, pero a menudo es más fácil administrar y transportar un formato de archivo CSV entre los entornos de desarrollo y de prueba. Tenga en cuenta que la creación de archivos CSV con dicho contenido puede requerir la creación de herramientas personalizadas para enumerar el entorno basado en SharePoint Server 2010 y registrar las distintas direcciones URL que se usan. Es posible que deba usar herramientas para realizar tareas como las siguientes: Crear usuarios y grupos en Active Directory u otro almacén de autenticación si usa autenticación basada en formularios Enumerar las direcciones URL de sitios, listas y bibliotecas, elementos de lista, documentos, etc. y colocarlos en archivos CSV para las pruebas de carga Cargar documentos de ejemplo en una gran variedad de bibliotecas de documentos y sitios Crear colecciones de sitios, sitios web, listas, bibliotecas, carpetas y elementos de lista Crear Mis sitios Crear archivos CSV con nombres de usuario y contraseñas para usuarios de prueba; éstas son las cuentas de usuario con las que se ejecutarán las pruebas de carga. Debe haber varios archivos de forma tal que, por ejemplo, algunos contengan solo los usuarios administradores, algunos contengan otros usuarios con privilegios elevados (como autor o colaborador, administrador de jerarquía, etc.), y otros contengan solo lectores, etc. Crear una lista de frases y palabras clave de búsqueda de ejemplo 72

73 Rellenar los grupos y niveles de permisos de SharePoint con usuarios y grupos de Active Directory (o roles si usa autenticación basada en formularios) Al crear pruebas web, existen otros procedimientos recomendados que debería observar e implementar, como por ejemplo: Registre pruebas web simples para empezar. Estas pruebas contendrán valores codificados de forma rígida para parámetros como dirección URL, identificador, etc. Reemplace los valores codificados de forma rígida con vínculos de los archivos CSV. Enlazar los datos de dichos valores en Visual Studio Team System (Team Test Load Agent) es muy sencillo. Siempre tenga reglas de validación para la prueba. Por ejemplo, cuando solicite una página, si se produce un error, normalmente obtendrá la página error.aspx como respuesta. Desde la perspectiva de una prueba web aparece como si fuera una respuesta positiva más, ya que obtendrá un código de estado HTTP 200 (correcto) en la carga de los resultados de pruebas. Pero obviamente se ha producido un error, por lo que debería seguirse de manera diferente. Crear una o varias reglas de validación permite interceptar cuando cierto texto se envía como respuesta de forma tal que la validación produzca un error y la solicitud se marque como error también. Por ejemplo, en Visual Studio Team System (Team Test Load Agent), una regla de validación simple podría ser una validación ResponseUrl, que registra un error si la página que se representa después de los redireccionamientos no es la misma página de respuesta que se registró en la prueba. También puede agregar una regla de FindText que registre un error si encuentra la palabra "acceso denegado", por ejemplo, en la respuesta. Use varios usuarios en distintos roles en las pruebas. Algunos comportamientos, como el almacenamiento en caché de los resultados, funcionan de forma diferente según los derechos del usuario actual. Por ejemplo, un administrador de una colección de sitios o un usuario autenticado con derechos de aprobación o de creación no obtendrán resultados almacenados en caché ya que siempre deseamos que vean la versión más reciente del contenido. Sin embargo, los usuarios anónimos obtendrán el contenido almacenado en caché. Debe asegurarse de que los usuarios de prueba representen una combinación de estos roles que coincida aproximadamente con la combinación de usuarios en el entorno de producción. Por ejemplo, en producción hay probablemente solo dos o tres administradores de colecciones de sitios, por lo que no es aconsejable crear pruebas en las que el 10% de las solicitudes de páginas son realizadas por cuentas de usuarios que son administradores de colecciones de sitios sobre el contenido de la prueba. El análisis de las solicitudes dependientes es un atributo de Visual Studio Team System (Team Test Load Agent) que determina si el agente de prueba debería intentar recuperar solo la página, o la página y todas las solicitudes asociadas que forman parte de la página, como imágenes, hojas de estilos, scripts, etc. Durante una prueba de carga, estos elementos se suelen ignorar por varias razones: Cuando un usuario visita un sitio por primera vez, el explorador local suele almacenar estos elementos en la memoria caché 73

74 Normalmente, estos elementos no proceden de SQL Server en un entorno basado en SharePoint Server Si el almacenamiento en caché BLOB está activado, estos elementos son procesados por los servidores web, por lo que no generan carga para SQL Server. Si tiene regularmente un alto porcentaje de usuarios nuevos en el sitio, o si ha deshabilitado el almacenamiento en caché del explorador, o si por alguna razón no va a usar la memoria caché BLOB, entonces podría convenirle habilitar el análisis de solicitudes dependientes en las pruebas. Sin embargo, esto es realmente una excepción y no la regla general para la mayoría de las implementaciones. Tenga en cuenta que si se activa, puede inflar significativamente los números de RPS notificados por el controlador de prueba. Estas solicitudes se atienden tan rápidamente que pueden inducirle a pensar de forma errónea que hay más capacidad disponible en la granja de servidores que la que hay realmente. Recuerde modelar la actividad de las aplicaciones cliente también. Las aplicaciones cliente, como Microsoft Word, PowerPoint, Excel y Outlook, generan solicitudes a granjas de servidores de SharePoint Server 2010 también. Agregan carga al entorno enviando a los servidores solicitudes tales como recuperar fuentes RSS, adquirir información social, solicitar detalles sobre la estructura de sitios y listas, sincronizar datos, etc. Estos tipos de solicitudes deben incluirse y modelarse si tiene estos clientes en su implementación. En la mayoría de los casos, una prueba web debe contener una única solicitud. Es más fácil ajustar y solucionar los problemas del arnés de prueba y las solicitudes individuales si la prueba contiene una sola solicitud. Normalmente, las pruebas web deben contener varias solicitudes si la operación que está simulando se compone de varias solicitudes. Por ejemplo, para probar este conjunto de acciones necesitará una prueba con varios pasos: desproteger un documento, editarlo, protegerlo y publicarlo. También requiere la reserva de estado entre los pasos, por ejemplo, se debe usar la misma cuenta de usuario para desprotegerlo, realizar las modificaciones y volver a protegerlo. Estas operaciones de varios pasos que requieren transportar el estado de un paso al otro se atienden mejor mediante varias solicitudes en una sola prueba web. Pruebe cada prueba web de forma individual. Asegúrese de que cada prueba puede completarse correctamente antes de ejecutarla en una prueba de carga más grande. Compruebe que todos los nombres de las aplicaciones web se resuelven y que las cuentas de usuario que se usan en la prueba tienen derechos suficientes para ejecutar la prueba. Las pruebas web incluyen las solicitudes de páginas individuales, carga de documentos, visualización de elementos de lista, etc. Todo esto se combina en las pruebas de carga. Una prueba de carga es donde se conectan las diferentes pruebas web que se van a ejecutar. A cada prueba web se le puede dar un porcentaje de tiempo para ejecutarse, por ejemplo, si comprueba que el 10% de las solicitudes de una granja de servidores de producción son consultas de búsqueda, entonces en la prueba de carga debería configurar una prueba web de consulta que se ejecute el 10% del tiempo. En Visual Studio Team System (Team Test Load Agent), las pruebas de carga son también la forma en que se configuran elementos como la combinación de exploradores, la combinación de redes, los modelos de carga y la configuración de ejecución. Hay algunos procedimientos adicionales que debería tener en cuenta e implementar para las pruebas de carga: 74

75 Use una proporción de lectura y escritura razonable en las pruebas. Si se sobrecarga el número de escrituras en una prueba, puede verse considerablemente afectada la capacidad de proceso general. Incluso en granjas de servidores de colaboración, las proporciones de lectura y escritura suelen incluir muchas más lecturas que escrituras. Para obtener más información, vea la página sobre casos técnicos prácticos de rendimiento y capacidad ( Tenga en cuenta el impacto de otras operaciones con uso intensivo de recursos y decida si deberían estar realizándose durante la prueba de carga. Por ejemplo, operaciones como la copia de seguridad y restauración no se realizan normalmente durante una prueba de carga. Es posible que un rastreo de búsqueda completo no se ejecute durante una prueba de carga, mientras que un rastreo incremental puede ser normal. Debe considerar cómo se programarán estas tareas en producción: se ejecutarán en los momentos de máxima carga? Si no es así, entonces deberían excluirse durante las pruebas de carga, cuando se intenta determinar la carga de estado de equilibrio máxima que puede admitir para el tráfico pico. No use tiempos de reflexión. Los tiempos de reflexión son una característica de Visual Studio Team System (Team Test Load Agent) que permite simular el tiempo de la pausa que hacen los usuarios entre clics en una página. Por ejemplo, un usuario típico puede cargar una página, pasar tres minutos leyéndola y después hacer clic en un vínculo de la página para visitar otro sitio. Tratar de modelar esto en un entorno de prueba es prácticamente imposible de hacer de forma correcta y eficaz y no agrega valor a los resultados de las pruebas. Es difícil de modelar porque la mayoría de las organizaciones no tiene una forma de supervisar los diferentes usuarios y el tiempo que pasan entre clics en diferentes tipos de sitios de SharePoint (como sitios de publicación, de búsqueda, de colaboración, etc.). En realidad, tampoco agrega valor debido a que aunque un usuario pueda hacer una pausa entre las solicitudes de página, los servidores basados en SharePoint Server 2010 no lo hacen. Simplemente reciben un flujo sostenido de solicitudes que pueden tener picos y valles a lo largo del tiempo, pero no esperan inactivos mientras cada usuario hace una pausa antes de hacer clic en los diferentes vínculos de una página. Comprenda la diferencia entre usuarios y solicitudes. Visual Studio Team System (Team Test Load Agent) tiene un modelo de carga que le pide que escriba el número de usuarios que desea simular. Esto no tiene nada que ver con los usuarios de las aplicaciones. En realidad, se trata simplemente del número de subprocesos que se van a usar en los agentes de prueba de carga para generar las solicitudes. Un error común es pensar que si la implementación tendrá, por ejemplo, usuarios, es el número que se debe usar en Visual Studio Team System (Team Test Load Agent). Esto es incorrecto. Es una de las muchas razones por las que al calcular los requisitos de planeación de capacidad, los requisitos de uso deben basarse en el número de solicitudes por segundo y no en el número de usuarios. En una prueba de carga de Visual Studio Team System (Team Test Load Agent), verá que suelen generarse cientos de solicitudes por segundo usando solo 50 a 75 "usuarios" de prueba de carga. Use un modelo de carga constante para obtener resultados más reproducibles y confiables en las pruebas. En Visual Studio Team System (Team Test Load Agent) tiene la opción de basar la carga en un número constante de usuarios (subprocesos, como se explicó en el punto anterior), un modelo de carga de usuarios incremental o una prueba de uso basada en objetivos. Un modelo de 75

76 carga incremental es cuando comienza con un número de usuarios menor y lo va incrementando agregando más usuarios cada pocos minutos. Una prueba de uso basada en objetivos es cuando se establece un umbral para un determinado contador de diagnóstico, como utilización de CPU, y la prueba intenta controlar la carga para mantener dicho contador entre un umbral mínimo y máximo definidos. Sin embargo, si solo desea determinar la capacidad de proceso máxima que puede admitir la granja de servidores de SharePoint Server 2010 durante los picos de carga, es más eficaz y preciso simplemente elegir un modelo de carga constante. Esto permite identificar más fácilmente la cantidad de carga que el sistema puede admitir antes de comenzar a exceder regularmente los umbrales que deberían mantenerse en una granja de servidores en buen estado. Cada vez que ejecute una prueba de carga no olvide que se modifican datos en la base de datos. Ya sea que se trate de cargar documentos, editar elementos de listas o simplemente registrar actividad en la base de datos de uso, se escribirán algunos datos en SQL Server. Para garantizar un conjunto de resultados coherente y legítimo en cada prueba de carga, debe tener una copia de seguridad disponible antes de ejecutar la primera prueba de carga. Una vez finalizada cada prueba de carga, se debe usar la copia de seguridad para restaurar el contenido al estado en que se encontraba antes de iniciar la prueba. Vea también Conceptos Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server 2010 Planeación de la capacidad para SharePoint Server 2010 Supervisión y mantenimiento de SharePoint Server 2010 Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010) Otros recursos Health Monitoring (SharePoint Server 2010) 76

77 Supervisión y mantenimiento de SharePoint Server 2010 En este artículo se proporciona información acerca de la supervisión y los contadores de rendimiento para los conjuntos o granjas de servidores de Microsoft SharePoint Server Para mantener el rendimiento del sistema de SharePoint Server 2010, debe supervisar el servidor e identificar los posibles cuellos de botella. Para poder supervisar con eficacia, debe conocer los indicadores clave que muestran si una parte específica de la granja de servidores requiere atención y saber cómo interpretar dichos indicadores. Si observa que la granja de servidores funciona sin cumplir los objetivos que definió, puede ajustarla. Para ello, agregue o elimine recursos de hardware, modifique la topología o cambie el modo en que se almacenan los datos. La información de esta sección está dirigida a los administradores, para ayudarles a configurar manualmente los contadores de rendimiento y otras opciones de configuración. Para obtener más información acerca del seguimiento de estado y la solución de problemas mediante las herramientas de seguimiento de estado integradas en la interfaz de Administración central de SharePoint, consulte los siguientes artículos: Health Monitoring (SharePoint Server 2010) Solving Problems and Troubleshooting (SharePoint Server 2010) Antes de leer este artículo, debe leer Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server En este artículo: Configuración de la supervisión Eliminación de cuellos de botella Configuración de la supervisión A continuación se proporciona una lista de las opciones de configuración que se pueden modificar para supervisar el entorno en sus etapas iniciales, y que ayudará a determinar si necesita realizar algún cambio. Tenga en cuenta que el aumento de la funcionalidad de supervisión afectará a la cantidad de espacio en disco que requerirá la base de datos de uso. Una vez que el entorno está estable y la supervisión detallada ya no es necesaria, puede que desee revertir las opciones de configuración siguientes a sus valores predeterminados. 77

78 Opción Valor Notas Protección de "flood" del registro de eventos Deshabilitado El valor predeterminado es Habilitado. Se puede deshabilitar para recopilar la mayor cantidad de datos de supervisión posible. Para las operaciones normales, debe estar habilitado. Programación de trabajos del temporizador Importación de datos de uso de Microsoft SharePoint Foundation Proveedores de diagnóstico 5 minutos El valor predeterminado es 30 minutos. Al disminuir este valor, se importarán los datos a la base de datos de uso con mayor frecuencia, lo cual es especialmente útil para solución de problemas. Para las operaciones normales, el valor debe ser 30 minutos. Habilitar todos los proveedores de diagnóstico Habilitado El valor predeterminado es Deshabilitado excepto para el proveedor de eventos de rastreo de Seguimiento de estado de búsqueda. Estos 78

79 Opción Valor Notas Establecer los intervalos de programación "jobdiagnostics-performance-counter-wfe-provider" y "jobdiagnostics-performance-counter-sql-provider" Varios Habilitar el seguimiento de la pila para solicitudes de contenido 79 proveedores recopilan datos de estado de diversos componentes y características. Para las operaciones normales, puede que desee revertir al valor predeterminado. 1 minuto El valor predeterminado es 5 minutos. Al disminuir este valor, se sondearán los datos con mayor frecuencia, lo cual es especialmente útil para solución de problemas. Para las operaciones normales, el valor debe ser 5 minutos. Habilitado El valor predeterminado es Deshabilitado. Al habilitar esta opción, se realizará un diagnóstico de los errores de las solicitudes de contenido mediante el seguimiento de la pila del proceso. Para las operaciones normales, debe deshabilitarse. Habilitar el panel del programador Habilitado El valor predeterminado es

80 Opción Valor Notas Recolección de datos de uso Uso de importación de contenido Uso de exportación de contenido Solicitudes de página Uso de características Uso de consulta de búsqueda Uso del inventario de sitios Trabajos del temporizador Uso de calificación Habilitado Deshabilitado. Si habilita esta opción, se realizará un diagnóstico de las páginas lentas u otros problemas mediante el panel del programador. Esta opción debe deshabilitarse para las operaciones normales, siempre que la solución de problemas ya no sea necesaria. Al habilitar el registro de este conjunto de contadores, podrá recopilar más datos de uso de todo el entorno y comprender mejor los patrones de tráfico en el entorno. Contadores de rendimiento Si usa la base de datos de uso, puede agregar a ella los contadores de rendimiento que ayudan a supervisar y evaluar el rendimiento de la granja de servidores, de modo que se registran automáticamente a un intervalo específico (el valor predeterminado es de 30 minutos). De esta manera, podrá consultar la base de datos de uso para recuperar los contadores y crear gráficos con los resultados distribuidos 80

81 en el tiempo. A continuación, presentamos un ejemplo del uso del cmdlet de PowerShell Add-SPDiagnosticsPerformanceCounter para agregar el contador % de tiempo de procesador a la base de datos de uso. Solo necesita ejecutarse en uno de los servidores web: Add-SPDiagnosticsPerformanceCounter -Category "Processor" -Counter "% Processor Time" -Instance "_Total" -WebFrontEnd Copiar código Existe una serie de contadores de rendimiento genéricos que se deben supervisar para cualquier sistema de servidor. En la siguiente tabla se describen estos contadores de rendimiento. Contador de rendimiento Procesador Interfaz de red Discos y memoria caché Descripción Debe supervisar el rendimiento del procesador para asegurarse de que todo el uso del procesador no se mantenga constantemente alto (más del 80 por ciento), ya que esto indica que el sistema no sería capaz de controlar los flujos de actividad repentinos. En el estado común, no verá un efecto dominó si el error de uno de los componentes ocasiona el funcionamiento incorrecto del resto. Por ejemplo, si tiene tres servidores web, debe asegurarse de que el uso medio de CPU de todos los servidores sea menos del 60%, de modo que si se produce un error en uno de ellos, aún haya espacio para que los otros dos se ocupen de la carga adicional. Supervise la velocidad del envío y recepción de datos a través de la tarjeta de interfaz de red. La misma debe permanecer por debajo del 50 por ciento de la capacidad de red. Hay varias opciones de disco lógico que debe supervisar regularmente. El espacio disponible en disco es esencial en un estudio de capacidad, pero también debe revisar el tiempo que el disco está inactivo. Según los tipos de aplicaciones o servicios que ejecute en los servidores, es posible que deba revisar los tiempos 81

82 Contador de rendimiento Memoria y archivo de paginación Descripción de lectura y escritura del disco. Una cola prolongada para las funciones de lectura o escritura afectará al rendimiento. La memoria caché tiene un gran impacto sobre las operaciones de lectura y escritura, por lo que debe supervisar el aumento de errores en caché. Supervise la cantidad de memoria física disponible para la asignación. Si no hay suficiente memoria, se hará un uso excesivo del archivo de paginación y se producirá un aumento del número de errores de página por segundo. Contadores del sistema En la tabla siguiente se proporciona información acerca de los objetos y contadores del sistema que puede agregar al conjunto de contadores que se supervisan en la base de datos de uso mediante SPDiagnosticPerformanceCounter en un servidor web. Objetos y contadores Procesador 82 Descripción % de tiempo de procesador Muestra el uso del procesador durante un período de tiempo. Si se mantiene siempre demasiado alto, es posible que el rendimiento se vea afectado negativamente. Recuerde que debe contar el "total" en los sistemas con varios procesadores. También puede medir el uso de cada procesador, para garantizar el rendimiento equilibrado entre los núcleos. Disco Longitud promedio de la cola de disco Muestra el promedio de las solicitudes de lectura y escritura que se pusieron en cola para el disco seleccionado durante el intervalo de ejemplo. Una mayor longitud de la cola de disco podría no ser un

83 Objetos y contadores Longitud promedio de cola de lectura de disco Longitud promedio de cola de escritura de disco Lecturas de disco/s Escrituras en disco/s Memoria MB disponibles Errores de caché/s Páginas por segundo Descripción problema, siempre que las lecturas y escrituras del disco no sea vean afectadas y el sistema esté funcionando en un estado estable sin expandir la puesta en cola. El promedio de solicitudes de lectura que se ponen en cola. El promedio de solicitudes de escritura que se ponen en cola. El número de lecturas de disco por segundo. El número de escrituras de disco por segundo. Muestra la cantidad de memoria física disponible para la asignación. Si no hay suficiente memoria, se hará un uso excesivo del archivo de paginación y se producirá un aumento del número de errores de página por segundo. Este contador muestra la velocidad a la que se producen errores cuando se busca una página en la memoria caché del sistema de archivos y no se encuentra. Puede tratarse de un error flexible, cuando la página se encuentra en la memoria; o de o un error severo, cuando la página está en el disco. El uso eficaz de la memoria caché para las operaciones de lectura y escritura puede tener un efecto significativo en el rendimiento del servidor. Debe supervisar el aumento de errores de caché, que podría estar indicado por una disminución de Lecturas asincrónicas rápidas/s o Lecturas anticipadas/s. Este contador muestra la velocidad a la que las páginas se leen desde el disco o se escriben en él para resolver errores graves en la página. Si aumenta, indica que hay problemas de rendimiento en todo el sistema. 83

84 Objetos y contadores Archivo de paginación 84 Descripción % usado y % de uso máximo El archivo de paginación del servidor, a veces denominado archivo de intercambio, contiene las direcciones de memoria "virtuales" en el disco. Los errores de página ocurren cuando un proceso se tiene que detener y esperar mientras se recuperan los recursos "virtuales" del disco en la memoria. Estos serán más frecuentes si la memoria física no es la adecuada. NIC Total de bytes/s Proceso Espacio de trabajo Se trata de la velocidad del envío y recepción de datos a través de la tarjeta de interfaz de red. Es posible que tenga que investigar más sobre si este valor es superior al por ciento de la capacidad de red. Para hacerlo, supervise los valores de Bytes recibidos/s y Bytes enviados/s. Este contador indica el tamaño actual (en bytes) del espacio de trabajo para un proceso determinado. Esta memoria se reserva para el proceso, incluso si no está en uso. % de tiempo de procesador Este contador indica el porcentaje de tiempo de procesador que usa un proceso determinado. Recuento de subprocesos (_Total) ASP.NET Total de solicitudes Solicitudes en cola El número actual de subprocesos. El número total de solicitudes desde que se inició el servicio. Microsoft SharePoint Foundation 2010 proporciona los bloques de creación para páginas HTML que se representan en el explorador del usuario a través de HTTP. Este contador muestra el número de

85 Objetos y contadores Tiempo de espera de la solicitud Solicitudes rechazadas Solicitudes en ejecución (_Total) Solicitudes por segundo (_Total) Memoria de.net CLR Número de colecciones de gen. 0 Número de colecciones de gen. 1 Descripción solicitudes en espera para ser procesadas. La cantidad de milisegundos que la solicitud más reciente esperó en la cola para ser procesada. A medida que aumenta el número de eventos de espera, los usuarios experimentarán una degradación del rendimiento de la representación de página. El número total de solicitudes que no se ejecutaron debido a que los recursos del servidor eran insuficientes para procesarlas. Este contador representa el número de solicitudes que devuelven un código de estado HTTP 503, que indica que el servidor está demasiado ocupado. El número de solicitudes actualmente en ejecución. El número de solicitudes ejecutadas por segundo. Esto representa la capacidad de rendimiento actual de la aplicación. Con una carga constante, este número debe permanecer dentro de un intervalo determinado, bloqueando otros trabajos de servidor (por ejemplo, la recolección de elementos no usados, el subproceso de limpieza de caché, las herramientas de servidor externo, entre otros). Muestra el número de veces que los objetos de generación 0 (es decir, los objetos más recientes, asignados últimamente) se recopilaron como elementos no usados desde que se inició la aplicación. Este número sirve como una relación de #Gen 0: #Gen 1: #Gen 2 para asegurarse de que el número de colecciones de generación 2 no sea muy superior al de las colecciones de generación 0; lo óptimo es un factor de 2. Muestra el número de veces que los objetos de generación 1 se recopilaron como elementos no usados desde que se inició la 85

86 Objetos y contadores Número de colecciones de gen. 2 Descripción aplicación. Muestra el número de veces que los objetos de generación 2 se recopilaron como elementos no usados desde que se inició la aplicación. El contador se incrementa al final de una recolección de elementos no usados de generación 2 (también denominada recolección completa de elementos no usados). % de tiempo del GC Muestra el porcentaje de tiempo transcurrido que se dedicó a realizar una recolección de elementos no usados desde el último ciclo de recolección de elementos no usados. Este contador suele indicar el trabajo que realiza el recolector de elementos no usados para recopilar y compactar la memoria en nombre de la aplicación. Este contador solo se actualiza al final de cada recolección de elementos no usados. Dicho contador no es un promedio y su valor refleja el último valor observado. Este contador debe ser menor que 5% en funcionamiento normal. Contadores SQL Server En la tabla siguiente se proporciona información acerca de los objetos y contadores SQL Server. Objetos y contadores Estadísticas generales Conexiones de usuario 86 Descripción Este objeto proporciona contadores para supervisar la actividad general de todo el servidor, por ejemplo, el número de conexiones actuales y el número de usuarios que se conectan y desconectan por segundo de los equipos que ejecutan una instancia de SQL Server. Este contador muestra el número de conexiones de usuario en la instancia de SQL Server. Si este número aumenta al 500 por ciento

87 Objetos y contadores Bases de datos Transacciones por segundo Bloqueos Número de interbloqueos/s Tiempo promedio de espera (ms) Tiempo de espera de bloqueos (ms) Esperas de bloqueo/s Descripción de su línea base, es posible que disminuya el rendimiento. Este objeto proporciona contadores para supervisar las operaciones de copia masiva, capacidad de proceso de la copia de seguridad y restauración, así como las actividades de registro de transacciones. Supervise las transacciones y el registro de transacciones para determinar cuánta actividad de usuario se produce en la base de datos y cuánto se está llenando el registro de transacciones. La cantidad de actividad de usuario puede determinar el rendimiento de la base de datos y afectar al tamaño del registro, los bloqueos y la replicación. La supervisión de la actividad de registro de bajo nivel para medir el uso de los recursos y la actividad de usuario puede ayudar a identificar los cuellos de botella de rendimiento. Este contador muestra la cantidad de transacciones en una base de datos determinada o en toda la instancia de SQL Server por segundo. Este número ayuda a crear una línea base y solucionar problemas. Este objeto brinda información acerca de los bloqueos de SQL Server en tipos de recursos individuales. Este contador muestra el número de interbloqueos de SQL Server por segundo. Normalmente, debe ser 0. Este contador muestra el promedio de tiempo de espera para cada solicitud de bloqueo que se esperó. Este contador muestra el tiempo de espera total de los bloqueos en el último segundo. Este contador muestra el número de bloqueos por segundo que no se pudieron satisfacer inmediatamente y que tuvieron que esperar recursos. 87

88 Objetos y contadores Bloqueos temporales Promedio de tiempo de espera de bloqueos temporales (ms) Esperas de bloqueos temporales/s Estadísticas SQL Compilaciones SQL/s Recompilaciones SQL/s Caché del plan Frecuencia de aciertos de caché 88 Descripción Este objeto proporciona contadores para supervisar los bloqueos de recursos de SQL Server internos llamados bloqueos temporales. La supervisión de los bloqueos temporales para determinar el uso de los recursos y la actividad de usuario puede ayudarle a identificar los cuellos de botella de rendimiento. Este contador muestra el tiempo de espera promedio de bloqueos temporales de las solicitudes de bloqueos temporales que tuvieron que esperar. Este contador muestra el número de solicitudes de bloqueos temporales por segundo que no pudieron concederse inmediatamente. Este objeto proporciona contadores para supervisar la compilación y el tipo de solicitudes enviadas a una instancia de SQL Server. Supervisar el número de compilaciones y nuevas compilaciones de consulta y el número de lotes recibidos por una instancia de SQL Server indica la rapidez con la que SQL Server procesa las consultas de usuario y la eficacia con la que el optimizador de consultas procesa las consultas. Este contador indica el número de veces que se especifica la ruta de acceso al código de compilación por segundo. Este contador indica el número de veces que se desencadenan recompilaciones de instrucción por segundo. Este objeto proporciona contadores para supervisar cómo SQL Server usa la memoria para almacenar objetos, como procedimientos almacenados, instrucciones Transact-SQL ad hoc y preparadas, así como desencadenadores. Este contador indica la frecuencia entre aciertos de caché y

89 Objetos y contadores Caché del búfer Frecuencia de aciertos de caché del búfer Descripción búsquedas de planes. Este objeto proporciona contadores para supervisar cómo usa SQL Server la memoria para almacenar las páginas de datos, las estructuras de datos internos y la memoria caché de procedimientos, así como los contadores para supervisar la E/S física mientras SQL Server lee y escribe páginas de base de datos. Este contador muestra el porcentaje de páginas que se encontraron en la memoria caché del búfer sin necesidad de leer el disco. La relación es el número total de aciertos de caché dividido por el número total de búsquedas de caché desde que se inició una instancia de SQL Server. Eliminación de cuellos de botella Los cuellos de botella del sistema representan un punto de contención cuando no hay suficientes recursos para atender las solicitudes de transacciones de usuario. Pueden estar basados en hardware físico, entorno operativo o aplicaciones. A menudo, el motivo del cuello de botella es código personalizado o soluciones de terceros ineficaces; si se revisan esos elementos, se podrían obtener mejores resultados que si se agrega hardware. Otra causa común de los cuellos de botella es un error de configuración de la granja de servidores o una implementación ineficaz de la solución que estructura los datos de modo que se requieren más recursos que los necesarios. Es esencial que un administrador del sistema administre los cuellos de botella mediante la supervisión constante del rendimiento. Cuando identifica un problema de rendimiento, debe evaluar la mejor solución para eliminar el cuello de botella. Los contadores de rendimiento y otras aplicaciones de supervisión del rendimiento, como System Center Operations Manager (SCOM), son las herramientas clave de seguimiento y análisis de problemas para que pueda desarrollar una solución. Resolución de cuellos de botella físicos Los cuellos de botella físicos se basan en la contención de red, memoria, disco y procesador: demasiadas solicitudes para muy pocos recursos físicos. Los objetos y contadores que se describen en el tema sobre la supervisión de rendimiento indican que el problema de rendimiento se encuentra, por ejemplo, en el procesador de hardware o ASP.NET. La resolución de cuellos de botella requiere que identifique el problema de rendimiento y, a continuación, realice un cambio o varios para mitigarlo. 89

90 Los problemas rara vez aparecen de forma repentina; normalmente, se produce una degradación gradual del rendimiento. Puede realizar un seguimiento de esta degradación si supervisa periódicamente mediante la herramienta Monitor de rendimiento o un sistema más sofisticado, como SCOM. Para usar cualquiera de estas opciones, en distintos grados, puede insertar soluciones dentro de una alerta, en el formato de texto de asesoramiento o comandos de script. Puede que deba resolver problemas de cuello de botella mediante cambios en la configuración de hardware o del sistema, una vez que haya determinado que no están ocasionados por un error de configuración, soluciones de terceros o código personalizado ineficaces, o una implementación ineficaz de la solución. En las siguientes tablas se identifican el umbral del problema y las posibles opciones de resolución. Algunas de las opciones sugieren actualizaciones o modificaciones de hardware. Objetos y contadores Problema Opciones de resolución Procesador Procesador - % de tiempo de procesador Más del 75-85% Actualizar el procesador Aumentar el número de procesadores Agregar servidores adicionales Disco Promedio de longitud de la cola de disco Aumento gradual, el sistema no está en un estado estable y se está realizando una copia de seguridad de la cola Aumentar la cantidad o la velocidad de discos Cambiar la configuración de la matriz a franja Mover algunos datos a un servidor alternativo % de tiempo de inactividad Más del 90% Aumentar el número de discos Mover los datos a un servidor o disco alternativo % de espacio disponible Menos del 30% Aumentar el número de discos Mover los datos a un servidor o disco alternativo Memoria MB disponibles Menos de 2 GB en un servidor web. Agregar memoria. 90

91 Objetos y contadores Problema Opciones de resolución Nota: La memoria disponible del servidor SQL Server será baja debido a su diseño y no siempre indicará un problema. Errores de caché/s Mayor que 1 Agregar memoria Aumentar el tamaño o la velocidad de la memoria caché si es posible Mover los datos a un servidor o disco alternativo Páginas por segundo Mayor que 10 Agregar memoria Archivo de paginación % usado y % de uso máximo El archivo de paginación del servidor, a veces denominado archivo de intercambio, contiene las direcciones de memoria "virtuales" en el disco. Los errores de página ocurren cuando un proceso se tiene que detener y esperar mientras se Agregar memoria recuperan los recursos "virtuales" del disco en la memoria. Estos serán más frecuentes si la memoria física no es la adecuada. NIC Total de bytes/s Más del 40-50% de la capacidad de red. Se trata de la velocidad del envío y recepción de datos a través de la tarjeta 91 Investigar más mediante la supervisión de Bytes recibidos/s y Bytes enviados/s.

92 Objetos y contadores Problema Opciones de resolución Proceso de interfaz de red. Espacio de trabajo Más del 80% de la memoria total Agregar memoria Reevaluar la velocidad de la tarjeta de interfaz de red Comprobar el número, tamaño y uso de búferes de memoria % de tiempo de procesador Más del 75-85% Aumentar el número de procesadores Redistribuir la carga de trabajo en servidores adicionales ASP.NET Reciclajes del grupo de aplicaciones Varios por día, lo que produce una lentitud intermitente. Asegúrese de que no se han implementado opciones de configuración para reciclar de manera automática el grupo de aplicaciones innecesariamente a lo largo del día. Solicitudes en cola Cientos o miles de solicitudes en cola. Implementar servidores web adicionales El valor máximo predeterminado para este contador es Puede cambiar esta configuración en el archivo Machine.config Tiempo de espera de la solicitud A medida que aumenta el número de eventos de espera, los usuarios experimentarán una disminución del rendimiento de la representación de página. Implementar servidores web adicionales Solicitudes rechazadas Mayor que 0 Implementar servidores web adicionales 92

93 Vea también Conceptos Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server 2010 Pruebas de rendimiento para SharePoint Server 2010 Planeación de la capacidad para SharePoint Server 2010 Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010) Otros recursos Health Monitoring (SharePoint Server 2010) 93

94 Administración de la capacidad de SharePoint Server 2010: restricciones y límites del software En este documento se describen los límites y límites máximos del software de Microsoft SharePoint Server Estos incluyen los siguientes: Límites máximos: límites estáticos que el diseño no debe exceder. Umbrales: límites configurables que se pueden exceder para dar cabida a ciertos requisitos. Límites admitidos: límites configurables que se han establecido en un valor probado de forma predeterminada. Nota: La información acerca de la planeación de la capacidad que se incluye en este documento proporciona directrices que se deben tener en cuenta durante la planeación. Esta información se basa en las pruebas realizadas en Microsoft con propiedades activas. No obstante, los resultados que se obtengan pueden variar en función de los equipos usados y según las características y la funcionalidad que se implemente en los sitios. En este artículo: Información general de límites máximos y límites Límites máximos, umbrales y límites admitidos Establecimiento de los límites Límites y límites máximos Límites por jerarquía Límites de aplicaciones web Límites de servidores web y servidores de aplicaciones 94

95 Límites de bases de datos de contenido Límites de colecciones de sitios Límites de listas y bibliotecas Límites de columnas Límites de páginas Límites por característica Límites de búsqueda Límites de servicio de perfiles de usuario Límites de distribución de contenido Límites de blogs Límites de Servicios de conectividad empresarial Límites de flujos de trabajo Límites de almacén de términos de metadatos administrados (base de datos) Límites de Servicios de Visio Límites de PerformancePoint Services Límites de Word Automation Services Límites de SharePoint Workspace Límites de OneNote Límites de Office Web Application Service Límites de Project Server Información general de límites máximos y límites Este artículo contiene información que le ayudará a entender los límites de rendimiento y capacidad probados de SharePoint Server 2010 y proporciona directrices sobre la relación de los límites con un rendimiento aceptable. Use la información incluida en este artículo para determinar si la implementación que planeó se encuentra dentro de límites de rendimiento y capacidad aceptables y para configurar de forma adecuada los límites en su entorno. 95

96 Los resultados de las pruebas y las directrices proporcionados en este artículo se aplican a un solo conjunto o granja de servidores de SharePoint Server Si se agregan servidores a la instalación, es posible que no aumenten los límites de capacidad de los objetos enumerados en las tablas de la sección Límites y límites máximos más adelante en este tema. Por otra parte, si se agregan equipos servidores, aumentará el rendimiento de una granja de servidores, lo que podría ser necesario para lograr un rendimiento aceptable con muchos objetos. En algunos casos, los requisitos de números elevados de objetos en una solución podrían requerir más servidores en la granja. Tenga en cuenta que hay muchos factores que pueden afectar al rendimiento en un determinado entorno y cada uno de estos factores puede afectar a su vez al rendimiento en otras áreas. Algunos de los resultados de las pruebas y recomendaciones incluidos en este artículo pueden estar relacionados con características u operaciones del usuario que no existen en su entorno y, por lo tanto, no se aplican a su solución. Solo es posible obtener datos exactos sobre su propio entorno mediante pruebas exhaustivas. Límites máximos, umbrales y límites admitidos En SharePoint Server 2010, hay ciertos límites que son de diseño y que no se pueden exceder y otros límites que se establecen en valores predeterminados que el administrador de la granja de servidores puede modificar. También hay ciertos límites que no están representados por un valor configurable, como el número de colecciones de sitios por aplicación web. Los límites máximos son límites absolutos que no se pueden exceder por diseño Es importante entender estos límites para no hacer suposiciones incorrectas al diseñar una granja de servidores. Un ejemplo de límite máximo es el límite de tamaño de documento de 2 GB; no se puede configurar SharePoint Server para almacenar documentos de más de 2 GB. Éste es un valor absoluto integrado y no se puede exceder por diseño. Los umbrales son límites que tienen un valor predeterminado que no se puede exceder a menos que se modifique el valor. En ciertos casos, los umbrales se pueden exceder para dar cabida a desviaciones en el diseño de la granja de servidores, pero es importante entender que al hacerlo se puede ver afectado el rendimiento de la granja además del valor efectivo de otros límites. El valor predeterminado de ciertos umbrales solo se puede exceder hasta un valor máximo absoluto. Un buen ejemplo es el límite de tamaño de documento. De forma predeterminada, el umbral de tamaño de documento predeterminado está establecido es 50 MB, pero puede modificarse para admitir un límite máximo de 2 GB. Los límites admitidos definen el valor probado de un parámetro específico. Los valores predeterminados de estos límites se definen mediante pruebas y representan las limitaciones conocidas del producto. Si se exceden los límites admitidos, se pueden producir resultados inesperados, una reducción considerable en el rendimiento u otros efectos perjudiciales. Algunos límites admitidos son parámetros configurables que se establecen de forma predeterminada en el valor recomendado, mientras que otros están relacionados con parámetros no representados por un valor configurable. 96

97 Un ejemplo de un límite admitido es el número de colecciones de sitios por aplicación web. El límite admitido es de , que es la cantidad máxima de colecciones de sitios por aplicación web que alcanzó los niveles de referencia de rendimiento durante las pruebas. Es importante tener en cuenta que muchos de los valores límite que se proporcionan en este documento representan un punto en una curva que describe una carga de recursos creciente y una reducción concomitante en el rendimiento a medida que aumenta el valor. Por lo tanto, si se exceden ciertos límites, como el número de colecciones de sitios por aplicación web, solo podría obtenerse una reducción fraccional en el rendimiento de la granja de servidores. No obstante, en la mayoría de los casos, el funcionamiento a un límite establecido o a un nivel próximo no es un procedimiento recomendado, ya que es más fácil alcanzar las metas aceptables de rendimiento y confiabilidad cuando el diseño de una granja de servidores proporciona un equilibrio razonable de los valores límite. Las directrices de umbrales y límites admitidos están determinadas por el rendimiento. En otras palabras, se pueden exceder los valores predeterminados de los límites, pero a medida que se aumenta el valor límite, el rendimiento de la granja de servidores y el valor efectivo de otros límites pueden verse afectados. Muchos de los límites de SharePoint Server pueden modificarse, pero es importante entender cómo se verán afectadas otras partes de la granja de servidores al modificar un determinado límite. Establecimiento de los límites En SharePoint Server 2010, los umbrales y límites admitidos se establecen mediante pruebas y la observación del comportamiento de la granja de servidores bajo cargas en aumento hasta el punto en que los servicios y operaciones de la granja de servidores alcanzan sus límites de funcionamiento efectivos. Algunos servicios y componentes de la granja de servidores pueden admitir una carga mayor que otros, por lo que en algunos casos debe asignarse un valor límite basado en un promedio de varios factores. Por ejemplo, las observaciones del comportamiento de la granja de servidores bajo carga cuando se agregan colecciones de sitios indican que ciertas características presentan una latencia inaceptablemente alta mientras que otras características siguen funcionando con parámetros aceptables. Por lo tanto, el valor máximo asignado a la cantidad de colecciones de sitios no es absoluto, sino que se calcula en función de un conjunto esperado de características de uso en el que el rendimiento de la granja de servidores en general sería aceptable en el límite especificado en la mayoría de los casos. Obviamente, si algunos servicios funcionan con parámetros más altos que los usados en las pruebas de límites, los límites efectivos máximos de otros servicios se reducirán. Por lo tanto, es importante ejecutar rigurosos ejercicios de administración de la capacidad y pruebas de escala para implementaciones específicas a fin de establecer límites efectivos para dicho entorno. Nota: no se describe el hardware que se usó para validar los límites indicados en este documento, ya que estos se recopilaron de varias granjas de servidores y entornos. Para obtener descripciones de las granjas de servidores que se usaron en las pruebas, vea Recomendaciones y resultados de pruebas de rendimiento y capacidad (SharePoint Server 2010) y Performance and capacity technical case studies (SharePoint Server 2010) (en inglés). 97

98 La metáfora del ecualizador Los umbrales y límites admitidos pueden considerarse como los controles deslizantes de un ecualizador gráfico, donde cada límite representa una determinada frecuencia. Según esta metáfora, al aumentar el valor de un límite, se puede reducir el valor efectivo de uno o más límites. Suponga que un control deslizante representa el número máximo de documentos por biblioteca, un límite admitido con un valor probado máximo de aproximadamente 30 millones. Sin embargo, este valor depende de otro control deslizante, que representa el tamaño máximo de los documentos de la granja de servidores y que es un umbral con un valor predeterminado de 50 MB. Si cambia el tamaño máximo de los documentos a 1 GB para admitir vídeos u otros objetos grandes, el número de documentos que la biblioteca puede servir a los usuarios de forma eficiente se reduce de la misma forma. Por ejemplo, la configuración de hardware y la topología de una determinada granja de servidores pueden admitir 1 millón de documentos hasta 50 MB. No obstante, la misma granja de servidores con el mismo número de documentos no puede alcanzar la misma latencia y metas de rendimiento si sirve un tamaño de documento promedio mayor, ya que el límite de tamaño de archivo se estableció en 1 GB. El grado en que se reduce el número máximo de documentos en este ejemplo es difícil de predecir y se basa en el número de archivos grandes de la biblioteca, el volumen de datos que contienen, las características de uso de la granja de servidores y la disponibilidad de recursos de hardware. Límites y límites máximos En esta sección se enumeran los objetos que pueden formar parte de una solución y se proporcionan directrices para el rendimiento aceptable de cada tipo de objeto. Un rendimiento aceptable significa que el sistema, tal como se probó, puede admitir ese número de objetos, pero el número no se puede exceder sin que se produzca cierta reducción en el rendimiento o en el valor de los límites relacionados. Los objetos se enumeran por ámbito y por característica. Se proporcionan datos de límites, así como notas que describen las condiciones en las que se obtiene el límite y vínculos a información adicional según corresponda. Use las directrices incluidas en este artículo para revisar sus planes de solución generales. Si sus planes de solución exceden las recomendaciones para uno o varios objetos, siga uno de estos procedimientos: Evalúe la solución para garantizar que se realizan compensaciones en otras áreas. Marque estas áreas para probarlas y supervisarlas durante su implementación. Rediseñe o particione la solución para asegurarse de que no se excedan los niveles de capacidad recomendados. Límites por jerarquía En esta sección se proporcionan límites ordenados por la jerarquía lógica de una granja de servidores de SharePoint Server

99 Límites de aplicaciones web En la siguiente tabla se enumeran las recomendaciones para aplicaciones web. Límite Valor máximo Tipo de límite Notas Base de datos de contenido 300 por aplicación web Compatible Con 300 bases de datos de contenido por aplicación web, las operaciones de usuario final, como abrir el sitio o las colecciones de sitios, no se ven afectadas. No obstante, las operaciones administrativas, como crear una nueva colección de sitios, experimentarán una reducción en su rendimiento. Recomendamos usar Windows PowerShell para administrar la aplicación web cuando hay presente un gran número de bases de datos de contenido, ya que la interfaz de administración se vuelve lenta y difícil de navegar. Zona 5 por aplicación web Límite máximo El número de zonas definido para una granja de servidores se codifica de forma rígida en 5. Las zonas incluyen Predeterminada, Intranet, Extranet, Internet y personalizada. Ruta de acceso administrada 20 por aplicación web Compatible Las rutas de acceso administradas se almacenan en 99

100 Límite Valor máximo Tipo de límite Notas 100 la memoria caché del servidor web y se usan recursos de la CPU para procesar las solicitudes entrantes respecto de la lista de rutas de acceso administradas. Si se exceden 20 rutas de acceso administradas por aplicación web, se agrega más carga al servidor web para cada solicitud. Si planea exceder veinte rutas de acceso administradas en una aplicación web determinada, recomendamos probar el sistema para comprobar si tiene un rendimiento aceptable. Tamaño de caché de la solución 300 MB por aplicación web Umbral La memoria caché de la solución permite al servicio de InfoPath Forms mantener soluciones en la memoria caché a fin de acelerar la recuperación de las soluciones. Si se excede el tamaño de memoria caché, las soluciones se recuperan del disco, lo que puede demorar los tiempos de respuesta. Puede configurar el tamaño de la memoria caché de solución usando el cmdlet Set- SPInfoPathFormsService de Windows PowerShell. Para obtener más información, vea

101 Límite Valor máximo Tipo de límite Notas Set-SPInfoPathFormsService. Límites de servidores web y servidores de aplicaciones En la siguiente tabla se enumeran las recomendaciones para servidores web de la granja de servidores. Límite Valor máximo Tipo de límite Notas Grupos de aplicaciones 10 por servidor web Compatible El número máximo está determinado por las capacidades del hardware. Este límite depende principalmente de: La cantidad de RAM asignada a los servidores web La carga de trabajo que sirve la granja de servidores, es decir, la base de usuarios y las características de uso (los grupos de aplicaciones con una sola aplicación altamente activa pueden llegar a 10 GB o más) Límites de bases de datos de contenido En la siguiente tabla se enumeran las recomendaciones para bases de datos de contenido. Límite Valor máximo Tipo de límite Notas Tamaño de base de datos de contenido 200 GB por base de datos de contenido Compatible Recomendamos 101

102 Límite Valor máximo Tipo de límite Notas 102 especialmente limitar el tamaño de las bases de datos de contenido a 200 GB para garantizar el rendimiento del sistema. Los tamaños de bases de datos de contenido de hasta 1 terabyte se admiten solo para repositorios grandes de un solo sitio y archivos con patrones de uso y de E/S que no sean de colaboración, como los centros de registros. Los tamaños de bases de datos más grandes se admiten en estos escenarios ya que los patrones de E/S y los formatos habituales de estructura de datos se han diseñado y probado para escalas de mayor tamaño. Para obtener más información acerca de repositorios de documentos de gran escala, vea el tema sobre la estimación de requisitos de rendimiento y capacidad para repositorios de documentos de gran escala, disponible en

103 Límite Valor máximo Tipo de límite Notas Colecciones de sitios por base de datos de contenido Se recomiendan máximo 103 Compatible Recomendaciones y resultados de pruebas de rendimiento y capacidad (SharePoint Server 2010), y el tema sobre la escenarios habituales de administración de contenido a gran escala, disponible en Enterprise content storage planning (SharePoint Server 2010). Una colección de sitios no debe superar los 100 GB a menos que sea la única colección de sitios en la base de datos. Recomendamos especialmente limitar el número de colecciones de sitios en una base de datos de contenido a No obstante, se admiten hasta colecciones de sitios. Estos límites se relacionan con la velocidad de la actualización. Cuanto más grande sea el número de colecciones de sitios en una base de datos, más lenta será la actualización.

104 Límite Valor máximo Tipo de límite Notas 104 El límite en el número de colecciones de sitios en una base de datos está subordinado al límite en el tamaño de la base de datos de contenido que tenga más de una colección de sitios (200 GB). En consecuencia, a medida que aumente el número de colecciones de sitios de una base de datos, el tamaño promedio de las colecciones de sitio que contiene deberá reducirse. Si se excede el límite de colecciones de sitios, se corre el riesgo de que los tiempos de inactividad se prolonguen durante las actualizaciones. Si planea exceder las colecciones de sitios, recomendamos contar con una estrategia de actualización clara y obtener hardware adicional para acelerar las actualizaciones y las actualizaciones de software

105 Límite Valor máximo Tipo de límite Notas Subsistema de almacenamiento remoto de El tiempo hasta el primer byte de cualquier blobs (RBS) en almacenamiento conectado a respuesta del NAS no puede exceder 20 la red (NAS) milisegundos. Límite máximo que afectan a las bases de datos. Para establecer el nivel de advertencia para el número de sitios de una base de datos de contenido, use el cmdlet Set- SPContentDatabase de Windows PowerShell con el parámetro - WarningSiteCount. Para obtener más información, vea Set- SPContentDatabase. Cuando SharePoint Server 2010 se configura para usar RBS, y los blobs en almacenamiento NAS, considere el siguiente límite máximo. Desde el momento en que SharePoint Server 2010 solicita un BLOB, hasta que recibe el primer byte del NAS, no pueden pasar más de 20 milisegundos. 105

106 Límites de colecciones de sitios En la siguiente tabla se enumeran las recomendaciones para colecciones de sitios. Límite Valor máximo Tipo de límite Notas Sitio web por colección de sitios Compatible El número máximo recomendado de sitios y subsitios es sitios. Puede crearse un número total de sitios web muy grande si se anidan los subsitios. Por ejemplo, en una jerarquía superficial con 100 sitios, cada uno de ellos con subsitios, tendría un total de sitios web. Una jerarquía profunda con 100 sitios, cada uno de ellos con 10 niveles de subsitios, también contendría en total sitios web. Nota: la eliminación o creación de un sitio o subsitio puede afectar considerablemente a la disponibilidad de un sitio. El acceso al sitio y a los subsitios será 106

107 Límite Valor máximo Tipo de límite Notas 107 limitado mientras se elimina el sitio. El intento de crear muchos subsitios al mismo tiempo también puede producir un error. Tamaño de la colección de sitios 100 GB por colección de sitios Compatible Una colección de sitios no debe superar los 100 GB a menos que sea la única colección de sitios en la base de datos. Ciertas acciones de relacionadas con las colecciones de sitios, como la copia de seguridad y restauración de una colección de sitios o el cmdlet Move- SPSite de Windows PowerShell, generan operaciones de Microsoft SQL Server grandes que pueden afectar al rendimiento o producir un error si hay otras colecciones de sitios activas en la misma base de datos. Para obtener más información, vea Move- SPSite.

108 Límites de listas y bibliotecas En la siguiente tabla se enumeran las recomendaciones para listas y bibliotecas. Para obtener información, vea las notas del producto sobre el diseño de listas grandes y maximización del rendimiento de listas disponible en Recomendaciones y resultados de pruebas de rendimiento y capacidad (SharePoint Server 2010). Límite Valor máximo Tipo de límite Notas Tamaño de filas de lista bytes por fila Límite máximo Cada elemento de lista o biblioteca solo puede ocupar bytes en total en la base de datos. 256 bytes están reservados para columnas integradas, lo que deja 7744 bytes para columnas de usuario final. Para obtener detalles sobre la cantidad de espacio que consume cada tipo de campo, vea Límites de columnas. Tamaño de archivos 2 GB Límite máximo El tamaño de archivo máximo predeterminado es 50 MB. El tamaño puede aumentarse hasta 2 GB, pero un volumen elevado de archivos de gran tamaño puede afectar al rendimiento de la granja de servidores. Documentos por biblioteca Compatible Se pueden crear bibliotecas de documentos muy grandes anidando carpetas, o usando vistas estándar y jerarquía de sitios. Este valor puede variar según la forma en que se organizan los documentos y carpetas, y según el tipo y tamaño de los documentos que se almacenan. Versiones principales Compatible Si se excede este límite, las operaciones de archivo básicas, como abrir, guardar o eliminar archivos y ver el historial de versiones, pueden producir errores. Elementos por lista Compatible Se puede crear listas muy grandes usando vistas estándar, jerarquías de sitio y navegación de metadatos. 108

109 Límite Valor máximo Tipo de límite Notas Límite de tamaño de filas Operaciones en masa 6 filas de tabla internas a la base de datos usadas para un elemento de lista o biblioteca 100 elementos por operación en masa Umbral de búsqueda en la vista 8 operaciones de combinación de lista por consulta Compatible 109 Este valor puede variar según el número de columnas de la lista y el uso de la lista. Especifica el número máximo de filas de tablas internas a la base de datos que se pueden usar para un elemento de lista o biblioteca. Para admitir listas anchas con muchas columnas, cada elemento puede ajustarse sobre varias filas de tabla internas, hasta seis filas de forma predeterminada. Los administradores de la granja de servidores pueden configurar esto a través del modelo de objetos únicamente. El método del modelo de objetos es SPWebApplication.MaxListItemRowStorage. Límite máximo La interfaz de usuario permite seleccionar un máximo de 100 elementos para operaciones en masa. Umbral Especifica la cantidad máxima de combinaciones permitidas por consulta, tales como las basadas en las columnas de búsqueda, persona o grupo o de estado de flujo de trabajo. Si la consulta usa más de ocho combinaciones, la operación se bloquea. Esto no se aplica a las operaciones de un solo elemento. Cuando se usa la vista máxima mediante el modelo de objetos (sin especificar ningún campo de vista), SharePoint devolverá hasta las primeras ocho búsquedas. Umbral de la vista de lista Umbral Especifica la cantidad máxima de elementos de lista o biblioteca que puede procesar simultáneamente una operación de base de datos, como una consulta, fuera del intervalo diario de horas que establece el administrador y durante el cual las consultas no tienen restricciones. Umbral de la vista de lista para Umbral Especifica la cantidad máxima de elementos de lista o

110 Límite Valor máximo Tipo de límite Notas auditores y administradores 110 biblioteca que puede procesar simultáneamente una operación de base de datos, como una consulta, cuando un auditor o administrador con los permisos apropiados realiza la operación. Esta configuración funciona junto con Permitir invalidación de modelos de objetos. Subsitio por vista de sitio Umbral La interfaz para enumerar subsitios de un sitio web determinado no tiene un buen rendimiento ya que el número de subsitios supera los De la misma forma, el rendimiento de la página Todo el contenido del sitio y del control de vista de árbol se reducirán considerablemente a medida que aumente el número de subsitios. Coautoría en Microsoft Word y Microsoft PowerPoint para archivos.docx,.pptx y.ppsx 10 editores simultáneos por documento Umbral El número máximo recomendado de editores simultáneos es 10. El límites máximo es 99. Si hay 99 coautores que tienen un mismo documento abierto para edición simultánea, cualquier usuario después del número 100 recibirá un error de "Archivo en uso" y deberá ver una copia de solo lectura. Más de 10 co-editores degradarán gradualmente la experiencia del usuario y crearán más conflictos y los usuarios deberán pasar por más iteraciones para que sus cambios se carguen correctamente. Ámbito de seguridad por lista Umbral El número máximo de ámbitos de seguridad únicos establecidos para una lista no debe exceder Un ámbito es el límite máximo de seguridad de un objeto protegible y cualquiera de sus elementos secundarios que no tenga definido un límite máximo de seguridad separada. Un ámbito contiene una lista de control de acceso (ACL), pero a diferencia de las ACL de NTFS, un

111 Límite Valor máximo Tipo de límite Notas ámbito puede incluir entidades de seguridad específicas a SharePoint Server. Los miembros de la ACL de un ámbito pueden incluir usuarios de Windows, cuentas de usuario que no sean usuarios de Windows (como cuentas basadas en formularios), grupos de Active Directory o grupos de SharePoint. Límites de columnas Los datos de SharePoint Server 2010 se almacenan en tablas de SQL Server. Para permitir el número máximo de columnas posibles en una lista de SharePoint, SharePoint Server creará varias filas en la base de datos cuando los datos no entren en una sola fila. Esto se denomina ajuste de filas. Cada vez que se ajusta una fila en SQL Server, se coloca una carga de consulta adicional en el servidor cuando se consulta dicho elemento ya que debe incluirse una combinación de SQL en la consulta. Para evitar una carga excesiva, de forma predeterminada se permiten como máximo seis filas de SQL Server para un elemento de SharePoint. Este límite lleva a una limitación particular en el número de columnas de cada tipo que se pueden incluir en una lista de SharePoint. En la siguiente tabla se describen los límites aplicables a cada tipo de columna. El parámetro de ajuste de fila puede aumentarse por encima de seis, pero puede generar una carga excesiva en el servidor. Se recomienda realizar pruebas de rendimiento antes de exceder este límite. Para obtener más información, vea las notas del producto sobre el diseño de listas grandes y maximización del rendimiento de listas que puede consultar en Recomendaciones y resultados de pruebas de rendimiento y capacidad (SharePoint Server 2010). Cada tipo de columna tiene un valor de tamaño expresado en bytes. La suma de todas las columnas de una lista de SharePoint no puede exceder bytes. Según el uso de columnas, los usuarios pueden llegar al límite de bytes antes de alcanzar la limitación de ajuste de filas de seis filas. Límite Valor máximo Tipo de límite 111 Tamaño por columna Línea de texto única 276 Umbral 28 bytes El ajuste de filas de SQL Server se realiza después de cada 64 columnas en una lista de Notas

112 Límite Valor máximo Tipo de límite 112 Tamaño por columna Notas SharePoint. El valor de ajuste de fila predeterminado de seis permite un máximo de 384 columnas de línea de texto única por lista de SharePoint (6 * 64 = 384). No obstante, dado que el límite por elemento de lista de SharePoint es de bytes, de los cuales 256 bytes están reservados para columnas de SharePoint integradas, el límite real es de 276 columnas de línea de texto única. Líneas de texto múltiples 192 Umbral 28 bytes El ajuste de filas de SQL Server se realiza después de cada 32 columnas en una lista de SharePoint. El valor de ajuste de fila predeterminado de seis permite un máximo de 192 columnas de líneas de texto múltiples por lista de SharePoint (6 * 32 = 192). Elección 276 Umbral 28 bytes La envoltura de la fila de SQL Server se realiza después de cada 64 columnas en una lista de SharePoint. El valor de ajuste de fila predeterminado de seis permite un máximo de 384 columnas de elección por lista de SharePoint (6 * 64 = 384). No obstante, dado que el límite por elemento de lista de SharePoint es de bytes, de los cuales 256 bytes están reservados para columnas de SharePoint integradas, el límite real es de 276 columnas de elección. Número 72 Umbral 12 bytes El ajuste de filas de SQL Server se realiza después de cada 12 columnas en una lista de SharePoint. El valor de ajuste de fila predeterminado de seis permite un máximo de 72

113 Límite Valor máximo Tipo de límite Tamaño por columna Notas columnas de número por lista de SharePoint (6 * 12 = 72). Moneda 72 Umbral 12 bytes El ajuste de las filas de SQL Server se realiza después de cada 12 columnas en una lista de SharePoint. El valor de ajuste de fila predeterminado de seis permite un máximo de 72 columnas de moneda por lista de SharePoint (6 * 12 = 72). Fecha y hora 48 Umbral 12 bytes El ajuste de filas de SQL Server se realiza después de cada 8 columnas en una lista de SharePoint. El valor de ajuste de fila predeterminado de seis permite un máximo de 48 columnas de fecha y hora por lista de SharePoint (6 * 8 = 48). Búsqueda 96 Umbral 4 bytes El ajuste de líneas de SQL Server se realiza después de cada 16 columnas en una lista de SharePoint. El valor de ajuste de fila predeterminado de seis permite un máximo de 96 columnas de búsqueda de valor único por lista de SharePoint (6 * 16 = 96). Sí/No 96 Umbral 5 bytes El ajuste de filas de SQL Server se realiza después de cada 16 columnas en una lista de SharePoint. El valor de ajuste de fila predeterminado de seis permite un máximo de 96 columnas Sí / No por lista de SharePoint (6 * 16 = 96). Persona o grupo 96 Umbral 4 bytes El ajuste de las filas de SQL Server se realiza después de cada 16 columnas en una lista de 113

114 Límite Valor máximo Tipo de límite 114 Tamaño por columna Notas SharePoint. El valor de ajuste de fila predeterminado de seis permite un máximo de 96 columnas de persona o grupo por lista de SharePoint (6 * 16 = 96). Hipervínculo o imagen 138 Umbral 56 bytes El ajuste de filas de SQL Server se realiza después de cada 32 columnas en una lista de SharePoint. El valor de ajuste de fila predeterminado de seis permite un máximo de 192 columnas de hipervínculo o imagen por lista de SharePoint (6 * 32 = 192). No obstante, dado que el límite por elemento de lista de SharePoint es de bytes, de los cuales 256 bytes están reservados para columnas de SharePoint integradas, el límite real es de 138 columnas de hipervínculo o imagen. Calculado 48 Umbral 28 bytes El ajuste de las filas de SQL Server se realiza después de cada 8 columnas en una lista de SharePoint. El valor de ajuste de fila predeterminado de seis permite un máximo de 48 columnas Calculado por lista de SharePoint (6 * 8 = 48). GUID 6 Umbral 20 bytes El ajuste de las filas de SQL Server se realiza después de cada columna en una lista de SharePoint. El valor de ajuste de fila predeterminado de seis permite un máximo de 6 columnas GUID por lista de SharePoint (6 * 1 = 6). Int 96 Umbral 4 bytes El ajuste de las filas de SQL Server se realiza después de cada 16 columnas en una lista de

115 Límite Valor máximo Tipo de límite Tamaño por columna Notas SharePoint. El valor de ajuste de fila predeterminado de seis permite un máximo de 96 columnas Int por lista de SharePoint (6 * 16 = 96). Metadatos administrados 94 Umbral 40 bytes para el primero, 32 bytes para cada uno de los siguientes Al primer campo de metadatos administrados agregado a una lista se asignan cuatro columnas: Campo de búsqueda para la etiqueta real Campo de texto oculto para el valor de cadena Un campo de búsqueda para el detectar todo Un campo de búsqueda para el desbordamiento del detectar todo Cada campo de metadatos administrados subsiguiente agregado a una lista agrega dos columnas más: Campo de búsqueda para la etiqueta real Campo de texto oculto para el valor de cadena El número máximo de columnas de metadatos administrados se calcula como (14 + (16 * (n-1))), donde n es el valor de asignación de fila (predeterminado como 6). Las columnas de datos externos tienen el concepto de una columna principal y columnas secundarias. Cuando se agrega una columna de datos externos, se pueden seleccionar algunos campos secundarios del tipo de contenido externo que se desea agregar a la lista. Por ejemplo, en el caso de un tipo de contenido externo Cliente que tiene campos como Id., Nombre, País y Descripción, cuando se agrega una columna de datos externos del tipo Cliente a una lista, se pueden agregar campos secundarios para mostrar el Id., Nombre y Descripción del cliente. En general, éstas son las columnas que se agregan: 115

116 Columna principal: un campo de texto. Columna Id. oculta: un campo de texto multilínea. Columnas secundarias: cada columna secundaria es un texto/número/expresión booleana/texto multilínea basado en el tipo de datos de la columna secundaria definido en el modelo del Catálogo de datos profesionales. Por ejemplo, Id. podría asignarse a una columna Número; Nombre podría asignarse a una columna de línea de texto única; Descripción podría asignarse a una columna de líneas de texto múltiples. Límites de páginas En la siguiente tabla se enumeran las recomendaciones para páginas. Límite Valor máximo Tipo de límite Notas Elementos web 25 por página wiki o de elemento web Umbral Esta cifra es una estimación basada en elementos web simples. La complejidad de los elementos web determina cuántos elementos web se pueden usar en una página sin que se vea afectado el rendimiento. 116

117 Límites de seguridad Límite Valor máximo Tipo de límite Notas Número de grupos de SharePoint al que puede pertenecer un usuario Compatible No es un límite estricto pero es coherente con las directrices de Active Directory. Hay varias cosas que pueden afectar a este número: El tamaño del token de usuario La memoria caché de grupos: SharePoint Server 2010 tiene una tabla que almacena en caché el número de grupos a los que pertenece un usuario en cuanto dichos grupos se usan en listas de control de acceso (ACL). El tiempo de comprobación de seguridad: a medida que aumenta el número de grupos del que un usuario es miembro, también aumenta el tiempo requerido para la comprobación de acceso. Usuarios de una colección de sitios 2 millones por colección de sitios Compatible Puede agregar millones de personas al sitio web mediante grupos de seguridad de Microsoft Windows para administrar la seguridad en vez de usar usuarios individuales. Este límite se basa en la capacidad de administración y facilidad de navegación en la interfaz de usuario. Cuando hay muchas entradas (grupos de seguridad de usuarios) en la colección de 117

118 Límite Valor máximo Tipo de límite Notas sitios (más de mil), debe usar Windows PowerShell para administrar los usuarios en vez de la UI. Esto proporcionará una mejor experiencia de administración. Principios/usuarios de Active Directory en un grupo de SharePoint por grupo de SharePoint Compatible SharePoint Server 2010 permite agregar usuarios o grupos de Active Directory a un grupo de SharePoint. Tener hasta usuarios (o grupos o usuarios de Active Directory) en un grupo de SharePoint proporciona un rendimiento aceptable. Las actividades más afectadas por este límite son las siguientes: Capturar usuarios para validar permisos. Esta operación requiere cada vez más tiempo a medida que aumenta el número de usuarios de un grupo. Representar la pertenencia de la vista. Esta operación siempre requiere tiempo. Grupos de SharePoint por colección de sitios Compatible Por encima de grupos, el tiempo para ejecutar operaciones aumenta de forma considerable. Esto ocurre especialmente cuando se agrega un usuario a un grupo existente, cuando se crea un nuevo grupo y cuando se representan vistas de grupo. Entidad de seguridad: tamaño del ámbito de seguridad por lista de control de acceso (ACL) Compatible El tamaño del ámbito afecta a los datos que se usan para un cálculo de comprobación de 118

119 Límite Valor máximo Tipo de límite Notas seguridad. Este cálculo se realiza cada vez que cambia el ámbito. No hay un límite estricto, pero cuanto más grande sea el ámbito, más tiempo llevará el cálculo. Límites por característica En esta sección se enumeran los límites ordenados por característica. Límites de búsqueda En la siguiente tabla se enumeran las recomendaciones para búsquedas. Límite Valor máximo Tipo de límite Notas Aplicaciones de servicio de búsqueda de SharePoint Bases de datos de rastreo y elementos de bases de datos 20 por granja de servidores Compatible Pueden implementarse varias aplicaciones de servicio de búsqueda de SharePoint en la misma granja de servidores, ya que se pueden asignar bases de datos y componentes de búsqueda a distintos servidores. El límite recomendado de 20 es inferior al límite máximo para todas las aplicaciones de servicio de una granja de servidores. 10 bases de datos de rastreo por aplicación de servicio de búsqueda 25 millones de elementos por base de datos de rastreo Umbral La base de datos de rastreo almacena los datos de rastreo (tiempo/estado, etc.) acerca de todos los elementos que se han rastreado. El límite admitido es de 119

120 Límite Valor máximo Tipo de límite Notas bases de datos de rastreo por aplicación de servicio de búsqueda de SharePoint. El límite recomendado es de 25 millones de elementos por base de datos de rastreo (o un total de cuatro bases de datos de rastreo por aplicación de servicio de búsqueda). Componentes de rastreo 16 por aplicación de servicio de búsqueda Umbral El límite recomendado por aplicación es de 16 componentes de rastreo en total, a razón de dos por base de datos de rastreo, y dos por servidor, suponiendo que el servidor tiene al menos ocho procesadores (núcleos). El número total de componentes de rastreo por servidor debe ser inferior a 128/(total de componentes de consulta) para minimizar la degradación de E/S de propagación. Aunque se exceda el límite recomendado, es posible que no aumente el rendimiento del rastreo; de hecho, el rendimiento de rastreo podría bajar reducirse en función de los recursos disponibles en el servidor de rastreo, la base de datos y el host de contenido.

121 Límite Valor máximo Tipo de límite Notas Particiones de índice Elementos indizados 20 por aplicación de servicio de búsqueda; 128 en total 100 millones por aplicación de servicio de búsqueda; 10 millones por partición de índice 121 Umbral Compatible La partición de índice contiene un subconjunto del índice de aplicación de servicio de búsqueda. El límite recomendado es de 20. Si se aumenta el número de particiones de índice, cada partición contendrá un subconjunto más pequeño del índice, lo que reduce la RAM y el espacio en disco necesarios en el servidor de consulta que hospeda el componente de consulta asignado a la partición de índice. El límite máximo para el número total de particiones de índice es de 128. SharePoint Search admite particiones de índice, cada una de las cuales contiene un subconjunto del índice de búsqueda. El máximo recomendado es de 10 millones de elementos en cualquier partición. El número máximo total de elementos recomendado (por ejemplo, personas, elementos de lista, documentos, páginas web) es de 100 millones. Entradas de registro de rastreo 100 millones por aplicación de búsqueda Compatible Éste es el número de entradas de registro individuales en el registro

122 Límite Valor máximo Tipo de límite Notas Base de datos de propiedades Componentes de consulta Reglas de ámbito 10 por aplicación de servicio de búsqueda;128 en total 128 por aplicación de búsqueda; 64/(total de componentes de rastreo) por servidor 100 reglas de ámbito por ámbito; 600 en total por aplicación de servicio de búsqueda 122 Umbral Umbral Umbral de rastreo. Sigue el límite de "elementos indizados". La base de datos de propiedades almacena los metadatos de los elementos de cada partición de índice asociados con ella. Una partición de índice puede estar asociada con un solo almacén de propiedades. El límite recomendado es de 10 bases de datos de propiedades por aplicación de servicio de búsqueda. El límite máximo para particiones de índice es de 128. El número total de componentes de consulta está limitado por la capacidad de los componentes de rastreo de copiar archivos. El número máximo de componentes de consulta por servidor está limitado por la capacidad de los componentes de consulta de absorber archivos propagados desde componentes de rastreo. Si se excede este límite, se reducirá la actualización del rastreo y se retrasarán los resultados potenciales de las consultas del ámbito.

123 Límite Valor máximo Tipo de límite Notas Ámbitos 200 por sitio Umbral Éste es un límite recomendado por sitio. Si se excede este límite, se puede reducir la eficiencia del rastreo y, si se agregan los ámbitos al grupo de presentación, puede resultar afectada la latencia del explorador de usuario final. Además, la presentación de los ámbitos en la interfaz de administración de búsqueda se degrada a medida que el número de ámbitos excede el límite recomendado. Grupos de presentación 25 por sitio Umbral Los grupos de presentación se usan para la presentación agrupada de ámbitos a través de la interfaz de usuario. Si se excede este límite, comienza a degradarse la experiencia de ámbito en la interfaz de administración de búsqueda. Alertas por aplicación de búsqueda Compatible Éste es el límite probado. Orígenes de contenido 50 por aplicación de servicio de búsqueda Umbral El límite recomendado de 50 puede excederse hasta el límite máximo de 500 por aplicación de servicio de búsqueda. No obstante, deben usarse menos direcciones de comienzo y debe seguirse el límite de rastreo 123

124 Límite Valor máximo Tipo de límite Notas 124 simultáneo. Direcciones de comienzo 100 por origen de contenido Umbral El límite recomendado puede excederse hasta el límite máximo de 500 por origen de contenido. No obstante, cuantas más direcciones tenga, menos orígenes de contenido deben usarse. Si tiene muchas direcciones de comienzo, recomendamos colocarlas como vínculos en una página HTML y hacer que el rastreador HTTP rastree la página, siguiendo los vínculos. Rastreos simultáneos 20 por aplicación de búsqueda Umbral Éste es el número de rastreos que pueden realizarse al mismo tiempo. Si se excede este número, la velocidad de rastreo general puede reducirse. Propiedades rastreadas por aplicación de búsqueda Compatible Éstas son las propiedades detectadas durante un rastreo. Regla de impacto de rastreo 100 Umbral Límite recomendado de 100 por granja de servidores. La cantidad recomendada puede excederse, pero se degradará la presentación de las reglas de acceso al sitio en la interfaz de administración de búsqueda. Con aproximadamente reglas de acceso al sitio, la

125 Límite Valor máximo Tipo de límite Notas 125 página Administrar reglas de acceso al sitio se vuelve ilegible. Reglas de rastreo 100 por aplicación de servicio de búsqueda Umbral Este valor puede excederse, pero se degradará la presentación de las reglas de rastreo en la interfaz de administración de búsqueda. Propiedades administradas por aplicación de servicio de búsqueda Umbral Éstas son las propiedades que usa el sistema de búsqueda en las consultas. Las propiedades rastreadas se asignan a propiedades administradas. Asignaciones 100 por propiedad administrada Umbral Si se excede este límite, puede reducirse la velocidad de rastreo y rendimiento de las consultas. Eliminación de direcciones URL 100 eliminaciones por operación Compatible Éste es el número máximo recomendado de direcciones URL que deberían quitarse del sistema en una misma operación. Páginas relevantes 1 página de primer nivel y la menor cantidad posible de páginas de segundo y tercer nivel por aplicación de servicio de búsqueda Umbral El límite recomendado es de una página relevante de primer nivel y la menor cantidad posible de páginas de segundo y tercer nivel para lograr la relevancia deseada. El límite máximo es de 200 por nivel de relevancia por aplicación de búsqueda, pero aunque se agreguen más páginas, es posible que no se logre la relevancia

126 Límite Valor máximo Tipo de límite Notas deseada. Agregue el sitio clave al primer nivel de relevancia. Agregue más sitios clave al segundo o tercer nivel de relevancia, de a uno a la vez, y evalúe la relevancia después de cada adición para asegurarse de que se ha logrado el efecto de relevancia deseado. Palabras clave: 200 por colección de sitios Compatible El límite recomendado puede excederse hasta el límite máximo (impuestos por ASP.NET) de por colección de sitios, con cinco opciones más probables por palabra clave. Si se excede este límite, la presentación de palabras clave en la interfaz de usuario de administración del sitio se degradará. El límite impuesto por ASP.NET puede modificarse editando los archivos Web.Config y Client.config (MaxItemsInObjectGraph). Propiedades de metadatos reconocidas por elemento rastreado Límite máximo Éste es el número de propiedades de metadatos que se pueden determinar y potencialmente asignar o usar para consultas cuando se rastrea un elemento. 126

127 Límites de servicio de perfiles de usuario En la siguiente tabla se enumeran las recomendaciones para el servicio de perfiles de usuario. Límite Valor máximo Tipo de límite Notas Perfiles de usuario por aplicación de servicio Compatible Una aplicación de servicio de perfiles de usuario puede admitir hasta 2 millones de perfiles de usuario con funcionalidad de características sociales completas. Este número representa el número de perfiles que se puede importar en el almacén de perfiles de personas desde un servicio de directorio, y también el número de perfiles que una aplicación de servicio de perfiles de usuario puede admitir sin producir reducciones en el rendimiento de las 127

128 Límite Valor máximo Tipo de límite Notas características sociales. Etiquetas temáticas, notas y clasificaciones por base de datos social Compatible Se admiten hasta 500 millones en total de etiquetas temáticas, notas y clasificaciones en una base de datos social sin reducciones importantes en el rendimiento. No obstante, las operaciones de mantenimiento de bases de datos, como copia de seguridad y restauración, pueden presentar una reducción del rendimiento al llegar a ese punto. Límites de distribución de contenido En la siguiente tabla se enumeran las recomendaciones para la distribución de contenido. 128

129 Límite Valor máximo Tipo de límite Notas Trabajos de distribución de contenido que se ejecutan en diferentes rutas de acceso 20 Compatible En el caso de trabajos simultáneos en rutas de acceso conectadas a colecciones de sitios en la misma base de datos de contenido de origen, hay un riesgo mayor de interbloqueos en la base de datos. En el caso de trabajos que se deben ejecutar simultáneamente, recomendamos mover las colecciones de sitios a diferentes bases de datos de contenido de origen. Nota: No es posible realizar trabajos simultáneos en la misma ruta de acceso. Si usa instantáneas de SQL Server para la distribución de contenido, cada ruta de acceso crea una instantánea. Esto aumenta los requisitos de E/S de la base de datos de origen. Para obtener más información, vea el tema sobre rutas de acceso y trabajos de distribución. Límites de blogs En la siguiente tabla se enumeran las recomendaciones para blogs. Límite Valor máximo Tipo de límite Notas Entradas de blog por sitio Compatible El número máximo de 129

130 Límite Valor máximo Tipo de límite Notas entradas de blog es de por sitio. Comentarios por entrada Compatible El número máximo de comentarios es de por entrada. Límites de Servicios de conectividad empresarial En la siguiente tabla se enumeran las recomendaciones para Servicios de conectividad empresarial. Límite Valor máximo Tipo de límite Notas ECT (en memoria) por servidor web (por inquilino) Límite máximo Número total de definiciones de tipo de contenido externo (ECT) cargadas en la memoria en un determinado momento en un servidor web. Conexiones de sistema externo 500 por servidor web Límite máximo El número de conexiones de sistema externo activas/abiertas en un determinado momento. El valor máximo predeterminado es de 200; el límite máximo es 130

131 Límite Valor máximo Tipo de límite Notas Elementos de base de datos devueltos por solicitud 131 de 500. Este límite se aplica en el ámbito del servidor web, independientemente del tipo de sistema externo (por ejemplo, base de datos, ensamblado.net, etc.). El máximo predeterminado se usa para restringir el número de conexiones. Una aplicación puede especificar un límite más grande a través del contexto de ejecución; el límite máximo aplica el máximo incluso para aplicaciones que no respetan el valor predeterminado por conector de base de datos Umbral Número de elementos por solicitud que puede devolver el conector de base de datos. El conector de la base de datos usa el máximo predeterminado de para restringir el número de resultados que se pueden devolver por página. Una aplicación

132 Límite Valor máximo Tipo de límite Notas puede especificar un límite más grande a través del contexto de ejecución; el máximo absoluto aplica el máximo incluso para aplicaciones que no respetan el valor predeterminado. El límite máximo para este límite es de Límites de flujos de trabajo En la siguiente tabla se enumeran las recomendaciones para flujos de trabajo. Límite Valor máximo Tipo de límite Notas Umbral de aplazamiento de flujo de trabajo 15 Umbral 15 es el número máximo de flujos de trabajo que se pueden ejecutar simultáneamente respecto de una base de datos de contenido, excluidas las instancias que se ejecutan en el servicio del temporizador. Cuando se alcanza este umbral, las nuevas solicitudes 132

133 Límite Valor máximo Tipo de límite Notas 133 para activar flujos de trabajo se colocarán en cola para que el servicio de temporizador de flujo de trabajo las ejecute posteriormente. A medida que se realiza la ejecución sin temporizador, se tendrán en cuenta las nuevas solicitudes para determinar el umbral. Este límite puede configurarse mediante el cmdlet Set-SPFarmConfig de Windows PowerShell. Para obtener más información, vea Set- SPFarmConfig. Nota: este límite no se refiere al número total de instancias de flujo de trabajo que pueden estar en curso sino al número de instancias que se está procesando. Si se aumenta este límite, aumentará el

134 Límite Valor máximo Tipo de límite Notas Tamaño de lote de temporizador de flujo de trabajo rendimiento del comienzo y finalización de tareas de flujo de trabajo pero también aumentará la carga de la base de datos de contenido y los recursos del sistema. 100 Umbral El número de eventos que cada ejecución del trabajo del temporizador de flujo de trabajo capturará y entregará a los flujos de trabajo. Puede configurarse mediante Windows PowerShell. Para permitir eventos adicionales, se pueden ejecutar instancias adicionales del servicio del temporizador de flujo de trabajo de Microsoft SharePoint Foundation. Límites de almacén de términos de metadatos administrados (base de datos) En la siguiente tabla se enumeran las recomendaciones para almacenes de términos de metadatos administrados. 134

135 Límite Valor máximo Tipo de límite Notas Número máximo de niveles de términos anidados en un almacén de términos Número máximo de conjuntos de términos en un almacén de términos Número máximo de términos en un conjunto de términos 7 Compatible Los términos de un conjunto de términos pueden representarse jerárquicamente. Un conjunto de términos puede tener hasta siete niveles de términos (un término principal y seis niveles de anidación debajo de él.) 1000 Compatible Puede tener hasta conjuntos de términos en un almacén de términos Compatible es el número máximo de términos que puede haber en un conjunto de términos. Nota: Las etiquetas adicionales correspondientes al mismo término, como sinónimos y traducciones, no se cuentan como términos separados. Número total de elementos en un almacén de términos Compatible Un elemento es un término o un conjunto de términos. La suma del número de términos y conjuntos de términos no puede exceder Las etiquetas adicionales correspondientes al mismo término, como sinónimos y traducciones, no se cuentan como términos separados. 135

136 Límite Valor máximo Tipo de límite Notas Nota: No se puede tener el número máximo de conjuntos de términos y el número máximo de términos simultáneamente en un almacén de términos. Límites de Servicios de Visio En la siguiente tabla se enumeran las recomendaciones para instancias de Servicios de Visio en Microsoft SharePoint Server Límite Valor máximo Tipo de límite Notas Tamaño de archivos de dibujos web de Visio 50 MB Umbral Servicios de Visio tiene una opción de configuración que permite al administrador cambiar el tamaño máximo de los dibujos web que procesa Visio. Los tamaños de archivo más grandes tienen los siguientes efectos colaterales: Aumento de la huella de memoria de Servicios de Visio. Aumento en el uso de la CPU. Reducción de la cantidad de solicitudes de servidor de aplicaciones por segundo. Aumento de la latencia general. 136

137 Límite Valor máximo Tipo de límite Notas Aumento de la carga de la red de granjas de servidores de SharePoint. Tiempo de espera de recálculo de dibujo web de Visio 120 segundos Umbral Servicios de Visio tiene una opción de configuración que permite al administrador cambiar el tiempo máximo que puede pasar recalculando un dibujo después de actualizar los datos. Un mayor tiempo de espera de recálculo tiene las siguientes consecuencias: Reducción de la disponibilidad de la CPU y la memoria. Reducción en la cantidad de solicitudes de aplicaciones por segundo. Aumento de la latencia promedio en todos los documentos. Un menor tiempo de espera de recálculo tiene las siguientes consecuencias: Reducción de la complejidad de los diagramas que se pueden mostrar. Aumento de la cantidad de solicitudes por segundo. Reducción de la latencia promedio en todos los documentos. Edad de caché mínima de Servicios Edad mínima de caché: 0 a 24 horas Umbral La edad de caché mínima se aplica a diagramas 137

138 Límite Valor máximo Tipo de límite de Visio (diagramas conectados a datos) Notas conectados a datos. Determina la cantidad de tiempo que debe pasar para poder quitar el diagrama actual de la memoria caché. Si la edad mínima de caché se establece a un valor muy bajo, se reducirá el rendimiento y aumentará la latencia, ya que la invalidación de la memoria caché suele obligar a Visio a recalcular frecuentemente y reduce la disponibilidad de la CPU y la memoria. Edad de caché máxima de Servicios de Visio (diagramas no conectados a datos) Edad máxima de caché: 0 a 24 horas Umbral La edad de caché máxima se aplica a diagramas no conectados a datos. Este valor determina cuánto tiempo se mantendrá el diagrama actual en la memoria. Si se aumenta la edad máxima de caché, se reduce la latencia para los dibujos comúnmente solicitados. No obstante, si se establece la edad máxima de caché en un valor muy alto, aumentará la latencia y se reducirá el rendimiento en el caso de elementos no almacenados en la memoria caché, ya que aquellos elementos que ya están en la memoria caché consumen y reducen la memoria disponible. Límites de PerformancePoint Services En la siguiente tabla se enumeran las recomendaciones para PerformancePoint Services in Microsoft SharePoint Server

139 Límite Valor máximo Tipo de límite Notas Celdas por consulta en origen de datos de Servicios de Excel Límite máximo Un cuadro de mandos de PerformancePoint que llama a un origen de datos de Servicios de Excel está sujeto a un límite de no más de celdas por consulta. Columnas y filas 15 columnas por filas Umbral El número máximo de columnas y filas al representar cualquier objeto de panel de PerformancePoint que usa un libro de Microsoft Excel como origen de datos. El número de filas podría cambiar según el número de columnas. Consulta a una lista de SharePoint 15 columnas por filas Compatible El número máximo de columnas y filas al representar cualquier objeto de panel de PerformancePoint que usa una lista de SharePoint como origen de datos. El número de filas podría cambiar según el 139

140 Límite Valor máximo Tipo de límite Notas número de columnas. Consulta a un origen de datos de SQL Server 15 columnas por filas Compatible El número máximo de columnas y filas al representar cualquier objeto de panel de PerformancePoint que usa una tabla de SQL Server como origen de datos. El número de filas podría cambiar según el número de columnas. Límites de Word Automation Services En la siguiente tabla se enumeran las recomendaciones para Word Automation Services. Límite Valor máximo Tipo de límite Notas Tamaño de archivo de entrada 512 MB Límite máximo El tamaño de archivo máximo que se puede procesar con Word Automation Services. Frecuencia con la que se inician conversiones (minutos) 1 minuto (recomendado) 15 minutos (predeterminado) 59 minutos (límite máximo) Umbral Este valor determina la frecuencia con la que se ejecuta el trabajo del temporizador de Word Automation Services. Un número menor hace que el trabajo del temporizador se ejecute más rápido. Nuestras pruebas demuestran que es más útil ejecutar este trabajo del temporizador una vez por minuto. Número de conversiones que se Para formatos de salida PDF/XPS: Umbral El número de conversiones que se inician afecta 140

141 Límite Valor máximo Tipo de límite Notas inician por proceso de conversión 30 x M. Para todos los demás formatos de salida: 72 x M, donde M es el valor de la frecuencia con la que se inician las conversiones (minutos). Tamaño del trabajo de conversión elementos de conversión Compatible Total de procesos de conversión activos N-1, donde N es el número de núcleos en cada servidor de aplicaciones 141 Umbral al rendimiento de Word Automation Services. Si estos valores se establecen por encima de los niveles recomendados, es posible que algunos elementos de conversión comiencen a producir errores de forma intermitente y que los permisos del usuario expiren. Los permisos del usuario expiran 24 horas después del momento en que se inicia un trabajo de conversión. Un trabajo de conversión incluye uno o más elementos de conversión, cada uno de los cuales representa una sola conversión que se realiza en un único archivo de entrada en SharePoint. Cuando se inicia un trabajo de conversión (usando el método ConversionJob.Start), el trabajo de conversión y todos los elementos de conversión se transmiten a un servidor de aplicaciones que después almacena el trabajo en la base de datos de Word Automation Services. Si el número de elementos de conversión es grande, aumentará el tiempo de ejecución del método Start y el número de bytes transmitidos al servidor de aplicaciones. Un proceso de conversión activo puede consumir un solo núcleo de procesamiento. Por lo tanto, los clientes no deben ejecutar más procesos de conversión que la cantidad de núcleos de procesamiento que tienen sus servidores de aplicaciones. El trabajo del temporizador de conversión y otras actividades de SharePoint también requieren el uso ocasional de un núcleo

142 Límite Valor máximo Tipo de límite Notas Tamaño de la base de datos de Word Automation Services 2 millones de elementos de conversión Compatible de procesamiento. Recomendamos dejar siempre 1 núcleo libre para el trabajo del temporizador de conversión y SharePoint. Word Automation Services mantiene una cola persistente de elementos de conversión en su base de datos. Cada solicitud de conversión genera uno o varios registros. Word Automation Services no elimina los registros de la base de datos automáticamente, por lo que la base de datos puede crecer de forma indefinida sin mantenimiento. Los administradores pueden quitar manualmente el historial de trabajos de conversión usando el cmdlet Remove- SPWordConversionServiceJobHistory de Windows PowerShell. Para obtener más información, vea Remove- SPWordConversionServiceJobHistory. Límites de SharePoint Workspace En la siguiente tabla se enumeran las recomendaciones para Microsoft SharePoint Workspace Límite Valor máximo Tipo de límite Notas Sincronización con SharePoint Workspace elementos por lista Límite máximo SharePoint Workspace no sincroniza las listas que tienen más de

143 Límite Valor máximo Tipo de límite Notas Sincronización con SharePoint Workspace Límite de 1800 documentos en SharePoint Workspace Límite máximo elementos. Esta restricción existe porque el tiempo para descargar una lista que tiene más de elementos es muy largo y el uso de recursos es alto. Se advierte a los usuarios cuando tienen más de 500 documentos en SharePoint Workspace, pero pueden continuar agregando documentos. Límites de OneNote En la siguiente tabla se enumeran las recomendaciones para Servicios de Microsoft OneNote. Límite Valor máximo Tipo de límite Notas Número de secciones y grupos de sección en un bloc de notas de OneNote Vea el límite para "Documentos" en Límites de listas y bibliotecas 143 Cada sección se considera una carpeta y un documento en la lista.

144 Límite Valor máximo Tipo de límite Notas (en SharePoint) Tamaño máximo de una sección Tamaño máximo de una imagen, archivo incrustado y copia impresa XPS de OneNote en una sección de OneNote. Tamaño máximo de todas las imágenes, archivos incrustados y copias impresas XPS en una sola página de OneNote. Vea el límite para el "tamaño de archivo" en los límites de listas y bibliotecas Vea el límite para el "tamaño de archivo" en los límites de listas y bibliotecas El límite predeterminado es el doble del límite de "Tamaño de archivos". 144 Umbral Cada grupo de secciones se cuenta como una carpeta y un documento en la lista. Este máximo excluye las imágenes, archivos incrustados y copias impresas XPS para OneNote de más de 100 KB. Las imágenes y los archivos incrustados de más de 100 KB se dividen en sus propios archivos binarios. Esto significa que una sección con 100 KB de datos con tipo y cuatro documentos incrustados de Word de 1 MB cada uno se considerarán una sección de 100 KB. Cada elemento se almacena como un archivo binario independiente y, por lo tanto, está sujeto a los límites de tamaño de archivo. Cada operación de impresión de OneNote dará como resultado un archivo binario de copia impresa XPS, incluso si la copia impresa contiene varias páginas. Esto se aplica al contenido incrustado en una sola página de OneNote, no a una sección o bloc de notas. Si los usuarios encuentran esto, aparecerá el siguiente error en OneNote: jerrcstorageurl_hottablefull (0xE ). Los usuarios pueden solucionar esto mediante la división

145 Límite Valor máximo Tipo de límite Notas Operaciones de combinación Una por núcleo de CPU por servidor web Límite máximo del contenido incrustado en distintas páginas y eliminando las versiones anteriores de la página. Si los usuarios tienen que ajustar este valor ( Max Hot Table Size ), el límite efectivo es la mitad del valor absoluto que definen (por ejemplo, si se especifica un tamaño máximo de tabla dinámica de 400 MB, significa que el tamaño máximo de todo el contenido incrustado en una página está limitado a 200 MB). OneNote combina los cambios de combinación de varios usuarios que son co-autores de un bloc de notas. Si hay un núcleo de CPU disponible para ejecutar una combinación, se genera una página de conflicto, que obliga al usuario a realizar la combinación manualmente). Este límite se aplica si OneNote se ejecuta como una aplicación cliente o como Microsoft Office Web Apps. Límites de Office Web Application Service En la siguiente tabla se enumeran las recomendaciones para Office Web Apps. Los límites de aplicaciones cliente de Office también se aplican cuando una aplicación se ejecuta como una aplicación web. 145

146 Límite Valor máximo Tipo de límite Notas Tamaño de caché 100 GB Umbral Espacio disponible para representar documentos, creado como parte de una base de datos de contenido. De forma predeterminada, la memoria caché disponible para representar documentos es de 100 GB. No se recomienda aumentar la memoria caché disponible. Representaciones Uno por documento por segundo por núcleo de Límite máximo CPU por servidor de aplicaciones (máximo de ocho núcleos) Es el número promedio medido de representaciones que pueden realizarse de documentos "típicos" en el servidor de aplicaciones durante un determinado período de tiempo. Límites de Project Server En la siguiente tabla se enumeran las recomendaciones para Microsoft Project Server. Para obtener más información acerca de cómo planear para Project Server, vea Planning and architecture for Project Server

147 Límite Valor máximo Tipo de límite Notas Final de tiempo del proyecto Fecha: 31/12/2049 Límite máximo Los planes de Project no se pueden extender más allá del 31/12/2049. Entregas por plan del proyecto entregas Límite máximo Los planes de Project no pueden contener más de entregas. Número de campos de una vista 256 Límite máximo El usuario no puede agregar más de 256 campos a una vista definida en Project Web App. Número de cláusulas en un filtro de una vista 50 Límite máximo El usuario no puede agregar un filtro a una vista que tiene más de 50 cláusulas. 147

148 Performance and capacity technical case studies (SharePoint Server 2010) (en inglés) This section contains technical case studies that describe specific deployments of Microsoft SharePoint Server Compare the scenarios in these documents to your planned workload and usage characteristics. If your planned design is similar, you can use the documented deployment as a starting point for your own installation. These articles include information about environments, such as: Environment specifications, such as hardware, farm topology, and configuration The workload used for data generation, including the number and class of users, and farm usage characteristics Farm dataset, including database contents, Search indexes, and external data sources Health and performance data specific to the environment Performance data and recommendations for how to determine the hardware, topology, and configuration you need to deploy a similar environment, and how to optimize your environment for appropriate capacity and performance characteristics Before reading these articles, it is important that you understand the key concepts behind capacity management in SharePoint Server For more information, see Capacity management and sizing for SharePoint Server 2010 (en inglés). In this section: Publishing Entorno de publicación de intranet de empresa de Microsoft SharePoint Server 2010: caso práctico técnico Describes the published intranet environment used by employees at Microsoft. Enterprise Intranet Collaboration Enterprise intranet collaboration environment technical case study (SharePoint Server 2010) (en inglés) Describes an environment that hosts mission-critical team sites and publishing portals for internal organizations, teams, and projects. Enterprise intranet collaboration environment lab study (SharePoint Server 2010) (en inglés) 148

149 Describes lab testing performed on a similar environment to the enterprise Intranet collaboration environment. Departmental Collaboration Social Departmental collaboration environment technical case study (SharePoint Server 2010) (en inglés) Describes a departmental collaboration environment used by employees of one department inside Microsoft. Divisional portal environment lab study (SharePoint Server 2010) (en inglés) Describes lab testing performed on a similar environment to the departmental collaboration environment. Social environment technical case study (SharePoint Server 2010) (en inglés) Describes an environment that hosts My Sites that present employee information to the wider organization. The environment serves as a central location for personal sites and shared documents. Microsoft SharePoint Server 2010 social environment: Lab study Provides guidance on performance and capacity planning for a My Site and social computing portal based on SharePoint Server

150 Entorno de publicación de intranet de empresa de Microsoft SharePoint Server 2010: caso práctico técnico En este documento se describe una implementación específica de Microsoft SharePoint Server Se incluye lo siguiente: Especificaciones del entorno del caso práctico técnico como hardware, topología de conjunto o granja de servidores y configuración. La carga de trabajo, que incluye cantidad y tipos de usuarios o clientes y características de uso del entorno. Conjunto de datos de la granja de servidores del caso práctico técnico, que incluye el contenido de la base de datos y los índices de búsqueda. Datos de mantenimiento y rendimiento específicos del entorno. En este artículo: Información de requisitos previos Introducción a este entorno Especificaciones Carga de trabajo Conjunto de datos Datos de mantenimiento y rendimiento Información de requisitos previos Antes de leer este documento, asegúrese de comprender los conceptos clave sobre la administración de capacidad de SharePoint Server 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. Para obtener más información conceptual sobre el rendimiento y la capacidad que puede servirle para comprender el contexto de los datos en este caso práctico, vea los siguientes documentos: 150

151 Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server 2010 Administración de la capacidad de SharePoint Server 2010: restricciones y límites del software Introducción a este entorno En estas notas del producto se describe un entorno real de SharePoint Server 2010 en Microsoft. Use este documento para comparar las características de este entorno con las características de uso y de carga de trabajo planeadas. Si el diseño que ha planeado es similar, puede usar la implementación descrita en este artículo como punto de partida de su propia instalación. En este documento se incluye lo siguiente: Especificaciones, entre las que se incluye el hardware, la topología y la configuración Carga de trabajo, que es la demanda en la granja de servidores e incluye la cantidad de usuarios y las características de uso Conjunto de datos, que incluye los tamaños de base de datos Datos de mantenimiento y rendimiento específicos del entorno Este documento forma parte de una serie de Performance and capacity technical case studies (SharePoint Server 2010) (en inglés) sobre entornos de SharePoint en Microsoft. 151

152 El entorno de SharePoint Server 2010 descrito en este documento es un entorno de producción de una compañía de gran tamaño distribuida geográficamente. Los empleados visualizan contenido diverso, como noticias, artículos técnicos, perfiles de empleados, documentación y recursos de aprendizaje. Los empleados también usan este entorno para llevar a cabo consultas de búsqueda en todos los entornos de SharePoint de la compañía. Reciben a diario mensajes de correo electrónico con vínculos a artículos en el entorno y muchos de ellos lo establecen como la página principal de su explorador. Hasta usuarios exclusivos visitan el entorno en un día ajetreado, lo que genera hasta 345 solicitudes por segundo (RPS) en horas pico. Dado que se trata de un sitio de intranet, todos los usuarios están autenticados. Si bien el contenido se publica mediante un modelo de autor en contexto de entorno único, el procedimiento de publicación del entorno especifica que todos los borradores del contenido deben publicarse a la vez durante la noche fuera de horas pico. La información proporcionada en este documento refleja el entorno de publicación en la intranet empresarial en un día normal. Especificaciones En esta sección se ofrece información detallada sobre el hardware, el software, la topología y la configuración del entorno del caso práctico. Hardware En esta sección se proporcionan detalles sobre los equipos servidores usados en el entorno. Nota: Este entorno se ha escalado para dar cabida a versiones preliminares de SharePoint Server 2010 y otros productos. Por consiguiente, el hardware implementado tiene más capacidad que la necesaria para satisfacer la demanda que normalmente experimenta ese entorno. Este hardware se describe únicamente para proporcionar contexto adicional para este entorno y a modo de punto de partida para entornos similares. Es importante que realice su propia administración de capacidad en función de las características de uso y de carga de trabajo planeadas. Para obtener más información acerca del proceso de administración de capacidad, vea Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server

153 Servidores web La granja cuenta con cuatro servidores web cuyo hardware es idéntico. Tres de ellos sirven contenido y el cuarto es un objetivo de rastreo de búsqueda dedicado. Servidor web Procesadores RAM Sistema operativo WFE1-4 2 procesadores de cuatro núcleos de 2,33 GHz 32 GB Windows Server 2008 de 64 bits Tamaño de la unidad de SharePoint Número de adaptadores de red 2 Velocidad del adaptador de red Autenticación Tipo de equilibrador de carga Versión de software Servicios que se ejecutan localmente Servicios que se consumen desde una granja de servicios federados GB 1 Gigabit Windows NTLM Equilibrio de carga de hardware SharePoint Server 2010 (versión preliminar) Administración central 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 Servicio de perfiles de usuario Servicio web de Web Analytics

154 Servidor web WFE1-4 Servicio de conectividad a datos empresariales Servicio web de metadatos administrados Servidor de aplicaciones No hay ningún servidor de aplicaciones en la granja de servidores. Los servicios locales se hospedan en los servidores web y los demás servicios se consumen desde una granja de servicios federados. Servidores de bases de datos Hay un clúster de SQL con dos servidores de bases de datos cuyo hardware es idéntico. Uno de los servidores está activo y el otro es pasivo como copia adicional. Servidor de bases de datos Procesadores RAM Sistema operativo DB1-2 4 procesadores de cuatro núcleos de 2,4 GHz 32 GB Windows Server 2008 de 64 bits Almacenamiento y geometría Número de adaptadores de red 2 Velocidad del adaptador de red Autenticación (1,25 TB * 6) + 3 TB Discos 1-4: datos de SQL Disco 5: registros Disco 6: TempDB Gigabit Windows NTLM Versión de software SQL Server 2008

155 Topología En el siguiente diagrama se muestra la topología de esta granja. 155

156 156

157 Configuración En la siguiente tabla se enumeran los valores que se modificaron y afectan al rendimiento o la capacidad del entorno. Opción Valor Notas Administración de la colección de sitios: Caché de resultados de la colección de sitios Habilitada La habilitación de la memoria caché de resultados mejora la eficacia del servidor, ya que reduce las llamadas a la base de datos para los datos que se solicitan frecuentemente. Perfil de caché de la colección de sitios (seleccionar) Caché de objetos (deshabilitada n MB) Servicio de uso: Registro de seguimiento: días para almacenar los archivos de registro (valor predeterminado: 14 días) Umbral de registro de consulta: Base de datos de Microsoft SharePoint Foundation: configurar QueryLoggingThreshold en 1 segundo Servidor de bases de datos: instancia predeterminada: Intranet (sitio de colaboración) Habilitada: 500 MB La opción Permitir que los escritores vean contenido almacenado en caché está activada, lo que ocasiona que se pase por alto el comportamiento normal de no permitir a los usuarios con permisos de edición almacenar sus páginas en la memoria caché. El valor predeterminado es 100 MB. El aumento de este valor permite que se almacenen datos adicionales en la memoria del servidor front-end web. 5 días El valor predeterminado es 14 días. La disminución de este valor puede ahorrar espacio en disco en el servidor donde se almacenan los archivos de registro. 1 segundo El valor predeterminado es 5 segundos. La disminución de este valor puede ahorrar ancho de banda y CPU en el servidor de bases de datos. 1 El valor predeterminado es 0. Para garantizar un óptimo rendimiento, se recomienda fehacientemente establecer el grado máximo de paralelismo en 1 para servidores de 157

158 Opción Valor Notas Grado de paralelismo máximo bases de datos que hospedan bases de datos de SharePoint Server Para obtener más información acerca de cómo establecer el grado máximo de paralelismo, vea el tema sobre max degree of parallelism (opción)( Carga de trabajo En esta sección se describe la carga de trabajo, que es la demanda en la granja de servidores e incluye la cantidad de usuarios y las características de uso. Características de la carga de trabajo Valor Promedio de solicitudes por segundo (RPS) 100 Promedio de RPS en horas pico (de 11 a. m. a 3 p. m.) 226 Número total de usuarios únicos por día Promedio de usuarios simultáneos 172 Máximo de usuarios simultáneos 376 Nº total de solicitudes por día En esta tabla se muestra la cantidad de solicitudes para cada agente de usuario. Agente de usuario Solicitudes Porcentaje del total Explorador ,09% 158

159 Agente de usuario Solicitudes Porcentaje del total DAV ,07% Búsqueda (rastreo) ,75% OneNote ,05% Outlook 961 0,03% Word 449 0,01% Conjunto de datos En esta sección se describe el conjunto de datos de la granja de servidores del caso práctico, que incluye los tamaños de base de datos y los índices de búsqueda. Características del conjunto de datos Valor Tamaño de base de datos (combinado) 49,9 GB Tamaño BLOB 22,2 GB Número de bases de datos de contenido 3 Número de aplicaciones web 3 Número de colecciones de sitios 4 Número de sitios 797 Tamaño de índice de búsqueda (cantidad de elementos)

160 Datos de mantenimiento y rendimiento En esta sección se proporcionan los datos de mantenimiento y rendimiento específicos del entorno del caso práctico. Contadores generales Métrica Valor Disponibilidad (tiempo activo) 99,95% Frecuencia de errores 0,05% Promedio de memoria usada Máximo de memoria usada Porcentaje de tráfico del rastreo de búsqueda (Buscar solicitudes de clientes/solicitudes totales) 1,08 GB 2,60 GB Solicitudes de ASP.NET en cola 0,00 6% En los siguientes gráficos se muestra la latencia y el uso de CPU promedio de este entorno. 160

161 161

162 En este documento, la latencia se divide en cuatro categorías. La latencia de percentil 50 normalmente se usa para medir la capacidad de respuesta del servidor. Significa que la mitad de las solicitudes se atienden con ese tiempo de respuesta. La latencia de percentil 95 normalmente se usa para medir las puntas en los tiempos de respuesta del servidor. Significa que el 95% de las solicitudes se atienden dentro de este tiempo de respuesta y, por lo tanto, el 5% de las solicitudes sufren tiempos de respuesta más lentos. Contadores de la base de datos Al interpretar las estadísticas de la base de datos para este entorno de publicación empresarial, tenga en cuenta que la mayoría de los visitantes tienen permisos de solo lectura. Métrica Valor Tasa de lectura y escritura (E/S por base de datos) 99,999:0,

163 Métrica Valor Promedio de longitud de la cola de disco 0,35 Longitud de la cola de disco: lecturas 34 Longitud de la cola de disco: escrituras 2,5 Lecturas de disco/s 131,33 Escrituras en disco/s 278,33 Compilaciones SQL/s 2,36 Recompilaciones SQL/s 94,80 Bloqueos de SQL: tiempo promedio de espera 0 ms Bloqueos de SQL: tiempo de espera de bloqueos 0 ms Bloqueos de SQL: interbloqueos por segundo 0 Bloqueos temporales de SQL: tiempo promedio de espera 0,25 ms Frecuencia de aciertos de caché de SQL >99% 163

164 Enterprise intranet collaboration environment technical case study (SharePoint Server 2010) (en inglés) This article describes a specific deployment of Microsoft SharePoint Server 2010, that includes the following: Technical case study environment specifications, such as hardware, farm topology and configuration. The workload, that includes the number, and types, of users or clients, and environment usage characteristics. Technical case study farm dataset, that includes database contents and search indexes. Health and performance data that is specific to the environment. In this article: Prerequisite information Introduction to this environment Specifications Workload Dataset Health and Performance Data Prerequisite information Before reading this document, make sure that you understand the key concepts behind SharePoint Server 2010 capacity management. The following documentation will help you learn about the recommended approach to capacity management and provide context for helping you understand how to make effective use of the information in this document, and also define the terms used throughout this document. For more conceptual information about performance and capacity that you might find valuable in understanding the context of the data in this technical case study, see the following documents: 164

165 Capacity management and sizing for SharePoint Server 2010 (en inglés) Administración de la capacidad de SharePoint Server 2010: restricciones y límites del software Introduction to this environment This white paper describes an actual SharePoint Server 2010 environment at Microsoft. Use this document to compare to your planned workload and usage characteristics. If your planned design is similar, you can use the deployment described here as a starting point for your own installation. This document includes the following: Specifications, which include hardware, topology, and configuration. Workload, which is the demand on the farm that includes the number of users, and the usage characteristics. Dataset that includes database sizes. Health and performance data that is specific to the environment. This document is part of a series of Performance and capacity technical case studies (SharePoint Server 2010) (en inglés) about SharePoint environments at Microsoft. 165

166 The SharePoint environment described in this document is a production environment at a large, geographically distributed company. The environment hosts very important team sites and publishing portals for internal teams for enterprise collaboration, organizations, teams, and projects. Sites created in this environment are used as communication portals, applications for business solutions, and general collaboration. Self-service site creation is used to provision site collections. Custom code is not permitted. As many as 88,900 unique users visit the environment on a busy day, generating up to 669 requests per second (RPS) during peak hours. Because this is an intranet site, all users are authenticated. The information that is provided in this document reflects the enterprise intranet publishing environment on a typical day. Specifications This section provides detailed information about the hardware, software, topology, and configuration of the case study environment. Hardware This section provides details about the server computers that were used in this environment. Nota: This environment is scaled to accommodate pre-release builds of SharePoint Server 2010 and other products. Hence, the hardware deployed has larger capacity than necessary to serve the demand typically experienced by this environment. This hardware is described only to provide additional context for this environment and serve as a starting point for similar environments. It is important to conduct your own capacity management based on your planned workload and usage characteristics. For more information about the capacity management process, see Capacity management and sizing for SharePoint Server 2010 (en inglés). Web Servers There are four Web servers in the farm, each with identical hardware. Three serve content, and the fourth is a dedicated search crawl target. Web Server Processor(s) WFE1-4 2 quad 2.33 GHz 166

167 Web Server RAM OS WFE GB Windows Server 2008, 64 bit Size of the SharePoint drive Number of network adapters 2 Network adapter speed Authentication Load balancer type Software version Services running locally Services consumed from a federated Services farm 205 GB 1 Gigabit Windows NTLM Hardware load balancing SharePoint Server 2010 (pre-release version) Central Administration Microsoft SharePoint Foundation Incoming Microsoft SharePoint Foundation Web Application Microsoft SharePoint Foundation Workflow Timer Service Search Query and Site Settings Service SharePoint Server Search User Profile Service Web Analytics Web Service Business Data Connectivity Service Managed Metadata Web Service Application Server There are four application servers in the farm, each with identical hardware. 167

168 Application Server Processor(s) RAM OS Size of the SharePoint drive APP1-4 4 six 2.40 GHz 64 GB Windows Server 2008, 64 bit 300 GB Number of network adapters 1 Network adapter speed Authentication Load balancer type Software version Services running locally 1 Gigabit Windows NTLM Hardware load balancing SharePoint Server 2010 (pre-release version) Office Web Apps Excel PowerPoint Secure Store Usage and Health State Service Database Servers There is a SQL cluster with 2 database servers, each with identical hardware, one of the servers is active and the other is passive for redundancy. 168

169 Database Server Processor(s) RAM OS Storage and geometry Number of network adapters 2 Network adapter speed Authentication DB1-2 4 quad 2.4 GHz 32 GB Windows Server 2008, 64-bit (1.25 TB * 7) + 3 TB Disk 1-4: SQL Data Disk 5: Logs Disk 6: TempDB 1 Gigabit Windows NTLM Software version SQL Server 2008 Topology The following diagram shows the topology for this farm. 169

170 170

171 Configuration The following table enumerates settings that were changed that affect performance or capacity in the environment. Setting Value Notes Usage Service Trace Log days to store log files (default: 14 days) 5 days The default is 14 days. Lowering this setting can save disk space on the server where the log files are stored. QueryLoggingThreshold SharePoint Foundation Database change QueryLoggingThreshold to 1 second 1 second The default is 5 seconds. Lowering this setting can save bandwidth and CPU on the database server. Database Server Default Instance Max degree of parallelism 1 The default is 0. To ensure optimal performance, we strongly recommend that you set max degree of parallelism to 1 for database servers that host SharePoint Server 2010 databases. For more information about how to set max degree of parallelism, see max degree of parallelism Option( Workload This section describes the workload, which is the demand on the farm that includes the number of users, and the usage characteristics. Workload Characteristics Value Average Requests per Second (RPS) 157 Average RPS at peak time (11 AM-3 PM) 350 Total number of unique users per day 69,

172 Workload Characteristics Value Average concurrent users 420 Maximum concurrent users 1,433 Total # of requests per day 18,866,527 This table shows the number of requests for each user agent. User Agent Requests Percentage of Total Search (crawl) 6,384,488 47% DAV 2,446,588 18% Browser 730,139 5% OneNote 665,334 5% Office Web Applications 391,599 3% SharePoint Designer 215,695 2% Dataset This section describes the case study farm dataset that includes database sizes and Search indexes. Dataset Characteristics Database size (combined) BLOB size Value 7.5 TB 6.8 TB 172

173 Dataset Characteristics Value Number of content databases 87 Number of Web applications 2 Number of site collections 34,423 Number of sites 101,598 Search index size (number of items) 23 million Health and Performance Data This section provides health and performance data that is specific to the Case Study environment. General Counters Metric Value Availability (uptime) 99.1% Failure Rate 0.9% Average memory used 3.4 GB Maximum memory used 16.1 GB Search Crawl % of Traffic (Search client requests / total requests) 47% ASP.NET Requests Queued 0.00 The following charts show the average CPU utilization and latency for this environment: 173

174 174

175 In this document, latency is divided into four categories. The 50th percentile latency is typically used to measure the server s responsiveness. It means that half of the requests are served within that response time. The 95th percentile latency is typically used to measure spikes in server response times. It means that 95% of requests are served within that response time, and therefore 5% of the requests experience slower response times. Database counters Metric Value Read/Write Ratio (IO Per Database) 99.8 : 0.2 Average Disk queue length

176 Metric Value Disk Queue Length: Reads 2 Disk Queue Length: Writes 0.3 Disk Reads/sec Disk Writes/sec SQL Compilations/second 9.9 SQL Re-compilations/second 0.07 SQL Locks: Average Wait Time 225 ms SQL Locks: Lock Wait Time 507 ms SQL Locks: Deadlocks Per Second 3.8 SQL Latches: Average Wait Time 14.3 ms SQL Server: Buffer Cache Hit Ratio 74.3% 176

177 Enterprise intranet collaboration environment lab study (SharePoint Server 2010) (en inglés) This article contains guidance on performance and capacity planning for an enterprise intranet collaboration solution that is based on Microsoft SharePoint Server It includes the following: Lab environment specifications, such as hardware, farm topology and configuration Test farm dataset Test results analysis which should help you determine the hardware, topology and configuration that you must have to deploy a similar environment, and optimize your environment for appropriate capacity and performance characteristics In this article: Introduction to this environment Glossary Overview Specifications Results and Analysis Introduction to this environment This document provides guidance about scaling out and scaling up servers in a SharePoint Server 2010 enterprise intranet collaboration solution, based on a testing environment at Microsoft. Capacity planning informs decisions on purchasing hardware and making system configurations to optimize your solution. Different scenarios have different requirements. Therefore, it is important to supplement this guidance with additional testing on your own hardware and in your own environment. If your planned design and workload resembles the environment described in this document, you can use this document to draw conclusions about scaling your environment up and out. This document includes the following: 177

178 Specifications, which include hardware, topology, and configuration The workload, which is the demand on the farm, includes the number of users, and the usage characteristics The dataset, such as database sizes Test results and analysis for scaling out Web servers Test results and analysis for scaling up Web servers Test results and analysis for scaling out database servers Comparison between Microsoft Office SharePoint Server 2007 and SharePoint Server 2010 about throughput and effect on the web and database servers The SharePoint Server 2010 environment described in this document is a lab environment that mimics a production environment at a large company. The production environment hosts very important team sites and publishing portals for internal teams for enterprise collaboration, organizations, teams, and projects. Employees use that production environment to track projects, collaborate on documents, and share information within their organization. The environment includes a large amount of small sites used for ad-hoc projects and small teams. For details about the production environment, see Enterprise intranet collaboration environment technical case study (SharePoint Server 2010) (en inglés). Before reading this document, make sure that you understand the key concepts behind capacity management in SharePoint Server The following documentation will help you learn about the recommended approach to capacity management and provide context for helping you understand how to make effective use of the information in this document, and also define the terms used throughout this document. Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server 2010 Administración de la capacidad de SharePoint Server 2010: restricciones y límites del software Also, we encourage you to read the following: Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010) Glossary There are some specialized terms that you will encounter in this document. Here are some key terms and their definitions. RPS: Requests per second. The number of requests received by a farm or server in one second. This is a common measurement of server and farm load. 178

179 Note that requests differ from page loads; each page contains several components, each of which creates one or more requests when the page is loaded. Therefore, one page load creates several requests. Typically, authentication checks and events using insignificant resources are not counted in RPS measurements. Green Zone: This is the state at which the server can maintain the following set of criteria: The server-side latency for at least 75% of the requests is less than 1 second. All servers have a CPU Utilization of less than 50%. Nota: Because this lab environment did not have an active search crawl running, the database server was kept at 40% CPU Utilization or lower, to reserve 10% for the search crawl load. This assumes Microsoft SQL Server Resource Governor is used in production to limit Search crawl load to 10% CPU. Failure rate is less than 0.01%. Red Zone (Max): This is the state at which the server can maintain the following set of criteria: HTTP request throttling feature is enabled, but no 503 errors (Server Busy) are returned. Failure rate is less than 0. 1%. The server-side latency is less than 3 seconds for at least 75% of the requests. Database server CPU utilization is less than 80%, which allows for 10% to be reserved for the Search crawl load, limited by using SQL Server Resource Governor. AxBxC (Graph notation): This is the number of Web servers, application servers, and database servers respectively in a farm. For example, 8x1x2 means that this environment has 8 Web servers, 1 application server, and 2 database servers. MDF and LDF: SQL Server physical files. For more information, see Files and Filegroups Architecture. Overview This section provides an overview to our scaling approach, to the relationship between this lab environment and a similar case study environment, and to our test methodology. 179

180 Scaling approach This section describes the specific order that we recommend for scaling servers in your environment, and is the same approach we took for scaling this lab environment. This approach will enable you to find the best configuration for your workload, and can be described as follows: First, we scaled out the Web servers. These were scaled out as far as possible under the tested workload, until the database server became the bottleneck and was unable to accommodate any more requests from the Web servers. Second, we scaled out the database server by moving half of the content databases to another database server. At this point, the Web servers were not creating sufficient load on the database servers. Therefore, they were scaled out additionally. In order to test scale up, we tried another option which is scaling up the Web servers instead of scaling them out. Scaling out the Web servers is generally preferred over scaling them up because scaling out provides better redundancy and availability. Correlating the lab environment with a production environment The lab environment outlined in this document is a smaller scale model of a production environment at Microsoft, and although there are significant differences between the two environments, it can be useful to examine them side by side because both are enterprise collaboration environments where the patterns observed should be similar. The lab environment contains a subset of the data from the production environment, and also some modifications to the workload. This influences the test results with regard to Web server memory usage, because the object cache on the production environment receives a larger amount of hits on unique sites, and therefore uses more memory. The lab environment also has less data, and most of it is cached in memory as opposed to the production environment which carries over seven terabytes of data, so that the database server on the production environment is required to perform more disk reads than the database server in the lab environment. Similarly, the hardware that was used in the lab environment is significantly different from the production environment it models, because there is less demand on those resources. The lab environment relies on more easily available hardware. To get a better understanding of the differences between the environments, read the Specifications section in this document, and compare it to the specifications in the Enterprise intranet collaboration environment technical case study (SharePoint Server 2010) (en inglés). Methodology and Test Notes This document provides results from a test lab environment. Because this was a lab environment and not a production environment, we were able to control certain factors to show specific aspects of performance for this workload. In addition, certain elements of the production environment, listed here, were left out of the lab environment to simplify testing overhead. We do not recommend omitting these elements for production environments. Between test runs, we modified only one variable at a time, to make it easy to compare results between test runs. 180

181 The database servers that were used in this lab environment were not part of a cluster because redundancy was not necessary for the purposes of these tests. Search crawl was not running during the tests, whereas it might be running in a production environment. To take this into account, we lowered the SQL Server CPU utilization in our definition of Green Zone and Max to accommodate the resources that a search crawl would have consumed if it were running at the same time with our tests. To learn more about this, read Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010). Specifications This section provides detailed information about the hardware, software, topology, and configuration of the lab environment. Hardware The following sections describe the hardware that was used in this lab environment. Web and Application servers There are from one to eight Web servers in the farm, plus one Application server. Web Server Processor(s) RAM Operating system Size of the SharePoint drive WFE1-8 and APP1 2 quad-core 2.33 GHz processors 8 GB Windows 2008 Server R2 80 GB Number of network adapters 2 Network adapter speed Authentication Load balancer type 1 Gigabit Windows NTLM Windows NLB 181

182 Web Server Services running locally WFE1-8 and APP1 WFE 1-8: Basic Federated Services. This included the following: Timer Service, Admin Service, and Trace Service. APP1: Word Automation Services, Servicios de Excel and SandBoxed Code Services. Database Servers There are from two to three database servers, up to two running the default SQL Server instance housing the content databases, and one running the logging database. The logging database is not tracked in this document. Nota: If you enable usage reporting, we recommend that you store the logging database on a separate Logical Unit Number (LUN). For large deployments and some medium deployments, a separate LUN will not be sufficient, as the demand on the server s CPU may be too high. In that case, you will need a separate database server box for the logging database. In this lab environment, the logging database was stored in a separate instance of SQL Server, and its specifications are not included in this document. Database Server Default Instance Processor(s) RAM Operating system Storage and geometry 182 DB1-2 4 dual-core 3.19 GHz processors 32 GB Windows 2008 Server R2 Direct Attached Storage (DAS) Internal Array with 5 x 300GB 10krpm disk External Array with 15 x 450GB 15krpm disk 6 x Content Data (External RAID0, 2 spindles 450GB each)

183 Database Server Default Instance Number of network adapters 1 Network adapter speed Authentication Software version DB1-2 2 x Content Logs (Internal RAID0, 1 spindle 300GB each) 1 x Temp Data (Internal RAID0, 2 spindles 150GB each) 1 x Temp Log (Internal RAID0, 2 spindles 150GB each) 2 x Backup drive (Internal RAID0, 1 spindle each, 300GB each) 1 Gigabit Windows NTLM SQL Server 2008 R2 (pre-release version) Topology The following diagram shows the topology in this lab environment: 183

184 184

185 Configuration To allow for the optimal performance, the following configuration changes were made in this lab environment. Setting Value Notes Site Collection Blob Caching On The default is Off. Enabling Blob Caching improves server efficiency by reducing calls to the database server for static page resources that may be frequently requested. Database Server Default Instance Max degree of parallelism 1 The default is 0. To ensure optimal performance, we strongly recommend that you set max degree of parallelism to 1 for database servers that host SharePoint Server databases. For more information about how to set max degree of parallelism, see max degree of parallelism Option( Workload The transactional mix for the lab environment described in this document resembles the workload characteristics of a production environment at Microsoft. For more information about the production environment, see Enterprise intranet collaboration environment technical case study (SharePoint Server 2010) (en inglés). Here are the details of the mix for the lab tests run against SharePoint Server 2010 compared to the production environment. Although there are some minor differences in the workloads, both represent a typical transactional mix on an enterprise collaboration environment. 185

186 186

187 Dataset The dataset for the lab environment described in this document is a subset of the dataset from a production environment at Microsoft. For more information about the production environment, see Enterprise intranet collaboration environment technical case study (SharePoint Server 2010) (en inglés). Dataset Characteristics Database size (combined) BLOB size Value 130 GB GB Number of content databases 2 Number of site collections 181 Number of Web applications 1 Number of sites 1384 Results and Analysis The following results are ordered based on the scaling approach described in the Overview section of this document. Web Server Scale Out This section describes the test results that were obtained when we scaled out the number of Web servers in this lab environment. Test methodology Add Web servers of the same hardware specifications, keeping the rest of the farm the same. Measure RPS, latency, and resource utilization. Analysis In our testing, we found the following: 187

188 The environment scaled up to four Web servers per database server. However, the increase in throughput was non-linear especially on addition of the fourth Web server. After four Web servers, there are no additional gains to be made in throughput by adding more Web servers because the bottleneck at this point was the database server CPU Utilization. The average latency was almost constant throughout the whole test, unaffected by the number of Web servers and throughput. Nota: The conclusions described in this section are hardware specific, and the same throughput might have been achieved by a larger number of lower-end hardware, or a smaller number of higher-end hardware. Similarly, changing the hardware of the database server would affect the results. To get an idea on how much of a difference the hardware of the Web servers can affect these results, see the Web Server Scale Up section. Results graphs and charts In the following graphs, the x axis shows the change in the number of Web servers in the farm, scaling from one Web server (1x1x1) to five Web servers (5x1x1). 1. Latency and RPS The following graph shows how scaling out (adding Web servers) affects latency and RPS. 188

189 2. Processor utilization The following graph shows how scaling out the Web servers affects processor utilization on the Web server(s) and the database server. 189

190 3. SQL Server I/O operations per section (IOPs) for MDF and LDF files The following graphs show how the IOPs on the content databases change as the number of Web servers is scaled out. These are measured by looking at the following performance counters: PhysicalDisk: Disk Reads / sec 190

191 PhysicalDisk: Disk Writes / sec In this lab environment, we determined that our data on IOPs was not representative of a production environment because our dataset was so small that we could fit much more of it in cache than would be possible in the production environment we are modeling. We calculated projected reads by multiplying the value of the data we had from the lab for writes/second by the ratio of reads to writes in our production environment. The results in this section are averages. But there are also spikes that occur during certain operations which have to be accounted for. To learn more about how to estimate IOPs needed, see Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010). Maximum: 191

192 Green Zone: Example of how to read these graphs: An organization with a workload similar to that described in this document that expects 300 RPS to be their green zone, could use 3x1x1 topology, and would use approximately 600 Physical Disk reads/sec on the MDF file. Database Server Scale Out This section describes the test results that were obtained when we scaled out the number of database servers in this lab environment. 192

193 Test methodology Have two content databases on one database server, and then split them to two servers to effectively double the processor cores and memory available to the database servers in the environment. Keep the total IOPs capacity constant even while adding a database server. This means that the number of reads/sec and writes/sec that the disks could perform for each content database did not change despite splitting the content onto two database servers instead of one. Analysis The first bottleneck in the 4x1x2 environment was the database server CPU utilization. There was close to a linear scale when we added more processor and memory power. Scaling to four Web servers and 2 database servers did not provide much additional RPS because the CPU utilization on the Web servers was close to 100%. When we scaled out database servers (by adding one additional database server) and added four Web servers, performance scaled almost linearly. The bottleneck at that point shifted from being the database server CPU utilization to the content database disk IOPs. No additional tests were performed in this lab environment to scale out past 8x1x2. However we expect that additional IOPs capacity would additionally increase throughput. A correlation between the IOPs used and the RPS achieved by the tests was observed Results graphs and charts In the following graphs, the x axis is always showing four Web servers together with 1 application server and 1 database server (4x1x1) scaling out to eight Web servers together with two database servers (8x1x2). Some also show 1x1x1 or 4x1x2. 1. Latency and RPS The following graph shows how scaling out both Web servers and database servers affects latency and RPS. 193

194 2. Processor utilization The following graphs show how scaling out affects processor utilization. 194

195 3. Memory utilization at scale out Throughout our testing, we ve observed that the larger the number of site collections in an environment, the more the memory consumed. For example, in the tests here where 181 site collections were accessed, the main w3wp process used up 1.8 GB of RAM. For more examples, see the Performance and capacity technical case studies (SharePoint Server 2010) (en inglés). Additional content about memory requirements for increased numbers of site collections is under development. Check back for new and updated content. 195

196 4. SQL Server I/O operations per section (IOPs) for MDF and LDF files The following graphs show how the IOPs change as both the number of Web servers and the number of database servers is scaled out. Maximum RPS 196

197 Green Zone RPS Web server Scale Up This section describes the test results that were obtained when we scaled up the Web servers in this lab environment. Test methodology Add more Web server processors, but keep the rest of the farm the same. Analysis Scale is linear up to eight processor cores. 197

198 Tests show that the environment can take advantage of a twenty-four core box, although there is some degradation as twenty-four cores are approached. Results graphs and charts In the following graph, the x axis is the number of processors and the amount of RAM on the Web server. The following graph shows how scaling up (adding processors) affects RPS on the Web server. 198

199 Comparing SharePoint Server 2010 and Office SharePoint Server 2007 This section provides information about how the capacity testing for this workload varied between SharePoint Server 2010 and Microsoft Office SharePoint Server Workload To compare SharePoint Server 2010 with Office SharePoint Server 2007, a different test mix was used than the one outlined in the Specifications section, because some SharePoint Server 2010 operations were not available in Office SharePoint Server The test mix for Office SharePoint Server 2007 is inspired by the same production environment that the SharePoint Server 2010 tests follow. However this was recorded before the upgrade to SharePoint Server 2010 on that environment. The following graph shows the test mix for the lab and production environments for Office SharePoint Server

200 Test methodology The tests performed for this comparison were performed by creating an Office SharePoint Server 2007 environment, testing it with the workload outlined earlier in this section, and then upgrading the content databases to SharePoint Server 2010 without changing the clients using the environment, nor doing a visual upgrade. This upgraded environment was then re-tested for the SharePoint Server 2010 results with the same test mix which includes only Office SharePoint Server 2007 operations. The dataset was not modified after the content database upgrade for the SharePoint Server 2010 tests. The test mix for Office SharePoint Server 2007 excludes any new SharePoint Server 2010 specific operations, and resembles the enterprise intranet collaboration solution on the same production environment for Office SharePoint Server 2007, as described under the Workload section. Analysis When the same number of Web servers are stressed to their maximum throughput on SharePoint Server 2010 and Office SharePoint Server 2007, SharePoint Server 2010 achieves 20% less throughput compared to Office SharePoint Server When the Web servers were scaled out to maximize the database server usage, SharePoint Server 2010 was able to achieve 25% better throughput compared to Office SharePoint Server This reflects the improvements that were made in SharePoint Server 2010 to sustain larger deployments. When the web servers were scaled out to maximize the database server usage, SharePoint Server 2010 was SQL Server CPU Utilization bound, whereas Office SharePoint Server 2007 was Lock bound on the database tier. This means that increasing the processing power available to the database servers enables SharePoint Server 2010 to achieve better throughput than would be possible with the same hardware using Office SharePoint Server This is caused by the locking mechanisms in the database in Office SharePoint Server 2007 which are unaffected by improved hardware so that we were unable to push the database server s CPU Utilization past 80%. As a result of these findings outlined earlier in this section, on Office SharePoint Server 2007 the maximum throughput possible was achieved in a 5x0x1 topology whereas in SharePoint Server 2010 the maximum throughput possible with the same workload was achieved in a 7x0x1 topology, and yielded a 25% increased total RPS. Results graphs and charts The following graph shows the throughput without scaling out Web servers. 200

201 The following graph shows the throughput when Web servers were at maximum scale out. 201

202 202

203 Departmental collaboration environment technical case study (SharePoint Server 2010) (en inglés) This document describes a specific deployment of Microsoft SharePoint Server It includes the following: Technical case study environment specifications, such as hardware, farm topology and configuration The workload that includes the number, and types, of users or clients, and environment usage characteristics Technical case study farm dataset that includes database contents and Search indexes Health and performance data that is specific to the environment In this article: Prerequisite information Introduction to this environment Specifications Workload Dataset Health and Performance Data Prerequisite information Before reading this document, make sure that you understand the key concepts behind SharePoint Server 2010 capacity management. The following documentation will help you learn about the recommended approach to capacity management and provide context for helping you understand how to make effective use of the information in this document, and also define the terms used throughout this document. For more conceptual information about performance and capacity that you might find valuable in understanding the context of the data in this technical case study, see the following documents: 203

204 Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server 2010 Administración de la capacidad de SharePoint Server 2010: restricciones y límites del software Introduction to this environment This white paper describes an actual SharePoint Server 2010 environment at Microsoft. Use this document to compare with your planned workload and usage characteristics. If your planned design is similar, you can use the deployment described here as a starting point for your own installation. This document includes the following: Specifications, which include hardware, topology and configuration Workload, which is the demand on the farm that includes the number of users, and the usage characteristics Dataset that includes database sizes Health and performance data that is specific to the environment This document is part of a series of Performance and capacity technical case studies (SharePoint Server 2010) (en inglés) about SharePoint environments at Microsoft. 204

205 The SharePoint Server 2010 environment described in this document is a production environment at a large, geographically distributed company. Employees use this environment to track projects, collaborate on documents, and share information within their department. This environment is also used for internal testing, and is frequently upgraded to the latest SharePoint Server pre-release versions as they become available. As many as 9,000 unique users visit the environment on a busy day, generating up to 470 requests per second (RPS) during peak hours. Because this is an intranet site, all users are authenticated. The information that is provided in this document reflects the departmental collaboration environment on a typical day. Specifications This section provides detailed information about the hardware, software, topology, and configuration of the case-study environment. Hardware This section provides details about the server computers that were used in this environment. Nota: This environment is scaled to accommodate pre-release builds of SharePoint Server 2010 and other products. Hence, the hardware deployed has larger capacity than necessary to serve the demand typically experienced by this environment. This hardware is described only to provide additional context for this environment and serve as a starting point for similar environments. It is important to conduct your own capacity management based on your planned workload and usage characteristics. For more information about the capacity management process, see Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server Web Servers There are four Web servers in the farm, each with identical hardware. Three serve content, and the fourth is a dedicated search crawl target. 205

206 Web Server WFE1-2 WFE3-4 Processor(s) 2 quad 2.33 GHz 2 quad 2.33 GHz RAM 32 GB 16 GB Operating system Windows Server 2008, 64 bit Windows Server 2008, 64 bit Size of the SharePoint drive 3x146GB 15K SAS (3 RAID 1 Disks) Disk 1: OS Disk 2: Swap and BLOB Cache Disk 3: Logs and Temp directory 3x146GB 15K SAS (3 RAID 1 Disks) Disk 1: OS Disk 2: Swap and BLOB Cache Disk 3: Logs and Temp directory Number of network adapters 2 2 Network adapter speed 1 Gigabit 1 Gigabit Authentication Windows NTLM Windows NTLM Load balancer type Hardware load balancing Hardware load balancing Software version SharePoint Server 2010 (pre-release version) SharePoint Server 2010 (pre-release version) Services running locally Search Query WFE3 No services WFE4 Search crawl target Application Server There are four application servers in the farm. 206

207 Web Server APP1-3 APP4 Processor(s) 2 quad 2.33 GHz 2 quad 2.33 GHz RAM 16 GB 16 GB Operating system Windows Server 2008, 64 bit Windows Server 2008, 64 bit Size of the SharePoint drive 3x146GB 15K SAS (3 RAID 1 Disks) Disk 1: OS Disk 2: Swap and BLOB Cache Disk 3: Logs and Temp directory 2x136GB 15K SAS (RAID 0) 4x60GB SSD, SATA (RAID 5) Disk 1: OS Disk 2: Swap and BLOB Cache Disk 3: Logs and Temp directory Number of network adapters 2 2 Network adapter speed 1 Gigabit 1 Gigabit Authentication Windows NTLM Windows NTLM Load balancer type Hardware load balancing Hardware load balancing Software version SharePoint Server 2010 (pre-release version) SharePoint Server 2010 (pre-release version) Services running locally APP1 Central Administration and all applications except for Office Web Applications APP2 All applications (including Office Web Applications) APP3 Office Web Applications Search Crawler 207

208 Database Servers There are three database servers, one running the default SQL Server instance housing the content databases, one running the Usage and Web Analytics databases, and one running the Search databases. Database DB1 Default Instance DB2 DB3 Processor(s) 4 quad 3.2 GHz 2 quad 3.2 GHz quad 3.2 GHz RAM 32 GB 16 GB 32 GB Operating system Windows Server 2008 SP1, 64 bit Windows Server 2008 SP1, 64 bit Storage and geometry 5x146GB 15K SAS + SAN Disk 1: OS (2 disk RAID 10) Disk 2: Swap (2 disk RAID 10) Disk 3: Direct Attached Storage (16 disk RAID 10, Temp DB data) SAS 146 GB 15K Disk 4: Direct Attached Storage (16 disk RAID 10, Temp DB data) SAS 146 GB 15K Disk 5-15: SAN using fiber connection. When possible, one database per two disks. Separating logs and data between LUNs. 15K drives. 6x450GB 15K SAS Directly attached 14x146GB 15K SAS Disk 1: Usage logs and OS Disk 2: Usage data Windows Server 2008 SP1, 64 bit 2x136GB 15K SAS (RAID 0) 6x60GB SSD, SATA (RAID 5) Disk 1: OS Disk 2: Swap and BLOB Cache Disk 3: Logs and Temp directory. Solid state drives. 6-

209 Database DB1 Default Instance DB2 DB3 Number of network adapters GB Solid state drives (RAID 5) Network adapter speed 1 Gigabit 1 Gigabit 1 Gigabit Authentication Windows NTLM Windows NTLM Windows NTLM Software version SQL Server 2008 SQL Server 2008 SQL Server 2008 R2 Topology The following diagram shows the topology for this farm. 209

210 210

211 Configuration The following table enumerates settings that were made that affect performance or capacity in the environment. Setting Value Notes Site collection: On Object Caching (On Off) Disabled Anonymous Cache Profile Disabled (select) On 100GB Anonymous Cache Profile 60 seconds (select) Object Cache (Off n MB) Cross List Query Cache Changes (Every Time Every n seconds) Enabling the output cache improves server efficiency by reducing calls to the database for data that is frequently requested. Site collection cache profile (select) Intranet (Collaboration Site) Allow writers to view cached content is checked, bypassing the ordinary behavior of not letting people with edit permissions to have their pages cached. Object Cache (Off n MB) On 500 MB The default is 100 MB. Increasing this setting enables additional data to be stored in the front-end Web server memory. Usage Service: Trace Log days to store log files (default: 14 days) Query Logging Threshold: Microsoft SharePoint Foundation Database configure 5 days The default is 14 days. Lowering this setting can save disk space on the server where the log files are stored. 1 second The default is 5 seconds. Lowering this setting can save bandwidth and CPU on the database server. 211

212 Setting Value Notes QueryLoggingThreshold to 1 second Database Server Default Instance: Max degree of parallelism 1 The default is 0. To ensure optimal performance, we strongly recommend that you set max degree of parallelism to 1 for database servers that host SharePoint Server 2010 databases. For more information about how to set max degree of parallelism, see max degree of parallelism Option ( Workload This section describes the workload, which is the demand on the farm that includes the number of users, and the usage characteristics. Workload Characteristics Value Average Requests per Second (RPS) 165 Average RPS at peak time (11 AM-3 PM) 216 Total number of unique users per day 9186 Average concurrent users 189 Maximum concurrent users 322 Total # of requests per day 7,124,943 This table shows the number of requests for each user agent. 212

213 User Agent Requests Percentage of Total Search (crawl) 4,373, % Outlook 897, % OneNote 456, % DAV 273, % Browser 247, % Word 94, % SharePoint Workspaces 70, % Office Web Applications 45, % Excel 8, % Access 1, % Dataset This section describes the case study farm dataset that includes database sizes and Search indexes. Dataset Characteristics Value Database size (combined) 1.8 TB BLOB size 1.68 TB Number of content databases 18 Total number of databases

214 Dataset Characteristics Value Number of site collections 7,499 Number of Web applications 7 Number of sites 42,457 Search index size (number of items) 4.6 million Health and Performance Data This section provides health and performance data that is specific to the case study environment. General Counters Metric Value Availability (uptime) % Failure Rate % Average memory used 0.89 GB Maximum memory used 5.13 GB Search Crawl % of Traffic (Search client requests / total requests) 82.5% The following charts show the average CPU utilization and latency for this environment: 214

215 215

216 In this document, latency is divided into four categories. The 50th percentile latency is typically used to measure the server s responsiveness. It means that half of the requests are served within that response time. The 95th percentile latency is typically used to measure spikes in server response times. It means that 95% of requests are served within that response time, and therefore, 5% of the requests experience slower response times. 216

217 Database Counters Metric Value Average Disk queue length 1.42 Disk Queue Length: Reads 1.38 Disk Queue Length: Writes 0.04 Disk Reads/sec Disk Writes/sec SQL Compilations/second SQL Re-compilations/second 0.14 SQL Locks: Average Wait Time ms SQL Locks: Lock Wait Time ms SQL Locks: Deadlocks Per Second 1.87 SQL Latches: Average Wait Time 5.10 ms SQL Cache Hit Ratio 99.77% 217

218 Divisional portal environment lab study (SharePoint Server 2010) (en inglés) This document provides guidance on performance and capacity planning for a divisional portal based on Microsoft SharePoint Server It includes the following: Test environment specifications, such as hardware, farm topology and configuration Test farm dataset Test data and recommendations for how to determine the hardware, topology and configuration that you must have to deploy a similar environment, and how to optimize your environment for appropriate capacity and performance characteristics In this article: Introduction to this environment Glossary Overview Specifications Results and analysis Introduction to this environment This document outlines the test methodology and results to provide guidance for capacity planning of a typical divisional portal. A divisional portal is a SharePoint Server 2010 deployment where teams mainly do collaborative activities and some content publishing. This document assumes a "division" to be an organization inside an enterprise with 1,000 to 10,000 employees. Different scenarios will have different requirements. Therefore, it is important to supplement this guidance with additional testing on your own hardware and in your own environment. If your planned design and workload resembles the environment described in this document, you can use this document to draw conclusions about scaling your environment up and out. When you read this document, you will understand how to do the following: 218

219 Estimate the hardware that is required to support the scale that you need to support: number of users, load, and the features enabled. Design your physical and logical topology for optimal reliability and efficiency. High Availability/Disaster Recovery are not covered in this document. Understand the effect of ongoing search crawls on RPS for a divisional portal deployment. The SharePoint Server 2010 environment described in this document is a lab environment that mimics a production environment at a large company. For details about the production environment, see Departmental collaboration environment technical case study (SharePoint Server 2010) (en inglés). Before reading this document, make sure that you understand the key concepts behind capacity management in SharePoint Server The following documentation will help you learn about the recommended approach to capacity management and provide context for helping you understand how to make effective use of the information in this document, and also define the terms used throughout this document. Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server 2010 Administración de la capacidad de SharePoint Server 2010: restricciones y límites del software Also, we encourage you to read the following: Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010) Glossary There are some specialized terms that you will encounter in this document. Here are some key terms and their definitions. RPS: Requests per second. The number of requests received by a farm or server in one second. This is a common measurement of server and farm load. Note that requests differ from page loads; each page contains several components, each of which creates one or more requests when the page is loaded. Therefore, one page load creates several requests. Typically, authentication checks and events using insignificant resources are not counted in RPS measurements. Green Zone: This is the state at which the server can maintain the following set of criteria: The server-side latency for at least 75% of the requests is less than.5 second. All servers have a CPU Utilization of less than 50%. 219

220 Nota: Because this lab environment did not have an active search crawl running, the database server was kept at 40% CPU Utilization or lower, to reserve 10% for the search crawl load. This assumes Microsoft SQL Server Resource Governor is used in production to limit Search crawl load to 10% CPU. Failure rate is less than 0.01%. Red Zone (Max): This is the state at which the server can maintain the following set of criteria: HTTP request throttling feature is enabled, but no 503 errors (Server Busy) are returned. Failure rate is less than 0. 1%. The server-side latency is less than 1 second for at least 75% of the requests. Database server CPU utilization is less than or equal to 75%, which allows for 10% to be reserved for the Search crawl load, limited by using SQL Server Resource Governor. All Web servers have a CPU Utilization of less than or equal to 75%. AxBxC (Graph notation): This is the number of Web servers, application servers, and database servers respectively in a farm. For example, 2x1x1 means that this environment has 2 Web servers, 1 application server, and 1 database server. MDF and LDF: SQL Server physical files. For more information, see Files and Filegroups Architecture. Overview This section provides an overview to our assumptions and our test methodology. Assumptions For our testing, we made the following assumptions: In the scope of this testing, we did not consider disk I/O as a limiting factor. It is assumed that an infinite number of spindles are available. The tests model only peak time usage on a typical divisional portal. We did not consider cyclical changes in traffic seen with day-night cycles. That also means that timer jobs which generally require scheduled nightly runs are not included in the mix. There is no custom code running on the divisional portal deployment in this case. We cannot guarantee behavior of custom code/thirdparty solutions installed and running in your divisional portal. 220

221 For the purpose of these tests, all of the services databases and the content databases were put on the same instance of Microsoft SQL Server. The usage database was maintained on a separate instance of SQL Server. For the purpose of these tests, BLOB cache is enabled. Search crawl traffic is not considered in these tests. But to factor in the effects of an ongoing search crawl, we modified definitions of a healthy farm. (Green-zone definition to be 40 percent for SQL Server to allow for 10 percent tax from Search crawls. Similarly, we used 80 percent SQL Server CPU as the criteria for max RPS.) Test methodology We used Visual Studio Team System for Test 2008 SP2 to perform the performance testing. The testing goal was to find the performance characteristic of green zone, max zone and various system stages in between for each topology. Detailed definitions of "max zone" and "green zone" are given in the Glossary as measured by specific values for performance counters, but in general, a farm configuration performing around "max zone" breakpoint can be considered under stress, whereas a farm configuration performing "green zone" breakpoint can be considered healthy. The test approach was to start by using the most basic farm configuration and run a set of tests. The first test is to gradually increase the load on the system and monitor its performance characteristic. From this test we derived the throughput and latency at various user loads and also identified the system bottleneck. After we had this data, we identified at what user load did the farm exhibit green zone and max zone characteristics. We ran separate tests at those pre-identified constant user loads for a longer time. These tests ensured that the farm configuration can provide constant green zone and max zone performance at respective user loads, over longer period of time. Later, while doing the tests for the next configuration, we scaled out the system to eliminate bottlenecks identified in previous run. We kept iterating in this manner until we hit SQL Server CPU bottleneck. We started off with a minimal farm configuration of 1 Web server /application server and 1 database server. Through multiple iterations, we finally ended at 3 Web servers, 1 application server, 1 database server farm configuration, where the database server CPU was maxed out. Below you will find a quick summary and charts of tests we performed on each iteration to establish green zone and max zone for that configuration. That is followed by comparison of green zone and max zone for different iterations, from which we derive our recommendations. The SharePoint Admin Toolkit team has built a tool that is named "Load Test Toolkit (LTK)" which is publically available for customers to download and use. Specifications This section provides detailed information about the hardware, software, topology, and configuration of the lab environment. 221

222 Hardware The table that follows presents hardware specs for the computers that were used in this testing. Every Web server that was added to the server farm during multiple iterations of the test complies with the same specifications. Web server Application Server Database Server Processor(s) 3.19GHz RAM 8 GB 8 GB 32 GB Number of network adapters Network adapter speed 1 Gigabit 1 gigabit 1 Gigabit Load balancer type F5 - Hardware load balancer Not applicable Not applicable ULS Logging level Medium Medium Not applicable Software The table that follows explains software installed and running on the servers that were used in this testing effort. Web Server Application Server Database Server Operating System Windows Server 2008 R2 x64 Windows Server 2008 R2 x64 Windows Server 2008 x64 222

223 Web Server Application Server Database Server Software version SharePoint Server 2010 and Office Web Applications, pre-release versions SharePoint Server 2010 and Office Web Applications, prerelease versions SQL Server 2008 R2 CTP3 Authentication Windows NTLM Windows NTLM Windows NTLM Load balancer type F5 - Hardware load balancer Not applicable Not applicable ULS Logging level Medium Medium Not applicable Anti-Virus Settings Disabled Disabled Disabled Services running locally Microsoft SharePoint Foundation Incoming Microsoft SharePoint Foundation Web Application Microsoft SharePoint Foundation Workflow Timer Service Search Query and Site Settings Service SharePoint Server Search Central Administration Excel Services Managed Metadata Web Service Microsoft SharePoint Foundation Incoming Microsoft SharePoint Foundation Web Application Microsoft SharePoint Foundation Workflow Timer Service PowerPoint Services Not applicable 223

224 Web Server Application Server Database Server Search Query and Site Settings Service SharePoint Server Search Visio Graphics Services Word Viewing Service The table indicates which services are provisioned in the test environment. Other services such as the User Profile service and Web Analytics are not provisioned. Topology and configuration The following diagram shows the topology used for the tests. We changed the number of Web servers from 1 to 2 to 3, as we moved between iterations, but otherwise the topology remained the same. 224

225 225

226 Dataset and disk geometry The test farm was populated with about 1.62 Terabytes of content, distributed across five different sized content databases. The following table explains this distribution: Content database Content database size 36 GB 135 GB 175 GB 1.2 terabytes 75 GB Number of sites Number of webs RAID configuration Number of spindles for MDF Number of spindles for LDF Transactional mix The following are important notes about the transactional mix: There are no My Sites provisioned on the divisional portal. Also, the User Profile service, which supports My Sites, is not running on the farm. The transactional mix does not include any My Site page/web service hits or traffic related to Outlook Social Connector. The test mix does not include any traffic generated by co-authoring on documents. The test mix does not include traffic from Search Crawl. However this was factored into our tests by modifying the Green-zone definition to be 40 percent SQL Server CPU usage instead of the standard 50 percent to allow for 10 percent for the search crawl. Similarly, we used 80 percent SQL Server CPU as the criteria for max RPS. The following table describes the overall transaction mix. The percentages total

227 Feature or Service Operation Read/write Percentage of mix ECM Get static files r 8.93% View home page r 1.52% Microsoft InfoPath Display/Edit upsize list item and new forms r 0.32% Download file by using "Save as" r 1.39% Microsoft OneNote 2010 Open Microsoft Office OneNote 2007 file r 13.04% Search Search through OSSSearch.aspx or SearchCenter r 4.11% Workflow Start autostart workflow w 0.35% Microsoft Visio Render Visio file in PNG/XAML r 0.90% Office Web Applications - PowerPoint Render Microsoft PowerPoint, scroll to 6 slides r 0.05% Office Web Applications - Word Render and scroll Microsoft Word doc in PNG/Silverlight r 0.24% Microsoft SharePoint Foundation List Check out and then check in an item w 0.83% List - Get list r 0.83% List - Outlook sync r 1.66% List - Get list item changes r 2.49% List - Update list items and adding new items w 4.34% Get view and view collection r 0.22% Get webs r 1.21% 227

228 Feature or Service Operation Read/write Percentage of mix Browse to Access denied page r 0.07% View Browse to list feeds r 0.62% Browse to viewlists r 0.03% Browse to default.aspx (home page) r 1.70% Browse to Upload doc to doc lib w 0.05% Browse to List/Library's default view r 7.16% Delete doc in doclib using DAV w 0.83% Get doc from doclib using DAV r 6.44% Lock and Unlock a doc in doclib using DAV w 3.32% Propfind list by using DAV r 4.16% Propfind site by using DAV r 4.16% List document by using FPSE r 0.91% Upload doc by using FPSE w 0.91% Browse to all site content page r 0.03% View RSS feeds of lists or wikis r 2.03% Servicios de Excel Render small/large Excel files r 1.56% Workspaces WXP - Cobalt internal protocol r 23.00% Full file upload using WXP w 0.57% 228

229 Results and analysis This section describes the test methodology and results to provide guidance for capacity planning of a typical divisional portal. Results from 1x1 farm configuration Summary of results On a 1 Web server and 1 database server farm, in addition to Web server duties, the same computer was also acting as application server. Clearly this computer (still called Web server) was the bottleneck. As presented in the data here, the Web server CPU reached around 86% utilization when the farm was subjected to user load of 125 users by using the transactional mix described earlier in this document. At that point, the farm exhibited max RPS of Even at a small user load, Web server utilization was always too high to consider this farm as a healthy farm. For the workload and dataset that we used for the test, we do not recommend this configuration as a real deployment. Going by definition of "green zone", there is not really a "green zone" for this farm. It is always under stress, even at a small load. As for "max zone", at the smallest load, where the farm was in "max zone", the RPS was 75. Because the Web server was the bottleneck due to its dual role as an application server, for the next iteration, we separated out the application server role onto its own computer. Performance counters and graphs The following table presents various performance counters captured during testing a 1x1 farm at different steps in user load. User Load RPS Latency Web server CPU Application server CPU N/A N/A N/A N/A Database server CPU th Percentile (sec)

230 User Load th Percentile (sec) The following chart shows the RPS and latency results for a 1x1 configuration. 230

231 The following chart shows performance counter data in a 1x1 configuration. 231

232 Results from 1x1x1 farm configuration Summary of results On a 1 Web server, 1 application server and 1 database server farm, the Web server was the bottleneck. As presented in the data in this section, the Web server CPU reached around 85% utilization when the farm was subjected to user load of 150 users by using the transactional mix described earlier in this document. At that point, the farm exhibited max RPS of This configuration delivered "green zone" RPS of 99, with 75th percentile latency being 0.23 sec, and the Web server CPU hovering around 56 % utilization. This indicates that this farm can healthily deliver an RPS of around 99. "Max zone" RPS delivered by this farm was 123 with latencies of 0.25 sec and the Web server CPU hovering around 85%. Because the Web server CPU was the bottleneck in this iteration, we relived the bottleneck by adding another the Web server for the next iteration. Performance counters and graphs The following table presents various performance counters captured during testing a 1x1x1 farm, at different steps in user load. User Load RPS Latency Web server CPU Application server CPU Database server CPU th Percentile (sec) The following chart shows RPS and latency results for a 1x1x1 configuration. 232

233 The following chart shows performance counter data in a 1x1x1 configuration. 233

234 Results from 2x1x1 farm configuration Summary of results On a 2 Web server, 1 application server and 1 database server farm, the Web server was the bottleneck. As presented in the data in this section, Web server CPU reached around 76% utilization when the farm was subjected to user load of 200 users by using the transactional mix described earlier in this document. At that point, the farm exhibited max RPS of

235 This configuration delivered "green zone" RPS of 191, with 75th percentile latency being 0.37 sec, and Web server CPU hovering around 47 % utilization. This indicates that this farm can healthily deliver an RPS of around 191. "Max zone" RPS delivered by this farm was 291 with latencies of 0.5 sec and Web server CPU hovering around 75%. Because the Web server CPU was the bottleneck in this iteration, we relived the bottleneck by adding another Web server for the next iteration. Performance counters and graphs The following table presents various performance counters captured during testing a 2x1x1 farm, at different steps in user load. User Load RPS Latency Web server CPU Application server CPU Database server CPU th Percentile (sec) th Percentile (sec) The following chart shows RPS and latency results for a 2x1x1 configuration. 235

236 The following chart shows performance counter data in a 2x1x1 configuration. 236

237 Results from 3x1x1 farm configuration Summary of results On a 3 Web server, 1 application server and 1 database server farm, finally, the database server CPU was the bottleneck. As presented in the data in this section, database server CPU reached around 76% utilization when the farm was subjected to user load of 226 users by using the transactional mix described earlier in this document. At that point, the farm exhibited max RPS of

238 This configuration delivered "green zone" RPS of 242, with 75th percentile latency being 0.41 sec, and database server CPU hovering around 44% utilization. This indicates that this farm can healthily deliver an RPS of around 242. "Max zone" RPS delivered by this farm was 318 with latencies of 0.5 sec and database server CPU hovering around 75%. This was the last configuration in the series. Performance counters and graphs The following table presents various performance counters captured during testing a 3x1x1 farm, at different steps in user load. User Load RPS Latency Web server CPU Application server CPU Database server CPU th Percentile (sec) th Percentile (sec) The following chart shows RPS and latency results in a 3x1x1 configuration. 238

239 The following chart shows performance counter data for a 3x1x1 configuration. 239

240 Comparison From the iterative tests we performed, we found out the points at which a configuration enters max zone or green zone. Here s a table of those points. The table and charts in this section provide a summary for all the results that were presented earlier in this article. 240

241 Topology 1x1 1x1x1 2x1x1 3x1x1 Max RPS Green Zone RPS Not applicable Max Latency Green Zone Latency The following chart shows a summary of RPS at different configurations. 241

242 The following chart shows a summary of latency at different configurations. 242

243 A note on disk I/O Disk I/O based bottlenecks are not considered while prescribing recommendations in this document. However, it is still interesting to observe the trend. Here are the numbers: 243

244 Configuration 1x1 1x1x1 2x1x1 3x1x1 Max RPS Reads/Sec Writes/Sec Because we ran the tests in durations of 1 hour and the test uses only a fixed set of sites/webs/document libraries and so on, SQL Server could cache all the data. Thus, our testing caused very little Read IO. We see more write I/O operations that read. It is important to be aware that this is an artifact of the test methodology, and not a good representation of real deployments. Most of the typical divisional portals would have more read operations 3 to 4 times more than write operations. The following chart shows I/Ops at different RPS. 244

245 Tests with Search incremental crawl As we mentioned before, all the tests until now were run without Search crawl traffic. In order to provide information about how ongoing search crawl can affect performance of a farm, we decided to find out the max user RPS and corresponding user latencies with search crawl traffic in the mix. We added a separate Web server to 3x1x1 farm, designated as a crawl target. We saw a 17% drop in RPS compared to original RPS exhibited by 3x1x1. 245

246 In a separate test, on the same farm, we used Resource Governor to limit available resources to search crawl 10%. We saw that as Search uses lesser resources, the max RPS of the farm climbs up by 6%. Baseline 3x1x1 Only Incremental Crawl No Resource Governor RPS 318 N/A Percent RPS difference from baseline 0% N/A 83% 88% Database server CPU (%) SA Database server CPU (%) Web server CPU (%) Application server CPU (%) Crawl Web server CPU (%) % Resource Governor The following chart shows results from tests with incremental Search crawl turned on. 246

247 247

248 Importante: Here we are only talking about incremental crawl, on a farm where there are not very many changes to the content. It is important to be aware that 10% resource utilization will be insufficient for a full search crawl. It may also prove to be less if there are too many changes. It is definitely not advised to limit resource utilization to 10% if you are running a full search crawl, or your farm generally sees a high volume of content changes between crawls. Summary of results and recommendations To paraphrase the results from all configurations we tested: With the configuration, dataset and test workload we had selected for the tests, we could scale out to maximum 3 Web servers before SQL Server was bottlenecked on CPU. The absolute max RPS we could reach that point was somewhere around 318. With each additional Web server, increase in RPS was almost linear. We can extrapolate that as long as SQL Server is not bottlenecked, you can add more Web servers and additional increase in RPS is possible. Latencies are not affected much as we approached bottleneck on SQL Server. Incremental Search crawl directly affects RPS offered by a configuration. The effect can be minimized by using Resource Governor. Using the results, here are few recommendations on how to achieve even larger scale if you must have more RPS from your divisional portal: 1x1 farm can deliver up to 75 RPS. However, it is usually stressed. It s not a recommended configuration for a divisional portal in production. Separate out content databases and services databases on separate instances of SQL Server: In the test workload used in tests, when SQL Server was bottlenecked on CPU, only 3% of the traffic was to the services databases. Thus this step would have achieved slightly better scale out than what we saw. But, in general, increase in scale out by separating out content databases and services databases is directly proportional to the traffic to services database in your farm. Separate out individual content databases on separate instances of SQL Server. In the dataset used for testing, we had 5 content databases, all located on the same instance of SQL Server. By separating them out on different computers, you will be spreading CPU utilization across multiple computers. Therefore, you will see much larger RPS numbers. Finally when SQL Server is bottlenecked on CPU, adding more CPU to SQL Server can increase RPS potential of the farm almost linearly. 248

249 How to translate these results into your deployment In this article, we discussed results as measured by RPS and latency, but how do you apply these in the real world? Here s some math based on our experience from divisional portal internal to Microsoft. A divisional portal in Microsoft which supports around 8000 employees collaborating heavily, experiences an average RPS of 110. That gives a Users to RPS ratio of ~72 (that is, 8000/110). Using the ratio, and the results discussed earlier in this article, we can estimate how many users a particular farm configuration can support healthily: Farm configuration "Green Zone" RPS Approximate number of users it can support 1x1x x1x x1x Of course, this is only directly applicable if your transactional mix and hardware is exactly same as the one used for these tests. Your divisional portal may have different usage pattern. Therefore, the ratio may not directly apply. However, we expect it to be approximately applicable. About the authors Gaurav Doshi is a Program Manager for SharePoint Server at Microsoft. Raj Dhrolia is a Software Test Engineer for SharePoint Server at Microsoft. Wayne Roseberry is a Principal Test Lead for SharePoint Server at Microsoft. 249

250 Social environment technical case study (SharePoint Server 2010) (en inglés) This document describes a specific deployment of Microsoft SharePoint Server It includes the following: Technical case study environment specifications, such as hardware, farm topology and configuration The workload that includes the number, and types, of users or clients, and environment usage characteristics Technical case study farm dataset that includes database contents and Search indexes Health and performance data that is specific to the environment In this article: Prerequisite information Introduction to this environment Specifications Workload Dataset Health and Performance Data Prerequisite information Before reading this document, make sure that you understand the key concepts behind SharePoint Server 2010 capacity management. The following documentation will help you learn about the recommended approach to capacity management and provide context for helping you understand how to make effective use of the information in this document, and also define the terms used throughout this document. For more conceptual information about performance and capacity that you might find valuable in understanding the context of the data in this technical case study, see the following documents: 250

251 Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server 2010 Administración de la capacidad de SharePoint Server 2010: restricciones y límites del software Introduction to this environment This white paper describes an actual SharePoint Server 2010 environment at Microsoft. Use this document to compare with your planned workload and usage characteristics. If your planned design is similar, you can use the deployment described here as a starting point for your own installation. This document includes the following: Specifications, which include hardware, topology and configuration Workload, which is the demand on the farm that includes the number of users, and the usage characteristics Dataset that includes database sizes Health and performance data specific to the environment This document is part of a series of Performance and capacity technical case studies (SharePoint Server 2010) (en inglés) about SharePoint environments at Microsoft. 251

252 The SharePoint Server 2010 environment described in this document is a production environment at a large, geographically distributed company. This environment hosts SharePoint My Sites that connect employees with one another and the information that they need. Employees use this environment to present personal information such as areas of expertise, past projects, and colleagues to the wider organization. The environment also hosts personal sites and documents for viewing, editing, and collaboration. My Sites are integrated with Active Directory Domain Services (AD DS) to provide a central location that can be accessed from the browser and various client applications. As many as 72,000 unique users visit the environment on a busy day, generating up to 180 requests per second (RPS) during peak hours. Because this is an intranet site, all users are authenticated. The information that is provided in this document reflects the enterprise social environment on a typical day. Specifications This section provides detailed information about the hardware, software, topology, and configuration of the case-study environment. Hardware This section provides details about the server computers that were used in this environment. Nota: This environment is scaled to accommodate pre-release builds of SharePoint Server 2010 and other products. Hence, the hardware deployed has larger capacity than necessary to serve the demand typically experienced by this environment. This hardware is described only to provide additional context for this environment and serve as a starting point for similar environments. It is important to conduct your own capacity management based on your planned workload and usage characteristics. For more information about the capacity management process, see Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server Web Servers There are three Web servers in the farm, each with identical hardware. Two serve content, and the third is a dedicated search crawl target. 252

253 Web Server Processor(s) RAM Operating system Size of the SharePoint drive WFE1-3 2 quad 2.33 GHz 16 GB Windows Server 2008, 64 bit 400 GB Number of network adapters 2 Network adapter speed Authentication Load balancer type Software version Services running locally Services consumed from a federated services farm 1 Gigabit Windows NTLM Hardware load balancing SharePoint Server 2010 (pre-release version) Central Administration Microsoft SharePoint Foundation Incoming Microsoft SharePoint Foundation Web Application Microsoft SharePoint Foundation Workflow Timer Service Search Query and Site Settings Service SharePoint Server Search User Profile Service Web Analytics Web Service Business Data Connectivity Service Managed Metadata Web Service Application Server There are two application servers in the farm, each with identical hardware. 253

254 Application Server Processor(s) RAM OS Size of the SharePoint drive Number of network adapters 1 Network adapter speed Authentication Load balancer type Software version Services running locally APP1-4 2 quad 2.33 GHz 16 GB Windows Server 2008, 64 bit 400 GB 1 Gigabit Windows NTLM Hardware load balancing SharePoint Server 2010 (pre-release version) Office Web Apps Excel PowerPoint Secure Store Usage and Health State Service Database Servers There is a SQL cluster with two database servers, each with identical hardware. One of the servers is active and the other is passive for redundancy. 254

255 Database Server Processor(s) RAM Operating system DB1-2 4 quad 2.4 GHz 64 GB Windows Server 2008, 64 bit Storage and geometry (1.25 TB * 6) Disk 1-4: SQL Data Disk 5: Logs Disk 6: TempDB Number of network adapters 2 Network adapter speed Authentication 100MB, 1GB Windows NTLM Software version SQL Server 2008 Topology The following diagram shows the topology for this farm. 255

256 256

257 Configuration The following table enumerates settings that were changed that affect performance or capacity in the environment. Setting Value Notes Usage Service: Trace Log days to store log files (default: 14 days) QueryLoggingThreshold Microsoft SharePoint Foundation Database configure QueryLoggingThreshold to 1 second Database Server Default Instance Max degree of parallelism 5 days The default is 14 days. Lowering this setting can save disk space on the server where the log files are stored. 1 second The default is 5 seconds. Lowering this setting can save bandwidth and CPU on the database server. 1 The default is 0. To ensure optimal performance, we strongly recommend that you set max degree of parallelism to 1 for database servers that host SharePoint Server 2010 databases. For more information about how to set max degree of parallelism, see max degree of parallelism Option( Workload This section describes the workload, which is the demand on the farm that includes the number of users, and the usage characteristics. Workload Characteristics Value Average Requests per Second (RPS)

258 Workload Characteristics Value Average RPS at peak time (11 AM-3 PM) 112 Total number of unique users per day 69,814 Average concurrent users 639 Maximum concurrent users 1186 Total # of requests per day 4,045,677 This table shows the number of requests for each user agent. User Agent Requests Percentage of Total Outlook Social Connector Browser 1,808, % Search (crawl) 704, % DAV 459, % OneNote 266, % Outlook 372, % Browser 85, % Word 38, % Excel 30, % Office Web Applications 20, % SharePoint Workspaces 19, % 258

259 Dataset This section describes the case study farm dataset that includes database sizes and Search indexes. Dataset Characteristics Value Database size (combined) 1.5 TB BLOB size 1.05 TB Number of content databases 64 Number of Web applications 1 Number of site collections 87,264 Number of sites 119,400 Search index size (number of items) 5.5 million Health and Performance Data This section provides health and performance data that is specific to the case study environment. General Counters Metric Value Availability (uptime) 99.61% Failure Rate 0.39% Average memory used 0.79 GB 259

260 Metric Value Maximum memory used 4.53 GB Search Crawl % of Traffic (Search client requests / total requests) 17.42% The following charts show average CPU utilization and latency for this environment. 260

261 261

262 In this document, latency is divided into four categories. The 50th percentile latency is typically used to measure the server s responsiveness. It means that half of the requests are served within that response time. The 95th percentile latency is typically used to measure spikes in server response times. It means that 95% of requests are served within that response time, and therefore, 5% of the requests experience slower response times. Database Counters Metric Value Read/Write Ratio (IO Per Database) : Average Disk queue length

263 Metric Value Disk Queue Length: Reads Disk Queue Length: Writes Disk Reads/sec Disk Writes/sec SQL Compilations/second SQL Re-compilations/second SQL Locks: Average Wait Time 125 ms SQL Locks: Lock Wait Time ms SQL Locks: Deadlocks Per Second 0 SQL Latches: Average Wait Time 0 ms SQL Cache Hit Ratio 20.1% 263

264 Recomendaciones y resultados de pruebas de rendimiento y capacidad (SharePoint Server 2010) Esta sección contiene una serie de notas del producto y artículos que describen el impacto de rendimiento y capacidad de los conjuntos de características específicas incluidos en Microsoft SharePoint Server Estas notas del producto y artículos incluyen información acerca del rendimiento y la capacidad de la característica, y las pruebas de Microsoft, incluidas: Prueba de las características de la granja de servidores Resultados de las pruebas Recomendaciones Solución de problemas de rendimiento y escalabilidad Nota: Las notas del producto se van a actualizar y volver a publicar como artículos. Si descarga una nota del producto desde esta página, es posible que, cuando vuelva a publicarse como un artículo, contenga información actualizada. Antes de leer estas notas del producto y estos artículos, es importante que conozca los conceptos clave sobre la administración de capacidad en SharePoint Server Para obtener más información, vea Capacity management and sizing for SharePoint Server 2010 (en inglés). La siguiente tabla describe las notas del producto y los artículos disponibles. Si el contenido está disponible como notas del producto, aparecerá como un documento de Microsoft Word en el tema sobre recomendaciones y resultados de las pruebas de rendimiento y capacidad de SharePoint Server

265 Asunto Servicios de Access Servicios de conectividad empresarial Información general sobre las memorias caché Servicios de Excel en Microsoft SharePoint Server 2010 InfoPath Forms Services Listas de gran tamaño Descripción Proporciona información orientativa sobre cómo el uso de Servicios de Access afecta a las topologías que ejecutan SharePoint Server Vea el artículo en Estimate performance and capacity requirements for Access Services in SharePoint Server 2010 (en inglés). Proporciona información orientativa sobre el impacto en el uso de recursos que tiene la utilización de Servicios de conectividad empresarial en las topologías que ejecutan SharePoint Server Descargue estas notas del producto (BCSCapacityPlanningDoc.docx). Proporciona información acerca del modo en que las tres memorias caché de SharePoint Server 2010 ayudan a que el producto escale y crezca para satisfacer las demandas de la aplicación empresarial. Descargue estas notas del producto (SharePointServerCachesPerformance.docx). Proporciona información orientativa sobre planeación para Servicios de Excel en Microsoft SharePoint Server Vea el artículo en Estimate performance and capacity requirements for Excel Services in SharePoint Server 2010 (en inglés). Proporciona información orientativa sobre el impacto en el uso de recursos que tiene la utilización de InfoPath Forms Services en las topologías que ejecutan SharePoint Server Descargue estas notas del producto (InfoPath2010CapacityPlanningDoc.docx). Proporciona información orientativa sobre el rendimiento de las listas y bibliotecas de documentos de gran tamaño. Este documento es específico para SharePoint Server 2010, aunque las limitaciones que se mencionan también se aplican a Microsoft SharePoint Foundation Descargue estas notas del producto (DesigningLargeListsMaximizingListPerformance.docx). 265

266 Asunto Repositorios de documentos de gran escala Mis sitios y sistemas sociales Office Web Apps PerformancePoint Services Búsqueda Servicios de Visio Descripción Proporciona información orientativa sobre el rendimiento de los repositorios de documentos de gran escala en relación con SharePoint Server Descargue estas notas del producto (LargeScaleDocRepositoryCapacityPlanningDoc.docx). Proporciona información orientativa sobre el impacto en el uso de recursos que tiene la utilización de Mis sitios y otras características de sistemas sociales en las topologías que ejecutan SharePoint Server Descargue estas notas del producto (MySitesSocialComputingCapacityPlanningDoc.docx). Proporciona información orientativa sobre el impacto en el uso de recursos que tiene la utilización de Office Web Apps en las topologías que ejecutan SharePoint Server Descargue estas notas del producto (OfficeWebAppsCapacityPlanningDoc.docx). Proporciona información orientativa sobre el impacto en el uso de recursos que tiene la utilización de PerformancePoint Services en las topologías que ejecutan SharePoint Server Vea el artículo en Estimación de los requisitos de rendimiento y capacidad de PerformancePoint Services. Proporciona información acerca del planeamiento de capacidad para distintas implementaciones de búsqueda en SharePoint Server 2010, incluidas las granjas de servidores pequeñas, medianas y grandes. Descargue estas notas del producto (SearchforSPServer2010CapacityPlanningDoc.docx). Si usa FAST Search Server 2010 for SharePoint como solución del motor de búsqueda Enterprise Search, vea Plan for performance and capacity (FAST Search Server 2010 for SharePoint). Proporciona información orientativa sobre el impacto en el uso de recursos que tiene la utilización de Servicios de Visio en las topologías 266

267 Asunto Web Analytics Administración de contenido web Servicios de automatización de Word Flujo de trabajo Descripción que ejecutan SharePoint Server Descargue estas notas del producto (VisioServicesCapacityPlanningDoc.docx). Proporciona información orientativa sobre el impacto en el uso de recursos que tiene la utilización del servicio de Web Analytics en las topologías que ejecutan SharePoint Server Vea los artículos en Capacity requirements for Web Analytics Shared Service in SharePoint Server 2010 (en inglés). Proporciona información acerca de la planeación de rendimiento y capacidad para una solución de administración de contenido web. Vea el artículo en Estimación de los requisitos de rendimiento y capacidad para la administración de contenido web en SharePoint Server Proporciona información orientativa sobre el planeamiento de capacidad para Servicios de automatización de Word en SharePoint Server Descargue estas notas del producto (WASCapacityPlanningDoc.docx). Proporciona información orientativa sobre el impacto en el uso de recursos que tiene la utilización del flujo de trabajo en las topologías que ejecutan SharePoint Server Descargue estas notas del producto (WorkflowCapacityPlanningDoc.docx). Estimate performance and capacity requirements for Access Services in SharePoint Server 2010 (en inglés) This article provides guidance on the footprint that usage of Servicios de Access en Microsoft SharePoint Server 2010 has on topologies that are running Microsoft SharePoint Server In this article: 267

268 Test farm characteristics Test results Recommendations Troubleshooting Test farm characteristics This section describes the dataset that was used during the testing; the workloads that were placed on the product during performance gathering; the hardware that was used during the testing; and the topology for how that hardware was deployed. Dataset Servicios de Access capacity and performance is highly dependent on the makeup of the applications that are hosted on the service. The size of tables and the complexity of queries often have the most effect on capacity and performance. The testing used representative sizes and complexities, but every application and dataset is different. The capacity and performance will depend on the applications that are being used, their specific complexity, and the data size. To evaluate the capacity profile, Servicios de Access applications were simulated on a farm dedicated to Servicios de Access (no other SharePoint tests were running). The farm contained the following representative sites: 1,500 Servicios de Access applications that have a Small size profile; 100 items maximum per list. 1,500 Servicios de Access applications that have a Medium size profile; 2,000 items maximum per list. 1,500 Servicios de Access applications that have a Large size profile; 10,000 items maximum per list. Each application is made up of multiple lists, and the other lists are appropriately sized based on this largest list. Servicios de Access can handle more data than 10,000 items. This number for the Large profile was chosen because it was expected that larger applications would not be common. The applications were evenly distributed among the following applications: Contacts A simple contact management application, dominated by a single list. Projects A simple task and project tracking applications, dominated by two lists (projects and tasks associated with each project). Orders A simple order entry system, similar to the Northwind Traders sample of Microsoft Access, but scaled down, and included many interrelated lists (orders, order details, invoices, invoice details, purchase orders, purchase order details, and so on). 268

269 Workload To simulate application usage, workloads were created to perform one or more of the following operations: Opening forms Paging through the forms Filtering and sorting data sheets Updating, deleting and inserting records Publishing application Render reports Each workload includes think time between user actions, ranging from 5 to 20 seconds. This differs from other SharePoint capacity planning documents. Servicios de Access is stateful; memory cursors and record sets were maintained between user interactions. It was important to simulate a full user session and not merely individual requests. For a single user workload, there is an average of two requests per second. The following table shows the percentages used to determine which application and which size of application to use. Small Medium Large Contacts 16% 10% 9% Projects 18% 12% 10% Orders 11% 8% 6% Green and red zone definitions For each configuration, two tests were ran to determine a green zone and a red zone. The green zone is the recommended throughput that can be sustained. The red zone is the maximum throughput that can be tolerated for a short time, but should be avoided. The green zone was defined as a point at which the test being run consumes at most half the bottlenecking resource. In this case, the bottlenecking resource was %CPU on any of the three tiers: front-end Web server, application server (Access Data Services), or database server (SQL Server). First, the bottleneck was identified for a particular configuration. If the bottleneck was Access Data Services CPU, we made sure that the green zone test consumed CPU on the Access Data Services computers in a range between 40 and 50 percent. 269

270 For the red zone, a point was selected at which the maximum throughput was reached. This proved to be a CPU range between 80 and 90 percent. When searching for bottleneck, we looked at %CPU, memory usage (private bytes), disk queue length, network I/O, and other resources that could result in a bottleneck. Both the green and red zone tests were run for 1 hour at a fixed user load. Your results might vary The specific capacity and performance figures presented in this article will differ from figures in a real-world environment. This simulation is only an estimate of what actual users might do. The figures presented are intended to provide a starting point for the design of an appropriately scaled environment. After you have completed the initial system design, you should test the configuration to determine whether the system will support the factors in your environment. Hardware setting and topology Lab Hardware To provide a high level of test-result detail, several farm configurations were used for testing. Farm configurations ranged from one to four front-end Web servers, one to four application servers (if there is Servicios de Access or Access Data Services), and a single database server computer that is running Microsoft SQL Server In addition, testing was performed by using four client computers. All server computers were 64-bit. All client computers were 32-bit. The following table lists the specific hardware that was used for the testing. Machine role CPU Memory Network Disk Front-end Web server 2 processor, 4 core 2.33 GHz 8 GB 1 gig 2 spindles RAID 5 Application server (Access Data Services) 2 processor, 4 core 2.33 GHz 8 GB 1 gig 2 spindles RAID 5 Database server (SQL Server) 4 processor, 4 core 2.6 GHz 32GB 1 gig Direct Attached Storage (DAS) attached RAID 0 for 270

271 Machine role CPU Memory Network Disk each Logical Unit Number (LUN) Topology From our experience, CPU on the application sever tier, where Access Data Services is running, is an important limiting factor for throughput. We varied our topology by adding additional Access Data Services computers until it was no longer the bottleneck, and then added a front-end Web server to obtain even more throughput. 1x1: One front-end Web server computer to one Access Data Services computer 1x2: One front-end Web server computer to two Access Data Services computers 1x3: One front-end Web server computer to three Access Data Services computers 1x4: One front-end Web server computer to four Access Data Services computers 2x1: Two front-end Web server computers to one Access Data Services computer 2x2: Two front-end Web server computers to two Access Data Services computers 2x4: Two front-end Web server computers to four Access Data Services computers The computer running SQL Server is a relatively strong computer and at no time did it become the bottleneck (although it started to approach CPU saturation on our 2x4 test), so we did not vary this in our topologies. Depending on the queries that are a part of a realworld application mix, it is expected that the database server (SQL Server) tier could become the bottleneck. Reporting Services was running in connected mode for all of our tests, running in the application server (Access Data Services) tier. Test results The following tables show the test results of Servicios de Access. For each group of tests, only certain specific variables are changed to show the progressive impact on farm performance. 271

272 All the tests reported in this article were conducted with think time or wait time. This differs from the capacity planning results for other parts of SharePoint. For information about bottlenecks of Servicios de Access, see Common bottlenecks and their causes later in this article. Overall scale The following table and graph summarize the impact of adding additional front-end Web servers and dedicated Active Data Services computers to the farm. These throughput numbers are specifically for the Active Data Services computers. They do not reflect the impact on the overall farm. Topology Baseline solution maximum (RPS) Baseline recommended (RPS) 1x x x x x x x

273 273

274 Recommended results The following graph shows the results for recommended sustainable throughput. 274

275 As described earlier in this article, adding the fourth Access Data Services computer shifts the bottleneck to the front-end Web server, and that adding a second front-end Web server resolves the resource constraint on the front-end Web server tier. This would imply, that 1x1, 1x2, and 1x3 are reasonable configurations. However, when the fourth Access Data Services computer is added, a front-end Web server should also be added. Because scaling is in a linear manner (straight line between from 1x1 to 1x4), it can be assumed that the addition of a seventh Access Data Services computer would also imply the addition of a third front-end Web server, and so on, to satisfy the needs of the farm. Remember that these results are based on a simulated work load only, and that an actual deployment should be monitored to find the point at which additional front-end Web servers are needed to support additional Access Data Services computers. Also, the front-end Web servers are dedicated to Servicios de Access, and in reality the front-end Web servers are likely shared with other SharePoint workloads. The following graph shows the results. 275

276 The following graph shows the response time at this throughput level. The response time is very fast, at less than ¼ second on average per request. 276

277 These results show that the SQL Server computer was not a bottleneck, because adding a second front-end Web server resolved the resource shortage, and the SQL Server CPU was always less than 50 percent. However, be aware that the instance of SQL Server is 277

278 shared with other SharePoint services and SharePoint itself, and so the cumulative effect might drive CPU or disk I/O queue lengths to the point that they do become a bottleneck. Maximum The following graph shows the results, in which throughput was pushed beyond what could be sustained. In this graph we see that again a second front-end Web server was needed to maximum the usefulness of the fourth Access Data Services computer. Again, your results might vary, because this is highly dependent on the applications and their usage patterns. 278

279 279

280 In this case, the response time is increased, as the overall system is under stress. However, these levels are still approximately one second, and acceptable to most users. It might seem odd that with four Access Data Services computers, two front-end Web servers have an increased response time than one front-end Web server. This is because the overall throughput of the system is increased with two front-end Web servers. 280

281 SQL Server is again not a limiting factor here, because adding the second front-end Web server put us back on a linear scaling line. However, we are reaching almost 90 percent CPU usage on the instance of SQL Server. Therefore, there is very little headroom remaining. If we were to add a fifth Access Data Services computer, the SQL Server computer likely would have become the bottleneck. 281

282 Detailed results The following tables show the detailed results for the recommended configurations. 282

283 Overall 1x1 1x2 1x3 1x4 2x1 2x2 2x4 Req/Sec Tests/Sec Average Latency Average front-end Web server tier 1x1 1x2 1x3 1x4 2x1 2x2 2x4 %CPU Max w3wp Private Bytes 9.46E E E E E E E+09 Average application server (Access Data Services) tier 1x1 1x2 1x3 1x4 2x1 2x2 2x4 %CPU %CPU w3wp %CPU RS Max total Private Bytes 4.80E E E E E E E+09 Max w3wp Private Bytes 2.10E E E E E E E+09 Max RS Private Bytes 1.78E E E E E E E

284 Database server (SQL Server) tier (single computer) 1x1 1x2 1x3 1x4 2x1 2x2 2x4 %CPU Avg Private Bytes 2.96E E E E E E E+10 Max Private Bytes 3.26E E E E E E E+10 Avg Disk Queue Length Total The following tables show the detailed results for the maximum configurations. Overall 1x1 1x2 1x3 1x4 2x1 2x2 2x4 Req/Sec Tests/Sec Average Latency Average front-end Web server tier 1x1 1x2 1x3 1x4 2x1 2x2 2x4 %CPU Max w3wp Private Bytes 9.46E E E E E E E

285 Average application server (Access Data Services) tier 1x1 1x2 1x3 1x4 2x1 2x2 2x4 %CPU %CPU w3wp %CPU RS Max total Private Bytes 4.80E E E E E E E+09 Max w3wp Private Bytes 2.10E E E E E E E+09 Max RS Private Bytes 1.78E E E E E E E+09 Database server (SQL Server) tier (single computer) 1x1 1x2 1x3 1x4 2x1 2x2 2x4 %CPU Avg Private Bytes 2.96E E E E E E E+10 Max Private Bytes 3.26E E E E E E E+10 Avg Disk Queue Length Total Recommendations This section provides general performance and capacity recommendations. Servicios de Access capacity and performance is highly dependent on the makeup of the applications that are hosted on the service. The size of tables and the complexity of queries often have the most effect. The testing used representative sizes and complexities, but every 285

286 application and dataset is different. Therefore, the capacity and performance will depend on the applications in use, their specific complexity, and the data size. Hardware recommendations Servicios de Access uses standard hardware for both front-end Web servers and application servers; no special requirements are necessary. General SharePoint Server 2010 guidelines for CPU number, speed, and memory are applicable for computers in the application server (Access Data Services) tier. Scaled-up and scaled-out topologies To increase the capacity and performance of one of the starting-point topologies, you can do one of two things. You can either scale up by increasing the capacity of your existing servers or scale out by adding additional servers to the topology. This section describes the general performance characteristics of several scaled-out topologies. The sample topologies represent the following common ways to scale out a topology for an Servicios de Access scenario: To provide for more user load, check the CPU for the existing Servicios de Access application servers. Add additional CPUs or cores, or both, to these servers if it is possible. Add more Servicios de Access server computers as needed. This can be done to the point that the front-end Web server has become the bottleneck, and then add front-end Web servers as needed. In our tests, memory on the front-end Web server tier and application server (Access Data Services) tier was not a bottleneck. Depending on the size of the result sets, memory could become an issue. However, we do not expect that to be the norm. Track the private bytes for the Access Data Services w3wp process, as described here. In our tests, SQL Server was not a bottleneck. However, our tests were run in isolation from other SharePoint Server 2010 services. SQL Server CPU and disk I/O should be monitored and additional servers or spindles added as needed. Performance-related Access Services settings One way to control the performance characteristics of Servicios de Access is to limit the size and complexity of queries that can be performed. Servicios de Access provides a set of configurable throttles for controlling queries. Each of the following queries can be set through SharePoint Central Administration. (In the Application Management section, click Manage Service Applications, and then click Servicios de Access.) In general, how much data that has to be retrieved from SharePoint to perform a query will have a significant effect on performance. This can be controlled in several ways. First, the inputs to a query can be limited: Maximum Sources per Query Maximum Records per Table Second, the resulting size of a query can be limited: 286

287 Maximum Columns per Query Maximum Rows per Query Allow Outer Joins In addition to the size of the query (data size in and out), the processing complexity on the data can be controlled, to reduce the CPU load on the application server (Access Data Services) tier: Maximum Calculated Columns per Query Maximum Order by Clauses per Query Obviously, the previous settings will affect the applications that can be run on the server. For example, if an application is written with 40 output columns from a query, and the settings are below this level, the application will throw a runtime error. A balance between user need and acceptable performance must be struck, and is highly dependent on the kind of Access applications that are expected to be run on the farm. One additional, more extreme measure can be taken. SharePoint Server 2010 supports a set of query operations natively, which Servicios de Access augments to cover a broader set of application scenarios. For Servicios de Access to improve queries from SharePoint, there is the potential that a large amount of data might have to be retrieved from the SharePoint content database. Instead, Servicios de Access can be set to stick with only query operations, which can be natively supported by SharePoint. Therefore, avoiding the data fetch required for more complex operations: Allow Non-Remotable Queries Optimizations Common bottlenecks and their causes During performance testing, several different common bottlenecks were revealed. A bottleneck is a condition in which the capacity of a particular constituent of a farm is reached. This causes a plateau or decrease in farm throughput. The table in Troubleshooting later in this article lists some common bottlenecks and describes their causes and possible resolutions. Performance monitoring To help you determine when you have to scale up or scale out the system, use performance counters to monitor the health of the system. Use the information in the following tables to determine which performance counters to monitor, and to which process the performance counters should be applied. Front-end Web servers The following table shows performance counters and processes to monitor for Web servers in your farm. 287

288 Performance counter Apply to object Notes % Processor Time Processor(_Total) Shows the percentage of elapsed time that this thread used the processor to execute instructions. Private Bytes Process(w3wp) This value should not approach the Max Private Bytes set for w3wp processes. Iif it does, additional investigation is needed into what component is using the memory. Access Data Services The following table shows performance counters and processes to monitor for application servers, or Access Data Services (Access Data Services) in this case, within your farm. Performance counter Apply to object Notes % Processor Time Processor(_Total) Shows the percentage of elapsed time that this thread used the processor to execute instructions. % Processor Time Process(w3wp) The Access Data Services runs within its own w2wp process, and it will be obvious which w2wp 288

289 Performance counter Apply to object Notes 289 process this is as it will be getting the bulk of the CPU time. Avg. Disk Queue Length PhysicalDisk(_Total) Watch for too much disk writing because of logging. % Processor Time Process(ReportingServicesService) Reports are handled by SQL Server Reporting Services. If too many reports are being run, or if the reports are very complex, then the CPU and Private Bytes for this process will be high. Private Bytes Process(w3wp) Servicios de Access caches the results of queries in memory, until the user s session expires (the time-out for which is configurable). If a large amount of data is being processed through the Access Data Services, memory consumption for the Access Data Services w3wp will increase. Private Bytes Process(ReportingSrevicesService) Reports are handled by SQL Server Reporting Services. If too many reports are being run, or

290 Performance counter Apply to object Notes reports are very complex, the CPU and Private Bytes for this process will be high. Database servers The following table shows performance counters and processes to monitor for database servers in your farm. Performance counter Apply to object Notes % Processor Time Processor(_Total) Shows the percentage of elapsed time that this thread used the processor to execute instructions. % Processor Time Process(sqlservr) Average values larger than 80 percent indicate that processor capacity on the database server is insufficient. Private Bytes Process(sqlservr) Shows the average amount of memory being consumed by SQL Server. Avg. Disk Queue Length PhysicalDisk(_Total) Shows the average disk queue length; the database requests waiting to be committed to disk. This is often a good indicator that the instance 290

291 Performance counter Apply to object Notes of SQL Server is becoming overloaded, and that possibly additional disk spindles would help distribute the load. Troubleshooting The following table lists some common bottlenecks and describes their causes and possible resolutions. Bottleneck Cause Resolution Access Data Services CPU Web server CPU usage Database server disk I/O Servicios de Access depends on a large amount of processing in the application server tier. If a 1x1, 1x2, or 1x3 configuration is used, the first bottleneck encountered will likely be the CPU on the Access Data Services servers. When a Web server is overloaded with user requests, average CPU usage will approach 100 percent. This prevents the Web server from responding to requests quickly and can cause timeouts and error messages on client computers. When the number of I/O requests to a hard disk exceeds the disk s I/O 291 Increase the number of CPUs or cores, or both, in the existing Access Data Services computers. Add additional Access Data Services computers if possible. This issue can be resolved in one of two ways. You can add more Web servers to the farm to distribute user load, or you can scale up the Web server or servers by adding higherspeed processors. Distributing data files across multiple physical drives allows for parallel I/O. The blog SharePoint Disk Allocation and Disk

292 Bottleneck Cause Resolution Reporting Services CPU utilization capacity, the requests will be queued. I/O ( contains As a result, the time to complete useful information about resolving disk I/O issues. each request increases. The Reporting Services process is using a large share of the CPU resources. Dedicate a computer to Reporting Services, taking load from the application server (Access Data Services) tier (connected mode) or the front-end Web server tier (local mode). 292

293 Estimate performance and capacity requirements for Excel Services in SharePoint Server 2010 (en inglés) This article describes the effects of using Servicios de Excel en Microsoft SharePoint Server 2010 on topologies running Microsoft SharePoint Server You can use this information to better scale your deployments based on your latency and throughput requirements. Nota: It is important to be aware that the specific capacity and performance figures presented in this article will differ from the figures in realworld environments. The figures presented are intended to provide a starting point for the design of an appropriately scaled environment. After you have completed your initial system design, test the configuration to determine whether the system will support the needs of your environment. In this article: Test farm characteristics Test Results Recommendations For general information about how to plan and run your capacity planning for SharePoint Server 2010, see Capacity management and sizing for SharePoint Server 2010 (en inglés). Test farm characteristics This section describes the dataset, workloads, hardware settings, topology, and test definitions that were used during the performance and capacity testing of Servicios de Excel. 293

294 Dataset Servicios de Excel capacity and performance is highly dependent on the makeup of the workbooks that are hosted on the service. The size of the workbook and the complexity of calculations have the most impact. Our testing used representative sizes and complexities, but every workbook is different, and your capacity and performance depends on the actual workbooks you use, and their specific size and complexity. We simulated Excel workbooks on a farm dedicated to Excel to evaluate our capacity profile. Note that no other SharePoint Server tests were running during our capacity profile tests. Within this farm, we used three buckets of workbooks Small, Large, and Very Large based on workbook size and complexity: Workbook Characteristics Small Large Very Large Sheets Columns ,000 Rows , ,000 Calculated Cells 0-20% 0-70% 0-70% Number of Formats Tables Charts Workbook Uses External Data 0% 20% 50% Workbook Uses a Pivot Table 0% 3% 3% Workbook Uses Conditional Formats 0% 10% 20% 294

295 This test farm included 2,000 SharePoint Server sites. Each site contained one small, one large, and one very large workbook. The distribution of the workbooks on the SharePoint Server pages was 10% small workbooks and 90% large and very large workbooks. Additionally, the test farm dataset included SharePoint Server pages that contained 1-5 Excel Web Parts. Workload To simulate application usage, workloads were created to perform one or more of the following operations: Action Mix Small Workbook Large Workbook View 50% 70% Edit 35% 15% Collaborative Viewing 10% 10% Collaborative Editing 5% 5% In addition, 17% of all the workbooks included external data. For large and very large workbooks that included external data, refreshes were performed 80% of the time; small workbooks do not include external data. Each workload includes think time between user actions of 10 seconds. Think time refers to user action delays that simulate how long a user might take to perform the actions. This differs from other SharePoint Server 2010 capacity planning documents. Servicios de Excel is stateful the workbook is maintained in memory between user interactions making it important to simulate a full user session and not merely individual requests. On average, there are 0.2 requests per second for a single user workload. We randomly selected one of the 2,000 sites to run the test for each workload. We used the percentages in the following table to select application and application size, within that site. Workbook Selection Use Percentage Small Workbook 30% Large Workbook 55% 295

296 Workbook Selection Use Percentage Dashboard 10% Very Large Workbook 5% Green and Red Zone definitions For each configuration two zones were determined before throughput tests were performed. One zone was the green zone or recommended zone in which throughput can be sustained. The other zone was the red zone or maximum zone in which throughput can be tolerated for a short time but should be avoided. To determine our red and green zone user loads, we first conducted a step test and then stopped when the following conditions were met: Green zone We stopped at the point when any of the computers in our farm (Web front-end, Excel Calculation Services, or Microsoft SQL Server) exceeded 50% CPU usage or the response time for the overall system exceeded 1 second. Red Zone We stopped at the point where the successful RPS for the Excel Calculation Services computers in the farm was at a maximum. Past this point, the overall throughput for the farm started to decrease and/or we would start to see failures from one of the tiers. Often the maximum private bytes in Excel Calculation Services would be exceeded when throughput was in the red zone. After conducting the step tests, we retreated from these maximum values to run a longer constant load test of 1 hour. We stopped the green zone test when 75% of the load was used. We peaked in the red zone step test when we used 65% of the load. If the green zone test was limited by memory, and the CPU usage percentage never exceeded 50%, we instead used 75% of the load number calculated for the red zone. The average response time was less than.25 seconds for both green and red zones, and for both scale-out and scale-up tests. Hardware Settings and Topology This section describes the kinds of computer hardware we used in our lab and the farm configuration topologies that we used in our tests. Lab Hardware Several farm configurations were used for our testing to provide a high level of test-result detail. The farm configurations ranged from one to three Web front-end servers, one to three application servers for Servicios de Excel and Excel Calculation Services, and a single database server computer that is running Microsoft SQL Server Additionally, our tests used four client computers. All servers were 64-bit, and the client computers were 32-bit. The following table lists the specific hardware that we used for testing. 296

297 Machine Role CPU Memory Network Web front-end server 2 proc/4 core 2.33 GHz Intel Xeon 8 GB 1 gig Excel Calculation Services 2 proc/4 core 2.33 GHz Intel Xeon 8 GB 1 gig SQL Server 4 proc/4 core 2.6 GHz Intel Xeon 16 GB 1 gig Topology Our testing experience indicates that memory on the Excel Calculation Services tier and CPU on the Web front-end server tier are the most important limiting factors for throughput. Be aware that your experience may vary. As a result, we varied the number of computer servers in both tiers for the scale-out tests. We deployed a topology of 1:1 for the Excel Calculation Services and Web front-end servers for the scale-up tests, and then varied the number of processors and available memory in the Excel Calculation Services computers. Excel Calculation Services is not especially demanding on the SQL Server instance running SharePoint Server 2010, as the workbook is read a binary large object (BLOB) from SharePoint Server 2010 and put in memory on the Excel Calculation Services tier (and additionally disk cached). At no time did SQL Server become a bottleneck. For all tests, bottleneck is defined as a state in which the capacity of a particular component of a farm is reached. Test Results The following tables show the test results of Servicios de Excel en Microsoft SharePoint Server For each group of tests, only certain specific variables are changed to show the progressive effect on farm performance. Note that all the tests reported on in this article were conducted with think or wait time (think time equals 10 seconds between user actions). This differs from the capacity planning results for other parts of SharePoint Server For information about Servicios de Excel bottlenecks, see the Common bottlenecks and their causes section in this article. 297

298 Overall Scale The table here summarizes the effect of adding additional Web Front-End and dedicated Excel Calculation Services computers to the farm. These throughput numbers are specifically for the Excel Calculation Services computers, and do not reflect the effect on the overall farm. Topology Baseline Maximum (RPS) Baseline Recommended (RPS) 1x x x x x x x x x

299 299

300 Recommended Results The following chart shows our results for recommended sustainable throughput. 300

301 The previous chart shows that there is overhead associated with adding Web front-end computers to the farm. However, this is offset as Excel Calculation Services computers are added. A single Web front-end became the bottleneck after adding two additional Excel Calculation Services computers. This Web front-end bottleneck reversed any benefit that was gained from the additional capacity of adding a second and third Excel Calculation Services computer. Also notice that three Web front-end computers did not add any more throughput, as Excel Calculation Services became the limiting factor. 301

302 302

303 Notice in the previous chart that as Web front-end computers are added, the CPU load on each computer is reduced significantly. Note too, that with two Web front-end computers and three Excel Calculation Services computers, the CPU load is reaching the maximum seen for a single Web front-end computer. This implies that adding another Excel Calculation Services computer would make the Web front-end tier the limiting factor. Remember that these results are for the recommended load. This is why the CPU load is maxing out at around 35% instead of at an increased level. Maximum Results The following chart shows our results for maximum peak throughput. 303

304 304

305 Similar to our recommended results, we see that a single Web front-end computer is the limiting factor as we add a second and third Excel Calculation Services computer. Also notice that exactly as with the recommended results, adding a third Web front-end computer does not add to throughput as Excel Calculation Services is the limiting factor after the second Web front-end computer is added. 305

306 306

307 The results in the previous chart show that multiple Web front-end computers do not become as heavily loaded as a single Web front-end computer configuration. This indicates that the Excel Calculation Services computers are the bottleneck after the second Web front-end computer is added. Detailed Results This section shows details for the recommended and maximum results obtained in our tests. Recommended Results The following tables show the recommended results of our tests. Overall 1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3 Client Successful RPS Client Response Time (sec.) TPS Web Front-end Tier 1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3 % CPU (average over all Web Frontend computers Excel Calculation Services Tier % CPU (average over all Excel 1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x

308 Excel Calculation Services Tier Calculation Services computers) Peak Private Bytes (maximum over all Excel Calculation Services computers) 1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3 5.94E E E E E E E E E+09 Maximum Results The following tables show the maximum results of our tests. Overall 1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3 Client Successful RPS Client Response Time (sec.) TPS Web Front-end Tier 1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3 % CPU (average over all Web Frontend computers 308

309 Excel Calculation Services Tier % CPU (average over all Excel Calculation Services computers) Peak Private Bytes (maximum over all Excel Calculation Services computers) 1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x E E E E E E E E E+09 Scale Up Test results We also measured the effect of adding CPUs and memory to the Excel Calculation Services tier. For these tests, a 1x1 topology was used. 309

310 Our results in the previous chart show that adding additional CPUs was helpful but did not significantly affect the overall throughput. 310

311 311

312 The red zone line in the previous chart shows however, that adding memory does have a significant effect on throughput, especially at peak times. In this test, the same hardware was used throughout. However, the Maximum Private Bytes for the Servicios de Excel process was limited. Since workbooks are kept in memory, the size of the workbooks has a significant effect on how many workbooks, and also how many users, any Excel Calculation Services computer can support. Recommendations This section provides general performance and capacity recommendations for hardware, Servicios de Excel settings, common bottlenecks and troubleshooting. Note that Servicios de Excel capacity and performance is highly dependent on the makeup of the workbooks that are hosted on the service. The size of the workbook and the complexity of calculations have the most effect. Our testing used representative sizes and complexities, but every workbook is different, and your capacity and performance depends on the specific size and complexity of the workbooks you use. Hardware Recommendations Servicios de Excel uses standard hardware for both Web front-end servers and application servers, there are no special requirements. General SharePoint Server 2010 guidelines on CPU number, speed, and memory are applicable for computers in the Excel Calculation Services tier. Note that one of the first bottlenecks an Excel Calculation Services computer is likely to encounter is memory and this may require you to add resources. Before you do, we recommend that you test with a representative set of workbooks from your organization, as the size and complexity of workbooks have a large effect on how much more capacity the addition of memory is likely to have. To increase the capacity and performance of one of the starting-point topologies, you can do one of two things. You can either scale up by increasing the capacity of your existing servers or scale out by adding additional servers to the topology. This section describes the general performance characteristics of several scaled-out topologies. The sample topologies represent the following common ways to scale out a topology for an Servicios de Excel scenario: To provide for more user load, check the CPU and memory for the existing Servicios de Excel application servers. Add additional memory if the CPU is not a concern, or add CPUs if memory is not a concern. If both memory and CPU are reaching their upper limits, additional Excel Calculation Services computers may be necessary. Add additional Excel Calculation Services or application servers until the point that the Web front-end servers become the bottleneck, and then add Web front-end servers as needed. In our tests, SQL Server was not a bottleneck. Servicios de Excel does not make large demands on the database tier, as workbooks are read and written as whole documents, and also workbooks are held in memory throughout the user s session. 312

313 Performance-Related Servicios de Excel Settings One of the ways to control the performance characteristics of Servicios de Excel is to control how memory is used. Each of the global settings in the following list are set through SharePoint Server 2010 Central Administration > Application Management: Manage Service Applications > Aplicación de Servicios de Excel > Global Settings: Maximum Private Bytes By default, Excel Calculation Services will use up to 50% of the memory on the computer. If the computer is shared with other services, it may make sense to lower this number. If the computer is not being shared and is dedicated to Excel Calculation Services, and is indicating that memory may be a limiting factor, increasing this number may make sense. In any event, experimenting by adjusting this number can guide the administrator to making the necessary changes in order to better scale up. Memory Cache Threshold Excel Calculation Services will cache unused objects (for example, read-only workbooks for which all sessions have timed out) in memory. By default, Excel Calculation Services will use 90% of the Maximum Private Bytes for this purpose. Lowering this number can improve overall performance if the server is hosting other services in addition to Excel Calculation Services. Increasing this number increases the chances that the workbook being requested will already be in memory and will not have to be reloaded from the SharePoint Server content database. Maximum Unused Object Age By default, Excel Calculation Services will keep objects in the memory cache as long as possible. To reduce the Excel Calculation Services memory usage, in particular with other services that are running on the same computer, it may make more sense to impose a limit on how long objects are cached in memory. There are also settings available to control the maximum size of a workbook and the lifetime of a session, which in turn control how long a workbook is held in memory. These settings are associated with each trusted location and are not global. These settings can be set through SharePoint Server 2010 Central Administration > Application Management: Manage Service Applications > Aplicación de Servicios de Excel > Trusted Locations, and then edit the settings for each trusted location in the Workbook Properties section on the Edit Trusted File Location page. Maximum Workbook Size Maximum Chart or Image Size By default, Excel Calculation Services is limited to 10 MB or smaller workbooks and 1 MB or smaller charts/images. Obviously using larger workbooks and larger charts/images puts more strain on the available memory of the Excel Calculation Services tier computers. However, there may be users in your organization that need these settings to be increased for Excel Calculation Services to work with their particular workbooks. Session Timeout By decreasing the session time out, memory is made available for either the unused object cache or other services faster. 313

314 Volatile Function Cache Lifetime Volatile functions are functions that can change their value with each successive recalculation of the workbook, for example date/time functions, random number generators, and so on. Because of the load this could generate on the server, Excel Calculation Services does not recalculate these values for each recalculation, instead caching the last values for a short time period. Increasing this lifetime can reduce the load on the server. However, this depends on having workbooks that use volatile functions. Allow External Data Excel Calculation Services can draw on external data sources. However, the time that is required to draw upon the external source can be significant, with potentially a large amount of data returned. If external data is allowed, there are several additional settings that can help throttle the effect of this feature. Common bottlenecks and their causes During performance testing, several different common bottlenecks were revealed. Bottlenecks are defined as a state in which the capacity of a particular component of a farm is reached. This causes a plateau or decrease in farm throughput. The following table lists some common bottlenecks and describes their causes and possible resolutions. Troubleshooting performance and scalability Bottleneck Cause Resolution Excel Calculation Services Memory Servicios de Excel holds each workbook in memory throughout the user's session. A large number of workbooks, or large workbooks, can cause Excel Calculation Services to consume all available memory causing the actually consumed "Private Bytes" to exceed "Maximum Private Bytes." Scale Up with more memory in the Excel Calculation Services tier computers, or Scale Out with the addition of more Excel Calculation Services computers. The choice will partly depend on if CPU is also reaching a maximum. Excel Calculation Services CPU Servicios de Excel can depend on a large amount of processing in the application tier, depending on the number and complexity of workbooks. 314 Increase the number of CPUs and/or cores in the existing Excel Calculation Services computers, or add Excel Calculation

315 Bottleneck Cause Resolution Web server CPU usage When a Web server is overloaded with user requests, average CPU usage will approach 100 percent. This prevents the Web server from responding to requests quickly and can cause timeouts and error messages on client computers. Services computers. This issue can be resolved in one of two ways. You can add Web servers to the farm to distribute user load, or you can scale up the Web server or servers by adding faster processors. Performance monitoring To help you determine when you have to scale up or scale out the system, use performance counters to monitor the health of the system. Use the information in the following tables to determine which performance counters to monitor, and to which process the performance counters should be applied. Front-end Web server The following table shows performance counters and processes to monitor for front-end Web servers in your farm. Performance Counter Apply to object Notes % Processor Time Processor (w3wp) Shows the percentage of elapsed time that this thread used the processor to execute instructions. % Processor Time Processor (_Total) Shows the percentage of elapsed time that all threads on the server computer that used the processor to execute 315

316 Performance Counter Apply to object Notes instructions. Private Bytes Process (w3wp) This value should not approach the Max Private Bytes set for w3wp processes. If it does, additional investigation is needed into what component is using the memory. Excel Calculation Services The following table shows performance counters and processes to monitor for application servers, or in this case Excel Calculation Services, within your farm. Performance Counter Apply to object Notes % Processor Time Processor (_Total) Shows the percentage of elapsed time that all threads on the server that used the processor to execute instructions. % Processor Time Processor (w3wp) The Excel Calculation Services runs within its own w3wp process, and it will be obvious which w3wp process this is as it will be getting the bulk of the CPU time. 316

317 Performance Counter Apply to object Notes Average Disk Queue Length PhysicalDisk(_Total) Watch for too much disk writing because of logging. Private Bytes Process(w3wp) Servicios de Excel caches workbooks in memory, until the user's session expires (the time out for which is configurable). If a large amount of data is being processed through the Excel Calculation Services, memory consumption for the Excel Calculation Services w3wp will increase. SQL Server As we have previously described, Servicios de Excel is light on the SQL Server tier, as workbooks are read once into memory on the Excel Calculation Services tier during the user's session. Follow general SharePoint Server guidelines for monitoring and troubleshooting of the SQL Server tier. 317

318 Estimación de los requisitos de rendimiento y capacidad de PerformancePoint Services En este artículo se describe el efecto que tiene PerformancePoint Services en las topologías que ejecutan Microsoft SharePoint Server Nota: Es importante tener en cuenta que las cifras de capacidad y rendimiento específicas presentadas en este artículo serán diferentes de las cifras en entornos reales. Las cifras que se presentan están diseñadas para proporcionar un punto de partida para el diseño de un entorno a una escala adecuada. Después de completar el diseño inicial del sistema, pruebe la configuración para determinar si el sistema admitirá los factores del entorno. En este artículo: Prueba de las características del conjunto o granja de servidores Resultados de las pruebas Recomendaciones Si desea obtener información general sobre el modo de planear y ejecutar la capacidad para SharePoint Server 2010, vea Capacity management and sizing for SharePoint Server 2010 (en inglés). Prueba de las características del conjunto o granja de servidores Conjunto de datos El conjunto de datos constaba de un portal corporativo creado mediante SharePoint Server 2010 y PerformancePoint Services que contenía un solo panel de tamaño mediano. El panel contenía dos filtros vinculados a un cuadro de mandos, dos gráficos y una 318

319 cuadrícula. El panel estaba basado en un solo origen de datos de Microsoft SQL Server 2008 Analysis Services (SSAS) que usaba las bases de datos de ejemplo AdventureWorks para el cubo de SQL Server 2008 Analysis Services. En la tabla siguiente se describen el tipo y el tamaño de cada elemento del panel. Nombre Descripción Tamaño Filtro uno Filtro de selección de miembros 7 miembros de dimensión Filtro dos Filtro de selección de miembros 20 miembros de dimensión Cuadro de mandos Cuadro de mandos 15 filas de miembros de dimensión por 4 columnas (2 KPI) Gráfico uno Gráfico de líneas 3 series por 12 columnas Gráfico dos Gráfico de barras apiladas 37 series por 3 columnas Cuadrícula Cuadrícula analítica 5 filas por 3 columnas En el panel mediano se usó la plantilla de encabezado y dos columnas y los tamaños de los elementos del panel se establecieron en tamaño automático o en un porcentaje específico del panel. Cada elemento del panel se representó con un alto y ancho aleatorios de entre 400 y 500 píxeles para simular las diferencias existentes entre los tamaños de ventana del explorador web. Es importante cambiar el alto y el ancho de cada elemento del panel debido a que los gráficos se representan en función de los tamaños de ventana del explorador web. Escenarios de prueba y procesos En esta sección se definen los escenarios de prueba y se describe el proceso de prueba que se usó para cada escenario. En la sección "Resultados de las pruebas", más adelante en este artículo, se proporciona información detallada, como los resultados de las pruebas y parámetros específicos. 319

320 Nombre de la prueba Represente un panel y cambie uno de los dos filtros cinco veces de forma aleatoria con una pausa de 15 segundos entre las interacciones. Descripción de la prueba 1. Represente el panel. 2. Seleccione uno de los dos filtros. A continuación, seleccione de forma aleatoria un valor de filtro y espere a que el panel se vuelva a representar. 3. Repita el procedimiento otras cuatro veces, en las que debe seleccionar de forma aleatoria uno de los dos filtros y un valor de filtro aleatorio. Represente un panel, seleccione un gráfico y expándalo y contráigalo cinco veces con una pausa de 15 segundos entre las interacciones. 1. Represente el panel. 2. Seleccione un miembro aleatorio en un gráfico y expándalo. 3. Seleccione otro miembro aleatorio en el gráfico y contráigalo. 4. Seleccione otro miembro aleatorio en el gráfico y expándalo. 5. Seleccione otro miembro aleatorio en el gráfico y contráigalo. Represente un panel, seleccione una cuadrícula y expándala y contráigala cinco veces con una pausa de 15 segundos entre las interacciones. 1. Represente el panel. Seleccione un miembro aleatorio en una cuadrícula y expándalo. 2. Seleccione otro miembro aleatorio de la cuadrícula y expándalo. 3. Seleccione otro miembro aleatorio en la cuadrícula y contráigalo. 4. Seleccione otro miembro aleatorio de la cuadrícula y expándalo. Se usó una combinación de pruebas única que consistió en los siguientes porcentajes de las pruebas iniciadas. 320

321 Nombre de la prueba Represente un panel y cambie de forma aleatoria uno de los dos filtros cinco veces. Represente un panel, seleccione un gráfico y expándalo y contráigalo cinco veces. Represente un panel, seleccione una cuadrícula y expándala y contráigala cinco veces. Combinación de pruebas 80% 10% 10% Con las herramientas de prueba de carga de Microsoft Visual Studio 2008 se creó un conjunto de pruebas web y pruebas de carga que simularon cambios aleatorios en los filtros y la navegación por las cuadrículas y los gráficos por parte de los usuarios. Las pruebas usadas en este artículo contenían una distribución normal de pausas de 15 segundos entre las interacciones, también denominadas "tiempos de reflexión", y un tiempo de reflexión entre iteraciones de prueba de 15 segundos. Se aplicó la carga para producir un tiempo de respuesta promedio de dos segundos para representar un cuadro de mandos o un informe. Se midió el tiempo de respuesta promedio durante un período de 15 minutos después de un tiempo de preparación inicial de 10 minutos. Cada nueva iteración de prueba selecciona una cuenta de usuario distinta de un grupo de cinco mil cuentas y una dirección IP aleatoria (mediante el uso de conmutación de IP de Visual Studio) de un grupo de aproximadamente direcciones. La combinación de pruebas se ejecutó dos veces respecto del mismo panel de tamaño mediano. En la primera ejecución, la autenticación del origen de datos se configuró para usar la cuenta de servicio desatendida, que usa una cuenta común para solicitar los datos. Los resultados de datos son idénticos para varios usuarios y PerformancePoint Services puede usar almacenamiento en caché para mejorar el rendimiento. En la segunda ejecución, la autenticación de origen de datos se configuró para usar la identidad de usuario y el cubo de SQL Server Analysis Services se configuró para usar seguridad dinámica. En esta configuración, PerformancePoint Services usa la identidad del usuario para solicitar los datos. Debido a que los resultados de datos podrían ser diferentes, no se puede compartir el almacenamiento en caché entre usuarios. En algunos casos, puede compartirse el almacenamiento en caché para identidad de usuario si no se configuró la seguridad dinámica de Analysis Services y los roles de Analysis Services asignados a los usuarios y grupos de Microsoft Windows son idénticos. 321

322 Configuración de hardware y topología Hardware de laboratorio Para proporcionar un alto nivel de detalle en los resultados de la prueba, se usaron varias configuraciones de granja de servidores para las pruebas. Las configuraciones de granjas de servidores incluyeron de uno a tres servidores web, de uno a cuatro servidores de aplicaciones y un solo servidor de bases de datos que ejecutaba Microsoft SQL Server Se realizó una instalación empresarial predeterminada de SharePoint Server En la tabla siguiente se enumera el hardware específico usado para realizar las pruebas. Servidor web Servidor de aplicaciones Equipo que ejecuta SQL Server Equipo que ejecuta Analysis Services Procesadores 2px4c de 2,66 GHz 2px4c de 2,66 GHz 2px4c de 2,66 GHz 4px6c a 2,4 GHz RAM 16 GB 32 GB 16 GB 64 GB Sistema operativo Windows Server 2008 R2 Enterprise Windows Server 2008 R2 Enterprise Windows Server 2008 R2 Enterprise Windows Server 2008 R2 Enterprise NIC 1x1 gigabit 1x1 gigabit 1x1 gigabit 1x1 gigabit Autenticación NTLM y Kerberos NTLM y Kerberos NTLM y Kerberos NTLM y Kerberos Después de incrementar la escalabilidad horizontal de la granja de servidores a varios servidores web, se usó un equilibrador de carga de hardware para equilibrar la carga de usuarios entre varios servidores web mediante el uso de afinidad de dirección de origen. La afinidad de dirección de origen registra la dirección IP de origen de las solicitudes entrantes y el host de servicios en el que se equilibró la carga, y canaliza todas las transacciones futuras al mismo host. 322

323 Topología La topología inicial consistió en dos servidores físicos. Uno se usó como servidor web y de aplicaciones y el otro como servidor de bases de datos. Esta topología inicial se considera una topología de dos máquinas (2M) o una topología "1 por 0 por 1", en que el número de servidores web dedicados aparece al comienzo de la lista, seguido de los servidores de aplicaciones dedicados y, a continuación, los servidores de bases de datos. Los servidores web también se denominan front-end web (WFE) más adelante en este documento. Se aplicó la carga hasta que se encontraron factores restrictivos. Por lo general, el factor restrictivo fue la CPU del servidor web o del servidor de aplicaciones y se agregaron recursos para solucionar ese límite. Los factores restrictivos y las topologías difirieron considerablemente en función de la configuración de la autenticación del origen de datos de cuenta de servicio desatendida o identidad de usuario con seguridad de cubo dinámico. Resultados de las pruebas Los resultados de las pruebas contienen tres medidas importantes que ayudan a definir la capacidad de PerformancePoint Services. Medida Recuento de usuarios Solicitudes por segundo (RPS) Vistas por segundo (VPS) Descripción Recuento de usuarios total que informa Visual Studio. Total de solicitudes por segundo que notifica Visual Studio, que incluye todas las solicitudes y las solicitudes de un archivo estático, como imágenes y hojas de estilos. Total de vistas que puede representar PerformancePoint Services. Una vista es cualquier filtro, cuadro de mandos, cuadrícula o gráfico representado por PerformancePoint Services o cualquier solicitud web a la dirección URL del servicio de representación que contiene RenderWebPartContent o CreateReportHtml. Para obtener más información acerca de CreateReportHtml y RenderWebPartContent, vea el tema sobre la especificación del protocolo RenderingService de PerformancePoint Services ( Los registros IIS de estas solicitudes pueden analizarse para ayudar a planear 323

324 Medida Descripción la capacidad de PerformancePoint Services. Además, el uso de esta medida proporciona un número que es mucho menos dependiente de la composición del panel. Un panel con dos vistas se puede comparar con un panel con 10 vistas. Sugerencia: Cuando se usa un origen de datos que se ha configurado para usar autenticación de cuenta de servicio desatendida, la regla para la proporción de servidores dedicados es un servidor web por cada dos servidores de aplicaciones que ejecutan PerformancePoint Services. Sugerencia: Cuando se usa un origen de datos que se ha configurado para usar autenticación de usuario, la regla para la proporción de servidores dedicados es un servidor web por cada cuatro o más servidores de aplicaciones que ejecutan PerformancePoint Services. En las topologías de más de cuatro servidores de aplicaciones, es probable que el cuello de botella sea el servidor de Analysis Services. Considere supervisar la CPU y el tiempo de consulta del servidor de Analysis Services para determinar si debe incrementar la escalabilidad horizontal de Analysis Services a varios servidores. Cualquier retraso en el tiempo de consulta en el servidor de Analysis Services aumentará considerablemente el tiempo de respuesta promedio de PerformancePoint Services más allá del umbral deseado de dos segundos. En las tablas siguientes se muestra un resumen de los resultados de las pruebas para autenticación de cuenta de servicio desatendida y autenticación de usuario al incrementar la escalabilidad horizontal de dos a siete servidores. Más adelante en este documento se incluyen resultados detallados con contadores de rendimiento adicionales. 324

325 Resumen de autenticación de cuenta de servicio desatendida Topología (WFE x APP x SQL) Usuarios Solicitudes por segundo (RPS) 2M (1x0x1) M (1x1x1) M (1x2x1) M (1x3x1) M (2x3x1) M (2x4x1) Vistas por segundo (VPS) Resumen de autenticación de usuario Topología (WFE x APP x SQL) Usuarios Solicitudes por segundo (RPS) 2M (1x0x1) M (1x1x1) M (1x2x1) M (1x3x1) Vistas por segundo (VPS) 325

326 Topologías 2M y 3M Para ayudar a explicar el costo de hardware por transacción y la curva de tiempo de respuesta, las pruebas de carga se ejecutaron con cuatro cargas de usuarios cada vez mayores, hasta alcanzar la carga máxima de usuarios para las topologías 2M y 3M. Autenticación de la cuenta de servicio desatendida Recuento de usuarios Promedio de CPU de WFE/APP 19,20% 57,70% 94,00% 96,70% RPS Vistas por segundo 10,73 31,72 49,27 49,67 Tiempo de respuesta promedio (seg.) 0,12 0,15 0,

327 Autenticación de usuario 327

328 Recuento de usuarios Promedio de CPU de WFE/APP 30,80% 61,30% 86,50% 93,30% RPS Vistas por segundo 10,3 19,32 26,04 27,75 Tiempo de respuesta promedio (seg.) 0,28 0,45 0,

329 Resultados de granja de servidores 3M (1x1x1) Autenticación de la cuenta de servicio desatendida 329

330 Recuento de usuarios RPS Vistas por segundo Tiempo de respuesta promedio (seg.) 0,12 0,18 0,65 2 Promedio de CPU de WFE 11% 28% 43% 46% Número máximo de bytes privados de WFE del proceso de trabajo de Internet Information Services (IIS) W3WP de SharePoint Server. 0,7 GB 1,4 GB 2,0 GB 2,4 GB Promedio de CPU de APP 25% 62% 94% 95% Máximo de bytes privados de APP de W3WP de PerformancePoint Services 5,9 GB 10,8 GB 14,1 GB 14,6 GB 330

331 Autenticación por usuario 331

332 Recuento de usuarios RPS Vistas por segundo Tiempo de respuesta promedio (seg.) 0,28 0,48 0,91 2 Promedio de CPU de WFE 5% 12% 17% 19% Máximo de bytes privados de WFE de W3WP de SharePoint Server 0,78 GB 1,3 GB 1,6 GB Promedio de CPU de APP 25% 57% 81% 81% Máximo de bytes privados de APP de W3WP de PerformancePoint Services 19 GB 20,1 GB 20,5 GB 1,9 GB 20,9 GB 332

333 333

334 Resultados para topologías de 4 o más máquinas para autenticación de cuenta de servicio desatendida Comenzando con una topología de cuatro máquinas, se aplicó carga para producir un tiempo de respuesta promedio de dos segundos para representar un cuadro de mandos o un informe. A continuación, se agregó un servidor adicional para resolver el factor restrictivo (siempre CPU en el servidor web o el servidor de aplicaciones) y, a continuación, se volvió a ejecutar la combinación de pruebas. Esta lógica se repitió hasta que se alcanzó un total de siete servidores. 4M (1x2x1) 5M (1x3x1) 6M (2x3x1) Recuento de usuarios RPS Vistas por segundo Promedio de CPU de WFE 77% 63% 54% 73% Máximo de bytes privados de WFE de W3WP de SharePoint Server 7M (2x4x1) 2,1 GB 1,7 GB 2,1 GB 2,0 GB Promedio de CPU de APP 83% 94% 88% 80% Máximo de bytes privados de APP de W3WP de 16 GB 12 GB 15 GB 15 GB PerformancePoint Services 334

335 Resultados para topologías de 4 o más máquinas para autenticación de usuario Se repitieron las mismas pruebas para un origen de datos configurado para autenticación de usuario. Tenga en cuenta que al agregar un servidor de aplicaciones para crear una topología de cuatro servidores de aplicaciones no se aumentó el número de usuarios ni las solicitudes por segundo que admitía PerformancePoint Services debido a los retrasos en las consultas que produjo Analysis Services. 3M (1x1x1) 4M (1x2x1) 5M (1x3x1) Recuento de usuarios RPS Vistas por segundo Promedio de CPU de WFE 19% 24% 26% 12% Máximo de bytes privados de WFE de W3WP de SharePoint Server 6M (1x4x1) 2,1 GB 1,9 GB 1,9 GB 1,5 GB Promedio de CPU de APP 89% 68% 53% 53% Máximo de bytes privados de APP de W3WP de 20 GB 20 GB 20 GB 20 GB PerformancePoint Services CPU de Analysis Services 17% 44% 57% 68% 335

336 336

337 Recomendaciones Recomendaciones de hardware Se recomienda usar los contadores de memoria y procesador de las tablas de prueba para determinar los requisitos de hardware para la instalación de PerformancePoint Services. En el caso de servidores web, PerformancePoint Services usa los requisitos de hardware de SharePoint Server 2010 recomendados. Es posible que sea necesario cambiar los requisitos de hardware de los servidores de aplicaciones si PerformancePoint Services consume una gran cantidad de memoria. Esto sucede cuando los orígenes de datos se configuran para autenticación de usuario o cuando el servidor de aplicaciones ejecuta muchos paneles con tiempos de espera de origen de datos largos. El servidor de bases de datos no produjo un cuello de botella en las pruebas y tuvo un pico máximo de uso de CPU del 31% bajo el panel con autenticación de cuenta de servicio desatendida de 7M. PerformancePoint Services almacena las definiciones de contenido de PerformancePoint Services, como informes, cuadros de mandos y KPI, en listas de SharePoint y en la memoria caché, lo que reduce la carga del servidor de bases de datos. Consumo de memoria PerformancePoint Services puede consumir grandes cantidades de memoria en determinadas configuraciones y es importante supervisar el uso de memoria del grupo de aplicaciones de PerformancePoint Services. PerformancePoint Services almacena varios elementos en la memoria caché, incluidos los resultados de Analysis Services y otros resultados de consultas de origen de datos, por la duración de la memoria caché de origen de datos (tiempo predeterminado de 10 minutos). Cuando se usa un origen de datos que está configurado para la autenticación de cuenta de servicio desatendida, los resultados de estas consultas solo se almacenan una vez y se comparten entre varios usuarios. Sin embargo, cuando se usa un origen de datos que está configurado para autenticación de usuario y seguridad de cubo dinámico de Analysis Services, los resultados de las consultas se almacenan una vez por cada usuario por cada vista (es decir, una combinación "por filtro"). La API de caché subyacente que usa PerformancePoint Services es la API de caché de ASP.NET. La ventaja significativa de usar esta API es que ASP.NET administra la memoria caché y quita (o recorta) elementos en función de los límites de la memoria para evitar errores de falta de espacio en memoria. El límite de memoria predeterminado es del 60 por ciento de la memoria física. Después de alcanzar este límite, PerformancePoint Services continuó representando vistas pero los tiempos de respuesta aumentaron considerablemente durante el breve período en que ASP.NET quitó las entradas almacenadas en la memoria caché. 337

338 El contador de rendimiento "Aplicaciones ASP.NET\Recortes API de caché" del grupo de aplicaciones que hospeda PerformancePoint Services se puede usar para supervisar los recortes de la memoria caché de ASP.NET que se producen debido a la presión de memoria. Si este contador es mayor que cero, revise la siguiente tabla para ver posibles soluciones. Problema El uso del procesador del servidor de aplicaciones es reducido y hay otros servicios que se están ejecutando en el servidor de aplicaciones. El uso del procesador del servidor de aplicaciones es reducido y solo se está ejecutando PerformancePoint Services en el servidor de aplicaciones. El uso del procesador del servidor de aplicaciones es intensivo. Solución Agregue más memoria física o limite la memoria caché de ASP.NET. Si es aceptable, configure las opciones de memoria caché de ASP.NET para que la memoria caché use o agregue más memoria. Agregue otro servidor de aplicaciones. Un origen de datos que se ha configurado para usar autenticación de usuario puede compartir los resultados de las consultas y las entradas de la memoria caché si los conjuntos de pertenencias a roles de Analysis Services de los usuarios son idénticos y si no se ha configurado la seguridad de cubo dinámico. Se trata de una nueva característica de PerformancePoint Services in Microsoft SharePoint Server Por ejemplo, si el usuario A está en el rol 1 y 2, el usuario B en el rol 1 y 2 y el usuario C en el rol 1, 2 y 3, solo el usuario A y el usuario B compartirán las entradas de caché. Si no hay seguridad de cubo dinámico, los usuarios A y B, así como el usuario C, no compartirán las entradas de la memoria caché. Analysis Services Durante la prueba de PerformancePoint Services con autenticación de usuario, se cambiaron dos propiedades de Analysis Services para mejorar el rendimiento multiusuarios. En la siguiente tabla se muestran las propiedades que se cambiaron y el nuevo valor de cada propiedad. 338

339 Propiedad Analysis Services Valor Memory \ HeapTypeForObjects 0 Memory \ MemoryHeapType 2 Estas dos opciones de memoria configuran Analysis Services para usar el montón de Windows en lugar del montón de Analysis Services. Antes de cambiar estas propiedades y, mientras se aumentaba la carga de usuarios, los tiempos de respuesta aumentaron significativamente de 0,2 segundos a más de 30 segundos mientras que la CPU de los servidores web, de aplicaciones y de Analysis Services se mantenía baja. Para solucionar el problema, se recopiló el tiempo de consulta usando vistas de administración dinámica (DMV) de Analysis Services, que mostraron un aumento de los tiempos de consulta individuales de 10 milisegundos a 5000 milisegundos. Estos resultados llevaron a la modificación de la configuración de memoria anterior. Es importante tener en cuenta que aunque esto mejoró notablemente la capacidad de proceso, según el equipo de Analysis Services, la modificación de esta configuración tiene un costo pequeño pero perceptible en las consultas de usuario único. Antes de cambiar cualquier propiedad de Analysis Services, vea el tema sobre la guía de rendimiento de Analysis Services de las notas del producto de SQL Server 2008 ( para conocer los procedimientos recomendados sobre cómo mejorar el rendimiento multiusuario. Cuellos de botella comunes y sus causas Durante las pruebas de rendimiento, se detectaron varios cuellos de botella habituales. Un cuello de botella es una situación en la que se alcanza la capacidad máxima de un componente determinado de una granja de servidores. Esto produce un estancamiento o una disminución en el rendimiento la granja de servidores. En los casos en que el intenso uso del procesador producía un cuello de botella, se agregaron servidores para resolver el problema. En la siguiente tabla se enumeran algunos cuellos de botella comunes, y las posibles soluciones, en los que se supone que el uso del procesador es reducido y que no produce ningún cuello de botella. Posible cuello de botella Causa y qué supervisar Resolución Rendimiento del montón de memoria de Analysis Services De manera predeterminada, Analysis Services usa su propio montón de memoria Cambie Analysis Services para usar el montón de Windows. Vea la sección "Analysis Services", anteriormente en este artículo, y el tema sobre la guía de rendimiento de Analysis Services de las notas del producto de SQL Server 339

340 Posible cuello de botella Causa y qué supervisar Resolución Subprocesos de consulta y procesamiento de Analysis Services Memoria del servidor de aplicaciones en lugar del montón de Windows, que proporciona un rendimiento multiusuario deficiente. Revise los tiempos de consulta de Analysis Services mediante las vistas de administración dinámica (DMV) para ver si los tiempos de consulta aumentan con la carga de usuarios y el uso del procesador de Analysis Services es reducido. De manera predeterminada, Analysis Services limita el número de subprocesos de consulta y procesamiento de las consultas. Las consultas de larga ejecución y las cargas de usuarios elevadas podrían usar todos los subprocesos disponibles. Supervise los subprocesos inactivos y los contadores de rendimiento de la cola de trabajos en la categoría 2008:Threads MSAS. PerformancePoint Services almacena en caché los 2008 ( para obtener instrucciones. Aumente el número de subprocesos disponibles para consultas y procesos. Vea la sección "Analysis Services" y el tema sobre la guía de rendimiento de Analysis Services de las notas del producto de SQL Server 2008 ( para obtener instrucciones. Agregue memoria o aumente los límites predeterminados de la memoria caché de ASP.NET. Vea la sección Consumo de memoria, anteriormente en este 340

341 Posible cuello de botella Causa y qué supervisar Resolución Configuración de limitación de peticiones de WCF resultados de la consulta de documento, para obtener más información. Vea también el tema sobre la Analysis Services y de otros configuración de elementos de la memoria caché de ASP.NET orígenes de datos por la ( y la entrada de duración de la memoria blog de Thomas Marquardt acerca de los antecedentes de los límites de la caché de origen de datos. memoria caché de ASP.NET Estos elementos pueden ( consumir una gran cantidad de memoria. Supervise el contador de rendimiento Aplicaciones de ASP.NET\Recortes API de caché del grupo de aplicaciones de PerformancePoint Services para determinar si las eliminaciones o recortes de la memoria caché son forzados por ASP.NET debido a la falta de memoria. PerformancePoint Services Si es necesario, cambie el comportamiento de limitación de peticiones de se implementa como un Windows Communication Foundation (WCF). Vea el tema sobre servicio WCF. WCF limita el comportamientos de limitación de peticiones de WCF número máximo de ( y la entrada de llamadas simultáneas como blog de Wenlong Dong sobre la limitación de peticiones de WCF y la un comportamiento de escalabilidad de los servidores limitación de peticiones de ( servicio. Aunque las consultas de larga ejecución podrían contribuir a este cuello de botella, es poco 341

342 Posible cuello de botella Causa y qué supervisar Resolución común que se produzca. Supervise las llamadas del contador de rendimiento de WCF/Modelo de servicio pendientes para PerformancePoint Services y compárelas con el número máximo actual de llamadas simultáneas. Supervisión del rendimiento Para ayudarle a determinar cuándo es necesario incrementar la escalabilidad vertical y horizontal del sistema, supervise el estado del sistema mediante el uso de contadores de rendimiento. PerformancePoint Services es un servicio de WCF de ASP.NET y puede supervisarse mediante el uso de los mismos contadores de rendimiento que se usan para supervisar cualquier otro servicio de WCF de ASP.NET. Además, puede usar la información incluida en las tablas siguientes para determinar los contadores de rendimiento adicionales que se deben supervisar y a qué proceso se deben aplicar los contadores de rendimiento. Contador de rendimiento Aplicaciones de ASP.NET/Recortes API de caché MSAS 2008:Threads/Subprocesos inactivos de grupo de consultas Instancia de contador Notas Grupo de aplicaciones de PerformancePoint Services No disponible Si el valor es mayor que cero, revise la sección "Consumo de memoria". Si el valor es cero, revise la sección "Analysis Services" y el tema sobre la guía de rendimiento de Analysis Services de las notas del producto de SQL Server 2008 ( MSAS 2008:Threads/Longitud de No disponible Si el valor es mayor que cero, revise la sección "Analysis Services" y el 342

343 Contador de rendimiento cola de trabajos de grupo de consultas MSAS 2008:Threads/Subprocesos inactivos de grupo de procesamiento MSAS 2008:Threads/Longitud de cola de trabajos de grupo de procesamiento WCF CountersServiceModelService (*)\Llamadas pendientes Instancia de contador Notas No disponible No disponible Instancia de servicio de PerformancePoint tema sobre la guía de rendimiento de Analysis Services de las notas del producto de SQL Server 2008 ( Si el valor es mayor que cero, revise la sección "Analysis Services" y el tema sobre la guía de rendimiento de Analysis Services de las notas del producto de SQL Server 2008 ( Si el valor es mayor que cero, revise la sección "Analysis Services" y el tema sobre la guía de rendimiento de Analysis Services de las notas del producto de SQL Server 2008 ( Si el valor es mayor que cero, vea el tema sobre la limitación de peticiones de WCF y escalabilidad de servidores ( Vea también Otros recursos Plan for PerformancePoint Services (SharePoint Server 2010) 343

344 Capacity requirements for Web Analytics Shared Service in SharePoint Server 2010 (en inglés) Initial capacity testing was performed for a simulated midsized deployment of Microsoft SharePoint Server 2010 and other applications that included 30,000 SharePoint entities. This article describes the results of the capacity testing activities and contains guidance on capacity management for the Web Analytics service application in SharePoint Server In SharePoint Server 2010, the Web Analytics service application enables you to collect, report, and analyze the usage and effectiveness of SharePoint Server 2010 sites. Web Analytics features include reporting, Web Analytics workflow, and Web Analytics Web Part. For more information, see Reporting and usage analysis overview. The aspects of capacity planning that are described in this article include the following: Description of the architecture and topology. Capacity planning guidelines based on the key factors such as total expected traffic and number of SharePoint components. Description of the other factors that affect the performance and capacity requirements. Before you continue to read this article, make sure that you understand key concepts related to SharePoint Server 2010 capacity management. The resources that are listed in this section can help you learn about frequently used terms and get an overview of the recommended approach to capacity management. These resources can also help you use the information that is provided in this article more effectively. For more conceptual information about performance and capacity management, see the following articles: Administración del rendimiento y de la capacidad (SharePoint Server 2010) Capacity management and sizing for SharePoint Server 2010 (en inglés) In this article: Introduction Hardware specifications and topology Capacity requirements 344

345 Introduction Overview As part of SharePoint Server 2010, the Web Analytics service application is a set of features that you can use to collect, report, and analyze the usage and effectiveness of a SharePoint Server 2010 deployment. You can organize SharePoint Web Analytics reports into three main categories: Traffic Search Inventory SharePoint Web Analytics reports are typically aggregated for various SharePoint entities, such as sites, site collections, and Web applications for each farm. To view an architectural overview of the Web Analytics service application in a SharePoint deployment, see Architectural overview later in this article. The Web Analytics shared service requires resources primarily at the application server and database server level. This article does not cover the Web Server layer capacity planning, because the Web Analytics service s capacity requirements are minimal at this level. This article contains the capacity requirements for several application servers and Microsoft SQL Server based computers, according to the following criteria: Total expected site traffic (clicks, search queries, ratings). Number of SharePoint components (Site, Site Collection, and Web Application) for each farm. Other less significant factors which can affect the capacity requirements are summarized in Other factors later in this article. Architectural overview The following diagram (Figure 1) shows the flow of the site usage data from a Web browser to the analytics databases, and then back to the Web browser as reports. The usage data is logged to the usage files on the Web servers. The usage timer job calls the Logging Web Service to submit the raw data from the usage files. The Logging Web Service writes it to the staging database, where the raw data is stored for seven days (this is not configurable). The Web Analytics components Log Batcher and User Behavior Analyzer clean and process the raw data on the staging database. The Report Consolidator runs one time every 24 hours. The Report Consolidator aggregates the raw data from the staging database on various dimensions, and then writes it to the reporting database. The aggregated data is stored in the reporting database for a default period of 25 months (this is configurable). 345

346 Figure 1. SharePoint Server 2010 Web Analytics architectural overview 346

347 The performance of the Logging Web Service primarily depends on the number of application servers. (Scaling out is available for the application servers.) The performance of the Log Batcher and User Behavior Analyzer depends primarily on the analytics staging database. The Read and Write activities that are performed by all the different components can cause the analytics staging database to slow down the process. (Scaling out is available for the staging database.) The performance of the Report Consolidator also primarily depends on the reporting database. (Scaling out of reporting database is not supported.) Hardware specifications and topology This section provides detailed information about the hardware, software, topology, and configuration of a case study environment. Hardware Nota: This environment is scaled to accommodate prerelease builds of SharePoint Server 2010 and other products. Therefore, the deployed hardware has larger capacity than necessary to serve the demand typically experienced by this environment. This hardware is described only to provide additional context for this environment and serve as a starting point for similar environments. It is important to conduct your own capacity management based on your planned workload and usage characteristics. For more information about the capacity management process, see Administración del rendimiento y de la capacidad (SharePoint Server 2010). Web servers This article does not cover the Web server layer capacity planning, because the Web Analytic service s capacity requirements are minimal at this level. Application servers The following table describes the configuration of each application server. Based on the site traffic and the number of SharePoint components that are involved, users will need one or more application servers. Application server Processors Minimum requirement 4 quad 2.33 GHz 347

348 Application server RAM Operating system Size of the SharePoint drive Minimum requirement 8 GB Windows Server 2008, 64 bit 300 GB Number of network adapters 1 Network adapter speed Authentication Load balancer type Software version 1 GB NTLM SharePoint Load Balancer SharePoint Server 2010 (prerelease version) Services running locally Central Administration Microsoft SharePoint Foundation Incoming Microsoft SharePoint Foundation Web Application Microsoft SharePoint Foundation Workflow Timer Service Search Query and Site Settings Service SharePoint Server Search Web Analytics Data Processing Service Web Analytics Web Service Database servers The following table describes the configuration of each database server. Instances of SQL Server were required for both the staging and reporting databases. 348

349 Database server Processors RAM Operating system Disk size Minimum requirement 4 quad 2.4 GHz 32 GB Windows Server 2008, 64-bit 3 terabytes Nota: Although we used this disk size for our capacity testing, your environment will likely require a much larger disk size to support Web Analytics. Number of network adapters 1 Network adapter speed 1 GB Authentication NTLM Software version SQL Server 2008 Topology The following diagram (Figure 2) shows the Web Analytics topology. 349

350 Figure 2. Web Analytics topology 350

351 Capacity requirements Testing methodology This section presents the capacity requirements with regard to the total amount of site traffic (this is measured by number of clicks, search queries, and ratings) per day that can be supported by different numbers of application servers and SQL Server based computers. The numbers presented currently are for a midsize SharePoint deployment that has about 30,000 SharePoint entities. The Web Analytics shared service aggregates the data for each day. Therefore, the data volume that is presented corresponds to the total number of records (this is measured by number of clicks, search queries, and ratings) that the SharePoint farm is expected to receive each day. This section provides diagrams that show the daily site traffic that can be supported by one, two, or three application servers (Figure 3) and the daily site traffic that can be supported that corresponds to the various database configurations (Figure 4). In the diagrams, data is shown by using two colors: Green Green values indicate the safe limit for the site traffic that can be processed for the corresponding number of application servers and SQL Server based computers. Yellow Yellow values indicate the expected limit for the site traffic that can be processed for the corresponding number of application servers and SQL Server based computers. The green and yellow values are estimates that are based on two key factors: Total site traffic, measured by number of page view clicks, search queries, and ratings. Number of SharePoint entities, such as sites, site collections, and Web applications, for each farm. The estimates also depend on other properties of the data and the data retention period in the reporting database. For testing, the other properties of the data were maintained as constant as described in Dataset description later in this section. Also, in smaller SharePoint deployment environments, you can share the application servers and SQL Server based computers together with other SharePoint services and databases. This article contains information about the capacity of the application servers and the SQL Server based computers that are in a test environment so that the Web Analytics shared service is the only major service that is running on the servers. The actual performance results for environments that actively use other shared services at the same time running might vary. To determine the capacity requirements for your environment, make sure that you estimate the expected daily site traffic and the number of components that you might use for a SharePoint deployment. Then, the number of application servers and SQL Server based computers should be estimated independently, as shown in Figure 3 and Figure

352 Dataset description The dataset that was selected for the test environment is a mid-sized dataset that has approximately 30,000 SharePoint components, which includes all web applications, site collections, and sites. Other characteristics of the data that were kept constant in the environment are also listed in the following table. Dataset characteristics Value Number of SharePoint components 30,000 Number of unique users 117,000 Number of unique queries 68,000 Number of unique assets 500,000 Data size in the reporting database 200 GB The total site traffic, measured by number of clicks, search queries, and ratings, was increased as part of this case study to establish the number of records that can be supported by the corresponding topology. Importante: Some typically used topologies generally exceed the capacity planning guidance. Those topologies include the following: Team sites My Site Web sites Self-provisioning portals If you anticipate that you might exceed the capacity planning guidelines, we recommend that you turn off the Web Analytics service application. For more information about how to turn off a service application, see Starting or stopping a service. 352

353 Application servers The following diagram (Figure 3) shows the daily site traffic that can be supported by one, two, or three application servers. The site traffic is represented in millions of records (each click, search query, or rating makes up a record) each day. The yellow line represents the expected number of records for the corresponding topology, whereas the green line represents the safe assumption for the number of records. 353

354 Figure 3. Daily site traffic vs. the application servers topology 354

355 The application servers are not very CPU-intensive or memory intensive. Thus, the CPU and the memory usage are not summarized for this section. SQL Server based computers The following diagram (Figure 4) shows the daily site traffic that can be supported that corresponds to the following configurations: One instance of SQL Server for both staging and reporting databases (1S+R). Two instances of SQL Server, one staging database and one reporting database (1S1R). Three instances of SQL Server, two staging databases and one reporting database (2S1R). The site traffic is represented in millions of records (each click, search, or rating makes up a record) each day. The yellow line represents the expected number of records for the corresponding topology, whereas the green line represents the safe assumption for the number of records. 355

356 Figure 4. Daily site traffic vs. SQL Server topology 356

357 The following table summarizes the CPU and memory usage of the various components on the instances of SQL Server that are hosting the staging database and the reporting database. Configuration 1S+R 1S1R 1S1R 2S1R 2S1R Total sum of percentage of processor time for 8 processor computer Staging + Reporting Staging Reporting Staging Reporting SQL Server buffer hit ratio % Disk time 7, Disk queue length Other factors Many other factors can affect the performance of various analytics components and can affect the capacity planning. These factors primarily affect the performance of the Report Extractor component because they can affect the size of the data aggregated each day. The total size of the data in the reporting database also affects the performance of the Reporting Extractor, although this is not significant because the data is partitioned daily. Some of these other factors are as follows: Number of unique queries each day. Number of unique users each day. Total number of unique assets clicked each day. Existing data size in the reporting warehouse, based on the data retention in the warehouse. The overall effect of these factors is less significant than the total data volume and the number of site entities. However, it is important to conduct your own capacity management based on your planned workload and usage characteristics. For more information about the capacity management process, see Administración del rendimiento y de la capacidad (SharePoint Server 2010). 357

358 Remaining issues There are current known issues that significantly affect the current performance of the Web Analytics service application for deployments that have a large site hierarchy, which includes approximately 100,000 or more SharePoint components. This article might be updated with the capacity requirements for larger site hierarchies when more information is available. Vea también Conceptos Administración del rendimiento y de la capacidad (SharePoint Server 2010) Otros recursos SharePoint 2010 Administration Toolkit (SharePoint Server 2010) Estimación de los requisitos de rendimiento y capacidad para la administración de contenido web en SharePoint Server 2010 En este artículo se proporciona una orientación acerca de la administración de la capacidad en los sitios de Microsoft SharePoint Server 2010 que tienen habilitada la infraestructura de publicación. Este documento es específico de SharePoint Server 2010 y la información descrita no se aplica a SharePoint Foundation. En este artículo se describen los siguientes escenarios: Un sitio de publicación en Internet: un sitio de presencia corporativa. Este tipo de sitio se publica en Internet y permite que los usuarios anónimos de Internet busquen información acerca de una organización. Este tipo de sitio tiene personalización de marca y su contenido está estrictamente controlado. Un sitio de publicación en la intranet: un sitio de noticias internas. Este tipo de sitio se publica en el ámbito interno de una organización. Sirve principalmente para compartir información con los usuarios autenticados de una organización. La información del sitio puede estar administrada estrictamente, aunque también es posible que algunas áreas se administren en menor grado. 358

359 Un sitio wiki empresarial: un repositorio de conocimientos. Un sitio wiki empresarial es un sitio formado por un único conjunto o granja de servidores que crece de forma gradual a medida que los colaboradores crean páginas nuevas y las vinculan a otras páginas que podrían ser ya existentes o no existir todavía. Los sitios wiki empresariales normalmente se publican en el ámbito interno de una organización. Este sitio permite a las personas de una compañía u organización obtener y compartir conocimientos mediante una solución integrada y mejorada por su entorno de SharePoint. Tras leer este documento, comprenderá los siguientes conceptos: El valor métrico clave (rendimiento) que debe maximizar para admitir gran cantidad de operaciones de lectura. Varios cuellos de botella posibles que son relevantes para una implementación de SharePoint Server 2010 de administración de contenido web. La importancia de la memoria caché de resultados para maximizar el rendimiento. El efecto de las operaciones de escritura en la experiencia de lectura del usuario final. En este artículo: Información de requisitos previos Método y detalles de las pruebas Implementaciones de administración de contenido web Optimizaciones necesarias Resultados de las pruebas y recomendaciones Acerca de los autores Información de requisitos previos Antes de leer este documento, asegúrese de que comprende los conceptos clave relacionados con la administración de la capacidad de SharePoint Server La documentación que se proporciona a continuación le permitirá conocer el método recomendado para administrar la capacidad y le ofrecerá más contexto para ayudarle a hacer un uso eficaz de la información de este documento. Para obtener información más conceptual sobre el rendimiento y la capacidad que puede servirle para comprender el contexto de los datos de este artículo, vea los siguientes documentos: Administración de la capacidad y tamaño de SharePoint Server

360 Casos prácticos técnicos de capacidad y rendimiento (SharePoint Server 2010) Método y detalles de las pruebas En cada prueba, se extrajeron las variables que pueden existir en la vida real para mostrar recomendaciones específicas. Por lo tanto, es muy importante que supervise y realice pruebas en su propio entorno para asegurarse de que ha escalado correctamente las variables para adaptarlas al volumen de solicitudes previsto. Para obtener más información acerca de los conceptos de la administración de la capacidad, vea Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server En este artículo se describe el rendimiento con las características de la colección de sitios, la infraestructura de publicación de SharePoint Server y el almacenamiento en la memoria caché de resultados. Estas características solo están disponibles cuando la infraestructura de publicación de SharePoint Server está habilitada. De manera predeterminada, los portales de publicación tienen esta característica habilitada. Conjunto de datos Las pruebas se realizaron con un conjunto de datos que comparte características comunes con implementaciones de administración de contenido web reales. Si bien la carga ha sido constante, se solicitaron distintas páginas. En la tabla siguiente se describe el conjunto de datos que se usó para estas pruebas. Conjunto de datos Objeto Tamaño de las bases de datos de contenido Número de bases de datos de contenido 1 Número de colecciones de sitios 1 Número de aplicaciones web 1 Número de sitios 50 Número de páginas 360 Sitio de publicación 2,63 GB páginas divididas en 20 carpetas con páginas cada una

361 Objeto Composición de las páginas Tamaño de página Imágenes Sitio de publicación Páginas de artículo en HTML básico, con referencias a dos imágenes 42 KB sin comprimir; 12 KB comprimida de 30 KB a 1,3 MB cada una Se recomienda configurar Internet Information Services (IIS) de modo que siempre comprima los archivos en lugar de conservar la configuración predeterminada de comprimir los archivos de forma dinámica. Al habilitar la compresión dinámica, IIS comprime las páginas hasta que el uso de CPU excede un umbral concreto. En ese momento, IIS deja de comprimir las páginas hasta que el uso disminuya y ya no exceda el umbral. Las pruebas de este artículo se realizaron con la compresión siempre habilitada. Este conjunto de datos de prueba solo usó características de SharePoint Server 2010 predeterminadas incluidas con el producto. Su sitio probablemente incluye personalizaciones además de estas características básicas. Por lo tanto, es importante que pruebe el rendimiento de su propia solución. Hardware La cantidad de servidores web en la granja de servidores varió por prueba, pero su hardware era idéntico. En la siguiente tabla se describe el hardware de los servidores web y de aplicaciones usados durante estas pruebas. Especificaciones de hardware para los servidores web y de aplicaciones Servidor web Procesadores RAM Sistema operativo 2 procesadores de cuatro núcleos a 2,33 GHz 8 GB Windows Server 2008 de 64 bits Tamaño de la unidad de SharePoint 300 GB Número de adaptadores de red 2 361

362 Servidor web Velocidad del adaptador de red Autenticación Tipo de equilibrador de carga Versión de software Servicios que se ejecutan localmente 1 gigabit Básica de Windows Equilibrio de carga de hardware SharePoint Server 2010 (versión preliminar) Administración central 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 En la siguiente tabla se describe el hardware del servidor de bases de datos usado durante estas pruebas. Especificaciones de hardware para los servidores de bases de datos Servidor de bases de datos Procesadores RAM Sistema operativo Almacenamiento 4 procesadores de cuatro núcleos a 3,19 GHz 16 GB Windows Server 2008 de 64 bits 15 discos de 300 GB a RPM Número de adaptadores de red 2 Velocidad del adaptador de red Autenticación 1 gigabit NTLM 362

363 Servidor de bases de datos Versión de software Microsoft SQL Server 2008 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 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%. La frecuencia de errores es menor que el 0,01%. Implementaciones de administración de contenido web Existen dos modelos mediante los cuales se crea contenido en los sitios de publicación de SharePoint que pueden influir en su elección de una topología de granja de servidores. En el modelo de autor en contexto, se comparte una sola colección de sitios entre autores y visitantes. Los autores pueden crear y actualizar el contenido en cualquier momento, lo que genera distribuciones variables de operaciones de lectura y escritura a lo largo de un día determinado. Normalmente, esta granja de servidores experimenta gran cantidad de lecturas y un número moderado de escrituras. En el siguiente diagrama se muestra cómo funciona la creación en contexto desde la perspectiva de una topología. 363

364 En el modelo de distribución de contenido, varias colecciones de sitios admiten la publicación y creación de contenido por separado y de forma exclusiva. El contenido se crea y actualiza en el entorno de creación y, a continuación, se implementa en el entorno de publicación de forma programada para que puedan leerlo los visitantes. El entorno de publicación principalmente atiende solicitudes de lectura, excepto cuando el contenido se implementa desde el entorno de creación. A diferencia del modelo de autor en contexto, la carga del servidor empleada por la distribución de contenido puede ajustarse a intervalos programados. En el siguiente diagrama se muestra cómo funciona la distribución de contenido desde la perspectiva de una topología. Estos modelos de creación de contenido se excluyen mutuamente. Si bien los sitios de publicación en Internet y los sitios de publicación en la intranet pueden usar tanto el modelo de autor en contexto como el modelo de distribución de contenido, los sitios wiki empresariales funcionan mejor con el modelo de autor en contexto. Un sitio wiki empresarial experimenta un volumen mayor de operaciones de escritura en relación con las operaciones de lectura, ya que un mayor porcentaje de usuarios puede editar las páginas. Las páginas wiki empresariales difieren de las páginas de artículo de publicación y presentan características de rendimiento diferentes. Optimizaciones necesarias En esta sección se ofrece información para optimizar el entorno de administración de contenido web. Para optimizar el entorno se debe comprender cómo administrar el rendimiento, los cuellos de botella y el almacenamiento en caché. En esta sección: El rendimiento es el valor métrico clave Cuellos de botella y su solución Ventajas del almacenamiento en caché 364

365 El rendimiento es el valor métrico clave El rendimiento y el tiempo de respuesta son los valores métricos más importantes que deben optimizarse al realizar la planeación de la capacidad para una implementación de administración de contenido web de SharePoint Server El rendimiento es la cantidad de operaciones que puede llevar a cabo una granja de servidores por segundo y se mide en RPS. Cuellos de botella y su solución Un cuello de botella es aquel recurso del sistema que, cuando se agota, impide que la granja siga atendiendo otras solicitudes. En el siguiente diagrama se muestran los elementos de una granja y los recursos que pueden convertirse en cuellos de botella y que, por lo tanto, deben supervisarse. 365

366 366

367 Uso de CPU del servidor web La CPU del servidor web debería ser el cuello de botella de una topología bien ajustada, ya que es el componente más fácil de escalar. El equilibrador de carga redirige las solicitudes entre los servidores web y se asegura de que ningún servidor se use en un grado considerablemente mayor que el resto. Aunque otros usuarios pueden seguir visitando el sitio después de agotarse por completo el uso de la CPU del servidor web, el tiempo de respuesta del servidor que experimentan estos usuarios es mayor. Este comportamiento resulta útil para administrar puntas en el volumen de solicitudes. Sin embargo, una carga continua que sobrepase la capacidad de la granja de servidores finalmente ocasionará un trabajo pendiente de solicitudes que será suficientemente grande como para exceder el umbral de solicitudes en espera. En este momento, los servidores web limitarán las solicitudes y responderán con un error HTTP 503. En la siguiente ilustración, el tiempo de respuesta del servidor disminuye cuando se alcanza el umbral de solicitudes en espera debido a que solo se sirven los errores HTTP. 367

368 368

369 En este diagrama se muestran los siguientes cambios: 1. El tiempo de respuesta aumenta a medida que el uso de CPU del servidor web se acerca al 100%. 2. Una vez excedido el umbral de solicitudes en espera, las solicitudes adicionales se atienden con errores. Otros cuellos de botella Si la CPU del servidor web no es el cuello de botella, los siguientes elementos en los que deben buscarse cuellos de botella son la topología de granja de servidores, la configuración de la granja o el contenido de las páginas que se sirven. Entre algunos de los posibles cuellos de botella en estos elementos se incluyen los siguientes: 1. Red En situaciones de alto rendimiento, es posible que la red se sature entre el servidor web y el servidor de bases de datos o entre el servidor web y los usuarios finales. Para evitar esta situación, se recomienda que los servidores web usen adaptadores de red de dos gigabits. 2. CPU del servidor de bases de datos Si la CPU del servidor de bases de datos se convierte en el cuello de botella, la adición de servidores web a la granja de servidores no puede incrementar el rendimiento máximo que puede admitir la granja. Un cuello de botella con la CPU de la base de datos pero sin las CPU del servidor web puede reflejar dos situaciones: a) Una configuración de caché insuficiente o páginas muy lentas, especialmente aquellas que no se almacenan en la memoria caché de resultados. Esto se caracteriza por un alto uso de CPU del servidor de bases de datos, pero un rendimiento bajo o medio o un uso del servidor web bajo o medio. b) Es posible que el servidor de bases de datos haya alcanzado la capacidad del rendimiento requerido para la granja. Esto se caracteriza por un alto uso de CPU del servidor web y del servidor de bases de datos durante un rendimiento alto. Ventajas del almacenamiento en caché SharePoint Server 2010 usa tres tipos de almacenamiento en caché. Su objetivo común es mejorar la eficacia mediante la disminución de las llamadas a la base de datos para los datos que se solicitan con frecuencia. Las solicitudes posteriores de una página pueden atenderse desde la memoria caché del servidor web, lo que disminuye considerablemente el uso de recursos en los servidores web y de bases de datos. Los tres tipos de almacenamiento en caché son los siguientes: Caché de resultados Esta memoria caché almacena el contenido de la página solicitada en la memoria del servidor web. Para obtener más información acerca de la memoria caché de resultados, vea el tema sobre el almacenamiento en la memoria caché de resultados y los perfiles de memoria caché ( 369

370 Caché de objetos Esta memoria caché almacena objetos de SharePoint, como metadatos web y de elemento de lista, en la memoria del servidor web. Para obtener más información acerca de la memoria caché de objetos, vea el tema sobre el almacenamiento en caché de objetos ( Caché basada en disco de objetos binarios grandes (BLOB) Esta memoria caché almacena archivos de vídeo, imagen, sonido y otros archivos binarios grandes en el disco. Para obtener más información acerca de la memoria caché BLOB, vea el tema sobre el almacenamiento en memoria caché basada en disco de objetos binarios grandes ( Cada una de estas memorias caché es importante para mantener un alto rendimiento. No obstante, el almacenamiento en la memoria caché de resultados es el que causa un mayor efecto y se describe en detalle a lo largo de este artículo. Resultados de las pruebas y recomendaciones En esta sección se describen las áreas específicas donde se realizaron pruebas y se proporcionan las recomendaciones obtenidas como resultado. En esta sección: Efecto de la habilitación de la memoria caché de resultados Usuarios anónimos y usuarios autenticados Características de escalabilidad horizontal de las operaciones de lectura y escritura Advertencias sobre la memoria caché de resultados Efecto del volumen de lecturas en la CPU y en el tiempo de respuesta Efecto de las operaciones de escritura en el rendimiento Efecto de la distribución de contenido Efecto de la instantánea de base de datos durante la exportación de distribución de contenido Características del contenido Efecto de la habilitación de la memoria caché de resultados La memoria caché de resultados es una característica de gran valor que puede usarse para optimizar una solución de SharePoint Server 2010 para gran cantidad de operaciones de lectura. 370

371 En estas pruebas, para determinar el máximo de RPS, la cantidad de usuarios activos que realizan solicitudes en la granja de servidores se incrementó hasta que el uso de CPU del servidor de bases de datos o de los servidores web alcanzó el 100% y se convirtió en un cuello de botella. La prueba se realizó en topologías de granja de servidores de 1x1 (un servidor web y un servidor de bases de datos), 2x1, 4x1 y 8x1 para demostrar el efecto del incremento de la escalabilidad horizontal de los servidores web en diferentes proporciones de aciertos de la memoria caché de resultados. Proporción de aciertos de la memoria caché de resultados La proporción de aciertos de la memoria caché de resultados es una medición de los aciertos de la memoria caché de resultados con respecto a los errores de caché. Un acierto de caché se produce cuando la memoria caché recibe una solicitud de datos de objeto que ya están almacenados en la memoria caché. Un error de caché se produce cuando se recibe una solicitud de datos de objeto que no están almacenados en la memoria caché. Cuando se produce un error de caché, la memoria caché intentará almacenar los datos de objeto solicitados para que las solicitudes posteriores de dichos datos produzcan un acierto de caché. Existen varias razones por las que una solicitud de página puede producir un error de caché. Páginas configuradas para no usar la memoria caché de resultados. Páginas personalizadas, por ejemplo, páginas que contienen datos específicos del usuario actual. Primera exploración por clave de variante de caché de resultados. Primera exploración después de que haya caducado o expirado el contenido almacenado en caché. En el siguiente diagrama se muestra el efecto del almacenamiento en la memoria caché de resultados en el rendimiento máximo en granjas de servidores que contienen de uno a cuatro servidores web y un servidor de bases de datos. 371

372 372

373 Nota: El punto de datos para el máximo de RPS en una granja de servidores de 4x1 con una proporción de aciertos de la memoria caché de resultados del 100% se ha extrapolado y en realidad no se ha observado. El volumen de solicitudes de la granja de servidores alcanzó el límite de ancho de banda de red; es decir, la velocidad de transferencia de datos alcanzó 1 gigabit por segundo. En todos los casos, el uso de CPU del servidor web es del 100%. En la siguiente tabla se enumeran los efectos de las proporciones de aciertos de la memoria caché de resultados en topologías de granja de servidores que contienen de uno a cuatro servidores web y un servidor de bases de datos. Efectos de la proporción de aciertos de la memoria caché de resultados en topologías de granja de servidores diferentes Proporción Medida 1x1 2x1 4x1 de aciertos de la memoria caché de resultados 100% Máximo de RPS Uso de CPU de SQL Server 0% 0% 0% 95% Máximo de RPS Uso de CPU de SQL Server 5,93% 12,00% 21,80% 373

374 Proporción Medida 1x1 2x1 4x1 de aciertos de la memoria caché de resultados 90% Máximo de RPS Uso de CPU de SQL Server 7,12% 14,40% 28,00% 50% Máximo de RPS Uso de CPU de SQL Server 9,86% 19,50% 42,00% 0% Máximo de RPS Uso de CPU de SQL Server 9,53% 19,00% 36,30% Conclusiones y recomendaciones sobre el efecto de la habilitación de la memoria caché de resultados Las proporciones de aciertos de la memoria caché de resultados más altas provocan aumentos considerables del máximo de RPS. Por lo tanto, se recomienda habilitar el almacenamiento en la memoria caché de resultados para optimizar la solución de publicación de SharePoint Server Puede configurar la memoria caché de resultados en la página Configuración de la memoria caché de 374

375 resultados de la colección de sitios. Para obtener más información, vea el tema sobre la configuración de la memoria caché de resultados de la página para una colección de sitios ( en el sitio web Office.Microsoft.com. En las pruebas donde el almacenamiento en la memoria caché de resultados estaba habilitado, se excluyó la primera solicitud que almacenaba una página en caché; es decir, un cierto porcentaje de páginas ya está almacenado en caché. La primera vez que un usuario solicita una página que no está almacenada en caché, dicha página se agrega a la memoria. Si la memoria caché ha alcanzado la capacidad o se está acercando a ella, la memoria recorta aquellos datos que no se han solicitado recientemente. La proporción de aciertos de la memoria caché del 0% simula el período de corta duración durante el cual la memoria caché de resultados habilitada se rellena después de haberse vaciado. Por ejemplo, esto se observa a diario en un entorno real cuando se recicla el grupo de aplicaciones. Es importante escalar adecuadamente el hardware horizontal o verticalmente para adaptarse a una situación donde hay una proporción de aciertos de la memoria caché del 0% en el período de corta duración entre el reciclaje del grupo de aplicaciones y la próxima solicitud y almacenamiento en caché de las páginas. La proporción de aciertos de la memoria caché del 0% también simula un entorno en el que el almacenamiento en la memoria caché de resultados no está habilitado. Usuarios anónimos y usuarios autenticados En la prueba anterior se supone que todas las solicitudes en el sitio se realizan por parte de lectores anónimos. Sin embargo, en su sitio, es posible que algunos de los usuarios estén autenticados. Entre los ejemplos de escenarios de lectura autenticada se incluyen un sitio de publicación en la intranet corporativa y contenido solo para miembros de un sitio de Internet. Con los perfiles de caché de resultados, puede especificar el comportamiento de la memoria caché de resultados para usuarios autenticados, que difiere del comportamiento para usuarios anónimos. Perfiles de caché Los perfiles de caché agregan configuración que puede aplicarse a páginas, elementos de página, tipos de contenido y niveles de escala en la implementación de un sitio. Un perfil de caché define los siguientes tipos de comportamiento de caché: El período de tiempo que los elementos deben permanecer en la memoria caché. La directiva de recorte de seguridad. La expiración de la configuración, como la duración y los cambios. Las variantes del contenido almacenado en caché, por ejemplo en función de los permisos de usuario, los derechos de usuario y otras variables personalizadas. Cualquier cambio a un perfil de caché afecta inmediatamente a todo el contenido aplicable del sitio. Puede establecer distintos perfiles de caché para usuarios anónimos y para usuarios autenticados. 375

376 Para los usuarios anónimos, se usó el perfil de caché de resultados Internet público (totalmente anónimo) y para los usuarios autenticados se usó el perfil de caché de resultados Extranet (sitio publicado). En el siguiente gráfico se muestran los efectos del rendimiento autenticado en el uso de CPU del servidor de bases de datos. El modelo de autenticación que se usó es la autenticación básica de Windows. Si bien no se recomienda usar la autenticación básica de Windows para sitios de Internet, se seleccionó este método de autenticación para demostrar una sobrecarga mínima impuesta por la autenticación. El tamaño de esta sobrecarga varía según el mecanismo de autenticación específico. Al probar su implementación, asegúrese de tener en cuenta el efecto del mecanismo de autenticación. Para obtener más información acerca de los mecanismos de autenticación admitidos por SharePoint Server 2010, vea Plan authentication methods (SharePoint Server 2010). 376

377 Conclusiones y recomendaciones sobre usuarios anónimos y usuarios autenticados Los usuarios autenticados experimentan RPS más bajas y un menor potencial de escalabilidad horizontal, ya que el trabajo adicional de validar las credenciales ejerce una carga en el servidor de bases de datos. Como se demostró en los resultados de las pruebas, el máximo de RPS observado cuando se autentica a los usuarios es considerablemente menor que el de una granja de servidores de acceso anónimo. Características de escalabilidad horizontal de las operaciones de lectura y escritura Las pruebas se crearon para registrar las escrituras por hora. En este artículo, una escritura se define como la creación y protección de una nueva página de publicación o la edición y protección de una página de publicación existente. En las pruebas siguientes, se agregaron lectores al sistema hasta que el uso de CPU del servidor web alcanzó aproximadamente el intervalo del 80-90% y, posteriormente, se realizaron operaciones de escritura en el entorno mediante un retraso artificial. El total de escrituras por hora en la prueba fue de aproximadamente 500. Se usó una proporción de aciertos de la memoria caché de resultados del 90% para todas las pruebas. Se llevó a cabo la misma prueba en granjas de servidores de 1x1, 2x1 y 4x1 y se observó el uso de CPU de SQL Server y del servidor web además del rendimiento de lectura general para cada configuración. Además, se probó una configuración de solo lectura anónima como línea base, así como una configuración con lectores autenticados mediante la autenticación básica de Windows. Aunque la CPU del servidor web se usó completamente en un 100% durante las pruebas de escalabilidad horizontal de solo lectura, se mantuvo la CPU del servidor web entre el 80% y el 90% para las pruebas de escalabilidad horizontal con las escrituras. Esto se ha hecho para dejar espacio para uso de CPU adicional al llevar a cabo una operación de escritura. En el siguiente gráfico se muestran las RPS de lectura generales observadas durante cada prueba. Las RPS de lectura se escalan linealmente a medida que se agregan servidores web adicionales, incluso con la actividad de escritura. No obstante, existe una pérdida de RPS cuando se incorporan escrituras. 377

378 378

379 El uso de CPU del servidor de bases de datos se incrementó a medida que aumentó la cantidad de servidores web. En el siguiente gráfico se muestra el patrón de crecimiento del uso de CPU de SQL Server en las diferentes configuraciones. Como se mencionó en la sección Usuarios anónimos y usuarios autenticados anteriormente en este artículo, la autenticación afecta al uso de CPU del servidor de bases de datos y esto se acentúa aún más a medida que se agrega actividad de escritura (que también afecta al uso de CPU del servidor de bases de datos). 379

380 380

381 La tendencia extrapolada en el uso de SQL Server demuestra que SQL Server se convertirá en el cuello de botella con seis servidores web que tienen solicitudes de lectura autenticadas. Sin embargo, en el caso de lectura anónima, puede servir el incremento de la escalabilidad horizontal a un mayor número de servidores web. Es importante comprender que en una implementación típica existen factores adicionales que afectan a la carga del servidor de bases de datos, y es importante tener en cuenta estos factores al planear la capacidad. Para obtener más información acerca de cómo determinar una zona verde para el uso de CPU típico del servidor de bases de datos, vea Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server Conclusiones y recomendaciones sobre las características de escalabilidad horizontal de las operaciones de lectura y escritura En los datos se muestra que el incremento de la escalabilidad horizontal del número de servidores web es una estrategia eficaz para incrementar el rendimiento si el servidor de bases de datos no se convierte en el cuello de botella. En promedio, la combinación de pruebas de escrituras autenticadas y lectura anónima empleó un aumento del 52% en el uso de CPU del servidor web en comparación con la combinación de pruebas de lectura anónima sin escrituras. Además, las lecturas autenticadas agregan una gran carga de SQL Server adicional, ya que cada carga implica comprobaciones de autenticación adicionales, lo que requiere una ida y vuelta a SQL Server. En el siguiente gráfico se muestra el efecto del rendimiento en el uso de CPU del servidor de bases de datos. 381

382 382

383 Advertencias sobre la memoria caché de resultados Si lo único que debe tenerse en cuenta en la planeación de la capacidad es maximizar las RPS, estas pruebas indicarían que la proporción de aciertos de la memoria caché óptima es del 100%. No obstante, es posible que no sea factible o deseable habilitar el almacenamiento en la memoria caché de resultados en algunas páginas, o en todas ellas, debido a requisitos de actualización de datos o a restricciones de memoria. Actualización de datos Es posible que los datos que se sirven desde la memoria caché de resultados no contengan actualizaciones recientes llevadas a cabo en el contenido original. En el origen de la distribución de contenido o (para autores autenticados) en un escenario de autor en producción, es posible que los autores deseen ver los cambios más recientes inmediatamente después de actualizar el contenido existente. Generalmente, esto se facilita al establecer la propiedad Duración en el perfil de caché, la cual especifica cuánto tiempo una página almacenada en caché persistirá en la memoria caché de resultados antes de expirar. Cuando una página expira, se quita de la memoria caché y una consulta posterior producirá un error de caché que actualizará el contenido de la página. También se puede establecer la propiedad de perfil de caché Buscar cambios para que el servidor compare la hora en la que se almacenó una página en caché con la hora en que el contenido se modificó por última vez en una colección de sitios. Una solicitud de una página cuyas marcas de tiempo no coinciden ocasionará una invalidación de caché en todas las páginas de la colección de sitios. Dado que la propiedad Buscar cambios afecta a todas las páginas de una colección de sitios, se recomienda habilitar esta opción únicamente si se trata de una solución de autor en contexto autenticada que no se actualiza frecuentemente y que es básicamente estática. La combinación de esta opción con una larga duración permite que todas las páginas se sirvan desde la memoria caché hasta que se realice una actualización en el sitio. De manera predeterminada, la propiedad Buscar cambios no está habilitada. Esto significa que el servidor web sirve los datos desde la memoria caché de resultados en respuesta a solicitudes de una página que todavía no ha expirado, independientemente de si se modificó la página ASPX original subyacente. En esta prueba, realizada en una granja de servidores de 1x1, todas las variables son las mismas que en las pruebas de la sección Características de escalabilidad horizontal de las operaciones de lectura y escritura, excepto la propiedad Buscar cambios. Cuando se activa la propiedad Buscar cambios, la memoria caché se vacía más seguido, lo que ocasiona una menor proporción de aciertos de la memoria caché de resultados. En el siguiente gráfico se muestra el efecto de la propiedad Buscar cambios en el rendimiento. 383

384 Se recomienda evitar la propiedad de perfil de caché de resultados Buscar cambios, excepto en casos específicos. Un sitio que usa el modelo de autor en contexto y no experimenta cambios frecuentes en el contenido puede beneficiarse de este valor para los usuarios autenticados junto con una larga duración, pero lo más probable es que otros tipos de sitios observen una degradación en RPS. 384

385 En función de sus requisitos, es posible que desee que el contenido sujeto a limitación temporal se publique instantáneamente o más rápido que lo permitido por la configuración predeterminada. En este caso, debe disminuir la duración o deshabilitar el almacenamiento en la memoria caché de resultados. Conclusiones y recomendaciones sobre las advertencias de la memoria caché de resultados El almacenamiento en la memoria caché de resultados no resuelve todos los problemas relacionados con la administración de la capacidad. En algunas situaciones, el almacenamiento en la memoria caché de resultados no es adecuado, por lo que debe tener en cuenta dichas situaciones al habilitar la memoria caché de resultados y configurar los perfiles de caché de resultados. Efecto del volumen de lecturas en la CPU y en el tiempo de respuesta Esta prueba se llevó a cabo en una granja de servidores de 1x1 con acceso anónimo y el almacenamiento en la memoria caché de resultados habilitado. En el siguiente gráfico se muestra el efecto del volumen de lecturas en la CPU y en el tiempo de respuesta. 385

386 Conclusiones y recomendaciones sobre el efecto del volumen de lecturas en la CPU y en el tiempo de respuesta Como se describió en la sección Cuellos de botella y su solución, el tiempo de respuesta del servidor generalmente será coherente hasta que el servidor web reciba un volumen de solicitudes suficiente para usar completamente su CPU. Cuando la CPU del servidor web se 386

387 usa por completo, el tiempo de respuesta aumenta considerablemente. No obstante, la granja de servidores aún podrá administrar un volumen de solicitudes adicional. Efecto de las operaciones de escritura en el rendimiento La proporción de la creación de operaciones de edición se distribuye equitativamente en el transcurso de las pruebas. Los valores de escrituras por hora se probaron hasta aproximadamente 500, ya que la creación o edición de más de 500 páginas por hora se encuentra fuera del intervalo en el que operarían la mayoría de las implementaciones de SharePoint. En la prueba no se incluyeron los procesos automatizados, como la distribución de contenido, la cual se describe en la sección Efecto de la distribución de contenido. Es posible que estas operaciones de creación y edición conlleven varias operaciones de SQL Server. Por lo tanto, es importante tener en cuenta que las escrituras que se miden en estas pruebas no se encuentran en el nivel de SQL Server, sino que representan lo que un usuario consideraría una operación de escritura. Todas las pruebas de RPS frente a escrituras por hora se llevaron a cabo en una granja de servidores de 1x1. En primer lugar, se agregaron operaciones de lectura a la prueba hasta que el uso de CPU del servidor web se encontró entre el 60% y el 80% para dejar un búfer para las puntas de tráfico, y se mantuvo este nivel de uso promedio durante el transcurso de toda la prueba. A continuación, se incorporaron escrituras mediante un retraso artificial para controlar la cantidad de operaciones de escritura. No obstante, hubo puntas de uso de CPU incrementado de SQL Server y del servidor web mientras se llevaban a cabo las escrituras. Algunas de estas puntas en algunas proporciones de aciertos de la memoria caché excedieron el umbral de la operación común, como se muestra en el siguiente gráfico, aunque la media se mantuvo dentro del intervalo de la operación común 387

388 388

389 Como se muestra en el gráfico anterior, hay una reducción de poca importancia en el rendimiento a medida que se agregan escrituras al entorno. En el gráfico se muestra el cambio en el rendimiento entre un escenario de solo lectura y las operaciones de lectura durante aproximadamente 500 escrituras por hora. Se registraron dos puntos de datos para cada proporción de aciertos de la memoria caché de resultados. Por lo tanto, la relación entre los puntos de datos no es necesariamente lineal. La reducción en porcentaje es más pronunciada en las proporciones de aciertos de la memoria caché más bajas, como se muestra en el siguiente gráfico. Las RPS de lectura generales dependen en gran parte de la proporción de aciertos de la memoria caché, independientemente de las escrituras. 389

390 390

391 En el siguiente gráfico se muestra que el uso de CPU del servidor de bases de datos no se incrementó perceptiblemente al agregar escrituras al sistema. Observe que la escala vertical es del 0% al 10% de la capacidad de CPU. Se observó una carga de SQL Server adicional durante las operaciones de lectura, lo cual estaba previsto. No obstante, el mayor aumento fue de un 2,06% adicional, lo que es insignificante. El uso de CPU del servidor de bases de datos promedio se mantuvo por 391

392 debajo del 10% en todas las pruebas. Esta prueba se realizó en una granja de servidores de 1x1. El uso de CPU del servidor de bases de datos aumentará a medida que la cantidad de servidores web se escale horizontalmente. Esto se describe en más detalle en Características de escalabilidad horizontal de las operaciones de lectura y escritura. Durante las pruebas, también se midió el uso de CPU del servidor web. En el siguiente gráfico se muestra que el uso de CPU del servidor web promedio se mantuvo en un intervalo del 60-80% durante el transcurso de las pruebas, incluso a medida que las escrituras por hora se aproximaban a

393 393

394 No obstante, el uso de CPU medido real genera puntas cuando se llevan a cabo las escrituras, como se muestra en el siguiente gráfico. En general, estas puntas de CPU no representan un problema. El objetivo de la zona verde es proporcionar margen adicional de CPU para absorber algunas puntas en la carga de CPU. Además, a medida que se agregan servidores web adicionales, el efecto de las puntas se distribuye en estos servidores para reducir el efecto en una sola CPU del servidor web. No obstante, debe saber que dichas puntas están previstas en un entorno real, ya que la actividad de escritura no se distribuye uniformemente, aunque generalmente se lleva a cabo en ráfagas. 394

395 395