planeación de la capacidad para microsoft sharepoint...

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

Publicado: enero de 2011

Autor: Equipo de Microsoft Office System and Servers ([email protected])

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 2010. 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 2010. 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 (http://go.microsoft.com/fwlink/?linkid=189513&clcid=0xC0A).

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 (http://go.microsoft.com/fwlink/?linkid=196150&clcid=0xC0A) y el tema sobre la guía de planeación de sitios y soluciones para Microsoft SharePoint Server 2010, Parte 2 (http://go.microsoft.com/fwlink/?linkid=208024&clcid=0xC0A).

El contenido de este libro es una copia del contenido seleccionado en la biblioteca técnica de SharePoint Server 2010 (http://go.microsoft.com/fwlink/?linkid=181463&clcid=0xC0A) en la fecha de publicación. Para obtener la información más actual, vea la biblioteca técnica en Internet.

http://go.microsoft.com/fwlink/?linkid=189513&clcid=0xC0A






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.

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

Contenido

Planeación de la capacidad para Microsoft SharePoint Server 2010 ............................................................................................................ 1

Cómo obtener ayuda ....................................................................................................................................................................................... 10

Administración del rendimiento y de la capacidad (SharePoint Server 2010) ................................................................................................ 11

Capacity management and sizing for SharePoint Server 2010 (en inglés) .................................................................................................... 13

Información general sobre administración y ajuste de tamaño de la capacidad de SharePoint Server 2010 ................................................ 14

Glosario ........................................................................................................................................................................................................ 15

¿Quién debería leer los artículos de administración de capacidad? ........................................................................................................... 15

Cuatro aspectos básicos de rendimiento ..................................................................................................................................................... 18

Administración de capacidad frente a planeación de capacidad ................................................................................................................. 23

Sobreasignación frente a subasignación de capacidad .............................................................................................................................. 26

Restricciones y límites del software ............................................................................................................................................................. 27

Diferencias clave entre SharePoint Server 2010 y Office SharePoint Server 2007 .................................................................................... 29

Diferenciadores clave de implementación de SharePoint Server 2010 ....................................................................................................... 38

Arquitecturas de referencia .......................................................................................................................................................................... 40

Vea también ................................................................................................................................................................................................. 46

Planeación de la capacidad para SharePoint Server 2010 ............................................................................................................................. 47

Paso 1: Modelo ............................................................................................................................................................................................ 47

Paso 2: Diseño ............................................................................................................................................................................................. 58

Paso 3: Piloto, prueba y optimización .......................................................................................................................................................... 64

Paso 4: Implementación ............................................................................................................................................................................... 65

Paso 5: Supervisión y mantenimiento .......................................................................................................................................................... 66

Vea también ................................................................................................................................................................................................. 67

Pruebas de rendimiento para SharePoint Server 2010 .................................................................................................................................. 68

Creación de un plan de pruebas .................................................................................................................................................................. 69

Creación del entorno de prueba ................................................................................................................................................................... 69

Creación de pruebas y herramientas ........................................................................................................................................................... 71

Vea también ................................................................................................................................................................................................. 76

Supervisión y mantenimiento de SharePoint Server 2010 .............................................................................................................................. 77

Configuración de la supervisión ................................................................................................................................................................... 77

Eliminación de cuellos de botella ................................................................................................................................................................. 89

Vea también ................................................................................................................................................................................................. 93

Administración de la capacidad de SharePoint Server 2010: restricciones y límites del software ................................................................. 94

Información general de límites máximos y límites ....................................................................................................................................... 95

Límites y límites máximos ............................................................................................................................................................................ 98

Performance and capacity technical case studies (SharePoint Server 2010) (en inglés) ............................................................................ 148

Entorno de publicación de intranet de empresa de Microsoft SharePoint Server 2010: caso práctico técnico............................................ 150

Información de requisitos previos .............................................................................................................................................................. 150

Introducción a este entorno ........................................................................................................................................................................ 151

Especificaciones......................................................................................................................................................................................... 152

Carga de trabajo ......................................................................................................................................................................................... 158

Conjunto de datos ...................................................................................................................................................................................... 159

Datos de mantenimiento y rendimiento ..................................................................................................................................................... 160

Enterprise intranet collaboration environment technical case study (SharePoint Server 2010) (en inglés) ................................................. 164

Prerequisite information ............................................................................................................................................................................. 164

Introduction to this environment ................................................................................................................................................................. 165

Specifications ............................................................................................................................................................................................. 166

Health and Performance Data .................................................................................................................................................................... 173

Enterprise intranet collaboration environment lab study (SharePoint Server 2010) (en inglés) ................................................................... 177


Glossary ..................................................................................................................................................................................................... 178

Overview .................................................................................................................................................................................................... 179

Specifications ............................................................................................................................................................................................. 181

Results and Analysis .................................................................................................................................................................................. 187

Departmental collaboration environment technical case study (SharePoint Server 2010) (en inglés) ......................................................... 203



Specifications ............................................................................................................................................................................................. 205

Workload .................................................................................................................................................................................................... 212

Dataset ....................................................................................................................................................................................................... 213


Divisional portal environment lab study (SharePoint Server 2010) (en inglés) ............................................................................................. 218


Glossary ..................................................................................................................................................................................................... 219

Overview .................................................................................................................................................................................................... 220

Specifications ............................................................................................................................................................................................. 221

Results and analysis .................................................................................................................................................................................. 229

About the authors ....................................................................................................................................................................................... 249

Social environment technical case study (SharePoint Server 2010) (en inglés) .......................................................................................... 250



Specifications ............................................................................................................................................................................................. 252

Workload .................................................................................................................................................................................................... 257

Dataset ....................................................................................................................................................................................................... 259


Recomendaciones y resultados de pruebas de rendimiento y capacidad (SharePoint Server 2010) .......................................................... 264

Estimate performance and capacity requirements for Access Services in SharePoint Server 2010 (en inglés) .......................................... 267

Test farm characteristics ............................................................................................................................................................................ 268

Test results ................................................................................................................................................................................................. 271

Recommendations ..................................................................................................................................................................................... 285

Troubleshooting .......................................................................................................................................................................................... 291

Estimate performance and capacity requirements for Excel Services in SharePoint Server 2010 (en inglés) ............................................. 293


Test Results ............................................................................................................................................................................................... 297


Estimación de los requisitos de rendimiento y capacidad de PerformancePoint Services ........................................................................... 318

Prueba de las características del conjunto o granja de servidores ........................................................................................................... 318

Escenarios de prueba y procesos .............................................................................................................................................................. 319

Configuración de hardware y topología ..................................................................................................................................................... 322

Resultados de las pruebas ......................................................................................................................................................................... 323

Topologías 2M y 3M ................................................................................................................................................................................... 326

Resultados para topologías de 4 o más máquinas para autenticación de cuenta de servicio desatendida ............................................. 334

Resultados para topologías de 4 o más máquinas para autenticación de usuario ................................................................................... 335

Recomendaciones...................................................................................................................................................................................... 337

Analysis Services ....................................................................................................................................................................................... 338

Cuellos de botella comunes y sus causas ................................................................................................................................................. 339

Supervisión del rendimiento ....................................................................................................................................................................... 342

Vea también ............................................................................................................................................................................................... 343

Capacity requirements for Web Analytics Shared Service in SharePoint Server 2010 (en inglés) .............................................................. 344

Introduction ................................................................................................................................................................................................. 345

Hardware specifications and topology ....................................................................................................................................................... 347

Capacity requirements ............................................................................................................................................................................... 351

Vea también ............................................................................................................................................................................................... 358

Estimación de los requisitos de rendimiento y capacidad para la administración de contenido web en SharePoint Server 2010 .............. 358

Información de requisitos previos .............................................................................................................................................................. 359

Método y detalles de las pruebas .............................................................................................................................................................. 360

Implementaciones de administración de contenido web ........................................................................................................................... 363

Optimizaciones necesarias ........................................................................................................................................................................ 364

Resultados de las pruebas y recomendaciones ........................................................................................................................................ 370

Acerca de los autores ................................................................................................................................................................................ 404

Estimate performance and capacity planning for workflow in SharePoint Server 2010 (en inglés) .............................................................. 405


Test results ................................................................................................................................................................................................. 410


Troubleshooting .......................................................................................................................................................................................... 424

Vea también ............................................................................................................................................................................................... 426

Planeación y configuración del almacenamiento y capacidad de SQL Server (SharePoint Server 2010) ................................................... 427

Proceso de diseño y configuración del nivel de base de datos y almacenamiento de productos de SharePoint 2010 ............................ 427

Recopilación de los requisitos de espacio y E/S para almacenamiento y SQL Server ............................................................................. 428

Elección de la versión y edición de SQL Server ........................................................................................................................................ 439

Diseño de la arquitectura de almacenamiento en función de la capacidad y los requisitos de E/S .......................................................... 441

Estimación de los requisitos de memoria .................................................................................................................................................. 443

Descripción de los requisitos de la topología de red ................................................................................................................................. 444

Configuración de SQL Server .................................................................................................................................................................... 444

Validación y supervisión del almacenamiento y rendimiento de SQL Server ........................................................................................... 450

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:

http://technet.microsoft.com/es-es/office/bb267342

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:

[email protected]

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:

http://support.microsoft.com/?ln=es-es

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

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

Pruebas de rendimiento para SharePoint Server 2010

En este artículo se proporcionan instrucciones para probar el rendimiento de las granjas de SharePoint de 2010.

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

http://technet.microsoft.com/library/5f5110f0-2a72-4509-97a4-6896838bed1e(Office.14).aspx

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

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

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

http://technet.microsoft.com/library/4d88c402-24f2-449b-86a6-6e7afcfec0cd(Office.14).aspx

http://technet.microsoft.com/library/bcbae7bd-656b-4003-969c-8411b81fcd77(Office.14).aspx

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:





14


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

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:


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


Actualización desde Office SharePoint Server 2007

Actualmente uso Office SharePoint Server 2007. ¿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:


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:


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:


http://technet.microsoft.com/library/1a20e357-a21f-4409-9a99-6b8263ab30c5(Office.14).aspx

http://technet.microsoft.com/library/396c85d9-4b86-484e-9cc5-f6c4d725c578(Office.14).aspx

http://technet.microsoft.com/library/de17a1ff-79f4-4638-918b-380fb0a15205(Office.14).aspx

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:


Para obtener información acerca del rendimiento y el ajuste de tamaño de la base de datos, vea el artículo siguiente:


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 2010. ¿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:


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:




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:


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:


http://technet.microsoft.com/library/7d7db565-d572-4fd3-a30c-2856d98c897c(Office.14).aspx

http://technet.microsoft.com/library/c1f83b4f-a507-42f7-bd82-fed5404ed1ad(Office.14).aspx

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:


Para obtener información acerca del rendimiento y el ajuste de tamaño de la base de datos, vea el artículo siguiente:


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:



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




http://technet.microsoft.com/library/951de096-8d0e-4c5f-a9fc-f97fed761a6b(Office.14).aspx

http://technet.microsoft.com/library/71c203cd-7534-47b0-9122-657d72ff0080(Office.14).aspx

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.

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

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

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.


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.

24

Modelo de administración de capacidad de SharePoint Server 2010

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

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.

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.

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.

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.


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

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.

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

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

http://technet.microsoft.com/library/396c85d9-4b86-484e-9cc5-f6c4d725c578(Office.14).aspx

31

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

Servicio de SharePoint Foundation

XXX XXX XX XXX XXX

Servicio de Administración central

XX XX X X X

Servicio de registro * XX XX XX XXX XXX

Servicio de búsqueda de SharePoint

XXX XXX XXX XXX XXX XXX XXX

Aplicación del Servicio de visualización de Word *

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

X XX XX XX XXX XXX XX

Servicio de metadatos administrados *

X XX XX XX X X XX

Servicio de Web Analytics *

X X XXX XXX XXX

Servicios de conectividad empresarial *

XX XX XXX XXX

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

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.

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

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



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

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

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.

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:

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

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

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

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.

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.

46

Vea también Conceptos







Otros recursos

Hardware and software requirements (SharePoint Server 2010)


47


En este artículo se describe cómo planear la capacidad de un conjunto o granja de servidores de Microsoft SharePoint Server 2010. 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 2010.

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.

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

49


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.

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 100.000 empleados, una cantidad de 15.000 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

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

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:

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

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 (http://www.microsoft.com/downloads/en/details.aspx?familyid=f159af68-c3a3-413c-a3f7-2e0be6d5532e&displaylang=en&tm).

http://www.microsoft.com/downloads/en/details.aspx?familyid=f159af68-c3a3-413c-a3f7-2e0be6d5532e&displaylang=en&tm

http://www.microsoft.com/downloads/en/details.aspx?familyid=f159af68-c3a3-413c-a3f7-2e0be6d5532e&displaylang=en&tm

56

Puede descargar Log Parser 2.2 en http://www.microsoft.com/downloads/en/details.aspx?FamilyID=890CD06B-ABF8-4C25-91B2-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 Valor

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

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

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=890CD06B-ABF8-4C25-91B2-F8D975CF8C07&displaylang=en

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=890CD06B-ABF8-4C25-91B2-F8D975CF8C07&displaylang=en

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

100.000 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

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.

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

Unidad de datos

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)

48 2k 400 GB 20 discos de 300 GB

a 15.000 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 núcleo cuádruple a

32 N/A 400 GB 500 GB

60

Rol Tipo (estándar o virtual) Número de máquinas

Procedimientos RAM E/S por segundo necesaria

Tamaño de disco SO + registro

Unidad de datos

búsqueda 2,33 (GHz)

Servidor de rastreador de búsqueda

Estándar 2 2 procesadores de núcleo cuádruple a 2,33 (GHz)

16 400 400 GB N/A

Servidor de bases de datos de rastreo de búsqueda


48 4 k (optimizado para lectura)

100 GB 16 discos de 150 GB a 15.000 RPM

Base de datos de almacén de propiedades de búsqueda + Servidor de bases de datos de administración


48 2 k (optimizado para escritura)

100 GB 16 discos de 150 GB a 15.000 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.

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 (http://technet.microsoft.com/es-es/library/cc261716.aspx).

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.

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



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 (http://technet.microsoft.com/es-es/library/ff607968.aspx).

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.

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

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

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

Creación de un plan de pruebas

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 2010. En este caso, la

implementación será la primera implementación amplia de SharePoint Server 2010. 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.

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

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

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:


Solución de problemas (http://technet.microsoft.com/es-es/library/ee748639.aspx)






Otros recursos



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


68


En este artículo se describe cómo probar el rendimiento de Microsoft SharePoint Server 2010. 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 2010.

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.


En este artículo:

Creación de un plan de pruebas

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:

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

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 (http://msdn.microsoft.com/es-es/library/fda2bad5.aspx").

http://msdn.microsoft.com/es-es/library/fda2bad5.aspx

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 2010. 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 2007. 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 (http://www.microsoft.com/downloads/en/details.aspx?FamilyId=718447d8-0814-427a-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

http://www.microsoft.com/downloads/en/details.aspx?FamilyId=718447d8-0814-427a-81c3-c9c3d84c456e&displaylang=en

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é

74

Normalmente, estos elementos no proceden de SQL Server en un entorno basado en SharePoint Server 2010. 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:

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 (http://technet.microsoft.com/es-es/library/cc261716.aspx).

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, 5.000 usuarios, 5.000 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



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.






Otros recursos



77


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




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.



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

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.

Proveedores de diagnóstico

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

79

Opción Valor Notas

proveedores recopilan datos de estado de diversos componentes y características. Para las operaciones normales, puede que desee revertir al valor predeterminado.

Establecer los intervalos de programación "job-diagnostics-performance-counter-wfe-provider" y "job-diagnostics-performance-counter-sql-provider"

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.

Varios

Habilitar el seguimiento de la pila para solicitudes de contenido

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

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.

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

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:

Copiar código

Add-SPDiagnosticsPerformanceCounter -Category "Processor" -Counter "% Processor Time" -Instance "_Total" -WebFrontEnd

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 Descripción

Procesador

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.

Interfaz de red

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.

Discos y memoria caché

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

82

Contador de rendimiento 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é.

Memoria y archivo de paginación

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 Descripción

Procesador

% 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


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.

Longitud promedio de cola de lectura de disco El promedio de solicitudes de lectura que se ponen en cola.

Longitud promedio de cola de escritura de disco El promedio de solicitudes de escritura que se ponen en cola.

Lecturas de disco/s El número de lecturas de disco por segundo.

Escrituras en disco/s El número de escrituras de disco por segundo.

Memoria

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

Errores de caché/s 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.

Páginas por segundo 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.

84


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 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 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 40-50 por ciento de la capacidad de red. Para hacerlo, supervise los valores de Bytes recibidos/s y Bytes enviados/s.

Proceso

Espacio de trabajo 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) El número actual de subprocesos.

ASP.NET

Total de solicitudes El número total de solicitudes desde que se inició el servicio.

Solicitudes en cola 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


solicitudes en espera para ser procesadas.

Tiempo de espera de la solicitud 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.

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

Solicitudes en ejecución (_Total) El número de solicitudes actualmente en ejecución.

Solicitudes por segundo (_Total) 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).

Memoria de .NET CLR

Número de colecciones de gen. 0 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.

Número de colecciones de gen. 1 Muestra el número de veces que los objetos de generación 1 se recopilaron como elementos no usados desde que se inició la

86


aplicación.

Número de colecciones de gen. 2 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.


Estadísticas generales 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.

Conexiones de usuario 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


de su línea base, es posible que disminuya el rendimiento.

Bases de datos 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.

Transacciones por segundo 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.

Bloqueos Este objeto brinda información acerca de los bloqueos de SQL Server en tipos de recursos individuales.

Número de interbloqueos/s Este contador muestra el número de interbloqueos de SQL Server por segundo. Normalmente, debe ser 0.

Tiempo promedio de espera (ms) Este contador muestra el promedio de tiempo de espera para cada solicitud de bloqueo que se esperó.

Tiempo de espera de bloqueos (ms) Este contador muestra el tiempo de espera total de los bloqueos en el último segundo.

Esperas de bloqueo/s Este contador muestra el número de bloqueos por segundo que no se pudieron satisfacer inmediatamente y que tuvieron que esperar recursos.

88


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

Promedio de tiempo de espera de bloqueos temporales (ms) Este contador muestra el tiempo de espera promedio de bloqueos temporales de las solicitudes de bloqueos temporales que tuvieron que esperar.

Esperas de bloqueos temporales/s Este contador muestra el número de solicitudes de bloqueos temporales por segundo que no pudieron concederse inmediatamente.

Estadísticas SQL 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.

Compilaciones SQL/s Este contador indica el número de veces que se especifica la ruta de acceso al código de compilación por segundo.

Recompilaciones SQL/s Este contador indica el número de veces que se desencadenan recompilaciones de instrucción por segundo.

Caché del plan 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.

Frecuencia de aciertos de caché Este contador indica la frecuencia entre aciertos de caché y

89


búsquedas de planes.

Caché del búfer 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.

Frecuencia de aciertos de caché del búfer 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.

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


Memoria

MB disponibles Menos de 2 GB en un servidor web. Agregar memoria.

91


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


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 recuperan los recursos "virtuales" del disco en la memoria. Estos serán más frecuentes si la memoria física no es la adecuada.

Agregar memoria

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

Investigar más mediante la supervisión de Bytes recibidos/s y Bytes enviados/s.

92


de interfaz de red. Reevaluar la velocidad de la tarjeta de interfaz de red

Comprobar el número, tamaño y uso de búferes de memoria

Proceso

Espacio de trabajo Más del 80% de la memoria total Agregar 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 5.000. 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

93






Otros recursos



94


En este documento se describen los límites y límites máximos del software de Microsoft SharePoint Server 2010. 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


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

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.

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

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


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

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

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

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


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.


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.


Tamaño de base de datos de contenido 200 GB por base de datos de contenido Compatible Recomendamos

http://technet.microsoft.com/library/ac13cd00-c372-4159-943d-98c016c7e96a(Office.14).aspx

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


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.

Colecciones de sitios por base de datos de contenido

Se recomiendan 2.000

5.000 máximo

Compatible Recomendamos especialmente limitar el número de colecciones de sitios en una base de datos de contenido a 2.000. No obstante, se admiten hasta 5.000 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.

http://technet.microsoft.com/library/9994b57f-fef8-44e7-9bf9-ca620ce20734(Office.14).aspx#plan_ent_typlarge



http://technet.microsoft.com/library/9994b57f-fef8-44e7-9bf9-ca620ce20734(Office.14).aspx



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 2.000 colecciones de sitios, se corre el riesgo de que los tiempos de inactividad se prolonguen durante las actualizaciones. Si planea exceder las 2.000 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


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.

Subsistema de almacenamiento remoto de blobs (RBS) en almacenamiento conectado a la red (NAS)

El tiempo hasta el primer byte de cualquier respuesta del NAS no puede exceder 20 milisegundos.

Límite máximo 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.

http://technet.microsoft.com/library/e1de8a07-868e-4a0d-bb5b-1f62392523f8(Office.14).aspx

http://technet.microsoft.com/library/e1de8a07-868e-4a0d-bb5b-1f62392523f8(Office.14).aspx

106

Límites de colecciones de sitios

En la siguiente tabla se enumeran las recomendaciones para colecciones de sitios.


Sitio web 250.000 por colección de sitios Compatible El número máximo recomendado de sitios y subsitios es 250.000 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 1.000 subsitios, tendría un total de 100.000 sitios web. Una jerarquía profunda con 100 sitios, cada uno de ellos con 10 niveles de subsitios, también contendría en total 100.000 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á

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.

http://technet.microsoft.com/library/e3bf1b34-78b9-4643-b0dd-24444e3cffc5(Office.14).aspx

http://technet.microsoft.com/library/e3bf1b34-78b9-4643-b0dd-24444e3cffc5(Office.14).aspx

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


Tamaño de filas de lista 8.000 bytes por fila Límite máximo Cada elemento de lista o biblioteca solo puede ocupar 8.000 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 30.000.000 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 400.000 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 30.000.000 por lista Compatible Se puede crear listas muy grandes usando vistas estándar, jerarquías de sitio y navegación de metadatos.

109


Este valor puede variar según el número de columnas de la lista y el uso de la lista.

Límite de tamaño de filas 6 filas de tabla internas a la base de datos usadas para un elemento de lista o biblioteca

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

Operaciones en masa 100 elementos por operación en masa

Límite máximo La interfaz de usuario permite seleccionar un máximo de 100 elementos para operaciones en masa.

Umbral de búsqueda en la vista de lista

8 operaciones de combinación por consulta

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 5.000 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 20.000 Umbral Especifica la cantidad máxima de elementos de lista o

http://msdn.microsoft.com/es-es/library/microsoft.sharepoint.administration.spwebapplication.maxlistitemrowstorage.aspx

110


auditores y administradores 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 2.000 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 2.000. 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 1.000 por lista Umbral El número máximo de ámbitos de seguridad únicos establecidos para una lista no debe exceder 1.000.

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


á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 8.000 bytes. Según el uso de columnas, los usuarios pueden llegar al límite de 8.000 bytes antes de alcanzar la limitación de ajuste de filas de seis filas.

Límite Valor máximo Tipo de límite

Tamaño por columna

Notas

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

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


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

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


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:

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.


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.

117

Límites de seguridad


Número de grupos de SharePoint al que puede pertenecer un usuario

5.000 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

118


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

5.000 por grupo de SharePoint Compatible SharePoint Server 2010 permite agregar usuarios o grupos de Active Directory a un grupo de SharePoint.

Tener hasta 5.000 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 10.000 por colección de sitios Compatible Por encima de 10.000 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

5.000 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

119


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.


Aplicaciones de servicio de búsqueda de SharePoint

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.

Bases de datos de rastreo y elementos de bases de datos

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

120


10 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


Particiones de índice 20 por aplicación de servicio de búsqueda; 128 en total

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

Elementos indizados 100 millones por aplicación de servicio de búsqueda; 10 millones por partición de índice

Compatible 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


de rastreo. Sigue el límite de "elementos indizados".

Base de datos de propiedades 10 por aplicación de servicio de búsqueda;128 en total

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

Componentes de consulta 128 por aplicación de búsqueda; 64/(total de componentes de rastreo) por servidor

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

Reglas de ámbito 100 reglas de ámbito por ámbito; 600 en total por aplicación de servicio de búsqueda

Umbral 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


Á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 1.000.000 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

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 500.000 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 2.000 reglas de acceso al sitio, la

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


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

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

127

Límites de servicio de perfiles de usuario

En la siguiente tabla se enumeran las recomendaciones para el servicio de perfiles de usuario.


Perfiles de usuario 2.000.000 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

128


características sociales.

Etiquetas temáticas, notas y clasificaciones 500.000.000 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.

129


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.


Entradas de blog 5.000 por sitio Compatible El número máximo de

http://technet.microsoft.com/library/b44a57af-98a1-4818-aab3-a561908d0e07(Office.14).aspx#section2

130


entradas de blog es de 5.000 por sitio.

Comentarios 1.000 por entrada Compatible El número máximo de comentarios es de 1.000 por entrada.

Límites de Servicios de conectividad empresarial

En la siguiente tabla se enumeran las recomendaciones para Servicios de conectividad empresarial.


ECT (en memoria) 5.000 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

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.

Elementos de base de datos devueltos por solicitud

2.000 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 2.000 para restringir el número de resultados que se pueden devolver por página. Una aplicación

132


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

Límites de flujos de trabajo

En la siguiente tabla se enumeran las recomendaciones para flujos de trabajo.


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

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

http://technet.microsoft.com/library/fc9fd625-0df1-467a-bd31-16b7e29fbca9(Office.14).aspx

http://technet.microsoft.com/library/fc9fd625-0df1-467a-bd31-16b7e29fbca9(Office.14).aspx

134


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.

Tamaño de lote de temporizador de flujo de trabajo

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.

135


Número máximo de niveles de términos anidados en un almacén 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.)

Número máximo de conjuntos de términos en un almacén de términos

1000 Compatible Puede tener hasta 1.000 conjuntos de términos en un almacén de términos.

Número máximo de términos en un conjunto de términos

30.000 Compatible 30.000 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

1.000.000 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 1.000.000. Las etiquetas adicionales correspondientes al mismo término, como sinónimos y traducciones, no se cuentan como términos separados.

136


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


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.

137


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

138


Notas

de Visio (diagramas conectados a datos)

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

139


Celdas 1.000.000 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 1.000.000 celdas por consulta.

Columnas y filas 15 columnas por 60.000 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 5.000 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

140


número de columnas.

Consulta a un origen de datos de SQL Server 15 columnas por 20.000 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.


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

141


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

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.

Tamaño del trabajo de conversión 100.000 elementos de conversión Compatible 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.

Total de procesos de conversión activos

N-1, donde N es el número de núcleos en cada servidor de aplicaciones

Umbral 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


de procesamiento.

Recomendamos dejar siempre 1 núcleo libre para el trabajo del temporizador de conversión y SharePoint.

Tamaño de la base de datos de Word Automation Services

2 millones de elementos de conversión

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


Sincronización con SharePoint Workspace 30.000 elementos por lista Límite máximo SharePoint Workspace no sincroniza las listas que tienen más de 30.000

http://technet.microsoft.com/library/b4ed215c-cb20-4171-9013-2cc243e106d2(Office.14).aspx

http://technet.microsoft.com/library/b4ed215c-cb20-4171-9013-2cc243e106d2(Office.14).aspx

143


elementos. Esta restricción existe porque el tiempo para descargar una lista que tiene más de 30.000 elementos es muy largo y el uso de recursos es alto.

Sincronización con SharePoint Workspace Límite de 1800 documentos en SharePoint Workspace

Límite máximo 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.


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

Cada sección se considera una carpeta y un documento en la lista.

144


(en SharePoint) Cada grupo de secciones se cuenta como una carpeta y un documento en la lista.

Tamaño máximo de una sección Vea el límite para el "tamaño de archivo" en los límites de listas y bibliotecas

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.

Tamaño máximo de una imagen, archivo incrustado y copia impresa XPS de OneNote en una sección de OneNote.

Vea el límite para el "tamaño de archivo" en los límites de listas y bibliotecas

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.

Tamaño máximo de todas las imágenes, archivos incrustados y copias impresas XPS en una sola página de OneNote.

El límite predeterminado es el doble del límite de "Tamaño de archivos".

Umbral 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 (0xE0000794). Los usuarios pueden solucionar esto mediante la división

145


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

Operaciones de combinación Una por núcleo de CPU por servidor web Límite máximo

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.

146


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 CPU por servidor de aplicaciones (máximo de ocho núcleos)

Límite máximo 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 2010.

http://technet.microsoft.com/library/a0ada5d4-fc5f-4334-b5cc-44b7fb069b90(Office.14).aspx

147


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 1.500 entregas Límite máximo Los planes de Project no pueden contener más de 1.500 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.

148


This section contains technical case studies that describe specific deployments of Microsoft SharePoint Server 2010. 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 2010. 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)

149

Describes lab testing performed on a similar environment to the enterprise Intranet collaboration environment.

Departmental Collaboration

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

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

http://technet.microsoft.com/library/7b39606d-57b3-47bc-90ac-7739a67e6577(Office.14).aspx

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 2010. 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 2010. La siguiente documentación le proporcionará información acerca del método recomendado para administrar la capacidad y sobre cómo usar eficazmente la información de este documento. También se definen los términos usados en todo el documento.

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:

151



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.

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

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 WFE1-4

Procesadores 2 procesadores de cuatro núcleos de 2,33 GHz

RAM 32 GB

Sistema operativo Windows Server 2008 de 64 bits

Tamaño de la unidad de SharePoint 300 GB

Número de adaptadores de red 2

Velocidad del adaptador de red 1 Gigabit

Autenticación Windows NTLM

Tipo de equilibrador de carga Equilibrio de carga de hardware

Versión de software SharePoint Server 2010 (versión preliminar)

Servicios que se ejecutan localmente 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

Servicios que se consumen desde una granja de servicios federados

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 DB1-2

Procesadores 4 procesadores de cuatro núcleos de 2,4 GHz

RAM 32 GB


Almacenamiento y geometría (1,25 TB * 6) + 3 TB

Discos 1-4: datos de SQL

Disco 5: registros

Disco 6: TempDB


Velocidad del adaptador de red 1 Gigabit

Autenticación Windows NTLM

Versión de software SQL Server 2008

155

Topología

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

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)

Intranet (sitio de colaboración)

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

Caché de objetos (deshabilitada | n MB)

Habilitada: 500 MB

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.

Servicio de uso:

Registro de seguimiento: días para almacenar los archivos de registro (valor predeterminado: 14 días)

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.

Umbral de registro de consulta:

Base de datos de Microsoft SharePoint Foundation: configurar QueryLoggingThreshold en 1 segundo

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.

Servidor de bases de datos: instancia predeterminada:

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

158

Opción Valor Notas

Grado de paralelismo máximo bases de datos que hospedan bases de datos de SharePoint Server 2010. 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)(http://go.microsoft.com/fwlink/?linkid=189030&clcid=0xC0A).

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.


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 33.580

Promedio de usuarios simultáneos 172

Máximo de usuarios simultáneos 376

Nº total de solicitudes por día 3.800.000

En esta tabla se muestra la cantidad de solicitudes para cada agente de usuario.

Agente de usuario Solicitudes Porcentaje del total

Explorador 3.261.563 97,09%



159

Agente de usuario Solicitudes Porcentaje del total

DAV 2.418 0,07%

Búsqueda (rastreo) 92.322 2,75%

OneNote 1.628 0,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) 275.000

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 1,08 GB

Máximo de memoria usada 2,60 GB

Porcentaje de tráfico del rastreo de búsqueda (Buscar solicitudes de clientes/solicitudes totales)

6%

Solicitudes de ASP.NET en cola 0,00

En los siguientes gráficos se muestra la latencia y el uso de CPU promedio de este entorno.

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,001

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%

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:

165



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.

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 WFE1-4

Processor(s) 2 quad core @ 2.33 GHz

167

Web Server WFE1-4

RAM 32 GB

OS Windows Server® 2008, 64 bit

Size of the SharePoint drive 205 GB

Number of network adapters 2

Network adapter speed 1 Gigabit

Authentication Windows NTLM

Load balancer type Hardware load balancing

Software version SharePoint Server 2010 (pre-release version)

Services running locally Central Administration

Microsoft SharePoint Foundation Incoming E-Mail

Microsoft SharePoint Foundation Web Application

Microsoft SharePoint Foundation Workflow Timer Service

Search Query and Site Settings Service

SharePoint Server Search

Services consumed from a federated Services farm 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.

168

Application Server APP1-4

Processor(s) 4 six core @ 2.40 GHz

RAM 64 GB

OS Windows Server 2008, 64 bit







Services running locally 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.

169

Database Server DB1-2


RAM 32 GB

OS Windows Server 2008, 64-bit

Storage and geometry (1.25 TB * 7) + 3 TB

Disk 1-4: SQL Data

Disk 5: Logs

Disk 6: TempDB




Software version SQL Server 2008

Topology

The following diagram shows the topology for this farm.

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(http://go.microsoft.com/fwlink/?LinkId=189030).

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,702

http://go.microsoft.com/fwlink/?LinkId=189030



172


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 Value

Database size (combined) 7.5 TB

BLOB size 6.8 TB

173


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:

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 2.3

176

Metric Value

Disk Queue Length: Reads 2

Disk Queue Length: Writes 0.3

Disk Reads/sec 131.33

Disk Writes/sec 278.33

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%

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


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.


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



Also, we encourage you to read the following:


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.

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.

http://msdn.microsoft.com/en-us/library/ms179316.aspx

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.

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 WFE1-8 and APP1

Processor(s) 2 quad-core 2.33 GHz processors

RAM 8 GB

Operating system Windows 2008 Server R2





Load balancer type Windows NLB

182

Web Server WFE1-8 and APP1

Services running locally 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 DB1-2

Processor(s) 4 dual-core 3.19 GHz processors

RAM 32 GB

Operating system Windows 2008 Server R2

Storage and geometry 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 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)




Software version SQL Server 2008 R2 (pre-release version)

Topology

The following diagram shows the topology in this lab environment:

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.


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(http://go.microsoft.com/fwlink/?LinkId=189030).

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.



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


Database size (combined) 130 GB

BLOB size 108.3 GB


Number of site collections 181


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:

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.

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.

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

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:

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.

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


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.

194

2. Processor utilization

The following graphs show how scaling out affects processor utilization.

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.

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

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.

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.


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.

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

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

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

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


The following graph shows the throughput without scaling out Web servers.

201

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

203

Departmental collaboration environment technical case study (SharePoint Server 2010) (en inglés)

This document describes a specific deployment of Microsoft SharePoint Server 2010. 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:



Specifications

Workload

Dataset




204



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.


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



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.


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


Nota:


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

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.

206

Web Server WFE1-2 WFE3-4

Processor(s) 2 quad core @ 2.33 GHz 2 quad core @ 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.

207

Web Server APP1-3 APP4


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


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

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


2 quad core @ 3.2 GHz

RAM 32 GB 16 GB 32 GB

Operating system Windows Server 2008 SP1, 64 bit 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

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

60GB Solid state drives (RAID 5)

Number of network adapters 2 2 2

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


211

Configuration

The following table enumerates settings that were made that affect performance or capacity in the environment.

Setting Value Notes

Site collection:

Object Caching (On | Off)

Anonymous Cache Profile (select)

Anonymous Cache Profile (select)

Object Cache (Off | n MB)

Cross List Query Cache Changes (Every Time | Every n seconds)

On

Disabled

Disabled

On – 100GB

60 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


212

Setting Value Notes

QueryLoggingThreshold to 1 second


Instance:


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 (http://go.microsoft.com/fwlink/?LinkId=189030).

Workload This section describes the workload, which is the demand on the farm that includes the number of users, and the usage characteristics.




Total number of unique users per day 9186


Maximum concurrent users 322





213


Search (crawl) 4,373,433 67.61%

Outlook 897,183 13.87%

OneNote 456,917 7.06%

DAV 273,391 4.23%

Browser 247,303 3.82%

Word 94,465 1.46%

SharePoint Workspaces 70,651 1.09%

Office Web Applications 45,125 0.70%

Excel 8,826 0.14%

Access 1,698 0.03%

Dataset This section describes the case study farm dataset that includes database sizes and Search indexes.



BLOB size 1.68 TB


Total number of databases 36

214





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


Failure Rate 0.0005%



Search Crawl % of Traffic (Search client requests / total requests) 82.5%

The following charts show the average CPU utilization and latency for this environment:

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.

217

Database Counters

Metric Value


Disk Queue Length: Reads 1.38






SQL Locks: Average Wait Time 294.56 ms

SQL Locks: Lock Wait Time 867.53 ms

SQL Locks: Deadlocks Per Second 1.87

SQL Latches: Average Wait Time 5.10 ms

SQL Cache Hit Ratio 99.77%

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


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:

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



Also, we encourage you to read the following:


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

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/third-

party solutions installed and running in your divisional portal.

http://msdn.microsoft.com/en-us/library/ms179316.aspx

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.

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) [email protected] [email protected] 4px4c@ 3.19GHz

RAM 8 GB 8 GB 32 GB

Number of network adapters 2 2 1

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

223


Software version SharePoint Server 2010 and Office Web Applications, pre-release versions

SharePoint Server 2010 and Office Web Applications, pre-release 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 E-Mail





Central Administration

Excel Services





PowerPoint Services

Not applicable

224




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.

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 1 2 3 4 5

Content database size 36 GB 135 GB 175 GB

1.2 terabytes

75 GB

Number of sites 44 74 9 9 222

Number of webs 1544 2308 2242 2041 1178

RAID configuration 0 0 0 0 0

Number of spindles for MDF 1 1 5 3 1

Number of spindles for LDF 1 1 1 1 1

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

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%

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%

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

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 50 75 100 125

RPS 74.958 89.001 95.79 101.37

Latency 0.42 0.66 0.81 0.81

Web server CPU 79.6 80.1 89.9 86

Application server CPU N/A N/A N/A N/A

Database server CPU 15.1 18.2 18.6 18.1

75th Percentile (sec) 0.3 0.35 0.55 0.59

230

User Load 50 75 100 125

95th Percentile (sec) 0.71 0.77 1.03 1

The following chart shows the RPS and latency results for a 1x1 configuration.

231

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

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

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.


The following table presents various performance counters captured during testing a 1x1x1 farm, at different steps in user load.

User Load 25 50 75 100 125 150

RPS 53.38 91.8 112.2 123.25 123.25 124.1

Latency 34.2 56 71.7 81.5 84.5 84.9

Web server CPU 23.2 33.8 34.4 32 30.9 35.8

Application server CPU 12.9 19.7 24.1 25.2 23.8 40.9

Database server CPU 0.22 0.23 0.27 0.32 0.35 0.42

75th Percentile (sec) 0.54 0.52 0.68 0.71 0.74 0.88

The following chart shows RPS and latency results for a 1x1x1 configuration.

233

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

234


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

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.



User Load 40 80 115 150 175 200

RPS 109 190 251 287 304 318

Latency 0.32 0.37 0.42 0.49 0.54 0.59

Web server CPU 27.5 47.3 61.5 66.9 73.8 76.2

Application server CPU 17.6 29.7 34.7 38 45 45.9

Database server CPU 21.2 36.1 43.7 48.5 52.8 56.2



The following chart shows RPS and latency results for a 2x1x1 configuration.

236

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

237


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

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.



User Load 66 103 141 17 202 226

RPS 193.8 218.5 269.8 275.5 318.25 310

Latency 0.3 0.41 0.47 0.58 0.54 0.78

Web server CPU 33 38.3 45.8 43.3 51 42.5

Application server CPU 28 32.6 46.5 40 45.1 43.7

Database server CPU 41.6 44.2 52.6 48 61.8 75



The following chart shows RPS and latency results in a 3x1x1 configuration.

239

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

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.

241

Topology 1x1 1x1x1 2x1x1 3x1x1

Max RPS 75 123 291 318

Green Zone RPS Not applicable 99 191 242

Max Latency 0.29 0.25 0.5 0.5

Green Zone Latency 0.23 0.23 0.37 0.41

The following chart shows a summary of RPS at different configurations.

242

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

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:

244

Configuration 1x1 1x1x1 2x1x1 3x1x1

Max RPS 75 154 291 318

Reads/Sec 38 34 54 58

Writes/Sec 135 115 230 270

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.

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.

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

10% Resource Governor

RPS 318 N/A 276 294.5

Percent RPS difference from baseline 0% N/A 83% 88%

Database server CPU (%) 83.40 8.00 86.60 87.3

SA Database server CPU (%) 3.16 2.13 3.88 4.2

Web server CPU (%) 53.40 0.30 47.00 46.5

Application server CPU (%) 22.10 28.60 48.00 41.3

Crawl Web server CPU (%) 0.50 16.50 15.00 12.1

The following chart shows results from tests with incremental Search crawl turned on.

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.

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

1x1x1 99 7128

2x1x1 191 13452

3x1x1 242 17424

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.

250

Social environment technical case study (SharePoint Server 2010) (en inglés)

This document describes a specific deployment of Microsoft SharePoint Server 2010. 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


In this article:



Specifications

Workload

Dataset




251



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.


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


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.


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


Nota:


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

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.

253

Web Server WFE1-3


RAM 16 GB

Operating system Windows Server 2008, 64 bit













Services consumed from a federated services farm User Profile Service


Business Data Connectivity Service


Application Server

There are two application servers in the farm, each with identical hardware.

254

Application Server APP1-4


RAM 16 GB

OS Windows Server 2008, 64 bit







Services running locally 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.

255

Database Server DB1-2


RAM 64 GB


Storage and geometry (1.25 TB * 6)

Disk 1-4: SQL Data

Disk 5: Logs

Disk 6: TempDB


Network adapter speed 1 @ 100MB, 1 @ 1GB



Topology


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



Instance


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(http://go.microsoft.com/fwlink/?LinkId=189030).

Workload This section describes the workload, which is the demand on the farm that includes the number of users, and the usage characteristics.






258



Total number of unique users per day 69,814


Maximum concurrent users 1186




Outlook Social Connector Browser 1,808,963 44.71%

Search (crawl) 704,569 17.42%

DAV 459,491 11.36%

OneNote 266,68 6.59%

Outlook 372,574 9.21%

Browser 85,913 2.12%

Word 38,556 0.95%

Excel 30,021 0.74%

Office Web Applications 20,314 0.50%

SharePoint Workspaces 19,017 0.47%

259

Dataset This section describes the case study farm dataset that includes database sizes and Search indexes.



BLOB size 1.05 TB





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


Failure Rate 0.39%


260

Metric Value


Search Crawl % of Traffic (Search client requests / total requests) 17.42%

The following charts show average CPU utilization and latency for this environment.

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) 99.854 : 0.146


263

Metric Value

Disk Queue Length: Reads 30.518






SQL Locks: Average Wait Time 125 ms

SQL Locks: Lock Wait Time 33.322 ms

SQL Locks: Deadlocks Per Second 0

SQL Latches: Average Wait Time 0 ms

SQL Cache Hit Ratio 20.1%

264


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

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=fd1eac86-ad47-4865-9378-80040d08ac55&displaylang=en


265

Asunto Descripción

Servicios de Access Proporciona información orientativa sobre cómo el uso de Servicios de Access afecta a las topologías que ejecutan SharePoint Server 2010. Vea el artículo en Estimate performance and capacity requirements for Access Services in SharePoint Server 2010 (en inglés).

Servicios de conectividad empresarial 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 2010. Descargue estas notas del producto (BCSCapacityPlanningDoc.docx).

Información general sobre las memorias caché 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).

Servicios de Excel en Microsoft SharePoint Server 2010 Proporciona información orientativa sobre planeación para Servicios de Excel en Microsoft SharePoint Server 2010. Vea el artículo en Estimate performance and capacity requirements for Excel Services in SharePoint Server 2010 (en inglés).

InfoPath Forms Services 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 2010. Descargue estas notas del producto (InfoPath2010CapacityPlanningDoc.docx).

Listas de gran tamaño 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 2010. Descargue estas notas del producto (DesigningLargeListsMaximizingListPerformance.docx).






266

Asunto Descripción

Repositorios de documentos de gran escala Proporciona información orientativa sobre el rendimiento de los repositorios de documentos de gran escala en relación con SharePoint Server 2010. Descargue estas notas del producto (LargeScaleDocRepositoryCapacityPlanningDoc.docx).

Mis sitios y sistemas sociales 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 2010. Descargue estas notas del producto (MySitesSocialComputingCapacityPlanningDoc.docx).

Office Web Apps 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 2010. Descargue estas notas del producto (OfficeWebAppsCapacityPlanningDoc.docx).

PerformancePoint Services 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 2010. Vea el artículo en Estimación de los requisitos de rendimiento y capacidad de PerformancePoint Services.

Búsqueda 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).

Servicios de Visio 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






http://technet.microsoft.com/library/2cabee64-40e0-4a49-a915-bd739074fd26(Office.14).aspx

http://technet.microsoft.com/library/2cabee64-40e0-4a49-a915-bd739074fd26(Office.14).aspx

267

Asunto Descripción

que ejecutan SharePoint Server 2010. Descargue estas notas del producto (VisioServicesCapacityPlanningDoc.docx).

Web Analytics 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 2010. Vea los artículos en Capacity requirements for Web Analytics Shared Service in SharePoint Server 2010 (en inglés).

Administración de contenido web 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 2010.

Servicios de automatización de Word Proporciona información orientativa sobre el planeamiento de capacidad para Servicios de automatización de Word en SharePoint Server 2010. Descargue estas notas del producto (WASCapacityPlanningDoc.docx).

Flujo de trabajo 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 2010. 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 2010.

In this article:





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

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.

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

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

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)

1x1 25 15

1x2 54 29

1x3 82 45

1x4 88 48

2x1 25 15

2x2 55 29

2x4 116 58

274

Recommended results

The following graph shows the results for recommended sustainable throughput.

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.

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.

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

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.

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.

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.

282

Detailed results

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

283

Overall 1x1 1x2 1x3 1x4 2x1 2x2 2x4

Req/Sec 14.96 28.76 45.22 48.01 14.85 28.77 58.02

Tests/Sec 2.00 3.81 6.11 6.42 1.99 3.81 7.80

Average Latency 235.80 241.21 247.21 244.87 240.70 242.26 250.94

Average front-end Web server tier

1x1 1x2 1x3 1x4 2x1 2x2 2x4

%CPU 13.82 24.40 41.02 43.62 6.31 12.48 26.18

Max w3wp Private Bytes 9.46E+08 2.31E+08 1.49E+09 1.55E+09 8.43E+08 9.84E+08 1.19E+09

Average application server (Access Data Services) tier

1x1 1x2 1x3 1x4 2x1 2x2 2x4

%CPU 46.30 42.83 43.74 34.51 46.56 43.45 42.13

%CPU w3wp 33.61 31.15 30.71 24.29 33.48 31.64 29.72

%CPU RS 8.62 7.94 9.17 6.84 9.03 8.02 8.71

Max total Private Bytes 4.80E+09 4.89E+09 4.91E+09 4.62E+09 5.32E+09 4.82E+09 5.07E+09


Max RS Private Bytes 1.78E+09 2.00E+09 1.97E+09 1.86E+09 2.30E+09 1.89E+09 2.02E+09

284

Database server (SQL Server) tier (single computer)

1x1 1x2 1x3 1x4 2x1 2x2 2x4

%CPU 12.07 18.64 32.53 36.05 9.89 21.42 47.46

Avg Private Bytes 2.96E+10 3.22E+10 3.25E+10 3.25E+10 2.89E+10 3.22E+10 3.25E+10

Max Private Bytes 3.26E+10 3.25E+10 3.25E+10 3.25E+10 3.25E+10 3.25E+10 3.25E+10

Avg Disk Queue Length Total 0.74 1.18 1.64 1.77 0.67 1.24 2.18

The following tables show the detailed results for the maximum configurations.

Overall 1x1 1x2 1x3 1x4 2x1 2x2 2x4

Req/Sec 14.96 28.76 45.22 48.01 14.85 28.77 58.02

Tests/Sec 2.00 3.81 6.11 6.42 1.99 3.81 7.80

Average Latency 235.80 241.21 247.21 244.87 240.70 242.26 250.94

Average front-end Web server tier

1x1 1x2 1x3 1x4 2x1 2x2 2x4

%CPU 13.82 24.40 41.02 43.62 6.31 12.48 26.18


285

Average application server (Access Data Services) tier

1x1 1x2 1x3 1x4 2x1 2x2 2x4

%CPU 46.30 42.83 43.74 34.51 46.56 43.45 42.13

%CPU w3wp 33.61 31.15 30.71 24.29 33.48 31.64 29.72

%CPU RS 8.62 7.94 9.17 6.84 9.03 8.02 8.71

Max total Private Bytes 4.80E+09 4.89E+09 4.91E+09 4.62E+09 5.32E+09 4.82E+09 5.07E+09


Max RS Private Bytes 1.78E+09 2.00E+09 1.97E+09 1.86E+09 2.30E+09 1.89E+09 2.02E+09

Database server (SQL Server) tier (single computer)

1x1 1x2 1x3 1x4 2x1 2x2 2x4

%CPU 12.07 18.64 32.53 36.05 9.89 21.42 47.46

Avg Private Bytes 2.96E+10 3.22E+10 3.25E+10 3.25E+10 2.89E+10 3.22E+10 3.25E+10

Max Private Bytes 3.26E+10 3.25E+10 3.25E+10 3.25E+10 3.25E+10 3.25E+10 3.25E+10

Avg Disk Queue Length Total 0.74 1.18 1.64 1.77 0.67 1.24 2.18

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

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:

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.

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.



% Processor Time Process(w3wp) The Access Data Services runs within its own w2wp process, and it will be obvious which w2wp

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


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.



% 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

291


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

Increase the number of CPUs or cores, or both, in the existing Access Data Services computers. Add additional Access Data Services computers if possible.

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.

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 higher-speed processors.

Database server disk I/O When the number of I/O requests to

a hard disk exceeds the disk’s I/O

Distributing data files across multiple physical drives allows for parallel I/O. The blog SharePoint Disk Allocation and Disk


292


capacity, the requests will be queued. As a result, the time to complete each request increases.

I/O (http://go.microsoft.com/fwlink/?LinkId=129557) contains useful information about resolving disk I/O issues.

Reporting Services CPU utilization 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).

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 2010. 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 real-world 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 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.

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 1-3 1-5 1-20

Columns 10-20 10-500 10-1,000

Rows 10-40 10-10,000 100-30,000

Calculated Cells 0-20% 0-70% 0-70%

Number of Formats 1-10 1-15 1-20

Tables 0-1 0-2 0-5

Charts 0-1 0-4 0-4

Workbook Uses External Data 0% 20% 50%

Workbook Uses a Pivot Table 0% 3% 3%

Workbook Uses Conditional Formats 0% 10% 20%

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%

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

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

For information about Servicios de Excel bottlenecks, see the Common bottlenecks and their causes section in this article.

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)

1x1 38 31

1x2 35 26

1x3 28 21

2x1 57 35

2x2 62 46

2x3 52 39

3x1 51 32

3x2 81 69

3x3 83 64

300

Recommended Results

The following chart shows our results for recommended sustainable throughput.

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.

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.

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.

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 30.56 34.55 31.67 26.03 45.94 68.37 20.71 38.82 63.70

Client Response Time (sec.) 0.22 0.18 0.19 0.16 0.19 0.20 0.15 0.15 0.17

TPS 1.58 1.77 1.61 1.40 2.38 3.54 1.08 2.03 3.25

Web Front-end Tier 1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3

% CPU (average over all Web Front-end computers

33.73 37.64 33.84 14.61 23.95 36.90 7.54 13.12 21.75

Excel Calculation Services Tier

1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3

% CPU (average over all Excel

30.56 34.55 31.67 26.03 45.94 68.37 20.71 38.82 63.70

308


1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3

Calculation Services computers)

Peak Private Bytes (maximum over all Excel Calculation Services computers)

5.94E+09 5.82E+09 5.79E+09 5.87E+09 6.09E+09 5.92E+09 5.79E+09 5.91E+09 5.85E+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 37.85 56.70 51.17 35.19 62.04 81.31 27.79 51.62 82.58

Client Response Time (sec.) 0.19 0.28 0.23 0.16 0.20 0.25 0.16 0.16 0.22

TPS 1.92 2.96 2.59 1.81 3.21 4.60 1.41 2.72 4.30

Web Front-end Tier 1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3

% CPU (average over all Web Front-end computers

41.08 67.78 58.59 19.44 34.11 45.97 10.19 17.79 28.69

309


1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3

% CPU (average over all Excel Calculation Services computers)

24.99 18…44 10.96 23.57 20.56 17.77 18.97 17.04 18.10

Peak Private Bytes (maximum over all Excel Calculation Services computers)

5.91E+09 5.85E+09 5.91E+09 5.88E+09 5.99E+09 6.502E+09 5.94E+09 5.94E+09 6.04E+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.

310

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

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.

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.

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


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.

Increase the number of CPUs and/or cores in the existing Excel Calculation Services computers, or add Excel Calculation

315


Services computers.

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.

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

316


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.


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

317


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.

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

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

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.

320

Nombre de la prueba Descripción 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.

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.

321

Nombre de la prueba Combinación de pruebas

Represente un panel y cambie de forma aleatoria uno de los dos filtros cinco veces.

80%

Represente un panel, seleccione un gráfico y expándalo y contráigalo cinco veces.

10%

Represente un panel, seleccione una cuadrícula y expándala y contráigala cinco veces.

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

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 2008. Se realizó una instalación empresarial predeterminada de SharePoint Server 2010.

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.

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 Descripción

Recuento de usuarios Recuento de usuarios total que informa Visual Studio.

Solicitudes por segundo (RPS) 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.

Vistas por segundo (VPS) 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 (http://go.microsoft.com/fwlink/?linkid=200609&clcid=0xC0A).

Los registros IIS de estas solicitudes pueden analizarse para ayudar a planear


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.

325

Resumen de autenticación de cuenta de servicio desatendida

Topología (WFE x APP x SQL) Usuarios Solicitudes por segundo (RPS)

Vistas por segundo (VPS)

2M (1x0x1) 360 83 50

3M (1x1x1) 540 127 75

4M (1x2x1) 840 196 117

5M (1x3x1) 950 215 129

6M (2x3x1) 1.250 292 175

7M (2x4x1) 1.500 346 205

Resumen de autenticación de usuario

Topología (WFE x APP x SQL) Usuarios Solicitudes por segundo (RPS)

Vistas por segundo (VPS)

2M (1x0x1) 200 47 27

3M (1x1x1) 240 56 33

4M (1x2x1) 300 67 40

5M (1x3x1) 325 74 44

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 50 150 250 360

Promedio de CPU de WFE/APP 19,20% 57,70% 94,00% 96,70%

RPS 18 53 83 83

Vistas por segundo 10,73 31,72 49,27 49,67

Tiempo de respuesta promedio (seg.) 0,12 0,15 0,38 2

327

Autenticación de usuario

328


Promedio de CPU de WFE/APP 30,80% 61,30% 86,50% 93,30%

RPS 17 32 43 47

Vistas por segundo 10,3 19,32 26,04 27,75


329

Resultados de granja de servidores 3M (1x1x1)

Autenticación de la cuenta de servicio desatendida

330


RPS 36 87 124 127

Vistas por segundo 21 52 74 75


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

331

Autenticación por usuario

332


RPS 17 39 52 56




Máximo de bytes privados de WFE de W3WP de SharePoint Server

0,78 GB 1,3 GB 1,6 GB

1,9 GB



19 GB 20,1 GB 20,5 GB

20,9 GB

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)

7M (2x4x1)

Recuento de usuarios 840 950 1.250 1.500

RPS 196 216 292 346




2,1 GB 1,7 GB 2,1 GB 2,0 GB



16 GB 12 GB 15 GB 15 GB

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)

6M (1x4x1)


RPS 56 67 74 74




2,1 GB 1,9 GB 1,9 GB 1,5 GB



20 GB 20 GB 20 GB 20 GB

CPU de Analysis Services 17% 44% 57% 68%

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

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 Solución

El uso del procesador del servidor de aplicaciones es reducido y hay otros servicios que se están ejecutando en el servidor de aplicaciones.

Agregue más memoria física o limite la memoria caché de ASP.NET.

El uso del procesador del servidor de aplicaciones es reducido y solo se está ejecutando PerformancePoint Services en el servidor de aplicaciones.

Si es aceptable, configure las opciones de memoria caché de ASP.NET para que la memoria caché use o agregue más memoria.

El uso del procesador del servidor de aplicaciones es intensivo. 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 2010. 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.

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 (http://go.microsoft.com/fwlink/?linkid=165486&clcid=0xC0A) 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





340


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.

2008 (http://go.microsoft.com/fwlink/?linkid=165486&clcid=0xC0A) para obtener instrucciones.

Subprocesos de consulta y procesamiento de Analysis Services

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.

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 (http://go.microsoft.com/fwlink/?linkid=165486&clcid=0xC0A) para obtener instrucciones.

Memoria del servidor de aplicaciones

PerformancePoint Services almacena en caché los

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



341


resultados de la consulta de Analysis Services y de otros orígenes de datos por la duración de la memoria caché de origen de datos. 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.

documento, para obtener más información. Vea también el tema sobre la configuración de elementos de la memoria caché de ASP.NET (http://go.microsoft.com/fwlink/?linkid=200610&clcid=0xC0A) y la entrada de blog de Thomas Marquardt acerca de los antecedentes de los límites de la memoria caché de ASP.NET (http://go.microsoft.com/fwlink/?linkid=200611&clcid=0xC0A).

Configuración de limitación de peticiones de WCF

PerformancePoint Services se implementa como un servicio WCF. WCF limita el número máximo de llamadas simultáneas como un comportamiento de limitación de peticiones de servicio. Aunque las consultas de larga ejecución podrían contribuir a este cuello de botella, es poco

Si es necesario, cambie el comportamiento de limitación de peticiones de Windows Communication Foundation (WCF). Vea el tema sobre comportamientos de limitación de peticiones de WCF (http://go.microsoft.com/fwlink/?linkid=200612&clcid=0xC0A) y la entrada de blog de Wenlong Dong sobre la limitación de peticiones de WCF y la escalabilidad de los servidores (http://go.microsoft.com/fwlink/?linkid=200613&clcid=0xC0A).








342


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 Instancia de contador Notas

Aplicaciones de ASP.NET/Recortes API de caché

Grupo de aplicaciones de PerformancePoint Services

Si el valor es mayor que cero, revise la sección "Consumo de memoria".

MSAS 2008:Threads/Subprocesos inactivos de grupo de consultas

No disponible 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 (http://go.microsoft.com/fwlink/?linkid=165486&clcid=0xC0A).

MSAS 2008:Threads/Longitud de No disponible Si el valor es mayor que cero, revise la sección "Analysis Services" y el

343

Contador de rendimiento Instancia de contador Notas

cola de trabajos de grupo de consultas

tema sobre la guía de rendimiento de Analysis Services de las notas del producto de SQL Server 2008 (http://go.microsoft.com/fwlink/?linkid=165486&clcid=0xC0A).

MSAS 2008:Threads/Subprocesos inactivos de grupo de procesamiento

No disponible 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 (http://go.microsoft.com/fwlink/?linkid=165486&clcid=0xC0A).

MSAS 2008:Threads/Longitud de cola de trabajos de grupo de procesamiento

No disponible 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 (http://go.microsoft.com/fwlink/?linkid=165486&clcid=0xC0A).

WCF CountersServiceModelService 3.0.0.0(*)\Llamadas pendientes

Instancia de servicio de PerformancePoint

Si el valor es mayor que cero, vea el tema sobre la limitación de peticiones de WCF y escalabilidad de servidores (http://go.microsoft.com/fwlink/?linkid=200613&clcid=0xC0A).

Vea también Otros recursos

Plan for PerformancePoint Services (SharePoint Server 2010)



http://technet.microsoft.com/library/4c1ac4c1-1154-4346-9b80-0b804802beaa(Office.14).aspx

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

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:



In this article:

Introduction

Hardware specifications and topology

Capacity requirements

http://technet.microsoft.com/library/bfc60f64-f816-4e68-896f-91784d0aaa47(Office.14).aspx

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

346

Figure 1. SharePoint Server 2010 Web Analytics architectural overview

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 Minimum requirement

Processors 4 quad core @ 2.33 GHz

348

Application server Minimum requirement

RAM 8 GB




Network adapter speed 1 GB

Authentication NTLM

Load balancer type SharePoint Load Balancer

Software version SharePoint Server 2010 (prerelease version)


Microsoft SharePoint Foundation Incoming E-mail





Web Analytics Data Processing 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.

349

Database server Minimum requirement

Processors 4 quad core @ 2.4 GHz

RAM 32 GB

Operating system Windows Server 2008, 64-bit

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


Network adapter speed 1 GB

Authentication NTLM


Topology

The following diagram (Figure 2) shows the Web Analytics topology.

350

Figure 2. Web Analytics topology

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

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.

http://technet.microsoft.com/library/8e0b7a53-6741-4b19-897e-4b42e5b8e005(Office.14).aspx#Section3

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.

354

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

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.

356

Figure 4. Daily site traffic vs. SQL Server topology

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

Staging + Reporting Staging Reporting Staging Reporting

Total sum of percentage of processor time for 8 processor computer

19 192 5.78 100 13.4

SQL Server buffer hit ratio 99 100 100 100 100

% Disk time 7,142 535 5.28 59.3 98.2

Disk queue length 357 28.6 0.26 2.97 4.91

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

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.



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.

http://technet.microsoft.com/library/a7c82686-15d9-4685-b303-44a3fc675d3f(Office.14).aspx

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


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

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 Sitio de publicación

Tamaño de las bases de datos de contenido 2,63 GB

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 20.000 páginas divididas en 20 carpetas con 1.000 páginas cada una


361

Objeto Sitio de publicación

Composición de las páginas Páginas de artículo en HTML básico, con referencias a dos imágenes

Tamaño de página 42 KB sin comprimir; 12 KB comprimida

Imágenes 3.000 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 2 procesadores de cuatro núcleos a 2,33 GHz

RAM 8 GB


Tamaño de la unidad de SharePoint 300 GB


362

Servidor web

Velocidad del adaptador de red 1 gigabit

Autenticación Básica de Windows

Tipo de equilibrador de carga Equilibrio de carga de hardware

Versión de software SharePoint Server 2010 (versión preliminar)

Servicios que se ejecutan localmente 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 4 procesadores de cuatro núcleos a 3,19 GHz

RAM 16 GB


Almacenamiento 15 discos de 300 GB a 15.000 RPM


Velocidad del adaptador de red 1 gigabit

Autenticación NTLM

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.

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é

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

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.

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é (http://go.microsoft.com/fwlink/?linkid=121543&clcid=0xC0A).

http://msdn.microsoft.com/es-es/library/aa661294.aspx


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 (http://go.microsoft.com/fwlink/?linkid=123948&clcid=0xC0A).

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

(http://go.microsoft.com/fwlink/?linkid=123947&clcid=0xC0A).

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.



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.

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


Medida 1x1 2x1 4x1

100%

Máximo de RPS

Uso de CPU de SQL Server

3.463

0%

7.331

0%

11.032

0%

95%

Máximo de RPS


2.137

5,93%

3.945

12,00%

5.937

21,80%

374


Medida 1x1 2x1 4x1

90%

Máximo de RPS


1.518

7,12%

2.864

14,40%

4.518

28,00%

50%

Máximo de RPS


459

9,86%

913

19,50%

1.596

42,00%

0%

Máximo de RPS


172

9,53%

339

19,00%

638

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 2010. Puede configurar la memoria caché de resultados en la página Configuración de la memoria caché de

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 (http://go.microsoft.com/fwlink/?linkid=205058&clcid=0xC0A) 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.

http://office.microsoft.com/es-es/ha101785628.aspx

http://office.microsoft.com/es-es/ha101785628.aspx

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

http://technet.microsoft.com/library/40117fda-70a0-4e3d-8cd3-0def768da16c(Office.14).aspx

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.

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

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

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.

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.

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.

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.

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

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

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.

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

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

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.

396

Una proporción de aciertos de la memoria caché del 90% es muy baja para una implementación típica. La mayoría de las implementaciones de SharePoint Server 2010 con gran cantidad de operaciones de lectura tendrán una proporción de aciertos del 95% o superior en la memoria caché de resultados.

Conclusiones y recomendaciones sobre el efecto de las operaciones de escritura en el rendimiento

Los datos presentados indican que las operaciones de escritura no supondrán un gran efecto negativo en el rendimiento general del sistema para los lectores. Debe recordar que la actividad de escritura puede causar puntas en el uso de CPU y debe planear la configuración típica de modo que prevea estas puntas. Una estrategia para nivelar estas puntas es incrementar la escalabilidad horizontal a varios servidores web. Esto tiene dos ventajas:

Dispersa la carga de escritura en varios servidores web, lo que suaviza las puntas totales.

Proporciona un aumento en las RPS de lectura, especialmente en proporciones de aciertos de la memoria caché de resultados altas.

Efecto de la distribución de contenido

Una alternativa al modelo de autor en contexto, que usa un entorno único para la edición y la lectura, consiste en dividir el entorno único en dos entornos independientes (un entorno de creación y uno de producción) y en usar la distribución de contenido para copiar contenido del entorno de creación al entorno de producción.

En esta configuración, en el entorno de producción puede haber poca actividad de escritura o ninguna actividad de escritura en absoluto, excepto cuando la distribución de contenido importa contenido. En estas pruebas, se agregaron lecturas hasta que el uso de CPU del servidor web se encontró en el intervalo del 70-80%. Posteriormente, el trabajo de distribución de contenido exportó 10 sitios con 500 páginas cada uno desde la colección de sitios de creación como un paquete e importó dicho paquete a la colección de sitios de publicación. El tamaño del paquete implementado es mayor que lo observado normalmente en entornos reales con el fin de extender bastante la duración del trabajo de distribución de contenido para ver resultados de las pruebas. Para obtener información adicional acerca de las características del contenido implementado, vea la sección Conjunto de datos.

Una vez finalizada la exportación, se importó el contenido en una colección de sitios independiente y se midió el servidor de aplicaciones y la carga de SQL Server, además del rendimiento, mientras la importación se encontraba en curso. La prueba de importación se realizó en varias proporciones de aciertos de la memoria caché de resultados diferentes.

La observación clave es que la importación solo tiene un efecto menor en las RPS de lectura generales, como se muestra en el siguiente gráfico. También se observó que la importación no tuvo un efecto importante en el uso de CPU del servidor web, como se muestra en las siguientes tablas, independientemente de la proporción de aciertos de la memoria caché. No obstante, el efecto fue más evidente en la CPU de SQL Server, como se muestra en el siguiente gráfico. Esto estaba previsto, ya que el servidor de bases de datos experimenta una carga adicional cuando se importa el contenido en él. Sin embargo, la CPU de SQL Server se mantuvo por debajo del uso del 12% en todas las proporciones de aciertos de la memoria caché probadas, incluso durante la importación.

398

En las siguientes tablas se muestra el efecto de la importación de distribución de contenido en el uso de CPU del servidor de bases de datos y del servidor web.

Efecto de la importación de distribución de contenido en el uso de CPU del servidor web

Acierto de caché 100% 99% 98% 95% 90% 50% 0%

Línea base 72,32% 73,26% 71,28% 73,53% 71,79% 68,05% 63,97%

Con la importación 70,93% 74,45% 69,56% 74,12% 70,95% 67,93% 63,94%

Efecto de la importación de la distribución de contenido en el uso de CPU del servidor de bases de datos

Acierto de caché 100% 99% 98% 95% 90% 50% 0%

Línea base 1,19% 1,64% 2,01% 3,00% 3,73% 5,40% 6,82%

Con la importación 6,03% 6,82% 6,97% 7,96% 8,52% 10,29% 10,56%

Conclusiones y recomendaciones sobre el efecto de la distribución de contenido

En los resultados de las pruebas se muestra que llevar a cabo operaciones de distribución de contenido durante las operaciones del sitio comunes no implica un problema importante en el rendimiento. En estos resultados se muestra que no es estrictamente necesario implementar contenido durante períodos de tráfico bajo para minimizar el efecto de la operación en el rendimiento general y que los tiempos de implementación pueden controlarse principalmente en función de las necesidades de negocio en lugar de los requisitos de rendimiento.

Efecto de la instantánea de base de datos durante la exportación de distribución de contenido

En SharePoint Server 2010, la distribución de contenido puede configurarse para crear una instantánea de la base de datos de contenido de origen antes de exportar su contenido. Esto protege eficazmente el proceso de exportación de cualquier actividad de creación que pueda llevarse a cabo durante la exportación. No obstante, las instantáneas pueden afectar al rendimiento de escritura del servidor de bases de datos, ya que actúan como multiplicadores de las escrituras. Por ejemplo, si tiene dos instantáneas de una base de datos de origen y, a continuación, escribe en dicha base de datos, el servidor de bases de datos copia los datos existentes en cada instantánea y,

399

posteriormente, escribe los datos nuevos en la base de datos de origen. Esto significa que una sola escritura en la base de datos de origen provoca tres escrituras reales: una en la base de datos de origen y otra en cada instantánea de base de datos.

Para determinar el efecto de una instantánea en el entorno de creación, se midieron las RPS de escritura, el tiempo de respuesta y el uso de CPU de los servidores web, del servidor de bases de datos y del servidor de aplicaciones durante una operación de exportación mientras también se llevaba a cabo una actividad de escritura. En las siguientes tablas se muestran los resultados.

Efecto de las instantáneas de base de datos durante la distribución de contenido

Valor métrico 4 WPH - Sin instantáneas 4 WPH - Con instantáneas

RPS de escritura 0,2 0,16

Tiempo de respuesta 0,13 0,15

% de CPU del servidor web 0,42% 0,27%

% de CPU del servidor de aplicaciones 8,67% 8,98%

% de CPU del servidor de bases de datos 3,34% 2,41%

Efecto de las instantáneas de base de datos durante la distribución de contenido

Valor métrico 8 WPH - Sin instantáneas 8 WPH - Con instantáneas

RPS de escritura 0,44 0,44

Tiempo de respuesta 0,13 0,13

% de CPU del servidor web 0,61% 0,73%

% de CPU del servidor de aplicaciones 14,6% 12%

% de CPU del servidor de bases de datos 7,04% 7,86%

400

Conclusiones y recomendaciones sobre el efecto de la instantánea de base de datos durante la exportación de distribución de contenido

En los resultados de las pruebas se muestra que no hubo un efecto importante en ningún punto de datos medido con las instantáneas de base de datos. Todas las varianzas registradas se encontraron dentro del margen de error. Esto confirma que las instantáneas de base de datos pueden usarse sin consideraciones de rendimiento importantes.

Características del contenido

Las pruebas se realizaron en un solo conjunto de datos creado para responder a un conjunto específico de preguntas. Su conjunto de datos diferirá y cambiará a lo largo del tiempo. En esta sección se investiga cómo las características del contenido, como el número de páginas de la biblioteca de páginas y las características incluidas en las páginas, pueden ayudar a tomar decisiones bien fundadas sobre la administración de la capacidad.

Número de páginas

Se probó el máximo de RPS en varios tamaños de bibliotecas de páginas. Esta prueba se llevó a cabo en una topología de 4x1 con el almacenamiento en la memoria caché de resultados deshabilitado y con acceso anónimo. Todas las páginas eran de 42 KB sin comprimir y 12 KB comprimidas. En la siguiente tabla se muestran los resultados de las pruebas.

Efecto del recuento de páginas de la biblioteca en las RPS

Número de páginas 3 1.000 20.000

Máximo de RPS 860 801 790

El aumento del número de páginas a 20.000 no supuso un efecto importante en el máximo de RPS.

Campos de búsqueda multivalor

Un campo de búsqueda multivalor es una columna de una lista que hace referencia a uno o varios elementos de otra lista, como columnas que usan metadatos administrados empresariales. Estos campos generalmente se usan como palabras clave de una página y no necesariamente se representan. En algunos casos, para sitios wiki empresariales de ejemplo, tiene sentido representar estos valores de campo en el contenido de las páginas. Por ejemplo, las páginas pueden archivarse en categorías cuando se crean (por ejemplo, Noticias internacionales, Interés humano y Deportes en un sitio de noticias) y la página maestra incluye un marcador de posición que mostrará al usuario en qué categoría se etiquetó la página.

401

Los campos de búsqueda multivalor hacen que se capturen más datos cada vez que se solicita una página. Por lo tanto, si hay muchos campos de búsqueda multivalor en una página, el rendimiento puede verse afectado.

En el siguiente gráfico se muestra el efecto de los campos de búsqueda multivalor en el rendimiento.

402

En el siguiente gráfico se muestra el efecto de los campos de búsqueda multivalor en el uso de recursos de la granja de servidores.

404

La degradación en el máximo de RPS tiene lugar a medida que aumenta la cantidad de campos de búsqueda multivalor debido al efecto en la red entre el servidor web y el servidor de bases de datos.

Efecto de los informes de uso

Los informes de uso son un servicio que ayuda a los administradores a supervisar las estadísticas sobre el uso de los sitios. Para obtener más información acerca de los informes de uso, vea Configure usage and health data collection (SharePoint Server 2010).

Se probó el efecto de los trabajos del temporizador de informes de uso en el máximo de RPS en una granja de servidores de 1x1. En la siguiente tabla se describen los resultados.

Efecto del registro de uso en el rendimiento (en RPS)

Base de datos de uso habilitada Base de datos de uso deshabilitada

Diferencia

Caché de resultados habilitada 3.459 3.463 4

Caché de resultados deshabilitada 629 638 9

En los resultados se muestra que la habilitación del registro de uso no afecta de manera significativa a las RPS en un escenario de solo lectura.

Acerca de los autores Joshua Stickler es jefe de programas de SharePoint Server 2010 en Microsoft.

Tyler Butler es jefe de programas de SharePoint Server 2010 en Microsoft.

Zhi Liu es ingeniero de desarrollo de software en pruebas para SharePoint Server 2010 en Microsoft.

Cheuk Dong es ingeniero de desarrollo de software en pruebas para SharePoint Server 2010 en Microsoft.

Philippe Flamm es ingeniero de desarrollo de software en pruebas para SharePoint Server 2010 en Microsoft.

http://technet.microsoft.com/library/33ed78c8-25fc-48ea-b0c1-50b540213cff(Office.14).aspx

405

Estimate performance and capacity planning for workflow in SharePoint Server 2010 (en inglés)

This performance and capacity planning article provides guidance on the effect that the use of workflow has on topologies that run Microsoft SharePoint Server 2010.

For general information about capacity planning for SharePoint Server 2010, see Administración del rendimiento y de la capacidad (SharePoint Server 2010).

Contents


Test results

Recommendations

Troubleshooting

Test farm characteristics The following sections describe the characteristics of the test farm:

Dataset

Workload

Hardware, settings, and topology

Dataset

To get benchmarks, most tests ran on a default Team Site on a single site collection in the farm. The manual start tests started workflows by using a list that has 8,000 items.

Workload

Testing for this scenario helps develop estimates of how different farm configurations respond to changes to the following variables:

406

Effect of the number of front-end servers on throughput for manually starting declarative workflows across multiple computers

Effect of the number of front-end servers on throughput for automatically starting declarative workflows on item creation across

multiple computers

Effect of the number of front-end servers on throughput for completing tasks across multiple computers

The specific capacity and performance figures presented in this article will differ from the figures in real-world environments. The figures presented are intended to provide a starting point for the design of an appropriately scaled environment. After you complete the initial system design, test the configuration to determine whether it will support the factors in your environment.

This section defines the test scenarios and discusses the test process that was used for each scenario. Detailed information such as test results and specific parameters are given in each test result section later in this article.

Test name Test description

Throughput for starting workflows manually 1. Associate the included MOSS Approval workflow with a list that

creates one task.

2. Populate the list with list items.

3. Call the StartWorkflow Web service method on Workflow.asmx

against the items in the list for five minutes.

4. Calculate throughput by looking at the number of workflows in

progress.

Throughput for starting workflows automatically when an item is created

1. Associate the included MOSS Approval workflow with a list that

creates one task, set to automatically start when an item is

created.

2. Create items in the list for five minutes.

3. Calculate throughput by looking at the number of workflows in

progress.

Throughput for completing workflow tasks 1. Associate the included MOSS Approval workflow with a list that

407

Test name Test description

creates one task, set to automatically start when an item is

created.

2. Create items in the list.

3. Call the AlterToDo Web service method on Workflows.asmx

against the items in the task list that was created by the

workflows that started.

4. Calculate throughput by looking at the number of workflows

completed.

Hardware, settings, and topology

Topologies that were used for these tests use a single computer for the content database and from one to four front-end computers that have the default installation for SharePoint Server 2010. Although the workflows that were used in these tests are not available in Microsoft SharePoint Foundation 2010, the results can be used to estimate similar scenarios on those deployments. The dataset that was used for these tests contains a single site collection with a single site that is based on the Team Site template on a single content database.

To provide a high level of test-result detail, several farm configurations were used for testing. Farm configurations ranged from one to four Web servers and a single computer that is running Microsoft SQL Server 2008. Testing was performed with one client computer. The database server and all Web servers were 64-bit, and the client computer was 32-bit.

The following table lists the specific hardware that was used for testing.

Web server Database server

Processor [email protected] [email protected]

RAM 4 GB 16 GB

Operating system Windows Server 2008 R2 x64 Windows Server 2008 R2

408

Web server Database server

x64

Storage 680 GB 4.2 terabyte


Network adapter speed 1 gigabit 1 gigabit

Authentication NTLM NTLM

Software version 4747 SQL Server 2008 R1

Number of SQL Server instances 1 1

Load balancer type No load balancer No load balancer

ULS logging level Medium Medium

409

Workflow Capacity Planning Topology

410

Test results The following tables show the test results for workflow in SharePoint Server 2010. For each group of tests, only certain specific variables are changed to show the progressive effect on farm performance.

All the tests reported in this article were conducted without think time, a natural delay between consecutive operations. In a real-world environment, each operation is followed by a delay as the user performs the next step in the task. By contrast, in the test, each operation was immediately followed by the next operation, which resulted in a continual load on the farm. This load can cause database contention and other factors that can adversely affect performance.

Effect of scaling the Web server on throughput

The following throughput tests were run by using the Approval workflow that is included with SharePoint Server 2010. The workflow association assigns one task, and all instances are run on a single list. Each instance of this workflow creates the following in the content database:

An entry in the Workflows table to store workflow status

Five secondary list items (one task and four history items)

Four event receivers to handle events on the workflow's parent item and task

Workflow Postpone Threshold was set to be very large so that workflow operations would never get queued. Each test was run five times, and each test ran for five minutes.

Manual start throughput

The test in the following table shows how the addition of front-end servers affects the throughput of starting workflows synchronously through the Web service. This test was run with a user load of 25 concurrent users continuously calling the StartWorkflow method on Workflow.asmx and no other load on the farm. The user load was the optimal load before dropped Web requests occurred. The list is prepopulated with up to 8,000 items.

Topology Approval workflow maximum RPS

1x1 14.35

2x1 24.08

3x1 29.7

411


4x1 30.77

The following graph shows how throughput changes. The addition of front-end servers does not necessarily affect farm throughput in a linear manner but instead peaks off at around three to four front-end servers. In summary, the maximum throughput for manually starting workflows is around 30 workflows per second, and adding more than four front-end servers will likely have an insignificant effect.

Manual start throughput

412

Automatically starting workflows when items are created throughput

The test in the following table shows how the addition of front-end servers affects the throughput of starting workflows automatically when items are created. This test was run with a user load of 150 concurrent users continuously calling the list Web service to create new list items in a single list and no other operations on the server. The list started as an empty list.

413


1x1 13.0

2x1 25.11

3x1 32.11

4x1 32.18

The following graph shows how throughput changes. The throughput is very close to the manual start operations. Similar to the manual start test, throughput peaks at approximately three or four front-end servers at approximately 32 workflows per second maximum. Adding more than three or four front-end servers will have an insignificant effect.

Autostart workflow throughput

415

Task completion throughput

The test in the following table shows how the addition of front-end servers affects the throughput of completing workflow tasks. The task list that was used by autostart workflows in the previous test was the list that was used to complete tasks. This test was run with a user load of 25 concurrent users continuously calling the AlterToDo method on Workflow.asmx and no other operations on the server. The list started as an empty list.


1x1 13.5

2x1 23.86

3x1 27.06

4x1 27.14

The following graph shows how throughput changes. Similar to the manual start test, throughput peaks at approximately three or four front-end servers at approximately 32 workflows per second maximum. Adding more than three front-end servers will have an insignificant effect.

416

Task completion throughput

417

Effect of list size and number of workflow instances on throughput

The test in the following table shows how throughput changes as list size and number of workflows increases. Data population was done by running the autostart workflow test continuously until 1 million items were created in the list, and stopping at different checkpoints throughout the test to perform throughput measurements as we did with the core throughput tests. Tests were performed on a 4x1 topology.

To maintain reliability during data population, we had to keep workflow queuing turned on to avoid reaching the maximum number of connections on the database server. If no connections are available and a workflow operation cannot connect to the content database, the operation will be unable to run. See Recommendations for more information about workflow queuing.

Number of items or workflows Baseline solution maximum (RPS)

0 32.18

10 32

1,000 28.67

10,000 27.16

100,000 16.98

1,000,000 9.27

418

Autostart throughput as number of items and workflows increases

419

For a single list and single task and history list, throughput decreases steadily between 1,000 and 100,000 items. However, the rate of degradation reduces after that point. We attribute degradation of throughput to many factors.

One factor is the number of rows added to many tables in the content database per instance. As mentioned earlier, workflows create several list items in addition to event receivers that each workflow instance registers. As table sizes grow large in different scopes, adding rows becomes slower, and the aggregate slowdown for these additions becomes a more significant degradation than what is experienced with only list item creation.

Task list size contributes additional overhead. In comparing throughput for workflows run on new lists versus new task lists, task lists had a bigger effect on performance. This is because task lists register for more event receivers than the parent list items. The following chart describes the differences.

Throughput with different list configurations (workflows started per second)

Million item task list Empty task list

Million item list 9.27 12

Empty item list 9.3 13

If you know that you will have to run lots of workflows against large lists and need more throughput than what your tests show you can get, consider whether your task lists can be separated between workflow associations.

Recommendations This section provides general performance and capacity recommendations. Use these recommendations to determine the capacity and performance characteristics of the starting topology that you created to decide whether you have to scale out or scale up the starting topology.

For specific information about minimum and recommended system requirements, see Hardware and software requirements (SharePoint Server 2010).

Scaled-out topologies

You can increase workflow throughput by scaling out to up to four Web servers. Then, additional increase will be insignificant. Workflow throughput can be restricted by performance-related workflow settings. These settings are described in more detail in Workflow queuing and performance-related settings.



420

Estimating throughput targets

Many factors can affect throughput. These factors include the number of users, and the type, complexity, and frequency of user operations. More complex workflows that perform many operations against the content database or register for more events will run slower and consume more resources than other workflows.

The workflow used in this test creates several entries in the content database that are built in to the task activities. If you expect to have workflows with small numbers of tasks, you can expect similar throughput characteristics. If most workflows contain very lightweight operations, throughput may be increased. If your workflows will consist of lots of tasks or intense back-end operations or processing power, you can expect throughput to decrease.

In addition to understanding what the workflows will do, consider where the workflows will run and whether they will run against large lists, on which throughput will decrease over time.

SharePoint Server 2010 can be deployed and configured in many ways. As a result, there is no simple way to estimate how many users can be supported by a given number of servers. Therefore, make sure that you conduct testing in your own environment before you deploy SharePoint Server 2010 in a production environment.

Workflow queuing and performance-related settings

Workflow uses a queuing system to control workflow-related stress on farm resources and the content database. By using this system, when the number of workflows executing against a database reaches an administrator-configured threshold, successive workflow operations are added to the queue to be run by the Workflow Timer service. By default, this service receives a batch of workflow work items through timer jobs every minute.

Several farm administrator settings directly and indirectly related to the queuing mechanism affect the performance and scaling for workflow. The following sections describe what these settings do and how to adjust them to meet performance requirements.

Understanding the basic queue settings

Farm administrators can adjust the following settings to configure basic characteristics of the queuing system:

Workflow Postpone Threshold (Set-SPFarmConfig –WorkflowPostponeThreshold <integer>)

The maximum number of workflows that can execute against a single content database before additional requests and operations are queued. Queued workflows show a status of Starting. This is a farm-wide setting that has a default value of 15. This represents the number of workflow operations that are being processed at a time, not the maximum number of workflows that can be in progress. As workflow operations are completed, successive operations will be able to run.

Workflow Event Delivery Batch Size (Set-SPWorkflow –BatchSize <integer>)

421

The Workflow Timer service is an exception to the postpone threshold limit and will retrieve batches of items from the queue and execute them one at a time. These batches can be larger than the postpone threshold. The number of work items that the service receives per run is set by using the BatchSize property. The BatchSize property can be set one time per service instance. The default value is 100. When running on application servers that are not configured to be front-end servers, the Workflow Timer service requires workflow configuration settings in Web.config to be set in the configuration database. This must be done through a script that calls UpdateWorkflowConfigurationSettings() on the SPWebApplication object, which will copy the Web.config settings from a front-end server.

Workflow Timer Job Frequency (Set-SPTimerJob job-workflow –schedule <string>)

The frequency with which the Workflow Timer service runs can be adjusted through timer job settings. By default, the service is set to run every five minutes. This means that there can be a five-minute delay before the work items at the top of the queue are processed.

Nota:

Scheduled work items such as task due date expirations are also picked up by the same timer mechanism. Therefore, they will be delayed by the same time interval.

The Workflow Timer service can be turned off on each server by using Shared Services Administration in Central Administration. By default, it will run on every front-end server in the farm. Each job will iterate through all the Web applications and content databases in the farm.

The combination of the postpone threshold, batch size, and timer frequency can be used to limit workflow operations against the database. Maximum throughput will be affected by how quickly operations get queued and processed from the queue.

For example, with the default settings, a single timer service, and a single content database, if there are 1,000 items in the queue, it will take ten timer job runs to execute them all, which will take 50 minutes to execute. However, if you set the batch size to 1,000 and set the timer job to run every minute, the operations would all begin execution after a minute. If you set the postpone threshold higher, more operations will run synchronously, reducing the number of requests that get queued and reducing the total time that is required to process those workflows.

422

Nota:

We recommend setting the postpone threshold no larger than 200, because concurrent workflow instances run in their own threads and will each open new SQL Server connections, potentially hitting the maximum connection limits on the database server over time.

If you do not want workflows running on front-end servers and know that operations do not have to occur immediately, you can isolate the Workflow Timer service to run on select application servers, set the postpone threshold to a very low number to force workflows to usually run in the timer service, and set the batch size large so that it receives items more quickly and frequently. If you want to make sure workflows run more synchronously across the system, set the postpone threshold larger so that workflows are not postponed often and have a more immediate effect.

Modify these settings to optimize for how you want workflows to operate. We recommend experimenting with different settings and testing them to optimize them for your environments and requirements.

Adjusting settings for queuing

If the farm will sustain heavy workflow load for long periods of time or there will be many delay events queued from workflows in the system, the number of queued workflow operations will grow. In addition to the basic queue settings, you may have to tune the following settings to keep the queue in good health:

Work Item Event Delivery Batchsize

The table that workflow uses for queued events is a general work item table that is shared with other non-workflow features in SharePoint Server 2010. Thus, there is another timer job that dequeues non-workflow work items. Similar to the workflow event delivery batch size, the work item event delivery batch size specifies the number of non-workflow work items that are dequeued at a time.

Workflow Failover Timer Job Frequency

In rare circumstances, if workflow events cannot be delivered to a workflow instance, the event delivery will be scheduled on the queue as a failover work item to be retried later (starting with 5 minutes later, and then 10 minutes if it fails again, and then 20 minutes, and so on). A workflow failover timer job dequeues failover work items, and this setting adjusts the frequency at which the failover timer will run. By default, this runs every 15 minutes.

Workflow Failover Batchsize

Similar to the workflow and work item batch size settings, this setting controls the number of failover events that each failover timer job will dequeue.

423

Because there are many timer jobs that operate on the same table, lots of queued items can cause database contention and reduce throughput and reliability. To reduce contention, we recommend the following:

Balance Postpone Threshold and Workflow Batchsize so that batch size is small enough or timer job frequency high enough that a

timer job can be completed before the next timer job starts in order to avoid building up too many parallel timer job runs that

cannot finish.

To avoid table locks, do not set either of the two batch size settings larger than 5,000.

Sugerencia:

Offset the frequency of the workflow, work item, and failover timer jobs so that they are not always executing at the same times. To get a large list that has workflows, four minutes for the workflow timer job and six minutes for the failover worked well in our data population scripts.

Improving scaling for task and history lists

Workflows generate many tasks and history items per instance. By default, these lists are indexed to help with scaling, but as these lists grow, performance will always decrease. To reduce the rate of the decrease, keep separate history and task lists for different workflow associations, and periodically change these lists in the workflow association settings as lists become large.

Workflow also has a daily timer job (job-workflow-autoclean) that will automatically delete workflow instances and tasks for instances that have been finished for more than 60 days. Leave this timer job on to keep the task lists and events on the task list as clean as possible. If data must be preserved, write the data to other lists or archive locations. Workflow history items are not deleted by this timer job. If you have to clean these up, this should be done with a script or manually through the list user interface.

Other considerations

Removing columns on lists causes a database operation proportional to the number of items in the list. Removing workflow associations will remove the workflow status column from the list. This causes a large operation on large lists. If you know that a list has millions of items, set the workflow to No New Instance instead of removing workflows.

424

Troubleshooting


Database contention (locks) Database locks prevent multiple users from making conflicting modifications to a set of data. When a set of data is locked by a user or process, no other user or process can change that same set of data until the first user or process is complete, changing the data and relinquishing the lock.

To help reduce the incidence of database locks, you can do the following:

Distribute workflows to more document libraries.

Scale up the database server.

Tune the database server hard disk for read/write.

Methods exist to circumvent the database locking system in SQL Server 2005, such as the NOLOCK parameter. However,

we do not recommend or support use of this method because of the possibility of data corruption.

Database server disk I/O When the number of I/O requests to a hard disk exceeds the disk's I/O capacity, the requests will be queued. As a result, the time to complete each request increases.

Distributing data files across multiple physical drives allows for parallel I/O. The blog SharePoint Disk Allocation and Disk I/O (http://go.microsoft.com/fwlink/?LinkId=129557) contains useful information about resolving disk I/O issues.

Web server CPU utilization When a Web server is overloaded with user requests, average CPU utilization will approach 100 percent. This prevents the Web server from responding to requests quickly and can cause timeouts and error messages on client 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.



425

Web servers

The following table shows performance counters and processes to monitor for Web servers in a farm.


Processor time Total Shows the percentage of elapsed time that this thread used the processor to execute instructions.

Memory utilization Application pool Shows the average utilization of system memory for the application pool. You must determine the correct application pool to monitor.

The basic guideline is to determine peak memory utilization for a given Web application, and assign that number plus 10 to the associated application pool.

Database servers

The following table shows performance counters and processes to monitor for database servers in your farm.


Average disk queue length Hard disk that contains SharedServices.mdf Average values larger than

426


1.5 per spindle indicate that the write times for that hard disk are insufficient.

Processor time SQL Server process Average values larger than 80 percent indicate that processor capacity on the database server is insufficient.

Processor time Total Shows the percentage of elapsed time that this thread used the processor to execute instructions.

Memory utilization Total Shows the average utilization of system memory.

Vea también Otros recursos

Workflow Scalability and Performance in Windows SharePoint Services 3.0 (http://go.microsoft.com/fwlink/?LinkId=207353)


427


En este artículo se describe cómo planear y configurar el almacenamiento y el nivel de base de datos de Microsoft SQL Server en un entorno de Microsoft SharePoint Server 2010.

La información acerca de la planeación de la capacidad que se incluye en este documento ofrece instrucciones para tener en cuenta durante la tarea de 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 que utilice y según las características y la funcionalidad que implemente en sus sitios.

Dado que SharePoint Server a menudo se ejecuta en entornos en los que las bases de datos se administran mediante administradores independientes de SQL Server, este documento está pensado tanto para implementadores de granja de servidores de SharePoint Server, como para administradores de bases de datos de SQL Server. Se le suponen unos amplios conocimientos acerca de SharePoint Server y SQL Server.

En este artículo se asume que está familiarizado con los conceptos presentados en Capacity management and sizing for SharePoint Server 2010 (en inglés).

Proceso de diseño y configuración del nivel de base de datos y almacenamiento de productos de SharePoint 2010 Se recomienda dividir el proceso de diseño de nivel de base de datos y almacenamiento en los siguientes pasos. Cada sección proporciona información detallada sobre cada paso de diseño, incluidos los requisitos de almacenamiento y los procedimientos recomendados:

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

428

Estimación de los requisitos de memoria

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

Recopilación de los requisitos de espacio y E/S para almacenamiento y SQL Server Varios factores de la arquitectura de SharePoint Server 2010 influyen en el diseño del almacenamiento. La cantidad de contenido, características y aplicaciones de servicio que se usan, el número de granjas de servidores y las necesidades de disponibilidad son factores clave.

Antes de empezar a planear el almacenamiento, debe conocer las bases de datos que SharePoint Server 2010 puede utilizar.

En esta sección:

Bases de datos que se usan en productos de SharePoint 2010

Descripción de SQL Server y las operaciones IOPS

Estimación de las necesidades de almacenamiento y de operaciones IOPS de la aplicación principal

Estimación de las necesidades de almacenamiento de aplicaciones de servicio y operaciones IOPS

Determinación de las necesidades de disponibilidad

Bases de datos que se usan en productos de SharePoint 2010

Las bases de datos que se instalan con SharePoint Server 2010 dependen de las características que se encuentran en uso en el entorno. Todos los entornos de Productos de SharePoint 2010 se basan en las bases de datos del sistema de SQL Server. En esta sección se proporciona un resumen de las bases de datos que se instalan con SharePoint Server 2010. Para obtener información más detallada, vea Database types and descriptions (SharePoint Server 2010) y el tema sobre el modelo de base de datos (http://go.microsoft.com/fwlink/?linkid=187968&clcid=0xC0A).

Versión y edición del producto Bases de datos

SharePoint Foundation 2010 Configuración

http://technet.microsoft.com/library/9b1e8b21-7675-4186-beb6-3adeef4360e6(Office.14).aspx


429


Contenido de Administración central

Contenido (uno o más)

Recolección de datos de mantenimiento y uso

Conectividad a datos empresariales

Servicio de registro de aplicaciones (si se actualiza desde el Catálogo de datos profesionales de Microsoft Office SharePoint Server 2007)

Servicio de configuración de suscripción (si se habilita mediante Windows PowerShell)

Bases de datos adicionales para SharePoint Server 2010 Standard Edition

Aplicación de servicio de búsqueda:

Administración de búsqueda

Rastreo (uno o más)

Propiedades (una o más)

Aplicación de servicio de perfiles de usuario:

Perfil

Sincronización

Etiquetas temáticas

Aplicación de servicio de Web Analytics

Almacenamiento provisional

Informes

Almacenamiento seguro

Estado

Metadados administrados

Servicios de automatización de Word

Bases de datos adicionales para SharePoint Server 2010 Enterprise PerformancePoint

430


Edition

Bases de datos adicionales para Project Server 2010 Borrador

Publicada

Archivar

Informes

Bases de datos adicionales para FAST Search Server Administración de búsqueda

Si realiza una integración más completa con SQL Server, su entorno podrá incluir bases adicionales, como en los siguientes escenarios:

Microsoft SQL Server 2008 R2 PowerPivot para Microsoft SharePoint 2010 se puede usar en un entorno de SharePoint Server 2010

que incluya SQL Server 2008 R2 Enterprise Edition y SQL Server Analysis Services. Si está en uso, también debe planear la

compatibilidad con la base de datos de la aplicación PowerPivot y la carga adicional en el sistema. Para obtener más información,

vea el tema sobre el planeamiento de la implementación de PowerPivot en una granja de servidores de SharePoint


El complemento Microsoft SQL Server 2008 Reporting Services (SSRS) puede usarse con todos los entornos de los productos de

SharePoint 2010. Si usa el complemento, planee la compatibilidad con las dos bases de datos de SQL Server 2008 Reporting

Services y la carga adicional que se necesita para SQL Server 2008 Reporting Services.

Descripción de SQL Server y las operaciones IOPS

En cualquier servidor que hospede SQL Server, es muy importante que el servidor logre la respuesta más rápida posible del subsistema de E/S.

Una mayor cantidad de matrices o discos más rápidos proporcionan suficientes operaciones de entrada y salida por segundo (IOPS) y a la vez se mantiene una baja latencia y puesta en cola en todos los discos.

La respuesta lenta del subsistema de E/S no puede compensarse con la adición de otros tipos de recursos, como CPU o memoria; no obstante, este tipo de respuesta puede influir y causar problemas en toda la granja de servidores. Planee una latencia mínima antes de la implementación y supervise los sistemas existentes.


431

Antes de implementar una nueva granja de servidores, se recomienda realizar una prueba comparativa del subsistema de E/S mediante la herramienta de pruebas comparativas del subsistema de disco SQLIO. Para obtener más información, vea el tema sobre la herramienta de pruebas comparativas del subsistema de disco SQLIO (http://go.microsoft.com/fwlink/?linkid=105586&clcid=0xC0A).

Para obtener más información acerca de la forma de analizar los requisitos de las operaciones IOPS desde una perspectiva de SQL Server, vea el tema sobre el análisis de las características de E/S y determinación del tamaño de los sistemas de almacenamiento para aplicaciones de bases de datos de SQL Server (http://sqlcat.com/whitepapers/archive/2010/05/10/analyzing-i-o-characteristics-and-sizing-storage-systems-for-sql-server-database-applications.aspx).

Estimación de las necesidades de almacenamiento y de operaciones IOPS de la aplicación principal

La configuración y el almacenamiento de contenido, así como las operaciones IOPS, constituyen la capa base que debe planear en toda implementación de SharePoint Server 2010.

Almacenamiento de configuración y operaciones IOPS

No son muchos los requisitos de almacenamiento para la base de datos de configuración y la base de datos de contenido de Administración central. Se recomienda asignar 2 GB para la base de datos de configuración y 1 GB para la base de datos de contenido de Administración central. Con el tiempo, la base de datos de configuración puede crecer más de 1 GB, pero no lo hace rápidamente, aumenta alrededor de 40 MB por cada 50.000 colecciones de sitios.

Los registros de transacciones de la base de datos de configuración pueden ser grandes; por lo tanto, se recomienda cambiar el modelo de recuperación de la base de datos, de completa a simple.

Nota:

Si desea usar la creación de reflejo de la base de datos de SQL Server para proporcionar disponibilidad para la base de datos de configuración, debe usar el modelo de recuperación completa.

Son mínimos los requisitos de las operaciones IOPS para la base de datos de configuración y la base de datos de contenido de Administración central.

Almacenamiento de contenido y operaciones IOPS

Estimar el almacenamiento y las operaciones IOPS necesarias para las bases de datos de contenido no es una actividad de precisión. Las pruebas y las explicaciones de la siguiente información están pensadas para ayudarle a calcular las estimaciones que luego usará para determinar el tamaño inicial de su implementación. No obstante, cuando el entorno esté en ejecución, deberá revisar las necesidades de capacidad en función de los datos obtenidos en el entorno activo.


http://sqlcat.com/whitepapers/archive/2010/05/10/analyzing-i-o-characteristics-and-sizing-storage-systems-for-sql-server-database-applications.aspx

http://sqlcat.com/whitepapers/archive/2010/05/10/analyzing-i-o-characteristics-and-sizing-storage-systems-for-sql-server-database-applications.aspx

432

Para obtener más información acerca de nuestra metodología de planificación de la capacidad total, vea Capacity management and sizing for SharePoint Server 2010 (en inglés).

Estimación del almacenamiento de bases de datos de contenido

El siguiente proceso describe cómo estimar aproximadamente el almacenamiento necesario para las bases de datos de contenido, sin tener en cuenta los archivos de registro:

1. Calcule el número esperado de documentos. Este valor se denomina D en la fórmula.

La forma de calcular el número de documentos estará determinada por las características que se usen. Por ejemplo, para sitios web de Mi sitio o sitios de colaboración, se recomienda calcular el número esperado de documentos por usuario y multiplicarlo por el número de usuarios. Para la administración de registros o sitios de publicación de contenido, se puede calcular el número de documentos administrados y generados por un proceso.

Si va a migrar desde un sistema actual, puede que sea más fácil extrapolar la tasa de crecimiento actual y el uso. Si va a crear un nuevo sistema, revise los recursos compartidos de archivos existentes u otros repositorios y realice la estimación en función de esa tasa de uso.

2. Estime el tamaño promedio de los documentos que va a almacenar. Este valor se denomina S en la fórmula. Puede ser útil estimar

los promedios de distintos tipos o grupos de sitios. El tamaño promedio de archivo de los sitios web de Mi sitio, de los repositorios de

medios y los portales de los distintos departamentos puede variar considerablemente.

3. Estime el número de elementos de lista en el entorno. Este valor se denomina L en la fórmula.

Es más difícil estimar los elementos de lista que los documentos. Normalmente, se usa una estimación de tres veces el número de documentos (D), pero esto variará en función de cómo piensa usar los sitios.

4. Determine el número aproximado de versiones. Estime el número promedio de versiones que tendrá cualquier documento de una

biblioteca (por lo general, este valor será mucho menor que el número máximo de versiones permitido). Este valor se denomina V en

la fórmula.

El valor de V debe ser superior a cero.

5. Utilice la siguiente fórmula para calcular el tamaño de las bases de datos de contenido:

Tamaño de base de datos = ((D × V) × S) + (10 KB × (L + (V × D)))

El valor de 10 KB en la fórmula es una constante que estima la cantidad aproximada de metadatos requeridos por SharePoint Server 2010. Si el sistema requiere un uso importante de metadatos, quizás desee incrementar esta constante.

Por ejemplo, si desea utilizar la fórmula para calcular la cantidad de espacio de almacenamiento necesario para los archivos de datos de una base de datos de contenido en un entorno de colaboración con las siguientes características, necesitará aproximadamente 105 GB.

433

Entrada Valor

Número de documentos (D) 200.000

Calculado suponiendo 10.000 usuarios multiplicado por 20 documentos

Tamaño promedio de documentos (S) 250 KB

Elementos de lista (L) 600.000

Número de versiones no actuales (V) 2

Suponiendo que el número máximo de versiones es 10

Tamaño de base de datos = (((200.000 x 2)) × 250) + ((10 KB × (600.000 + (200.000 x 2))) = 110.000.000 KB o 105 GB

Características que influyen en el tamaño de las bases de datos de contenido

El uso de las siguientes características de SharePoint Server 2010 puede afectar significativamente el tamaño de las bases de datos de contenido:

Papeleras de reciclaje Hasta que un documento no se elimine completamente de la papelera de reciclaje, tanto de la primera como

de la segunda etapa, ocupa espacio en una base de datos de contenido. Calcule cuántos documentos se eliminan por mes para

determinar el efecto que tienen las papeleras de reciclaje en el tamaño de las bases de datos de contenido. Para obtener más

información, vea Configure Recycle Bin settings (SharePoint Server 2010).

Auditoría Los datos de auditoría pueden aumentar rápidamente y usar grandes cantidades de espacio en una base de datos de

contenido, especialmente si se activa la vista de auditoría. En lugar de permitir que los datos de auditoría crezcan sin restricciones,

se recomienda que solo habilite la auditoría en eventos importantes para satisfacer las necesidades reglamentarias o realizar

controles internos. Use las instrucciones siguientes para calcular el espacio que necesitará reservar para la auditoría de datos:

Estime el número de nuevas entradas de auditoría para un sitio y multiplique ese número por 2 KB (por lo general, las entradas

se limitan a 4 KB, con un tamaño promedio de alrededor de 1 KB).

En función del espacio que desee asignar, determine el número de días de los registros de auditoría que desea conservar.

http://technet.microsoft.com/library/abcf2ba8-86f6-4116-8461-b3e5fc6fedfb(Office.14).aspx

434

Office Web Apps. Si se usa Office Web Apps, la memoria caché de Office Web Apps puede afectar considerablemente el tamaño de

una base de datos de contenido. De manera predeterminada, la memoria caché de Office Web Apps se configura en 100 GB. Para

obtener más información acerca el tamaño de la memoria caché de Office Web Apps, vea Manage the Office Web Apps cache.

Estimación de los requisitos de operaciones de IOPS para bases de datos de contenido

Los requisitos de IOPS para bases de datos de contenido varían considerablemente en función de la forma en que se usa el entorno, el espacio disponible en disco y el número de servidores que existen. En general, se recomienda que compare la carga de trabajo prevista en el entorno con una de las soluciones que se han probado. Para obtener más información, vea Recomendaciones y resultados de pruebas de rendimiento y capacidad (SharePoint Server 2010).

Importante:

Las pruebas para el contenido de esta sección aún no se han completado. Vuelva a consultar para obtener más información.

Estimación de las necesidades de almacenamiento de aplicaciones de servicio y operaciones IOPS

Después de calcular la necesidades de almacenamiento de contenido y operaciones IOPS, a continuación, debe determinar el almacenamiento y las operaciones IOPS que se necesitan para las aplicaciones de servicio que se usan en el entorno.

Requisitos de almacenamiento y de operaciones IOPS de las aplicaciones de servicio de SharePoint Foundation 2010

Para calcular los requisitos de almacenamiento para las aplicaciones de servicio del sistema, deberá, en primer lugar, conocer las aplicaciones de servicio y discernir cómo las usará. Las aplicaciones de servicio disponibles en SharePoint Foundation 2010 que tienen bases de datos se enumeran en la siguiente tabla.

Base de datos de la aplicación de servicio Recomendación de cálculo de tamaño

Recolección de datos de mantenimiento y uso La base de datos de uso puede crecer rápidamente y con ella, los requisitos de IOPS.

Por ejemplo, en entornos de colaboración que usan la configuración

de fábrica, 1 millón de solicitudes HTTP necesitan 2 GB de

almacenamiento.

http://technet.microsoft.com/library/9a75a461-6c86-4b61-be98-bcaf9290f2da(Office.14).aspx

435

Base de datos de la aplicación de servicio Recomendación de cálculo de tamaño

Use una de las siguientes fórmulas para estimar la cantidad requerida de operaciones IOPS:

115 × visitas a la página/segundo

5 × solicitudes HTTP

Si debe restringir el tamaño de la base de datos de uso, se recomienda que comience por registrar únicamente las solicitudes de página. También puede restringir el tamaño de la base de datos configurando el intervalo predeterminado de los datos que se van a conservar para que sea inferior a las dos semanas.

Si es posible, coloque la base de datos de uso en su propio disco o cilindro.

Servicio Conectividad a datos empresariales El tamaño de la base de datos de los servicios de Conectividad a datos empresariales se ve afectada principalmente por el número de

tipos de contenido externo que planea admitir. Asigne 0,5 MB para

cada tipo de contenido externo. Si no sabe cuántos tipos de

contenido externo podría necesitar, se recomienda asignar 50 MB.

Los requisitos de IOPS son mínimos.

Servicio de registro de aplicaciones Asigne 1 GB únicamente si va a actualizar a partir del catálogo de

datos profesionales de Microsoft Office SharePoint Server 2007. Los requisitos de IOPS son mínimos.

Configuración de suscripción Asigne 1 GB. Los requisitos de IOPS son mínimos.

Requisitos de almacenamiento y de operaciones IOPS de las aplicaciones de servicio de SharePoint Server 2010

Para calcular los requisitos de almacenamiento para las aplicaciones de servicio del sistema, deberá, en primer lugar, conocer las aplicaciones de servicio y discernir cómo las usará. Las aplicaciones de servicio disponibles en SharePoint Server 2010 que tienen bases de datos se enumeran en la siguiente tabla.

436

Aplicación de servicio Recomendación de cálculo de tamaño

Búsqueda La búsqueda requiere tres bases de datos. El entorno podría incluir varias bases de datos de rastreo y propiedades.

La base de datos de administración de búsqueda normalmente es pequeña: asigne 10 GB.

Para estimar el almacenamiento necesario para las bases de datos de rastreo y propiedades, use los siguientes multiplicadores:

Rastreo: 0,046 x (suma de las bases de datos de contenido)

Propiedad: 0,015 x (suma de las bases de datos de contenido)

Los requisitos de IOPS para la búsqueda son importantes.

Para la base de datos de rastreo, la búsqueda requiere de 3.500

a 7.000 IOPS.

Para la base de datos de propiedades, la búsqueda requiere

2.000 IOPS.

Para obtener información detallada acerca de cómo calcular la capacidad necesaria para realizar búsquedas, vea Recomendaciones y resultados de pruebas de rendimiento y capacidad (SharePoint Server 2010).

Perfil de usuario La aplicación de servicio de perfiles de usuario está asociada con las bases de datos de perfiles, de sincronización y de etiquetas temáticas.

Para calcular el almacenamiento necesario para las bases de datos, use la siguiente información:

Perfiles. Con la configuración de fábrica, en un entorno

configurado para usar Active Directory, la base de datos de

perfil requiere aproximadamente 1 MB por cada perfil de

usuario.

437


Sincronización. Con la configuración de fábrica, en un entorno

con pocos grupos por usuario, la base de datos de

sincronización requiere aproximadamente 630 KB por cada

perfil de usuario. El archivo de datos ocupará el 90% del

espacio.

Etiquetas temáticas. Con la configuración de fábrica, la base de

datos de etiquetas temáticas requiere aproximadamente 0,009

MB por cada etiqueta, comentario o clasificación. Para calcular

el número de etiquetas y notas que los usuarios crearán, tenga

en cuenta la siguiente información acerca del sitio del.icio.us:

Aproximadamente el 10% de los usuarios se considera

activo.

Los usuarios activos crean 4,5 etiquetas y 1,8 comentarios

por mes.

En un entorno de colaboración en directo con 160.000 perfiles de usuario, 5 grupos, 79.000 etiquetas, comentarios y clasificaciones (2.500 comentarios, 76.000 etiquetas y 800 clasificaciones), y configuración de fábrica, se han visto los siguientes tamaños para estas bases de datos:

Nombre de la base de datos Tamaño de la base de datos

Perfiles 155 Gigabytes (GB)

Sincronización 96 Gigabytes (GB)

Etiquetas temáticas 0,66 Gigabytes (GB)

Metadatos administrados La aplicación de servicio de metadatos administrados tiene una sola

438


base de datos. El tamaño de la base de datos se ve afectado por el número de tipos de contenido y palabras clave utilizados en el sistema. Muchos entornos incluirán varias instancias de la aplicación de servicio de metadatos administrados. Para obtener más información acerca de cómo calcular el tamaño y los requisitos de IOPS para esta base de datos, vea Recomendaciones y resultados de pruebas de rendimiento y capacidad (SharePoint Server 2010).

Web Analytics Web Analytics tiene dos bases de datos: provisional y de informes. Son muchos los factores que influyen en el tamaño de las bases de datos; entre ellos, el período de retención, el volumen diario de datos con seguimiento y la cantidad de colecciones de sitios, sitios y subsitios de la aplicación web que se va a analizar. Para obtener más información acerca de cómo calcular el tamaño y los requisitos de IOPS, vea Recomendaciones y resultados de pruebas de rendimiento y capacidad (SharePoint Server 2010).

Almacenamiento seguro El tamaño de la base de datos de la aplicación de servicio de almacenamiento seguro está determinado por el número de credenciales en el almacén y el número de entradas en la tabla de

auditoría. Se recomienda asignar 5 MB para cada 1.000

credenciales para la base de datos. Los requisitos de IOPS son mínimos.

Estado La aplicación de servicio de estado tiene una sola base de datos. Se recomienda asignar 1 GB para la base de datos. Los requisitos de

IOPS son mínimos.

Servicio de automatización de Word La aplicación de servicio de automatización de Word tiene una sola

base de datos. Se recomienda asignar 1 GB para la base de datos.

Los requisitos de IOPS son mínimos.

439


PerformancePoint La aplicación de servicio de PerformancePoint tiene una sola base

de datos. Se recomienda asignar 1 GB para la base de datos. Los

requisitos de IOPS son mínimos.

Determinación de las necesidades de disponibilidad

La disponibilidad es el grado en el que los usuarios perciben que un entorno de SharePoint Server 2010 está disponible. Un sistema disponible es un sistema que es resistente (es decir, los incidentes que afectan al servicio no son frecuentes y, cuando suceden, se buscan soluciones a tiempo y efectivas).

Los requisitos de disponibilidad pueden aumentar significativamente las necesidades de almacenamiento. Para obtener información detallada, vea Plan for availability (SharePoint Server 2010).

Elección de la versión y edición de SQL Server Aunque Productos de SharePoint 2010 se puede ejecutar en Microsoft SQL Server 2008 R2, SQL Server 2008 o SQL Server 2005, es muy recomendable considerar la posibilidad de que el entorno se ejecute en la edición Enterprise de SQL Server 2008 o SQL Server 2008 R2 para aprovechar las capacidades adicionales de rendimiento, disponibilidad, seguridad y administración que proporciona. Para obtener más información acerca de las ventajas de utilizar SQL Server 2008 R2 Enterprise Edition, vea SQL Server 2008 R2 and SharePoint Products 2010: Better Together (White paper) (SharePoint Server 2010).

En concreto, debe tener en cuenta la necesidad de las siguientes características:

Compresión de copia de seguridad La compresión de copia de seguridad puede acelerar cualquier copia de seguridad de

SharePoint y está disponible en SQL Server 2008 Enterprise Edition o SQL Server 2008 R2 Standard Edition. Si se configura la

opción de compresión en el script de copia de seguridad o si se configura el servidor que ejecuta SQL Server para comprimir de

manera predeterminada, se puede reducir significativamente el tamaño de las copias de seguridad de bases de datos y registros de

envío. Para obtener más información, vea el tema sobre compresión de copia de seguridad (SQL Server)


http://technet.microsoft.com/library/04812402-43d6-4605-960c-1dd5ec65bef1(Office.14).aspx

http://technet.microsoft.com/library/665876e1-2706-42ad-bd76-8e4d1da0ce92(Office.14).aspx

http://technet.microsoft.com/library/665876e1-2706-42ad-bd76-8e4d1da0ce92(Office.14).aspx


440

Nota:

La compresión de datos de SQL Server no es compatible con Productos de SharePoint 2010.

Cifrado de datos transparente Si los requisitos de seguridad incluyen la necesidad de cifrado de datos transparente, se debe usar

SQL Server Enterprise Edition.

Aplicación de servicio de Web Analytics Si va a utilizar la aplicación de servicio de Web Analytics para realizar un análisis

significativo, considere la posibilidad de usar SQL Server Enterprise Edition, de modo tal que el sistema pueda aprovechar las

ventajas de la partición de tabla.

Distribución de contenido Si va a utilizar la característica de distribución de contenido, considere la posibilidad de usar SQL Server

Enterprise Edition, de modo que el sistema pueda aprovechar las instantáneas de base de datos de SQL Server.

Almacenamiento remoto de blobs Si desea aprovechar las ventajas del almacenamiento remoto de blobs en una base de datos o

ubicación fuera de los archivos asociados con cada base de datos de contenido, debe usar SQL Server 2008 o SQL Server 2008 R2

Enterprise Edition.

Regulador de recursos El regulador de recursos es una tecnología que se incluyó por primera vez en SQL Server 2008 y que

permite administrar los recursos y las cargas de trabajo de SQL Server, especificando los límites en el consumo de recursos para las

solicitudes entrantes. El regulador de recursos permite diferenciar las cargas de trabajo y asignar la CPU y memoria que se solicitan,

según los límites especificados. Está disponible solo en SQL Server 2008 o SQL Server 2008 R2 Enterprise Edition. Para obtener

más información acerca de cómo usar el regulador de recursos, vea el tema sobre la administración de cargas de trabajo de SQL

Server con el regulador de recursos.

Se recomienda usar el regulador de recursos con SharePoint Server 2010 para llevar a cabo las siguientes tareas:

Limitar la cantidad de recursos de SQL Server que consumen los servidores web de destino mediante el componente de rastreo

de búsqueda. Como procedimiento recomendado, limite el componente de rastreo al 10 por ciento de CPU cuando el sistema

esté bajo carga.

Supervisar la cantidad de recursos consumida por cada base de datos en el sistema; por ejemplo, puede utilizar el regulador de

recursos para ayudarle a determinar la mejor ubicación de las bases de datos entre equipos que ejecutan SQL Server.

PowerPivot para SharePoint 2010 Permite a los usuarios compartir y colaborar en los modelos de datos generados por el

usuario y el análisis en Excel y en el explorador mientras se actualiza automáticamente esos análisis. Forma parte de Analysis

Services de SQL Server 2008 R2 Enterprise Edition.

http://msdn.microsoft.com/es-es/library/bb933866.aspx

http://msdn.microsoft.com/es-es/library/bb933866.aspx

441

Diseño de la arquitectura de almacenamiento en función de la capacidad y los requisitos de E/S Los tipos de disco y la arquitectura de almacenamiento que seleccione para su entorno podrán afectar al rendimiento del sistema.

En esta sección:

Elección de una arquitectura de almacenamiento

Elección de tipos de disco

Elección de tipos de RAID

Elección de una arquitectura de almacenamiento

Las arquitecturas de almacenamiento directo (DAS), red de área de almacenamiento (SAN) o almacenamiento conectado a la red (NAS) son compatibles con SharePoint Server 2010, aunque NAS se admite únicamente con bases de datos de contenido configuradas para usar almacenamiento remoto de blobs. La elección depende de factores de la solución de negocio y de la infraestructura existente.

Cualquier arquitectura de almacenamiento debe admitir las necesidades de disponibilidad y tener un rendimiento adecuado con respecto a IOPS y latencia. Para que sea compatible, el sistema siempre debe devolver el primer byte de datos dentro de los 20 milisegundos (ms).

Almacenamiento directo (DAS)

DAS es un sistema de almacenamiento digital que está conectado directamente a un servidor o estación de trabajo, sin una red de almacenamiento intermedia. Los tipos de disco físico de DAS incluyen Serial Attached SCSI (SAS) y Serial Attached ATA (SATA).

En general, se recomienda que elija una arquitectura DAS cuando una plataforma de almacenamiento compartido no pueda garantizar un tiempo de respuesta de 20 ms y una capacidad suficiente para el promedio y máximo de IOPS.

Red de área de almacenamiento (SAN)

SAN es una arquitectura de conexión de dispositivos de almacenamiento de equipos remotos (como matrices de discos o bibliotecas de cintas) con servidores, de modo que los dispositivos aparezcan localmente conectados al sistema operativo (por ejemplo, almacenamiento de bloques).

En general, se recomienda que elija una SAN si las ventajas del almacenamiento compartido son importantes para su organización.

Las ventajas del almacenamiento compartido son:

Es más fácil reasignar el almacenamiento en disco entre los servidores.

Puede dar servicio a varios servidores.

442

No hay limitación en la cantidad de discos a los que se puede tener acceso.

Almacenamiento conectado a la red (NAS)

Una unidad NAS es un equipo independiente que está conectado a una red. Su único propósito es proporcionar servicios de almacenamiento de datos de archivo a otros dispositivos de la red. El sistema operativo y otro software de la unidad NAS proporcionan la funcionalidad de almacenamiento de datos, sistemas de archivos y acceso a archivos, así como la administración de estas funcionalidades (por ejemplo, el almacenamiento de archivos).

Nota:

NAS solo es compatible con bases de datos de contenido configuradas para usar el almacenamiento remoto de blobs. Cualquier

arquitectura de almacenamiento de red debe responder a un ping en menos de 1 ms y debe devolver el primer byte en menos de 20 ms.

Esta restricción no se aplica al proveedor local de FILESTREAM de SQL Server porque éste solo almacena datos localmente en el mismo servidor.

Elección de tipos de disco

Los tipos de disco que se utilizan en el sistema pueden afectar al rendimiento y la confiabilidad. Siendo todo lo demás igual, unidades más grandes aumentan la media del tiempo de búsqueda. SharePoint Server 2010 admite los siguientes tipos de unidades:

Interfaz estándar de equipos pequeños (SCSI)

Serial Advanced Technology Attachment (SATA)

SCSI conectados en serie (SAS)

Canal de fibra (FC)

Electrónica integrada de dispositivos (IDE)

Unidad de estado sólido (SSD) o disco Flash

Elección de tipos de RAID

RAID (matriz redundante de discos independientes) a menudo se utiliza para mejorar las características de rendimiento de los discos individuales (mediante la selección de datos de varios discos) y para proporcionar protección frente a errores de discos individuales.

Todos los tipos de RAID son compatibles con SharePoint Server 2010; no obstante, se recomienda usar RAID 10 o una solución RAID específica del proveedor con rendimiento equivalente.

443

Cuando configure una matriz RAID, asegúrese de alinear el sistema de archivos con el desplazamiento proporcionado por el proveedor. Si no puede obtener información del proveedor, vea el tema sobre los procedimientos recomendados de entrada y salida antes de la implementación de SQL Server (http://go.microsoft.com/fwlink/?linkid=105583&clcid=0xC0A).

Para obtener más información acerca del aprovisionamiento de RAID y el subsistema de entrada y salida de SQL Server, vea el artículo sobre los procedimientos recomendados de SQL Server (http://go.microsoft.com/fwlink/?linkid=168612&clcid=0xC0A).

Estimación de los requisitos de memoria La memoria necesaria para SharePoint Server 2010 está directamente relacionada con el tamaño de las bases de datos de contenido que se hospedan en un servidor que ejecuta SQL Server.

A medida que agrega aplicaciones de servicio y características, es probable que los requisitos aumenten. La siguiente tabla proporciona instrucciones sobre la cantidad de memoria recomendada.

Nota:

Nuestras definiciones de implementaciones pequeñas y medianas se describen en la sección "Arquitecturas de referencia" del artículo Capacity management and sizing for SharePoint Server 2010 (en inglés).

Tamaño combinado de bases de datos de contenido RAM recomendado para el equipo que ejecuta SQL Server

Mínimo para implementaciones pequeñas de producción 8 Gigabytes (GB)

Mínimo para implementaciones medianas de producción 16 Gigabytes (GB)

Recomendación de hasta 2 terabytes 32 Gigabytes (GB)

Recomendación para el intervalo de 2 terabytes a un máximo de 5 terabytes

64 Gigabytes (GB)





444

Nota:

Estos valores son superiores a los que se recomiendan como valores mínimos para SQL Server debido a la distribución de datos necesaria para un entorno de SharePoint Server 2010. Para obtener más información acerca de los requisitos del sistema de SQL Server, vea el tema acerca de los requisitos de hardware y software para instalar SQL Server 2008 (http://go.microsoft.com/fwlink/?linkid=129377&clcid=0xC0A).

Entre otros factores que pueden influir en la memoria necesaria se incluyen los siguientes:

El uso de la creación de reflejo de SQL Server.

El uso frecuente de archivos de más de 15 megabytes (MB).

Descripción de los requisitos de la topología de red Planee las conexiones de red dentro y entre granjas de servidores. Se recomienda usar una red que tenga una latencia baja.

En la siguiente lista se proporcionan algunos procedimientos recomendados y sugerencias:

Todos los servidores de la granja de servidores deben tener el ancho de banda de LAN y la latencia para el servidor que ejecuta SQL

Server. La latencia no debe ser superior a 1 ms.

No se recomienda una topología de red de área extensa (WAN) en la que un servidor que ejecuta SQL Server se implementa

remotamente desde otros componentes de la granja de servidores a través de una red que tiene una latencia mayor que 1 ms. Esta

topología no se ha probado.

Planee una red WAN adecuada si tiene pensado usar el trasvase de registros o la creación de reflejo de SQL Server para mantener

un sitio remoto actualizado.

Se recomienda que los servidores web y los servidores de aplicaciones tengan dos adaptadores de red: un adaptador de red para

controlar el tráfico de usuario final y el otro para controlar la comunicación con los servidores que ejecutan SQL Server.

Configuración de SQL Server Las secciones siguientes describen cómo planear la configuración de SQL Server para SharePoint Server 2010.


445

En esta sección:

Determinación de la cantidad de instancias o servidores necesarios

Configuración de almacenamiento y memoria

Establecimiento de opciones de SQL Server

Configuración de bases de datos

Estimación de la cantidad de servidores necesarios

En general, SharePoint Server 2010 se ha diseñado para aprovechar las ventajas del escalado horizontal de SQL Server, es decir, SharePoint Server 2010 tendrá un mejor rendimiento con un gran número de servidores medianos que ejecutan SQL Server que con solo unos pocos servidores grandes.

Coloque siempre SQL Server en un servidor dedicado que no esté ejecutando ningún otro rol de granja de servidores ni que hospede bases de datos de cualquier otra aplicación, a menos que vaya a implementar el sistema en un servidor independiente.

A continuación se brinda una guía general sobre cuándo implementar un servidor adicional que ejecutará SQL Server:

Agregue un servidor de base de datos adicional si tiene más de cuatro servidores web que se ejecutan con plena capacidad.

Agregue un servidor de base de datos adicional cuando las bases de datos de contenido superan los 5 terabytes.

Nota:

Microsoft admite configuraciones de servidores que no siguen esta guía.

Para promover el almacenamiento seguro de credenciales cuando se ejecuta la aplicación del servicio de almacenamiento seguro, se recomienda que la base de datos de almacenamiento seguro se hospede en una instancia independiente de la base de datos donde el acceso esté limitado a un solo administrador.

Configuración de almacenamiento y memoria

En el servidor que ejecuta SQL Server 2008, se recomienda que la memoria caché de nivel 2 por cada CPU tenga un mínimo de 2 MB para mejorar la memoria.

http://technet.microsoft.com/library/3d7496d6-1a0b-4efd-bfe4-6e15c98ea932(Office.14).aspx#Section6_1




446

Siga las recomendaciones de configuración de almacenamiento del proveedor

Para obtener un rendimiento óptimo cuando se configura una matriz de almacenamiento físico, siga las recomendaciones de configuración de hardware suministradas por el proveedor de almacenamiento en lugar de depender de los valores predeterminados del sistema operativo.

En caso de no contar con información guía del proveedor, se recomienda configurar el almacenamiento para SQL Server 2008 mediante la utilidad de configuración de disco DiskPart.exe. Para obtener más información, vea el tema sobre los procedimientos recomendados de entrada y salida antes de la implementación (http://go.microsoft.com/fwlink/?linkid=105583&clcid=0xC0A).

Suministre la mayor cantidad de recursos posibles

Asegúrese de que los canales de entrada y salida de SQL Server a los discos no estén compartidos con otras aplicaciones, como el archivo de paginación y los registros de Internet Information Services (IIS).

Proporcione el mayor ancho de banda de bus posible. Un mayor ancho de banda de bus ayuda a mejorar la confiabilidad y el rendimiento. Tenga en cuenta que el disco no es el único usuario de ancho de banda de bus, por ejemplo, también debe tener en cuenta el acceso a la red.

Establecimiento de opciones de SQL Server

Es necesario configurar los siguientes parámetros y opciones de SQL Server antes de implementar SharePoint Server.

No habilite la creación automática de estadísticas en un sistema SQL Server que admite SharePoint Server. SharePoint Server

implementa estadísticas específicas y no se necesitan estadísticas adicionales. La creación automática de estadísticas puede

cambiar considerablemente el plan de ejecución de una consulta, de una instancia de SQL Server a otra instancia de SQL Server.

Por lo tanto, para suministrar soporte coherente para todos los clientes, SharePoint Server proporciona el código de las sugerencias

para las consultas según sea necesario para proporcionar el mejor rendimiento a través de todos los escenarios.

Para asegurar un óptimo rendimiento, se recomienda fehacientemente establecer el grado máximo de paralelismo en 1 para

servidores de bases de datos que hospedan bases de datos de SharePoint Server 2010. Para obtener más información acerca de

cómo establecer el grado máximo de paralelismo, vea el tema sobre la opción max degree of parallelism


Para facilitar el mantenimiento, configure los alias de conexión de SQL Server para cada servidor de base de datos en su granja de

servidores. Un alias de conexión es un nombre alternativo que puede usarse para conectarse a una instancia de SQL Server. Para

obtener más información, vea el tema sobre el procedimiento para establecer un alias de SQL Server (SQL Server Management

Studio) (http://go.microsoft.com/fwlink/?linkid=132064&clcid=0xC0A).





447

Configuración de bases de datos

Las instrucciones siguientes describen los procedimientos recomendados para planear mientras se configura cada base de datos en el entorno.

Separación y asignación de prioridades a los datos en los discos

Lo ideal es colocar la base de datos tempdb, las bases de datos de contenido, la base de datos de uso, las bases de datos de búsqueda y los registros de transacciones de SQL Server 2008 en discos duros físicos independientes.

En la siguiente lista se ofrecen algunos procedimientos recomendados y sugerencias para asignar prioridades a los datos:

Cuando asigne prioridades a los datos en discos más rápidos, use la siguiente clasificación:

1. Archivos de datos tempdb y registros de transacciones

2. Archivos de registro de transacciones de bases de datos

3. Bases de datos de búsqueda, excepto la base de datos de administración de búsqueda

4. Archivos de datos de las bases de datos

En un sitio del portal orientado principalmente a la lectura, asigne prioridad a los datos frente a los registros.

Las pruebas y los datos de los clientes han mostrado que el rendimiento de la granja de servidores de SharePoint Server 2010 se

puede dificultar de forma significativa por una E/S de disco insuficiente para tempdb. Para evitar este problema, asigne discos

dedicados para tempdb. Si se proyecta o supervisa una carga de trabajo alta, es decir, la operación de lectura media o la operación

de escritura media requieren más de 20 milisegundos (ms), es posible que deba quitar el cuello de botella separando los archivos en

los discos o reemplazando los discos por discos más rápidos.

Para obtener un mejor rendimiento, coloque tempdb en una matriz RAID 10. La cantidad de archivos de datos de tempdb debe ser

igual a la cantidad de CPU de núcleo y los archivos de datos de tempdb se deben establecer en el mismo tamaño. Para ello, cuente

los procesadores de doble núcleo como dos CPU. Cuente cada procesador compatible con la tecnología Hyper-Threading como una

única CPU. Para obtener más información, vea el tema en el que se explica cómo optimizar el rendimiento de tempdb


Separe los datos de la base de datos y los archivos de registro de transacciones en diferentes discos. Si los archivos deben compartir

discos porque son demasiado pequeños para aprovechar un disco completo o una banda, o bien no dispone de espacio en el disco,

coloque los archivos que tengan patrones de uso diferentes en el mismo disco para minimizar las solicitudes de acceso simultáneas.

Consulte al proveedor de hardware de almacenamiento acerca de cómo configurar todos los registros y las bases de datos de

búsqueda para optimizar la escritura en su solución de almacenamiento particular.


448

Uso de varios archivos de datos para bases de datos de contenido

Siga estas recomendaciones para obtener el mejor rendimiento:

Cree archivos únicamente en el grupo de archivos principal de la base de datos.

Distribuya los archivos en discos independientes.

El número de archivos de datos debe ser menor o igual que el número de CPU de núcleo. Con este fin, cuente los procesadores de

doble núcleo como dos CPU. Cuente cada procesador compatible con la tecnología Hyper-Threading como una única CPU.

Cree archivos de datos que tengan el mismo tamaño.

Importante:

Aunque las herramientas de copia de seguridad y recuperación integradas en SharePoint Server 2010 se pueden usar para realizar copias de seguridad de varios archivos de datos y recuperarlos, si sobrescribe en la misma ubicación, las herramientas no podrán restaurar varios archivos de datos en una ubicación diferente. Por este motivo, se recomienda que al usar varios archivos de datos para una base de datos de contenido, use las herramientas de copia de seguridad y recuperación de SQL Server. Para obtener más información acerca de cómo realizar copias de seguridad y recuperación de SharePoint Server 2010, vea Plan for backup and recovery (SharePoint Server 2010).

Para obtener más información acerca de la creación y administración de grupos de archivos, vea el tema sobre grupos de archivos y archivos de bases de datos físicas (http://go.microsoft.com/fwlink/?linkid=117909&clcid=0xC0A).

Limitación del tamaño de la base de datos de contenido para mejorar la facilidad de administración

Considere un tamaño de base de datos que permita mejorar la administración, el rendimiento y la actualización del entorno.

Para ayudar a garantizar el rendimiento del sistema, es muy recomendable limitar el tamaño de las bases de datos de contenido a 200 GB.

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. Este límite existe para que se puedan utilizar las herramientas de copia de seguridad pormenorizada de SharePoint Server 2010 para mover una colección de sitios a otra base de datos, si es necesario.

http://technet.microsoft.com/library/01abe8d2-33f8-48fe-af76-40522a5afe08(Office.14).aspx

http://technet.microsoft.com/library/01abe8d2-33f8-48fe-af76-40522a5afe08(Office.14).aspx



449

Importante:

Los tamaños de bases de datos de contenido de hasta 1 terabyte se admiten solo para repositorios grandes de único sitio y archivos en

los que los datos se mantienen relativamente estáticos, como sistemas de administración de documentos de referencia y sitios del centro de registros. Los tamaños más grandes de bases de datos se admiten para estos escenarios porque los patrones de E/S y los formatos habituales de estructura de datos han sido diseñados y probados para escalas de mayor tamaño.

Si el diseño requiere una base de datos más grande que el estándar recomendado, siga estas instrucciones:

Para las bases de datos que contienen muchos archivos de gran tamaño que se almacenan como objetos binarios grandes (BLOB),

considere la posibilidad de usar el almacenamiento remoto de blobs (RBS). RBS es adecuado en las siguientes circunstancias:

1. Cuando trabaja con sitios que contienen archivos grandes a los que se tiene acceso con escasa frecuencia, como repositorios de

conocimiento.

2. Cuando tenga terabytes de datos.

3. Para archivos de vídeo o multimedia.

Para obtener más información, vea Plan for remote BLOB storage (RBS) (SharePoint Server 2010).

Siga los procedimientos recomendados para ver datos de bases de datos grandes. Para obtener más información, vea

Administración de la capacidad de SharePoint Server 2010: restricciones y límites del software.

Para obtener más información acerca de los repositorios de documentos a gran escala, vea el tema sobre los requisitos calculados de capacidad y rendimiento para repositorios de documentos a gran escala disponible en Recomendaciones y resultados de pruebas de rendimiento y capacidad (SharePoint Server 2010).

Administración automática del crecimiento de datos y archivos de registro

Se recomienda administrar automáticamente el crecimiento de datos y archivos de registro teniendo en cuenta las siguientes sugerencias:

En la medida de lo posible, ajuste previamente los datos y archivos de registro a su tamaño final anticipado.

Se recomienda que habilite el crecimiento automático por razones de seguridad. No confíe en la configuración predeterminada de

crecimiento automático. Tenga en cuenta las siguientes instrucciones al configurar el crecimiento automático:

Cuando se planean bases de datos de contenido que superan el tamaño recomendado (200 GB), se debe establecer el valor de

crecimiento automático de la base de datos en un número fijo de megabytes, en lugar de un porcentaje. Esto permite reducir la


450

frecuencia con la que SQL Server aumenta el tamaño de un archivo. El aumento del tamaño del archivo es una operación de

bloqueo que implica rellenar el nuevo espacio con páginas vacías.

Establezca el valor de crecimiento automático para la base de datos de almacén de propiedades de la aplicación de servicio de

búsqueda en 10 por ciento.

Si no se espera que el tamaño calculado de la base de datos de contenido alcance el tamaño máximo recomendado de 200 GB

durante el próximo año, establezca el tamaño máximo que estima tendrá la base de datos dentro de un año, con un 20 por ciento

adicional como margen de error, mediante el uso de la propiedad ALTER DATABASE MAXSIZE. Revise periódicamente esta

configuración para asegurarse de que sigue siendo un valor apropiado en función de las tasas anteriores de crecimiento.

Mantenga un nivel de al menos el 25 por ciento del espacio disponible en los discos para permitir el crecimiento y los patrones de

uso máximo. Si administra el crecimiento agregando discos a una matriz RAID o asignando más almacenamiento, supervise el

tamaño del disco para evitar quedarse sin espacio.

Validación y supervisión del almacenamiento y rendimiento de SQL Server Pruebe si la solución de copia de seguridad y rendimiento permite cumplir en su hardware los contratos de nivel de servicio (SLA). En concreto, pruebe el subsistema de E/S del equipo que ejecuta SQL Server para asegurarse de que el rendimiento sea satisfactorio.

Pruebe la solución de copia de seguridad que va a usar para asegurarse de que la copia de seguridad del sistema pueda hacerse durante el período de mantenimiento disponible. Si la solución de copia de seguridad no puede cumplir los SLA que su negocio requiere, considere la posibilidad de usar una solución de copia de seguridad incremental, como System Center Data Protection Manager (DPM) 2010.

Es importante realizar un seguimiento de estos componentes de recursos de un servidor que ejecuta SQL Server: CPU, memoria, proporción de aciertos en caché y subsistema de E/S. Cuando parezca que uno o varios de los componentes están lentos o sobrecargados, analice la estrategia adecuada en función de la carga de trabajo actual y prevista. Para obtener más información, vea el tema sobre la solución de problemas de rendimiento en SQL Server 2008 (http://go.microsoft.com/fwlink/?linkid=168448&clcid=0xC0A).

En la sección siguiente se indican los contadores de rendimiento recomendados para supervisar el rendimiento de las bases de datos de SQL Server que se ejecutan en el entorno de SharePoint Server 2010. También se indican los valores aproximados de buen estado para cada contador.

Para obtener más información acerca de cómo supervisar el rendimiento y usar contadores de rendimiento, vea el tema sobre la supervisión del rendimiento (http://go.microsoft.com/fwlink/?linkid=189032&clcid=0xC0A).



451

Contadores de SQL Server para supervisar

Supervise los siguientes contadores de SQL Server para garantizar el buen estado de los servidores:

Estadísticas generales 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. Considere la posibilidad de supervisar los contadores siguientes:

Conexiones de usuario Este contador muestra el número de conexiones de usuario del equipo que ejecuta SQL Server. Si

este número aumenta al 500 por ciento de su línea base, es posible que disminuya el rendimiento.

Bases de datos Este objeto proporciona contadores para supervisar las operaciones de copia masiva, copia de seguridad y

rendimiento de la 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 está produciendo en la base de datos y cuánto está creciendo 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, a los bloqueos y a la réplica. Supervisar la actividad de registro de bajo nivel para medir el uso de los recursos y

la actividad de usuario puede ayudarle a identificar los cuellos de botella de rendimiento. Considere la posibilidad de supervisar los

siguientes contadores:

Transacciones/s Este contador muestra la cantidad de transacciones en una base de datos o en todo el servidor por segundo.

Este número sirve más para su línea base y para solucionar problemas.

Bloqueos Este objeto brinda información acerca de los bloqueos de SQL Server en tipos de recursos individuales. Considere la

posibilidad de supervisar los siguientes contadores:

Tiempo promedio de espera (ms) Este contador muestra el promedio de tiempo de espera para cada solicitud de bloqueo que

se esperó.

Tiempo de espera de bloqueos (ms) Este contador muestra el tiempo de espera de bloqueos durante el último segundo.

Esperas de bloqueo/s Este contador muestra el número de bloqueos por segundo que no se pudieron satisfacer

inmediatamente y que tuvieron que esperar recursos.

Número de interbloqueos/s Este contador muestra el número de interbloqueos en el equipo que ejecuta SQL Server por

segundo. No debe ser mayor que 0.

Bloqueos temporales 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. Considere la posibilidad de supervisar los siguientes

contadores:

452

Promedio de tiempo de espera de bloqueos temporales (ms) Este contador muestra el promedio del tiempo de espera de los

bloqueos temporales para solicitudes de bloqueos temporales que tuvieron que esperar.

Esperas de bloqueos temporales/s Este contador muestra el número de solicitudes de bloqueos temporales que no se

concedieron inmediatamente.

Estadísticas SQL 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. Considere la posibilidad de supervisar los siguientes contadores:

Compilaciones SQL/s Este contador indica el número de veces que se especifica la ruta de acceso del código de compilación

por segundo.

Recompilaciones SQL/s Este contador indica el número de recompilaciones de instrucciones por segundo.

Administrador de búfer Este objeto proporciona contadores para supervisar cómo utiliza 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. Considere la posibilidad de supervisar los siguientes

contadores:

Proporción de aciertos en caché del búfer

Este contador muestra el porcentaje de páginas encontradas en la memoria caché del búfer sin necesidad de leer en 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é a través de los últimos miles

de accesos a la página. Como la lectura de la memoria caché es mucho menos costosa que la lectura del disco, es deseable que

esta proporción sea alta. Por lo general, es posible aumentar la proporción de aciertos de caché del búfer si aumenta la cantidad

de memoria disponible para SQL Server.

Caché del plan 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. Considere la

posibilidad de supervisar los siguientes contadores:

Proporción de aciertos en caché

Este contador indica la proporción entre aciertos en caché y búsquedas de planes.

Contadores de servidor físico para supervisar

Supervise los siguientes contadores para asegurar el buen estado de los equipos que ejecutan SQL Server:

453

Procesador: % tiempo de procesador: _Total Este contador muestra el porcentaje de tiempo en que el procesador ejecuta

procesos de una aplicación o del sistema operativo, que no sean procesos inactivos. En el equipo que ejecuta SQL Server, este

contador se debe mantener entre el 50 y el 75 por ciento. Si se producen sobrecargas constantes, investigue si existe una actividad

de procesamiento anormal o si el servidor requiere unidades CPU adicionales.

Sistema: Longitud de la cola de procesador Este contador muestra la cantidad de subprocesos en la cola del procesador.

Supervise este contador para asegurarse de que permanece por debajo de un valor equivalente a dos veces la cantidad de CPU de

núcleo.

Memoria: Mbytes disponibles Este contador muestra la cantidad de memoria física, en megabytes, disponible para los procesos

que se ejecutan en el equipo. Supervise este contador para asegurarse de mantener un nivel de al menos el 20 por ciento del total de

la memoria RAM física disponible.

Memoria: Páginas/s Este contador muestra la velocidad con que se leen o escriben las páginas en el disco para resolver errores

graves de las páginas. Supervise este contador para asegurarse de que permanece por debajo de 100.

Para obtener más información y conocer métodos de resolución de problemas de la memoria, vea el tema sobre el uso de la memoria de supervisión en SQL Server 2005 (http://go.microsoft.com/fwlink/?linkid=105585&clcid=0xC0A).

Contadores de disco para supervisar

Supervise los siguientes contadores para garantizar el buen estado de los discos. Tenga en cuenta que los siguientes valores representan las medidas tomadas a lo largo del tiempo en lugar de los valores generados durante un pico repentino o valores basados en una única medición.

Disco físico: % de tiempo de disco: UnidadDeDatos Este contador contador muestra el porcentaje de tiempo transcurrido durante

el cual la unidad de disco seleccionada se encuentra ocupada atendiendo solicitudes de lectura o escritura; es un indicador general

de lo ocupado que está el disco. Si el contador Disco físico: % de tiempo de disco es alto (más del 90 por ciento), compruebe el

contador Disco físico: longitud actual de la cola de disco para ver cuántas solicitudes del sistema están esperando acceso al

disco. El número de solicitudes de E/S en espera debería mantenerse en no más de 1,5 a 2 veces el número de cilindros que

componen el disco físico.

Disco lógico: Transferencias de disco/s Este contador muestra la velocidad a la que se realizan las operaciones de lectura y

escritura en el disco. Use este contador para supervisar adecuadamente los pronósticos y tendencias de crecimiento.

Disco lógico: Bytes de lectura de disco/s y Disco lógico: Bytes de escritura en disco/s Estos contadores muestran la velocidad

con la que se transfieren los bytes desde el disco durante las operaciones de lectura o escritura.



454

Disco lógico: Promedio de bytes de disco/lectura Este contador muestra el promedio de bytes de transferencia desde el disco

durante las operaciones de lectura. Este valor puede reflejar la latencia del disco; las operaciones de lectura más grandes pueden

producir un pequeño aumento en la latencia.

Disco lógico: Promedio de bytes de disco/escritura Este contador muestra el promedio de bytes de transferencia al disco

durante las operaciones de escritura. Este valor puede reflejar la latencia del disco; las operaciones de escritura más grandes pueden

producir un pequeño aumento en la latencia.

Disco lógico: Longitud actual de la cola de disco Este contador muestra la cantidad de solicitudes pendientes en el disco en el

momento en que se recopilan los datos de rendimiento. Para este contador, los valores más bajos son mejores. Los valores mayores

de 2 por disco podrían indicar un cuello de botella y deberán ser investigados. Esto quiere decir que un valor de hasta 8 se podría

aceptar para una unidad lógica (LUN) formada por 4 discos. Los cuellos de botella pueden crear un trabajo acumulado que se puede

extender más allá del servidor actual que está teniendo acceso al disco y generar largos períodos de espera para los usuarios. Las

posibles soluciones para el cuello de botella consisten en agregar más discos a la matriz RAID, reemplazar los discos existentes por

discos más rápidos o mover algunos datos a otros discos.

Disco lógico: Longitud promedio de la cola de disco Este contador muestra el promedio de solicitudes de escritura y lectura que

se pusieron en cola para el disco seleccionado durante el intervalo de muestra. La regla requiere que haya dos o menos solicitudes

pendientes de lectura y escritura por cilindro, pero esto puede ser difícil de medir debido a la virtualización del almacenamiento y a

las diferencias en los niveles de RAID entre configuraciones. Busque longitudes de cola de disco superiores a la media junto con

latencias de disco superiores a la media. Esta combinación puede indicar que la memoria caché de la matriz de almacenamiento se

está usando excesivamente o que el rendimiento se ve afectado al compartir el cilindro.

Disco lógico: Promedio de segundos de disco/lectura y Disco lógico: Promedio de segundos de disco/escritura Estos

contadores muestran el tiempo medio, en segundos, de una operación de lectura o escritura en el disco. Supervise estos contadores

para asegurarse de que permanezcan por debajo del 85 por ciento de la capacidad del disco. El tiempo de acceso al disco aumenta

exponencialmente si las operaciones de lectura o escritura superan el 85 por ciento de la capacidad del disco. Para determinar la

capacidad específica de su hardware, vea la documentación de su proveedor o use la herramienta de pruebas comparativas del

subsistema de disco SQLIO para calcularla. Para obtener más información, vea el tema sobre la herramienta de pruebas

comparativas del subsistema de disco SQLIO (http://go.microsoft.com/fwlink/?linkid=105586&clcid=0xC0A).

Disco lógico: Promedio de segundos de disco/lectura Este contador muestra el tiempo medio, en segundos, de una

operación de lectura del disco. En un sistema bien ajustado, los valores ideales oscilan entre 1 y 5 milisegundos (ms) para los

registros (lo idóneo es 1 milisegundo en una matriz de caché) y entre 4 y 20 ms para los datos (lo idóneo es menos de 10 ms). Se

pueden producir latencias superiores en horas de máxima actividad, pero si los valores elevados se registran con frecuencia,

deberá investigar la causa.



455

Disco lógico: Promedio de segundos de disco/escritura Este contador muestra el tiempo medio, en segundos, de una

operación de escritura del disco. En un sistema bien ajustado, los valores ideales oscilan entre 1 y 5 milisegundos (ms) para los

registros (lo idóneo es 1 milisegundo en una matriz de caché) y entre 4 y 20 ms para los datos (lo idóneo es menos de 10 ms). Se

pueden producir latencias superiores en horas de máxima actividad, pero si los valores elevados se registran con frecuencia,

deberá investigar la causa.

Cuando use configuraciones RAID con los contadores Promedio de segundos de disco/lectura o Promedio de segundos de disco/escritura, use las fórmulas que se indican en la siguiente tabla para determinar la velocidad de entrada o salida en el disco.

Nivel RAID Fórmula

RAID 0 E/S por disco = (lecturas + escrituras) / cantidad de discos

RAID 1 E/S por disco = [lecturas + (2 x escrituras)] / 2

RAID 5 E/S por disco = [lecturas + (4 x escrituras)] / cantidad de discos

RAID 10 E/S por disco = [lecturas + (2 x escrituras)] / cantidad de discos

Por ejemplo, si tiene un sistema RAID 1 que tiene dos discos físicos y sus contadores están establecidos en los valores que se muestran en la tabla siguiente:

Contador Valor

Promedio de segundos de disco/lectura 80

Disco lógico: Promedio de segundos de disco/escritura 70

Longitud promedio de la cola de disco 5

El valor de E/S por disco se puede calcular de la siguiente manera: (80 + (2 x 70))/2 = 110

La longitud de la cola del disco se puede calcular de la siguiente manera: 5/2 = 2,5

En esta situación, tiene un cuello de botella de E/S límite.

456

Otras herramientas de supervisión

También puede supervisar la latencia de los discos y analizar las tendencias mediante la vista de administración dinámica sys.dm_io_virtual_file_stats en SQL Server 2008. Para obtener más información, vea sys.dm_io_virtual_file_stats (Transact-SQL) (http://go.microsoft.com/fwlink/?linkid=105587&clcid=0xC0A).


planeación de la capacidad para microsoft sharepoint...

Documents