Share PT Serv Plan Cap

Planeacin de la capacidad para Microsoft SharePoint Server 2010
Microsoft Corporation
Publicado: enero de 2011
Autor: Equipo de Microsoft Office System and Servers (itspdocs@microsoft.com)
Resumen
Este libro ofrece informacin acerca de la planeacin de los requisitos de capacidad y de rendimiento para la implementacin de
Microsoft SharePoint Server 2010. Entre los temas se incluyen el cambio de tamao, la prueba de rendimiento, los lmites de software y
los estudios de casos de capacidades. Est dirigido a especialistas en aplicaciones empresariales, especialistas en lneas de negocio,
arquitectos de la informacin, profesionales generales de TI, administradores de programa y especialistas en infraestructuras que
planean una solucin basada en SharePoint Server 2010. Este libro forma parte de un conjunto de cuatro guas de planeacin que
ofrecen informacin completa sobre la planeacin de TI para SharePoint Server.
Para obtener informacin acerca de la planeacin de la arquitectura de una implementacin de SharePoint Server 2010, vea el tema
sobre la gua de planeacin de entornos y granjas de servidores para Microsoft SharePoint Server 2010
(http://go.microsoft.com/fwlink/?linkid=189513&clcid=0xC0A).
Para obtener informacin acerca de la planeacin de sitios y soluciones creados mediante SharePoint Server, vea el tema sobre la gua
de planeacin 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 gua de planeacin 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 tcnica de SharePoint Server 2010
(http://go.microsoft.com/fwlink/?linkid=181463&clcid=0xC0A) en la fecha de publicacin. Para obtener la informacin ms actual, vea la
biblioteca tcnica en Internet.
Este documento se proporciona tal cual. Es posible que la informacin y los puntos de vista reflejados en este documento, incluidas la
direccin 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 asociacin o conexin real.
Este documento no proporciona ningn derecho legal sobre la propiedad intelectual e industrial de ningn 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 pases.
Contenido
Planeacin de la capacidad para Microsoft SharePoint Server 2010............................................................................................................ 1
Cmo obtener ayuda ....................................................................................................................................................................................... 10
Administracin del rendimiento y de la capacidad (SharePoint Server 2010) ................................................................................................ 11
Capacity management and sizing for SharePoint Server 2010 (en ingls) .................................................................................................... 13
Informacin general sobre administracin y ajuste de tamao de la capacidad de SharePoint Server 2010 ................................................ 14
Glosario ........................................................................................................................................................................................................ 15
Quin debera leer los artculos de administracin de capacidad? ........................................................................................................... 15
Cuatro aspectos bsicos de rendimiento ..................................................................................................................................................... 18
Administracin de capacidad frente a planeacin de capacidad ................................................................................................................. 23
Sobreasignacin frente a subasignacin de capacidad .............................................................................................................................. 26
Restricciones y lmites del software ............................................................................................................................................................. 27
Diferencias clave entre SharePoint Server 2010 y Office SharePoint Server 2007 .................................................................................... 29
Diferenciadores clave de implementacin de SharePoint Server 2010....................................................................................................... 38
Arquitecturas de referencia .......................................................................................................................................................................... 40
Vea tambin ................................................................................................................................................................................................. 46
Planeacin de la capacidad para SharePoint Server 2010 ............................................................................................................................. 47

Paso 1: Modelo ............................................................................................................................................................................................ 47
Paso 2: Diseo ............................................................................................................................................................................................. 58
Paso 3: Piloto, prueba y optimizacin .......................................................................................................................................................... 64
Paso 4: Implementacin ............................................................................................................................................................................... 65
Paso 5: Supervisin y mantenimiento .......................................................................................................................................................... 66
Vea tambin ................................................................................................................................................................................................. 67
Pruebas de rendimiento para SharePoint Server 2010 .................................................................................................................................. 68

Creacin de un plan de pruebas .................................................................................................................................................................. 69
Creacin del entorno de prueba................................................................................................................................................................... 69
Creacin de pruebas y herramientas ........................................................................................................................................................... 71
Vea tambin ................................................................................................................................................................................................. 76
Supervisin y mantenimiento de SharePoint Server 2010 .............................................................................................................................. 77

Configuracin de la supervisin ................................................................................................................................................................... 77
Eliminacin de cuellos de botella ................................................................................................................................................................. 89
Vea tambin ................................................................................................................................................................................................. 93
Administracin de la capacidad de SharePoint Server 2010: restricciones y lmites del software ................................................................. 94
Informacin general de lmites mximos y lmites ....................................................................................................................................... 95
Lmites y lmites mximos ............................................................................................................................................................................ 98
Performance and capacity technical case studies (SharePoint Server 2010) (en ingls) ............................................................................ 148
Entorno de publicacin de intranet de empresa de Microsoft SharePoint Server 2010: caso prctico tcnico............................................ 150
Informacin de requisitos previos .............................................................................................................................................................. 150
Introduccin 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 ingls) ................................................. 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 ingls) ................................................................... 177
Glossary ..................................................................................................................................................................................................... 178
Overview .................................................................................................................................................................................................... 179
Specifications ............................................................................................................................................................................................. 181
Results and Analysis .................................................................................................................................................................................. 187
Departmental collaboration environment technical case study (SharePoint Server 2010) (en ingls) ......................................................... 203
Specifications ............................................................................................................................................................................................. 205
Workload .................................................................................................................................................................................................... 212
Dataset ....................................................................................................................................................................................................... 213
Divisional portal environment lab study (SharePoint Server 2010) (en ingls) ............................................................................................. 218
Glossary ..................................................................................................................................................................................................... 219
Overview .................................................................................................................................................................................................... 220
Specifications ............................................................................................................................................................................................. 221
Results and analysis .................................................................................................................................................................................. 229
About the authors ....................................................................................................................................................................................... 249
Social environment technical case study (SharePoint Server 2010) (en ingls) .......................................................................................... 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 ingls) .......................................... 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 ingls)............................................. 293
Test Results ............................................................................................................................................................................................... 297
Estimacin de los requisitos de rendimiento y capacidad de PerformancePoint Services ........................................................................... 318

Prueba de las caractersticas del conjunto o granja de servidores ........................................................................................................... 318
Escenarios de prueba y procesos .............................................................................................................................................................. 319
Configuracin de hardware y topologa ..................................................................................................................................................... 322
Resultados de las pruebas......................................................................................................................................................................... 323
Topologas 2M y 3M ................................................................................................................................................................................... 326
Resultados para topologas de 4 o ms mquinas para autenticacin de cuenta de servicio desatendida ............................................. 334
Resultados para topologas de 4 o ms mquinas para autenticacin de usuario ................................................................................... 335
Recomendaciones...................................................................................................................................................................................... 337
Analysis Services ....................................................................................................................................................................................... 338
Cuellos de botella comunes y sus causas ................................................................................................................................................. 339
Supervisin del rendimiento ....................................................................................................................................................................... 342
Vea tambin ............................................................................................................................................................................................... 343
Capacity requirements for Web Analytics Shared Service in SharePoint Server 2010 (en ingls) .............................................................. 344
Introduction................................................................................................................................................................................................. 345
Hardware specifications and topology ....................................................................................................................................................... 347
Capacity requirements ............................................................................................................................................................................... 351
Vea tambin ............................................................................................................................................................................................... 358
Estimacin de los requisitos de rendimiento y capacidad para la administracin de contenido web en SharePoint Server 2010 .............. 358
Informacin de requisitos previos .............................................................................................................................................................. 359
Mtodo y detalles de las pruebas .............................................................................................................................................................. 360
Implementaciones de administracin 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 ingls) .............................................................. 405
Test results ................................................................................................................................................................................................. 410
Troubleshooting.......................................................................................................................................................................................... 424
Vea tambin ............................................................................................................................................................................................... 426
Planeacin y configuracin del almacenamiento y capacidad de SQL Server (SharePoint Server 2010) ................................................... 427
Proceso de diseo y configuracin del nivel de base de datos y almacenamiento de productos de SharePoint 2010 ............................ 427
Recopilacin de los requisitos de espacio y E/S para almacenamiento y SQL Server ............................................................................. 428
Eleccin de la versin y edicin de SQL Server ........................................................................................................................................ 439
Diseo de la arquitectura de almacenamiento en funcin de la capacidad y los requisitos de E/S .......................................................... 441
Estimacin de los requisitos de memoria .................................................................................................................................................. 443
Descripcin de los requisitos de la topologa de red ................................................................................................................................. 444
Configuracin de SQL Server .................................................................................................................................................................... 444
Validacin y supervisin del almacenamiento y rendimiento de SQL Server ........................................................................................... 450
Cmo obtener ayuda
Se ha hecho todo lo posible para garantizar la mxima precisin en este libro. Este contenido tambin est disponible en lnea en la
biblioteca TechNet de Office System, por lo que, si tuviera algn problemas, puede comprobar si hay actualizaciones en:
http://technet.microsoft.com/es-es/office/bb267342
Si no encuentra la respuesta en nuestros contenidos en lnea, puede enviar un mensaje de correo electrnico al equipo de contenidos de
Microsoft Office System and Servers a la direccin de correo electrnico:
itspdocs@microsoft.com
Si tiene alguna pregunta acerca de los productos de Microsoft Office, y no acerca del contenido de este libro, realice una bsqueda en
Ayuda y soporte tcnico de Microsoft o en Microsoft Knowledge Base en:
http://support.microsoft.com/?ln=es-es
10
Administracin del rendimiento y de la capacidad (SharePoint
Server 2010)
La planeacin de la capacidad y del rendimiento es el proceso de asignar el diseo de la solucin de Microsoft SharePoint Server 2010 a
un tamao del conjunto o granja de servidores y un conjunto de hardware que admitir los objetivos empresariales.
Puede encontrar artculos relevantes sobre rendimiento y planeacin de capacidad para Project Server 2010 en la biblioteca de
documentos de Project Server en Plan for performance and capacity (Project Server 2010).
Los artculos de esta seccin incluyen:
Informacin general sobre administracin y ajuste de tamao de la capacidad de SharePoint Server 2010
En este artculo se le guiar a travs de los conceptos relacionados con la administracin de la capacidad y el ajuste del tamao de
las granjas de SharePoint 2010 y se proporciona informacin general sobre el proceso de planeacin.
Planeacin de la capacidad para SharePoint Server 2010
En este artculo se proporcionan pasos detallados y procedimientos para planear la capacidad de las granjas de SharePoint de 2010.
Supervisin y mantenimiento de SharePoint Server 2010
En este artculo se proporciona informacin acerca de cmo mantener y supervisar el rendimiento de las granjas de SharePoint de
2010.
Pruebas de rendimiento para SharePoint Server 2010
En este artculo se proporcionan instrucciones para probar el rendimiento de las granjas de SharePoint de 2010.
Administracin de la capacidad de SharePoint Server 2010: restricciones y lmites del software
En este artculo se proporciona un punto de partida para planear el rendimiento y la capacidad de su sistema. Tambin 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 ingls)
En este artculo se proporcionan vnculos a artculos de casos prcticos tcnicos claves que contienen detalles de rendimiento y
capacidad para entornos especficos que ejecuten SharePoint Server 2010.
11
Recomendaciones y resultados de pruebas de rendimiento y capacidad (SharePoint Server 2010)
En este artculo se proporcionan vnculos a artculos que contienen resultados de pruebas y recomendaciones para conjuntos de
caractersticas especficos en SharePoint Server 2010.
Planeacin y configuracin del almacenamiento y capacidad de SQL Server (SharePoint Server 2010)
En este artculo, se describe un proceso para planear el almacenamiento y la capacidad de SQL Server para una implementacin de
SharePoint Server 2010.
Los siguientes recursos tambin pueden ser tiles para planear la capacidad:
Determine hardware and software requirements (SharePoint Server 2010)
Diagramas tcnicos:
Topologas para SharePoint Server 2010
Arquitecturas de bsqueda para Microsoft SharePoint Server 2010
Diseo de arquitecturas de bsqueda para Microsoft SharePoint Server 2010
Planeacin de entorno de bsqueda para Microsoft SharePoint Server 2010
Para descargar estos modelos, vea Technical diagrams (SharePoint Server 2010).
12
Capacity management and sizing for SharePoint Server 2010 (en
ingls)
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:
13
Informacin general sobre administracin y ajuste de tamao
de la capacidad de SharePoint Server 2010
En este artculo se proporciona informacin general acerca de cmo planear y administrar la capacidad de los entornos de Microsoft
SharePoint Server 2010 de forma eficaz. Tambin se describe cmo comprender las caractersticas y necesidades de capacidad de la
implementacin, mediante el anlisis de datos de rendimiento y volumen. Adems, revisa los impactos principales de la aplicacin que
afectan a la capacidad, incluidas las caractersticas de contenido y el uso.
La administracin de capacidad es un proceso continuo, ya que ninguna implementacin permanece esttica 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
solucin de negocios eficaz.
La planeacin de capacidad es solo una parte del ciclo de administracin de capacidad. Es el conjunto inicial de actividades que coloca al
arquitecto de diseo en el punto donde existe una arquitectura inicial que el arquitecto considera que servir mejor para la
implementacin de SharePoint Server 2010. El modelo de administracin de capacidad incluye pasos adicionales que ayudan a validar y
optimizar la arquitectura inicial. Tambin proporciona un bucle de realimentacin para volver a planear y optimizar el entorno de
produccin hasta que pueda admitir los objetivos de diseo con las opciones ptimas de hardware, topologa y configuracin.
En este artculo:
Glosario
Quin debera leer los artculos de administracin de capacidad?
Cuatro aspectos bsicos de rendimiento
Administracin de capacidad frente a planeacin de capacidad
Sobreasignacin frente a subasignacin de capacidad
Restricciones y lmites del software
Diferencias clave entre SharePoint Server 2010 y Office SharePoint Server 2007
Diferenciadores clave de implementacin de SharePoint Server 2010
Arquitecturas de referencia
14
Glosario
En la documentacin de administracin de capacidad de SharePoint Server 2010 se usan los siguientes trminos especializados.
RPS Solicitudes por segundo. El nmero de solicitudes que recibe un conjunto o granja de servidores o un servidor en un segundo.
Se trata de una medida comn de la carga de servidores y granjas de servidores. El nmero de solicitudes que procesa una granja
de servidores es mayor que el nmero de cargas de pginas y de interacciones del usuario final. Esto se debe a que cada pgina
contiene varios componentes, cada uno de los cuales crea una o varias solicitudes cuando se carga la pgina. Algunas solicitudes
son ms ligeras que otras con respecto a los costos de transaccin. En nuestras pruebas de laboratorio y documentos de casos
prcticos, quitamos 401 solicitudes y respuestas (protocolos de enlace de la autenticacin) 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 da en que la carga de la granja de servidores alcanza su nivel mximo.
Carga mxima El promedio de carga mxima diaria de la granja de servidores, medido en RPS.
Pico de carga Los puntos de carga mxima temporaria que tienen lugar fuera de las horas de mayor demanda habituales. Pueden
deberse a aumentos de trfico 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 ms servidores a una
granja de servidores.
Quin debera leer los artculos de administracin de capacidad?

Tenga en cuenta las siguientes preguntas para determinar si debera leer este contenido.
Evaluacin de SharePoint Server 2010
Soy un profesional de TI o responsable de decisiones empresariales y estoy buscando una solucin para problemas empresariales
especficos. SharePoint Server 2010 es una opcin para la implementacin. Puede proporcionar caractersticas y escalabilidad que
cumplan mis requisitos especficos?
Para obtener informacin acerca de cmo SharePoint Server 2010 se ajusta para satisfacer las demandas de soluciones especficas y
cmo determinar el hardware necesario para admitir los requisitos, consulte las secciones que aparecen ms adelante en este artculo:
15
Para obtener informacin acerca de cmo evaluar SharePoint Server 2010 para sus requisitos de negocio especficos, vea los siguientes
artculos:
Product evaluation for SharePoint Server 2010
Actualizacin 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 actualizacin en el rendimiento y la escala de mi topologa?
Para obtener informacin acerca de las diferencias entre los factores de rendimiento y capacidad en Office SharePoint Server 2007 y
SharePoint Server 2010, vea la seccin siguiente:
Para obtener informacin acerca de las consideraciones de actualizacin generales e instrucciones acerca de cmo planear y ejecutar
una actualizacin de Office SharePoint Server 2007, consulte el siguiente artculo:
Upgrading to SharePoint Server 2010
Ajuste y optimizacin de un entorno real basado en SharePoint
He implementado SharePoint Server 2010 y deseo asegurarme de que dispongo de la topologa y el hardware adecuados. Cmo valido
la arquitectura y la mantengo correctamente?
Para obtener informacin acerca de los contadores de supervisin y rendimiento para granjas de servidores de Microsoft SharePoint
Server 2010, vea el artculo siguiente:
Para obtener informacin acerca de cmo usar las herramientas de seguimiento de estado integradas a la interfaz de Administracin
central, vea el artculo siguiente:
Health Monitoring (SharePoint Server 2010)
He implementado SharePoint Server 2010 y surgieron problemas de rendimiento. Cmo soluciono los problemas y optimizo mi entorno?
Para obtener informacin acerca de los contadores de supervisin y rendimiento para granjas de servidores de Microsoft SharePoint
Server 2010, vea el artculo siguiente:
16
Para obtener informacin acerca de cmo solucionar problemas mediante las herramientas de seguimiento de estado integradas a la
interfaz de Administracin central, vea el artculo siguiente:
Solving Problems and Troubleshooting (SharePoint Server 2010)
Para ver una lista de los artculos de administracin de capacidad disponibles para varios servicios y caractersticas de SharePoint Server
2010 especficos (se agregarn ms artculos a medida que se encuentren a disposicin), vea el artculo siguiente:
Para obtener informacin acerca del rendimiento y el ajuste de tamao de la base de datos, vea el artculo siguiente:
Para obtener informacin acerca del almacenamiento remoto de blobs (RBS), vea el artculo siguiente:
Plan for remote BLOB storage (RBS) (SharePoint Server 2010)
De principio a fin
Deseo conocer todo sobre la administracin de capacidad de SharePoint Server 2010. Por dnde debo empezar?
Para obtener informacin acerca de los conceptos generales detrs de la administracin de capacidad y vnculos a recursos y
documentacin adicionales, vea el artculo siguiente:
Administracin del rendimiento y de la capacidad (SharePoint Server 2010)
Para obtener informacin adicional acerca de la administracin de capacidad, consulte los siguientes artculos complementarios de este
artculo de informacin general:
Ahora debera comprender mejor los conceptos. Para obtener informacin acerca de las restricciones y los lmites de SharePoint Server
2010, vea el siguiente artculo:
Cuando est preparado para identificar una topologa de punto de inicio para el entorno basado en SharePoint Server 2010, puede
buscar en la biblioteca de casos prcticos tcnicos disponibles el que mejor se ajuste a sus necesidades. Para ver una lista de casos
prcticos (se agregarn ms casos prcticos a medida que se encuentren a disposicin), vea el siguiente artculo:
17
2010 especficos (se agregarn ms artculos a medida que se encuentren a disposicin), vea el artculo siguiente:
Para obtener informacin acerca del rendimiento y el ajuste de tamao de la base de datos, vea el artculo siguiente:
Para obtener informacin acerca del almacenamiento remoto de blobs (RBS), vea el artculo siguiente:
Plan for remote BLOB storage (RBS) (SharePoint Server 2010)
Para obtener informacin acerca de cmo solucionar problemas y hacer un seguimiento de estado mediante las herramientas de
seguimiento de estado integradas a la interfaz de Administracin central, vea los artculos siguientes:
Para obtener informacin acerca de las instrucciones para optimizar el rendimiento general y diversos temas especficos de rendimiento y
capacidad (se agregarn ms artculos a medida que se encuentren a disposicin), vea el artculo siguiente:
Use search administration reports (SharePoint Server 2010)
Para obtener ms informacin acerca de cmo virtualizar servidores basados en SharePoint Server 2010, vea el siguiente artculo:
Virtualization planning (SharePoint Server 2010)
Cuatro aspectos bsicos de rendimiento

La administracin de capacidad se centra en los siguientes cuatro aspectos principales del ajuste de tamao de la solucin:
Latencia Para los fines de la administracin de capacidad, la latencia se define como la duracin entre el momento en que un
usuario inicia una accin, como al hacer clic en un hipervnculo, y el momento en que se transmite el ltimo byte a la aplicacin
cliente o el explorador web.
Rendimiento El rendimiento se define como el nmero de solicitudes simultneas 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 tamao del contenido que el sistema puede hospedar.
La estructura y la distribucin 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 nmero de solicitudes simultneas que puede servir (rendimiento).
18
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 administracin de capacidad del entorno es establecer y mantener un sistema que cumpla los objetivos de
latencia, rendimiento, escala de datos y confiabilidad de la organizacin.
Latencia
La latencia, tambin 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 travs de la red.
El tiempo que tarda la respuesta en representarse en la aplicacin cliente.
Cada organizacin define objetivos de latencia diferentes, segn 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 rpidas.
Generalmente, la optimizacin para obtener transacciones muy rpidas es ms costosa y suele requerir clientes y servidores ms
eficaces, versiones ms recientes de aplicaciones cliente y exploradores, soluciones de red de ancho de banda alto y, posiblemente,
inversiones en desarrollo y optimizacin de pginas.
En la lista siguiente se describen algunos de los principales factores que contribuyen a la obtencin de latencias percibidas por el usuario
final de mayor duracin y ejemplos de algunos problemas comunes. Estos factores son especialmente relevantes en escenarios donde
los clientes estn geogrficamente lejos de la granja de servidores o tienen acceso a ella a travs de una conexin de red de ancho de
banda bajo.
Las caractersticas, los servicios o los parmetros de configuracin que no estn optimizados podran retrasar el procesamiento de
solicitudes y tener un impacto sobre la latencia para los clientes remotos y locales. Para obtener ms informacin, vea Rendimiento y
Confiabilidad, ms adelante en este artculo.
Las pginas web que generan solicitudes innecesarias al servidor para descargar los datos y recursos necesarios. La optimizacin
incluira la descarga del nmero mnimo de recursos para dibujar la pgina, la disminucin del tamao de las imgenes, el
almacenamiento de los recursos estticos en carpetas que permitan el acceso annimo, la agrupacin en clsteres de las solicitudes
y la habilitacin de la interactividad de pginas mientras se descargan los recursos de forma asincrnica del servidor. Estas
optimizaciones son importantes para lograr una experiencia de exploracin aceptable en la primera visita.
Un volumen de datos excesivo que se transmite a travs de la red contribuye a la degradacin de la latencia y el rendimiento. Por
ejemplo, las imgenes y otros objetos binarios de una pgina deben usar un formato comprimido, como .png o .jpg, en lugar de
mapas de bits, siempre que sea posible.
19
Las pginas web que no estn optimizadas para cargas de pgina de segundo acceso. El tiempo de carga de pgina (PLT) mejora
para las cargas de pgina de segundo acceso, debido a que algunos recursos de la pgina se almacenan en la memoria cach del
cliente; de esta manera, el explorador solo debe descargar el contenido dinmico que no est almacenado en la memoria cach.
Normalmente, las latencias de carga de pgina de segundo acceso inaceptables se deben a la configuracin 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 pginas web que tienen cdigo no optimizado personalizado de JavaScript. Esto podra retrasar la representacin de la pgina
en el cliente. La optimizacin podra provocar un retraso en el procesamiento de JavaScript en el cliente hasta que se haya cargado
el resto de la pgina y, preferiblemente, debera hacer una llamada a script en lugar de agregar JavaScript alineado.
Rendimiento
El rendimiento se describe en base al nmero de solicitudes que una granja de servidores puede procesar en una unidad de tiempo.
Adems, se usa a menudo para medir la escala de las operaciones que se espera que el sistema soporte en funcin del tamao de la
organizacin y sus caractersticas de uso. Cada operacin tiene un costo especfico en los recursos de la granja de servidores. La
comprensin de la demanda y la implementacin de una arquitectura de granja de servidores que pueda satisfacer la demanda de forma
coherente requiere la estimacin 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 ms solicitudes de las que puede procesar
simultneamente, 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 continuacin se muestran
algunos ejemplos de optimizacin de una granja de servidores para que soporte un mayor rendimiento:
Asegrese de que los procesadores de los servidores de la granja no se estn 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 ms servidores o
redistribuya los servicios a otros servidores de la granja.
Asegrese 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.
Asegrese 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 mxima, agregue ms discos o redistribuya las bases de datos a discos
20
infrautilizados. Consulte la seccin "Quitar los cuellos de botella" del artculo sobre supervisin y mantenimiento de Productos y
Tecnologas de SharePoint Server 2010 para obtener ms informacin.
Si la adicin de recursos a los equipos existentes no es suficiente para resolver los problemas de rendimiento, agregue
servidores y redistribuya las caractersticas y los servicios afectados a los nuevos servidores.
Pginas web personalizadas no optimizadas Una causa comn de los problemas de rendimiento es la adicin de cdigo
personalizado a las pginas usadas con frecuencia en un entorno de produccin. La adicin de cdigo personalizado puede generar
ms idas y vueltas a los servidores de bases de datos o servicios web para atender las solicitudes de datos. La personalizacin de
las pginas que no se usan con frecuencia no afecta al rendimiento de forma significativa, pero incluso el cdigo bien optimizado
puede disminuir el rendimiento de la granja de servidores si se solicita miles de veces por da. Los administradores de SharePoint
Server pueden habilitar el panel del programador para que identifique el cdigo personalizado que requiera optimizacin. A
continuacin se proporcionan algunos ejemplos de optimizacin de cdigo personalizado:
Minimizar el nmero de solicitudes de servicio web y consultas SQL.
Capturar los mnimos datos necesarios en cada recorrido al servidor de bases de datos, a la vez que se minimiza el nmero de
idas y vueltas necesarias.
Evitar agregar cdigo personalizado a las pginas usadas con frecuencia.
Usar ndices al recuperar una cantidad filtrada de datos.
Soluciones que no son de confianza La implementacin de cdigo personalizado en carpetas Bin podra ralentizar el rendimiento
del servidor. Cada vez que se solicita una pgina que contiene cdigo que no es de confianza, SharePoint Server 2010 debe realizar
comprobaciones de seguridad antes de que se cargue la pgina. A menos que exista una razn especfica para implementar cdigo
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 mtodo que se usa para distribuir datos en los discos y servidores de bases de datos
tambin puede afectar al rendimiento y a la latencia de la granja de servidores.
El tamao 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 solucin de base de datos ptima. En una implementacin ideal, se ajusta el tamao de las bases de datos
de contenido en funcin de las instrucciones de lmites y se las distribuye en discos fsicos, de modo que no se ponen en cola las
21
solicitudes debido a la sobreutilizacin del disco. Adems, los servidores de bases de datos pueden admitir las cargas mximas y los
picos inesperados sin superar los umbrales de uso de recursos.
Adems, ciertas operaciones pueden bloquear determinadas tablas durante la operacin. Un ejemplo de esto es la eliminacin de un sitio
de gran tamao, 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 operacin de eliminacin.
A continuacin se muestran algunos ejemplos de optimizacin del rendimiento de datos y almacenamiento de una granja de servidores:
Asegrese 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 distribucin de datos.
Separe los volmenes de la base de datos en unidades lgicas (LUN) nicas, que consisten en ejes nicos de disco fsico. Use
varios discos con tiempo de bsqueda bajo y opciones de configuracin 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 administracin del almacenamiento de blobs se controla mediante un sistema diseado especficamente 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 ms informacin, vea Plan for remote BLOB storage (RBS) (SharePoint Server 2010).
Para obtener ms informacin acerca de cmo planear la escala de datos, vea Planeacin y configuracin 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 lmite, la capacidad
de respuesta, la tasa de errores, y la frecuencia y amplitud de los picos de latencia estn dentro de los requisitos operativos y objetivos
establecidos. Una granja de servidores confiable tambin puede soportar de forma coherente los objetivos de rendimiento y latencia
durante la carga mxima y las horas de mayor demanda o al realizar operaciones del sistema, como copias de seguridad diarias o
rastreos.
22
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 eliminacin de varios sitios con gran volumen de contenido, es posible que el sistema no pueda procesar las
solicitudes de usuario muy rpidamente. 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 transaccin y la frecuencia de dichas operaciones menos
comunes y de si se ejecutan durante las horas de operacin normales.
A continuacin se muestran algunos ejemplos de cmo mantener un sistema ms 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 adicin de servidores web, servidores de aplicaciones o servidores de bases de datos adicionales.
Distribuir servicios y caractersticas con uso intensivo de recursos en los servidores dedicados. Tambin puede usar un equilibrador
de carga de hardware para dirigir el trfico especfico de caracterstica a un servidor web dedicado a determinadas caractersticas o
servicios.
Administracin de capacidad frente a planeacin de capacidad

La administracin de la capacidad ampla el concepto de la planeacin de la capacidad para expresar un enfoque cclico en el que la
capacidad de una implementacin 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 implementacin nica. Por lo tanto, los diseadores de sistemas y los
administradores deben comprender los requisitos para sus entornos especficos.
23
Modelo de administracin de capacidad de SharePoint Server 2010
24
Paso 1: modelo El modelado es el proceso mediante el cual decide qu soluciones clave desea que su entorno admita y establece
todos los parmetros y mtricas importantes. El resultado del ejercicio de modelado debe ser una lista de todos los datos clave que
necesita para disear 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: diseo Una vez que haya recopilado los datos del paso 1, puede disear la granja de servidores. Los resultados son
arquitectura de datos detallada, y topologas fsicas y lgicas.
Determine la arquitectura de punto de inicio.
Seleccione el hardware.
Paso 3: piloto, prueba y optimizacin Si ha diseado una implementacin nueva, debe implementar un entorno piloto para probar
la carga de trabajo y las caractersticas 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
funcin de los resultados de supervisin, para mantener los objetivos de rendimiento. El resultado de esta fase es el anlisis de los
resultados de pruebas en funcin 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.
Optimizacin Recopile los resultados de pruebas y realice los cambios necesarios en los recursos de la granja de servidores y
la topologa.
Paso 4: implementacin Este paso describe la implementacin de la granja de servidores o la realizacin de cambios en una
granja de servidores existente. El resultado para un nuevo diseo es una implementacin completa de produccin 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: supervisin y mantenimiento Este paso describe cmo configurar la supervisin y cmo predecir e identificar cuellos de
botella, as como realizar peridicamente actividades de mantenimiento y mitigacin de cuellos de botella.
25
Sobreasignacin frente a subasignacin de capacidad
La sobreasignacin de capacidad describe un enfoque de diseo 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 implementacin con sobreasignacin de capacidad, la memoria, CPU y otros indicadores de recursos de la granja de servidores
muestran que tambin se puede servir la demanda con menos recursos. La desventaja de la sobreasignacin de capacidad es un mayor
gasto en hardware y mantenimiento. Adems, se podran imponer mayores demandas de potencia y espacio.
La subasignacin describe un enfoque de diseo 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 satisfaccin, escalaciones frecuentes, costos de soporte tcnico altos y gastos
innecesarios para solucionar problemas y optimizar el entorno.
Al disear la granja de servidores, asegrese de que esta pueda satisfacer los objetivos establecidos de rendimiento y capacidad, tanto
en cargas mximas normales como en picos inesperados. El diseo, las pruebas y la optimizacin 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 ms 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 solucin de problemas ocasionados por la subasignacin.
Siempre se debe ajustar el tamao de un sistema para que responda de forma adecuada durante niveles de demanda mximos, lo cual
puede variar para distintos servicios en momentos especficos. Para estimar los requisitos de capacidad de forma eficaz, debe identificar
el peor perodo de demanda posible para todos los recursos. Puede que haya un aumento de la carga en diversas caractersticas y
servicios a determinadas horas del da, como a primera hora de la maana o despus de la comida.
La granja de servidores tambin debe ser capaz de admitir los picos no planeados, como cuando se realizan anuncios en toda la
organizacin y un nmero inusualmente elevado de usuarios accede a un sitio al mismo tiempo. Durante estos perodos 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.
Tambin debera revisarse la capacidad de la granja de servidores cuando se aprovisionen usuarios adicionales a la empresa. En
escenarios como una fusin o adquisicin caracterizada por el acceso de nuevos empleados o integrantes a la granja de servidores, se
podran obtener efectos negativos sobre el rendimiento si no se planea y estima esta situacin por adelantado.
26
Estados operativos: zona verde y zona roja
Cuando se describe la carga de un sistema de produccin, 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 perodos 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 mximas
diarias esperadas. Una granja de servidores que opera en este intervalo debe ser capaz de soportar tiempos de respuesta y latencia
dentro de parmetros aceptables.
Zona roja Se trata del intervalo operativo en que la carga es mayor que la carga mxima normal, pero an puede servir las solicitudes
durante un perodo limitado. Este estado se caracteriza por una latencia mayor que la normal y posibles errores causados por saturacin
de cuellos de botella del sistema.
El objetivo fundamental del diseo de la granja de servidores es la implementacin 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.

En SharePoint Server 2010, hay ciertos lmites que son de diseo y que no se pueden exceder y otros lmites que se establecen en
valores predeterminados que el administrador de la granja de servidores puede modificar. Tambin hay ciertos lmites que no estn
representados por un valor configurable, como el nmero de colecciones de sitios por aplicacin web.
Los lmites son lmites absolutos que no se pueden exceder por diseo. Es importante entender estos lmites para no hacer suposiciones
incorrectas al disear una granja de servidores.
Un ejemplo de lmite es el lmite de tamao de documento de 2 GB. No se puede configurar SharePoint Server 2010 para que almacene
documentos de ms de 2 GB. ste es un valor absoluto integrado y no se puede exceder por diseo.
Los umbrales son lmites 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 diseo 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 lmites.
El valor predeterminado de ciertos umbrales solo se puede exceder hasta un valor mximo absoluto. Un buen ejemplo, nuevamente, es
el lmite de tamao de documento. De forma predeterminada, el lmite de tamao de documento se establece en 50 MB, pero se puede
cambiar a un valor mximo de 2 GB.
27
Los lmites admitidos definen el valor probado de un parmetro especfico. Los valores predeterminados de estos lmites se definen
mediante pruebas y representan las limitaciones conocidas del producto. Si se exceden los lmites admitidos, se pueden producir
resultados inesperados, una degradacin considerable del rendimiento u otros efectos perjudiciales.
Algunos lmites admitidos son parmetros configurables que se establecen de forma predeterminada en el valor recomendado, mientras
que otros estn relacionados con parmetros no representados por un valor configurable.
Un ejemplo de un lmite admitido es el nmero de colecciones de sitios por aplicacin web. El lmite admitido es de 500,000, que es la
cantidad mxima de colecciones de sitios por aplicacin web que alcanz los niveles de referencia de rendimiento durante las pruebas.
Es importante tener en cuenta que muchos de los valores lmite que se proporcionan en este documento representan un punto en una
curva que describe una carga de recursos creciente y una degradacin concomitante del rendimiento a medida que aumenta el valor. Por
lo tanto, si se exceden ciertos lmites, como el nmero de colecciones de sitios por aplicacin web, solo podra obtenerse una reduccin
fraccional del rendimiento de la granja de servidores. No obstante, en la mayora de los casos, el funcionamiento a un lmite establecido o
a un nivel prximo no es un procedimiento recomendado, ya que es ms fcil alcanzar los objetivos aceptables de rendimiento y
confiabilidad cuando el diseo de una granja de servidores proporciona un equilibrio razonable de los valores lmite.
Las directrices de umbrales y lmites admitidos estn determinadas por el rendimiento. En otras palabras, se pueden exceder los valores
predeterminados de los lmites, pero a medida que se aumenta el valor lmite, el rendimiento de la granja de servidores y el valor efectivo
de otros lmites pueden verse afectados. Muchos de los lmites de SharePoint Server 2010 pueden modificarse. No obstante, es
importante entender cmo se vern afectadas otras partes de la granja de servidores al modificar un determinado lmite.
Si se pone en contacto con los servicios de soporte al cliente de Microsoft acerca de un sistema de produccin que no cumple las
especificaciones mnimas de hardware publicadas descritas en Hardware and software requirements (SharePoint Server 2010), el
soporte tcnico estar limitado hasta que se actualice el sistema con los requisitos mnimos.
Establecimiento de los lmites
En SharePoint Server 2010, los umbrales y lmites admitidos se establecen mediante pruebas y la observacin 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
lmites 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 lmite 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 caractersticas presentan una latencia inaceptablemente alta mientras que otras caractersticas siguen funcionando
con parmetros aceptables. Por lo tanto, el valor mximo asignado a la cantidad de colecciones de sitios no es absoluto, sino que se
calcula en funcin de un conjunto esperado de caractersticas de uso en el que el rendimiento de la granja de servidores en general sera
aceptable en el lmite especificado en la mayora de los casos.
28
Si otros servicios funcionan con parmetros ms altos que los usados en las pruebas de lmites, los lmites efectivos mximos de otros
servicios se reducirn. Por lo tanto, es importante ejecutar rigurosos ejercicios de pruebas de administracin de capacidad y de escala
para implementaciones especficas, a fin de establecer lmites efectivos para dicho entorno.
Para obtener ms informacin acerca de las restricciones y los lmites, as como sobre el modo en que estos afectan al proceso de
administracin de la capacidad, vea Administracin de la capacidad de SharePoint Server 2010: restricciones y lmites del software.
Diferencias clave entre SharePoint Server 2010 y Office SharePoint

Server 2007
SharePoint Server 2010 ofrece un conjunto ms rico de caractersticas y un modelo de topologa ms flexible que en las versiones
anteriores. Antes de usar esta arquitectura ms compleja para ofrecer una funcionalidad y caractersticas ms 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, haba cuatro servicios principales que se podan habilitar en los proveedores de servicios compartidos
(SSP): servicio de bsqueda, servicio de Excel Calculation, servicio de perfiles de usuario y servicio de catlogo de datos profesionales.
Adems, exista un conjunto de clientes relativamente ms pequeo que poda interactuar directamente con Office SharePoint Server
2007.
En SharePoint Server 2010 hay ms servicios disponibles, conocidos como aplicaciones de servicio de SharePoint (SSA). Adems,
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 mviles, herramientas para diseadores y exploradores. A continuacin 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 informacin acerca de los destinatarios de correo electrnico que se extrae de la granja de servidores de SharePoint Server
cuando se ven los mensajes de correo electrnico en el cliente de Outlook. Esto presenta un nuevo conjunto de patrones de trfico y
una carga del servidor que deben tenerse en cuenta.
Algunas de las nuevas caractersticas de los clientes de Microsoft Office 2010 actualizan automticamente 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, tambin presentan algunos patrones de trfico nuevos y una carga del servidor que deben
tenerse en cuenta.
29
Las nuevas caractersticas de interactividad de SharePoint Server 2010, como Office Web Apps, que habilitan la edicin de archivos
de Office directamente desde el explorador, usan llamadas de AJAX que presentan algunos patrones de trfico 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 caractersticas ms completo de SharePoint Server 2010, se espera que crezca el nmero general de solicitudes por
segundo (RPS). Adems, se espera que el porcentaje de solicitudes provenientes del explorador sea ms pequeo que en Office
SharePoint Server 2007, lo cual deja espacio para el porcentaje creciente de trfico nuevo procedente de otros clientes, a medida que las
caractersticas se adopten ampliamente en toda la organizacin.
Adems, SharePoint Server 2010 presenta nuevas caractersticas, como admisin nativa de vdeo incrustado, que puede agregar un
esfuerzo a la granja de servidores. Algunas de las caractersticas tambin se han ampliado para admitir una escala mayor que en las
versiones anteriores.
La siguiente seccin describe estas interacciones de cliente, servicios y caractersticas, as como su rendimiento general e implicaciones
de capacidad en el sistema, que se deben tener en cuenta al disear la solucin.
Para obtener ms informacin acerca de cmo actualizar a SharePoint Server 2010, vea Upgrading to SharePoint Server 2010.
Servicios y caractersticas
En la tabla siguiente se proporciona una descripcin 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 mnimo o insignificante en el recurso. El servicio puede compartir este recurso con otros servicios.
XX: indica un costo medio en el recurso. El servicio podra compartir este recurso con otros servicios que tengan un impacto mnimo.
XXX: indica un costo alto en el recurso. Por lo general, el servicio no debera compartir este recurso con otros servicios.
Para obtener ms informacin acerca de cmo planear las bases de datos de SQL Server, vea Planeacin y configuracin del
almacenamiento y capacidad de SQL Server (SharePoint Server 2010).
2010 especficos (se agregarn ms artculos a medida que se encuentren a disposicin), vea Recomendaciones y resultados de
pruebas de rendimiento y capacidad (SharePoint Server 2010).
30
Aplicacin de servicio CPU del servidor web RAM del CPU del RAM del CPU de IOPS de Almacenamiento de
servidor servidor de servidor de SQL SQL SQL Server
web aplicaciones aplicaciones Server Server
Servicio de SharePoint XXX XXX XX XXX XXX

Foundation
Servicio de Administracin XX XX X X X
central
Servicio de registro * XX XX XX XXX XXX
Servicio de bsqueda de XXX XXX XXX XXX XXX XXX XXX
SharePoint
Aplicacin del Servicio de X X XXX XX
visualizacin de Word *
Servicio de PowerPoint * XX XX XXX XX
Servicio de Excel XX X XX XXX
Calculation
Servicio de Visio * X X XXX XXX X X X
Servicio de Access * X X XXX XX X X X
Servicio de perfiles de X XX XX XX XXX XXX XX
usuario
Servicio de metadatos X XX XX XX X X XX
administrados *
Servicio de Web Analytics X X XXX XXX XXX
*
Servicios de conectividad XX XX XXX XXX
empresarial *
31
Aplicacin de servicio CPU del servidor web RAM del CPU del RAM del CPU de IOPS de Almacenamiento de
servidor servidor de servidor de SQL SQL SQL Server
web aplicaciones aplicaciones Server Server
InfoPath Forms Services XX XX XX XX X X X

Word Automation Services X X XXX XX X X X
Aplicacin de Servicio XX XX XXX XXX X X X
PerformancePoint *
Servicio de Project * X X X X XXX XXX XX
Soluciones de espacio X X XXX XXX
aislado *
Caractersticas de flujo de XXX XXX
trabajo *
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 colaboracin de contenido. En implementaciones de

SharePoint Server de gran tamao, se recomienda asignar servidores web redundantes en funcin de la carga de trfico esperada,
ajustar correctamente el tamao de los equipos basados en SQL Server que sirven las bases de datos de contenido y asignar
correctamente el almacenamiento en funcin del tamao de la granja de servidores.
Servicio de Administracin central El servicio de administracin. Este servicio tiene requisitos de capacidad relativamente
pequeos. Se recomienda habilitar este servicio en varios servidores de la granja para asegurar la redundancia.
32
Servicio de registro El servicio que registra los indicadores de estado y de uso para fines de supervisin. Se trata de un servicio de
escritura intensiva, que puede requerir espacio en disco relativamente grande en funcin del nmero de indicadores y la frecuencia
con la que estos se registran. En implementaciones de SharePoint Server 2010 de gran tamao, se recomienda aislar la base de
datos de uso de las bases de datos de contenido de diferentes equipos basados en SQL Server.
Aplicacin de servicio de bsqueda de SharePoint La aplicacin de servicios compartidos que proporciona funciones de
indizacin 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 tamao, en que el motor de
bsqueda Enterprise Search es muy importante, se recomienda usar una "granja de servidores de servicio" independiente para
hospedar aplicaciones de servicio de bsqueda con recursos de base de datos dedicados, usar varios servidores de aplicaciones que
sirvan funciones de bsqueda especficas (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. Tambin puede habilitar las aplicaciones de
servicio FAST como la aplicacin de servicio de bsqueda. Elija crear uno o ms 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.
Aplicacin del Servicio de visualizacin 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 visualizacin en el explorador. En implementaciones de SharePoint
Server de gran tamao, se recomienda incrementar la escalabilidad horizontal del servicio en varios servidores de aplicaciones para
la redundancia y el rendimiento.
Nota:
La edicin 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 caracterstica se ejecuta en los servidores web de la granja de servidores y no usa ninguna aplicacin de
servicio.
Aplicacin de servicio de PowerPoint Este servicio muestra archivos de PowerPoint y permite que los usuarios los editen
directamente en el explorador. Adems, 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 visualizacin en el explorador. En implementaciones de SharePoint Server de gran tamao, en que el
servicio se convierte en una funcin que se usa con frecuencia, se recomienda implementar varios servidores de aplicaciones para
asegurar una redundancia y una capacidad de proceso aceptables, y agregar ms servidores web cuando la difusin de PowerPoint
tambin se use con frecuencia.
33
Aplicacin de Excel Calculation Services Este servicio muestra hojas de clculo de Excel directamente en el explorador y realiza
clculos de Excel en el servidor. Adems, permite la edicin de hojas de clculo directamente desde el explorador cuando se instala
Office Web Apps en SharePoint Server 2010. En implementaciones de SharePoint Server de gran tamao, en que el servicio se
convierte en una funcin que se usa con frecuencia, se recomienda asignar un nmero 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 clculo de Excel habilitadas para PowerPivot directamente desde el
explorador. En implementaciones de SharePoint Server de gran tamao, en que el servicio se convierte en una funcin que se usa
con frecuencia, se recomienda asignar un nmero suficiente de servidores de aplicaciones que tengan suficiente RAM y CPU para
garantizar un rendimiento y una capacidad de proceso aceptables. Para obtener ms informacin, vea el tema sobre los requisitos de
hardware y software (PowerPivot para SharePoint).
Aplicacin de Servicios de Visio El servicio para mostrar diagramas dinmicos de Visio directamente en el explorador. Este
servicio tiene una dependencia de la aplicacin de servicio de estado de sesin, lo cual requiere una base de datos de SQL Server
relativamente pequea. El servicio de Visio requiere un servidor de aplicaciones para preparar los archivos originales de Visio para la
visualizacin en el explorador. En implementaciones de SharePoint Server de gran tamao, en que el servicio se convierte en una
funcin 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.
Aplicacin de los Servicios de Access El servicio para hospedar soluciones de Access en SharePoint Server 2010. En
implementaciones de SharePoint Server de gran tamao, en que el servicio se convierte en una funcin 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.
Aplicacin 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 sincronizacin 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 sincronizacin, perfiles y
etiquetado social. Este servicio depende de la aplicacin de servicio de metadatos administrados. En implementaciones de
SharePoint Server de gran tamao, debe tener en cuenta la posibilidad de distribuir este servicio a una granja de servidores de
servicios compartidos y ajustar correctamente el tamao del nivel de servidor de bases de datos para garantizar un rendimiento
aceptable de las transacciones comunes y los trabajos de sincronizacin de directorios.
Aplicacin de servicio de metadatos administrados El servicio que potencia el repositorio de metadatos central y permite la
redifusin de los tipos de contenido en toda la empresa. El servicio se puede federar en una granja de servidores de servicios
dedicados. Requiere una base de datos que se pueda colocalizar con otras bases de datos.
34
Aplicacin de servicio de Web Analytics El servicio que agrega y almacena estadsticas sobre las caractersticas 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 tamao 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.
Aplicacin de Servicios de conectividad empresarial El servicio que permite la integracin de varias aplicaciones de lnea de
negocio de la organizacin junto con SharePoint Server 2010. Este servicio requiere un servicio de aplicacin para mantener las
conexiones de datos con recursos externos. En implementaciones de SharePoint Server de gran tamao, en que este servicio es una
funcin que se usa con frecuencia, se recomienda asignar un nmero suficiente de servidores de aplicaciones que tengan suficiente
RAM para obtener un rendimiento aceptable.
Aplicacin de InfoPath Forms Services El servicio que habilita los formularios basados en el explorador en SharePoint Server
2010 y la integracin con la aplicacin cliente de InfoPath para la creacin de formularios. Este servicio requiere un servidor de
aplicaciones y tiene una dependencia con la aplicacin de servicio de estado de sesin, lo que requiere una base de datos
relativamente pequea. Este servicio se puede colocalizar con otros servicios y tiene requisitos de capacidad relativamente
pequeos, que pueden aumentar en funcin de la frecuencia de uso de esta funcin.
Aplicacin de Word Automation Services El servicio que permite la conversin 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
tamao, en que el servicio se convierte en una funcin 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
conversin aceptable. Este servicio tambin requiere una base de datos relativamente pequea para mantener la cola de los trabajos
de conversin.
Aplicacin de Servicio PerformancePoint El servicio que habilita las funciones de BI de PerformancePoint en SharePoint Server
2010 y permite crear visualizaciones analticas. Este servicio requiere un servidor de aplicaciones y una base de datos. En
implementaciones de SharePoint Server de gran tamao, en que el servicio se convierte en una funcin 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.
Aplicacin de servicio de Project El servicio que habilita todas las caractersticas de planeacin y seguimiento de Microsoft
Project Server 2010 adems 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 tamao, en que el servicio es una
caracterstica que se usa con frecuencia, debe dedicar un servidor de bases de datos para la base de datos de Project Server e
35
incluso tener en cuenta una granja de servidores de SharePoint Server dedicada para las soluciones de administracin de Project
Server.
Servicio de temporizador El proceso encargado de la ejecucin 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 especficos, segn el rol del servidor. Algunos de estos trabajos del temporizador hacen un uso
intensivo de recursos y podran crear carga en el servidor local y en los servidores de bases de datos, en funcin de su actividad y de
la cantidad de contenido con la que operan. En implementaciones de SharePoint Server de gran tamao, en que los trabajos del
temporizador podran tener consecuencias sobre la latencia del usuario final, se recomienda dedicar un servidor para aislar la
ejecucin de los trabajos con uso ms intensivo de recursos.
Flujo de trabajo La caracterstica 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 nmero total de eventos que
controlan. En implementaciones de SharePoint Server de gran tamao, en que los flujos de trabajo son una caracterstica 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 trfico 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 cdigo personalizado en recursos de la granja de
servidores dedicados. En implementaciones de SharePoint Server de gran tamao, en que el servicio es una caracterstica usada
frecuentemente, debe considerar la posibilidad de dedicar servidores web adicionales si el cdigo personalizado comienza a tener
consecuencias en el rendimiento del servidor.
Nuevas interacciones de aplicaciones cliente con SharePoint Server 2010
En esta seccin se describen algunas nuevas interacciones de cliente y servidor que admite SharePoint Server 2010 y sus implicaciones
en la planeacin de capacidad.
En la tabla siguiente se proporciona una descripcin simplificada de nivel alto de la carga tpica que estas nuevas caractersticas
introducen en el sistema:
X: indica una carga mnima o insignificante en los recursos del sistema
XX: indica una carga media en los recursos del sistema
XXX: indica una carga alta en los recursos del sistema
36
Cliente Trfico Carga
Office Web Apps XXX XX

Difusin de PowerPoint XXX X
Aplicacin cliente de Word y PowerPoint 2010 XX X
Aplicacin cliente de OneNote XXX XXX
Outlook Social Connector XX XX
SharePoint Workspace XXX XX
Office Web Apps La visualizacin y edicin web de archivos de Word, PowerPoint, Excel y OneNote es un subconjunto de
solicitudes del explorador con caractersticas de trfico ligeramente diferentes. Este tipo de interaccin presenta una carga de trfico
relativamente alta, necesaria para habilitar ciertas caractersticas, como la coautora. En implementaciones de SharePoint Server de
gran tamao, en que se habilitan estas caractersticas, se debe esperar una carga adicional en los servidores web.
Difusin de PowerPoint El conjunto de solicitudes asociadas con la visualizacin en directo de presentaciones de PowerPoint en el
explorador web es otro subconjunto de solicitudes del explorador. Durante las sesiones de difusin en directo de PowerPoint, los
clientes que participan solicitan cambios desde el servicio. En implementaciones de SharePoint Server de gran tamao, en que se
trata de una caracterstica 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 caractersticas que
aprovechan la granja de servidores de SharePoint Server. Un ejemplo es la coautora de documentos, en la que todas las
aplicaciones cliente que participan en una sesin de coautora cargan y descargan con frecuencia actualizaciones desde y hacia el
servidor. En implementaciones de SharePoint Server de gran tamao, en que se trata de una caracterstica que se usa con
frecuencia, se debe esperar una carga adicional en los servidores web.
Aplicacin cliente de OneNote 2010 El cliente de OneNote 2010 interacta con la granja de servidores de SharePoint Server de
forma similar que en la versin anterior de OneNote y usa SharePoint Server 2010 para compartir blocs de notas de OneNote y
habilitar la coautora en ellos. Este escenario introduce una carga en SharePoint Server 2010 an cuando el cliente est abierto, pero
no se lo usa activamente. En implementaciones de SharePoint Server de gran tamao, en que se trata de una caracterstica que se
usa con frecuencia, se debe esperar una carga adicional en los servidores web.
37
Aplicacin cliente de Outlook 2010 Outlook 2010 tiene una caracterstica nueva, Outlook Social Connector, que aprovecha la
granja de servidores de SharePoint Server (este componente tambin puede agregarse a versiones anteriores de Outlook). Esta
caracterstica permite ver la actividad social solicitada desde la granja de servidores de SharePoint Server directamente en los
mensajes de correo electrnico. En implementaciones de SharePoint Server de gran tamao, en que se habilita esta caracterstica,
se debe esperar una carga adicional en los servidores web.
SharePoint Workspace Los clientes de SharePoint Workspace 2010 tienen nuevas caractersticas 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
conexin. SharePoint Workspace 2010 se sincroniza peridicamente 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 tamao, en que se
trata de una caracterstica que se usa con frecuencia, se puede esperar una carga adicional en los servidores web.
Diferenciadores clave de implementacin de SharePoint Server 2010

Cada implementacin de SharePoint Server 2010 tiene un conjunto clave de caractersticas que la hacen nica y la diferencian de otras
granjas de servidores. Estos diferenciadores clave se pueden describir a travs de las siguientes cuatro categoras principales:
Especificacin Describe el hardware de la granja de servidores, as como la topologa y configuracin de la misma.
Carga de trabajo Describe la demanda de la granja de servidores, incluido el nmero de usuarios y las caractersticas de uso.
Conjunto de datos Describe los tamaos y la distribucin 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 fsicos del equipo, como procesadores, memoria y discos duros. El hardware tambin incluye componentes
de red fsica, 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 utilizacin de un recurso de hardware, como memoria insuficiente en un servidor, puede afectar el rendimiento de toda la granja de
servidores.
Topologa
La topologa es la distribucin y las relaciones entre el hardware de la granja de servidores y los componentes. Existen dos tipos de
topologas:
38
Topologa lgica La asignacin de componentes de software, como servicios y caractersticas de una granja de servidores.
Topologa fsica La asignacin de servidores y recursos fsicos.
Normalmente, el nmero de usuarios y las caractersticas de uso determinan la topologa fsica de una granja de servidores y los
requisitos empresariales, de la misma manera que la necesidad de admitir caractersticas especficas para la carga esperada controla la
topologa lgica.
Configuracin
La configuracin de trminos se usa para describir la configuracin de software y el modo en que se establecen los parmetros. Adems,
la configuracin hace referencia al almacenamiento en cach, RBS, el modo en que se establecen los lmites configurables y cualquier
parte del entorno de software que se pueda configurar o modificar para satisfacer los requisitos especficos.
Carga de trabajo
La carga de trabajo define las caractersticas operativas clave de la granja de servidores, incluida la base de usuarios, la simultaneidad,
las caractersticas que se usan y los agentes de usuario o las aplicaciones cliente que se usan para conectarse con la granja de
servidores.
Distintas caractersticas de SharePoint Server tienen diferentes costos asociados en los recursos de la granja de servidores. La
popularidad de las caractersticas ms costosas podra tener un impacto significativo en el rendimiento y el estado del sistema. Si
comprende la demanda prevista y las caractersticas de uso, podr ajustar correctamente el tamao de la implementacin y reducir el
riesgo de ejecutar constantemente el sistema en una situacin de mal estado.
Base de usuarios
La base de usuarios de una aplicacin basada en SharePoint Server es una combinacin del nmero total de usuarios y el modo en que
se distribuyen geogrficamente. Adems, dentro de la base de usuarios total, hay subgrupos de usuarios que pueden usar ciertas
caractersticas o servicios ms 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 nmero de
usuarios nicos totales y el nmero de usuarios simultneos.
Caractersticas de uso
El rendimiento de una granja de servidores puede verse afectado no solo por el nmero de usuarios que interactan con el sistema, sino
tambin por sus caractersticas de uso. Dos organizaciones que tengan el mismo nmero de usuarios pueden tener requisitos muy
diferentes en funcin de la frecuencia con que los usuarios obtengan acceso a los recursos de la granja de servidores y de acuerdo a si
se habilitan caractersticas y servicios con uso intensivo de recursos en la granja de servidores. Los indicadores que describen las
caractersticas de uso incluyen la frecuencia de operaciones nicas, la combinacin de funcionamiento general (la relacin entre
39
operaciones administrativas y operaciones de lectura y escritura), y los patrones de uso y carga con respecto a las nuevas caractersticas
que se habilitan en la granja de servidores (por ejemplo, los sitios web de Mi sitio, la bsqueda, los flujos de trabajo y Office Web Apps).
Conjunto de datos
El volumen de contenido que se almacena en el sistema y las caractersticas de la arquitectura en que se almacena pueden tener un
efecto importante sobre el estado y el rendimiento generales del sistema. Comprender el tamao, la frecuencia de acceso y la distribucin
de datos permitir ajustar correctamente el tamao 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 disear correctamente la arquitectura de almacenamiento de una solucin basada en SharePoint Server, debe conocer el
volumen de datos que almacenar en el sistema y el nmero de usuarios que solicitan datos de distintos orgenes de datos. El volumen
del contenido es un elemento importante del tamao de la capacidad de disco, ya que puede influir en el rendimiento de otras
caractersticas y podra afectar tambin el ancho de banda disponible y la latencia de red. Los indicadores que definen el conjunto de
datos incluyen el tamao total del contenido, el nmero total de documentos, el nmero total de colecciones de sitios y los tamaos
mximo y medio de la coleccin de sitios.
Estado y rendimiento
El estado de la granja de servidores de SharePoint Server es bsicamente una medida o puntuacin simplificada que refleja la
confiabilidad, estabilidad y el rendimiento del sistema. El rendimiento de la granja de servidores con respecto a los objetivos depende
bsicamente de los tres primeros diferenciadores. Se puede realizar un seguimiento y describir la puntuacin de estado y rendimiento
mediante una destilacin de un conjunto de indicadores. Para obtener ms informacin, vea Supervisin y mantenimiento de SharePoint
Server 2010. Estos indicadores son el tiempo lmite del sistema, la latencia percibida por el usuario final, las tasas de errores de pgina y
los indicadores de uso de recursos (CPU, RAM).
Cualquier cambio significativo en el hardware, la configuracin, topologa, carga de trabajo o el conjunto de datos puede modificar
considerablemente la confiabilidad y la capacidad de respuesta del sistema. La puntuacin del estado se puede usar para hacer un
seguimiento a travs 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
implementacin de SharePoint Server es nica y se define mediante sus caractersticas de uso y datos. Cada organizacin debe realizar
40
un proceso de administracin de capacidad exhaustivo y aprovechar con eficacia la flexibilidad que ofrece el sistema de SharePoint
Server 2010 para personalizar una solucin de tamao correcto que mejor satisfaga las necesidades organizativas.
El concepto de arquitecturas de referencia se usa para describir e ilustrar las diferentes categoras principales de las implementaciones
de SharePoint Server y no para proporcionar una receta que los arquitectos puedan usar para disear sus soluciones. Esta seccin se
centra en describir los vectores que se usan normalmente para escalar las implementaciones de SharePoint Server.
Las arquitecturas que se enumeran a continuacin se proporcionan como una manera til para comprender los diferenciadores generales
entre estas categoras genricas y para diferenciarlos mediante los factores de costos generales y la escala de esfuerzo.
Implementacin de servidor nico
La arquitectura de implementacin de servidor nico consiste en un servidor que ejecuta SharePoint Server 2010 y una versin
compatible de SQL Server. Esta arquitectura podra ser apropiada para fines de evaluacin, para los programadores o para una
implementacin de departamento aislada, que no es crtica y tiene solo unos pocos usuarios. Sin embargo, no se recomienda su uso en
un entorno de produccin.
Implementacin de una granja de servidores pequea

Una implementacin de una granja de servidores pequea se compone de un nico servidor de base de datos o clster y uno o dos
equipos basados en SharePoint Server 2010. Las caractersticas principales de la arquitectura son redundancia y conmutacin por error
limitadas, y un conjunto mnimo de caractersticas de SharePoint Server habilitadas.
Una granja de servidores pequea es til para servir solo las implementaciones limitadas, con un conjunto mnimo de aplicaciones de
servicio habilitadas, una base de usuarios relativamente pequea, una carga de uso relativamente baja (algunas pocas solicitudes por
minuto hasta muy pocas solicitudes por segundo) y un volumen relativamente pequeo de datos (10 o ms gigabytes).
41
Implementacin de una granja de servidores mediana
Esta arquitectura presenta el desglose de la topologa en tres niveles: servidores web dedicados, servidores de aplicaciones dedicados y
uno o varios servidores de bases de datos o clsteres. La separacin 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 ms comn, que incluye un amplio espectro de tamaos de granja de servidores y topologas de servicio. Una
implementacin 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 tpico de caractersticas podra 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 almacn de datos de uno o dos terabytes.
42
43
Implementacin 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 tamao, normalmente hay servidores web, varios servidores de aplicaciones, segn la
caracterstica de uso de cada uno de los servicios locales (no compartidos), y varios servidores basados en SQL Server o clsteres de
SQL Server, dependiendo del tamao del contenido y las bases de datos de servicios de la aplicacin que estn 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 bsqueda, el servicio de metadatos administrados y Web Analytics.
La mayora de las dems 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 ms terabytes.
44
45
Vea tambin
Conceptos
Otros recursos
Hardware and software requirements (SharePoint Server 2010)
46
En este artculo se describe cmo planear la capacidad de un conjunto o granja de servidores de Microsoft SharePoint Server 2010.
Cuando tenga una apreciacin y comprensin adecuadas de la planeacin y administracin de la capacidad, podr aplicar sus
conocimientos para realizar el ajuste de tamao del sistema. Se entiende por ajuste de tamao el proceso de elegir y configurar de
manera adecuada la arquitectura de datos, la topologa lgica y fsica, y el hardware para una plataforma de solucin. Deben tenerse en
cuenta varias consideraciones sobre administracin y uso de la capacidad a la hora de determinar las opciones de hardware y de
configuracin ms apropiadas.
Antes de leer este artculo, debe leer Informacin general sobre administracin y ajuste de tamao de la capacidad de SharePoint Server
2010.
En este artculo se describen los pasos que se deben seguir para la administracin eficaz de la capacidad de un entorno. Cada paso
requiere cierta informacin para su correcta ejecucin e incluye un conjunto de entregas que se usarn en el paso siguiente. En las tablas
que siguen se describen los requisitos y objetivos correspondientes a cada paso.
En este artculo:
Paso 1: Modelo
Paso 2: Diseo
Paso 3: Piloto, prueba y optimizacin
Paso 4: Implementacin
Paso 5: Supervisin y mantenimiento
Paso 1: Modelo
Para crear un modelo de un entorno basado en SharePoint Server 2010, es necesario empezar con un anlisis de las soluciones
existentes y estimar la demanda y los objetivos previstos para la implementacin que se desea configurar. Primero, debe recopilar
informacin acerca de la base de usuarios, los requisitos de datos, la latencia y los objetivos de rendimiento, y documentar las
caractersticas de SharePoint Server que desea implementar. En esta seccin aprender qu datos debe recopilar, cmo recopilarlos y
cmo se pueden usar en los pasos siguientes.
47
Determinacin de la carga de trabajo y el conjunto de datos previstos
Para calcular correctamente el tamao de una implementacin de SharePoint Server 2010 debe analizar y conocer las caractersticas de
demanda que se espera que la solucin pueda controlar. Para conocer la demanda, debe poder describir las caractersticas de la carga
de trabajo, como el nmero de usuarios y las operaciones que se usan con ms frecuencia, as como las caractersticas del conjunto de
datos, como el tamao y la distribucin del contenido.
Esta seccin le ayudar a conocer algunos de los datos mtricos y parmetros especficos 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 caractersticas de uso. En la tabla
siguiente se proporcionan algunos datos mtricos esenciales que resultan tiles para determinar la carga de trabajo. Puede usar esta
tabla para registrar estos datos mtricos a medida que los recopila.
Caractersticas de la carga de trabajo Valor
Promedio de RPS por da

Promedio de RPS en horas pico
Nmero total de usuarios nicos por da
Promedio de usuarios simultneos por da
Pico de usuarios simultneos en horas pico
Nmero total de solicitudes por da
Distribucin de carga de trabajo prevista Nmero de solicitudes por da %
Explorador web: rastreo de bsqueda
Explorador web: interaccin general de colaboracin
Explorador web: interaccin social
Explorador web: interaccin general
48
Explorador web: Office Web Apps

Clientes de Office
Cliente de OneNote
SharePoint Workspace
Sincronizacin de RSS de Outlook
Outlook Social Connector
Otras interacciones (aplicaciones/servicios web
personalizados)
Usuarios simultneos: es ms comn medir la simultaneidad de las operaciones que se ejecutan en la granja de servidores, como
el nmero de usuarios distintos que generan solicitudes en una cantidad de tiempo determinada. Los datos mtricos esenciales son
el promedio diario y la cantidad de usuarios simultneos con carga pico.
Solicitudes por segundo (RPS): RPS es un indicador que se usa comnmente para describir la demanda en la granja de servidores
expresada segn el nmero de solicitudes que la granja de servidores procesa por segundo, sin distinguir entre el tipo o el tamao de
las solicitudes. La base de usuarios de cada organizacin genera la carga del sistema a una velocidad que depende de las
caractersticas de uso nicas de la organizacin. Vea la seccin Glosario en Informacin general sobre administracin y ajuste de
tamao de la capacidad de SharePoint Server 2010 para obtener ms informacin acerca de este trmino.
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 autenticacin (estado
HTTP 401), durante un perodo 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 nmero real de usuarios nicos en un perodo de 24 horas y no el nmero total de empleados de la organizacin.
49
Nota:
El nmero total de usuarios diarios puede indicar el potencial de crecimiento de la carga en la granja de servidores. Por ejemplo, si el
nmero 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 adopcin de usuarios.
Distribucin de la carga de trabajo: conocer la distribucin de las solicitudes en funcin de las aplicaciones cliente que interactan
con la granja de servidores puede ayudar a predecir la tendencia y los cambios de carga despus de migrar a SharePoint Server
2010. A medida que los usuarios realicen la transicin a versiones de clientes ms 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 aumentarn. Se puede
describir el nmero de usuarios distintos que usan cada cliente en un perodo de un da y la cantidad total de solicitudes que el cliente
o la caracterstica genera en el servidor en cada caso.
Por ejemplo, el grfico siguiente muestra una instantnea de un entorno interno real de Microsoft para una solucin social tpica. En
este ejemplo, se puede ver que la mayor parte de la carga se genera por el rastreador de bsqueda y el uso tpico de los
exploradores web por parte de los usuarios finales. Tambin se puede observar que la nueva caracterstica de Outlook Social
Connector introduce una carga considerable (6,2% de las solicitudes).
50
51
52
Estimacin de la carga de trabajo de produccin
Para calcular el rendimiento que la granja de servidores tendr que mantener, calcule primero la combinacin de transacciones que se
usarn en la granja de servidores. Cntrese en analizar las transacciones ms frecuentes que el sistema tendr que atender y en
determinar con qu frecuencia se usarn y cuntos usuarios las usarn. Esto le ayudar a validar ms adelante si la granja de servidores
puede mantener dicha carga en pruebas de preproduccin.
En el siguiente diagrama se describe la relacin entre la carga de trabajo y la carga del sistema:
53
54
Para calcular la carga de trabajo prevista, recopile la informacin siguiente:
Identifique las interacciones de los usuarios, como por ejemplo, pginas web que suelen visitar, descargas y cargas de archivos,
vistas y ediciones de Office Web Application en el explorador, interacciones de co-autora, sincronizaciones de sitios de SharePoint
Workspace, conexiones sociales de Outlook, sincronizacin 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 seccin sobre servicios y caractersticas del artculo Informacin general sobre administracin y ajuste de tamao de la
capacidad de SharePoint Server 2010 para obtener ms informacin. Cntrese en identificar las interacciones que pueden ser nicas
para la implementacin y determine el impacto previsto de dicha carga; por ejemplo, un uso considerable de formularios de InfoPath,
clculos de Servicios de Excel y soluciones dedicadas similares.
Identifique operaciones del sistema, como rastreos incrementales de bsqueda, copias de seguridad diarias, trabajos del
temporizador de sincronizacin de perfiles, procesamiento de Web Analytics, registro de trabajos del temporizador, etc.
Calcule el nmero total de usuarios por da que estima que usarn cada capacidad, derive la cantidad estimada de usuarios
simultneos y de solicitudes de alto nivel por segundo. Deber plantear algunos supuestos, como la simultaneidad presente y el
factor RPS por usuarios simultneos, que difiere entre las distintas capacidades. Se recomienda usar la tabla de carga de trabajo
incluida anteriormente en esta seccin para realizar los clculos. Es importante que se fije en las horas pico, en lugar del rendimiento
promedio. Si planea la actividad pico, podr ajustar correctamente el tamao de la solucin basada en SharePoint Server 2010.
Si dispone de una solucin de Office SharePoint Server 2007, puede extraer los archivos de registro de IIS o recurrir a otras herramientas
de supervisin web que tenga para entender mejor algunos de los comportamientos previstos de la solucin existente. Tambin puede
ver las instrucciones que se proporcionan en la seccin siguiente para obtener ms detalles. Si no va a migrar de una solucin existente,
debe rellenar la tabla con estimaciones aproximadas. En los pasos posteriores deber validar los supuestos planteados y optimizar el
sistema.
Anlisis de los registros de IIS de SharePoint Server 2010
Para obtener datos mtricos esenciales acerca de una implementacin de SharePoint Server 2010 existente, como cuntos usuarios
estn 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 ms sencillas de obtener este tipo de datos consiste en usar Log Parser, una
eficaz herramienta que se puede descargar de forma gratuita a travs de Microsoft. Log Parser puede leer y escribir en una serie de
formatos de texto y binarios, incluidos todos los formatos IIS.
Para obtener ms informacin acerca de cmo analizar el uso de SharePoint Server 2010 con Log Parser, lea el tema sobre el anlisis
de uso de Productos y Tecnologas de Microsoft SharePoint (http://www.microsoft.com/downloads/en/details.aspx?familyid=f159af68-
c3a3-413c-a3f7-2e0be6d5532e&displaylang=en&tm).
55
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 cmo puede distribuirse en el almacn de datos. En
la tabla siguiente se proporcionan algunos datos mtricos esenciales que resultan tiles para determinar el conjunto de datos. Puede usar
esta tabla para registrar estos datos mtricos a medida que los recopila.
Objeto Valor
Tamao de la base de datos (en GB)

Nmero de bases de datos de contenido
Nmero de colecciones de sitios
Nmero de aplicaciones web
Nmero de sitios
Tamao de ndice de bsqueda (nmero de elementos)
Nmero de documentos
Nmero de listas
Tamao promedio de los sitios
Sitio de mayor tamao
Nmero de perfiles de usuario
Tamao del contenido: es importante conocer el tamao del contenido que calcula que se almacenar en el sistema SharePoint
Server 2010 para planear y disear la arquitectura del almacenamiento de sistema y tambin para ajustar correctamente el tamao
de la solucin de bsqueda que va a rastrear e indizar este contenido. El tamao del contenido se describe en el espacio total en
56
disco. Si va a migrar contenido de una implementacin existente, puede que le resulte sencillo identificar el tamao total que mover;
durante la planeacin, debera dejar espacio para el crecimiento a lo largo del tiempo en funcin de la tendencia prevista.
Nmero total de documentos: aparte del tamao del cuerpo de datos, es importante realizar un seguimiento del nmero 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 tamao, 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 pequeos
en muchos sitios y la coleccin de sitios, es ms fcil de atender que una nica biblioteca de documentos de gran tamao con
archivos muy grandes.
Tamao mximo de la coleccin de sitios: es importante identificar cul es la unidad ms 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
organizacin. El tamao promedio de todas las colecciones de sitios y el nmero total estimado de colecciones de sitios son
indicadores adicionales que le ayudarn a identificar cul es la arquitectura de datos preferida.
Caractersticas de datos de aplicaciones de servicio: adems de analizar las necesidades de almacenamiento del almacn de
contenido, deber analizar y calcular los tamaos de otros almacenes de SharePoint Server 2010, incluidos:
Tamao total del ndice de bsqueda
El tamao total de base de datos de perfiles en funcin del nmero de usuarios en el almacn de perfiles
El tamao total de la base de datos social en funcin del nmero esperado de etiquetas, compaeros de trabajo y actividades
El tamao del repositorio de metadatos
El tamao de la base de datos de uso
El tamao de la base de datos de Web Analytics
Para obtener ms informacin acerca de cmo calcular los tamaos de las bases de datos, vea Planeacin y configuracin del
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 ms adecuados para las
necesidades de la organizacin. Una solucin de SharePoint Server que est diseada 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 funcin del porcentaje de tiempo de actividad general del sistema. Se
debe realizar un seguimiento del tiempo de inactividad inesperado y comparar la disponibilidad general con el objetivo de la
57
organizacin 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 organizacin tiene como objetivo atender
pginas de SharePoint Server 2010 en menos de dos segundos, el objetivo del servidor debe ser de fracciones de segundo para dar
tiempo a la pgina a que obtenga acceso al cliente a travs de la red y para que se represente en el explorador. Tambin, en general,
los tiempos de respuesta del servidor ms 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 ms de un segundo en el servidor para la
mayora 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% ms lento de todas las solicitudes. Las solicitudes ms lentas son normalmente las solicitudes que llegan al
sistema cuando este se encuentra sometido a una carga ms alta o, con ms frecuencia, las solicitudes que se ven afectadas por la
actividad menos frecuente que se produce mientras los usuarios interactan con el sistema; un sistema en buen estado es aquel que
tambin tiene bajo control las solicitudes ms 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
coleccin de contadores del sistema que indican el estado de cada servidor en la topologa de la granja de servidores. Los
indicadores que se usan con ms 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 ms detalles en el Paso 5: Supervisin y mantenimiento.
Paso 2: Diseo
Una vez que se han recopilado algunos datos o clculos sobre la solucin, puede continuar con el paso siguiente que consiste en disear
una propuesta de arquitectura que pueda mantener la demanda prevista segn sus clculos.
Al finalizar este paso, deber tener un diseo para la topologa fsica y otro para la topologa lgica, as que seguramente podr proseguir
con las compras necesarias.
58
Las especificaciones de hardware y el nmero de mquinas que incluya en el diseo estn estrechamente relacionados. Para administrar
una carga especfica se puede elegir entre varias soluciones para implementarlas. Es habitual usar un conjunto pequeo de mquinas
eficaces (incremento de la escalabilidad vertical) o bien un conjunto mayor de mquinas ms pequeas (incremento de la escalabilidad
horizontal). Cada solucin 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 topologa. Decida cmo tiene previsto disear las diferentes
granjas de servidores y los distintos servicios en cada granja y, a continuacin, elija las especificaciones de hardware para cada uno de
los servidores del diseo. Para realizar este proceso, tambin puede identificar las especificaciones de hardware que espera implementar
(muchas organizaciones estn limitadas a un determinado estndar de la compaa) y, a continuacin, definir la arquitectura y la
topologa.
Use la siguiente tabla para registrar los parmetros de diseo. Los datos que se incluyen son datos de ejemplo y no deben usarse para
calcular el tamao de la granja de servidores, ya que estn diseados para mostrar cmo usar esta tabla con sus propios datos.
Rol Tipo (estndar o virtual) Nmero de Procedimientos RAM E/S por Tamao Unidad
mquinas segundo de disco de datos
necesaria SO +
registro
Servidores web Virtual 4 4 ncleos 8 N/A 400 GB N/A

Servidor de bases de datos de Estndar 1 clster 4 procesadores de 48 2k 400 GB 20
contenido ncleo cudruple a discos
2,33 (GHz) de 300
GB
a 15.000
RPM
Servidores de aplicaciones Virtual 4 4 ncleos 16 N/A 400 GB N/A
Servidor web de destino de Virtual 1 4 ncleos 8 N/A 400 GB N/A
rastreo de bsqueda
Servidor de consultas de Estndar 2 2 procesadores de 32 N/A 400 GB 500 GB
ncleo cudruple a
59
Rol Tipo (estndar o virtual) Nmero de Procedimientos RAM E/S por Tamao Unidad
mquinas segundo de disco de datos
necesaria SO +
registro
bsqueda 2,33 (GHz)
Servidor de rastreador de Estndar 2 2 procesadores de 16 400 400 GB N/A
bsqueda ncleo cudruple a
2,33 (GHz)
Servidor de bases de datos de Estndar 1 clster 4 procesadores de 48 4 k (optimizado 100 GB 16
rastreo de bsqueda ncleo cudruple a para lectura) discos
2,33 (GHz) de 150
GB a
15.000
RPM
Base de datos de almacn de Estndar 1 clster 4 procesadores de 48 2 k (optimizado 100 GB 16
propiedades de bsqueda + ncleo cudruple a para escritura) discos
Servidor de bases de datos de 2,33 (GHz) de 150
administracin GB a
15.000
RPM
Determinacin de la arquitectura inicial

En esta seccin se describe cmo seleccionar una arquitectura inicial.
Cuando implemente SharePoint Server 2010, puede elegir entre una amplia gama de topologas para implementar la solucin. 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 clster o reflejados y servidores de aplicaciones discretos para varios servicios. Despus,
puede seleccionar las configuraciones de hardware en funcin de los requisitos de cada uno de los roles, segn sus necesidades de
capacidad, disponibilidad y redundancia.
60
Comience por revisar las diferentes arquitecturas de referencia y determine la estructura de la granja de servidores. Decida si debe dividir
la solucin en varias granjas de servidores, o federar algunos servicios, como la bsqueda, en una granja de servidores dedicada. Vea la
seccin sobre arquitectura de referencia en Informacin general sobre administracin y ajuste de tamao de la capacidad de
SharePoint Server 2010 para obtener ms informacin.
Casos prcticos tcnicos de SharePoint Server 2010
Las directrices de administracin de la capacidad de SharePoint Server 2010 contienen una serie de casos prcticos tcnicos de los
entornos de produccin existentes que presentan una descripcin detallada de los entornos de produccin actuales basados en
SharePoint Server. Ms adelante se publicarn ms casos prcticos tcnicos para que sirvan de referencia sobre cmo disear un
entorno basado en SharePoint Server con fines especficos.
Puede usar estos casos prcticos como una referencia al disear la arquitectura de las soluciones de SharePoint Server, especialmente
si encuentra la descripcin de estos factores diferenciadores clave especficos de la implementacin similares a las demandas y objetivos
de la arquitectura de la solucin que est diseando.
En estos documentos se proporciona la informacin siguiente para cada caso prctico documentado:
Especificaciones, como hardware, topologa de la granja de servidores y configuracin;
Carga de trabajo, incluida la base de usuarios y las caractersticas de uso;
Conjunto de datos, incluidos los tamaos del contenido, las caractersticas del contenido y la distribucin del contenido;
Mantenimiento y rendimiento, incluido un conjunto de indicadores registrados que describen las caractersticas de confiabilidad y
rendimiento de la granja de servidores.
Para obtener ms informacin, descargue los documentos relevantes de la pgina sobre casos prcticos tcnicos de rendimiento y
capacidad (http://technet.microsoft.com/es-es/library/cc261716.aspx).
Seleccin del hardware
La seleccin de las especificaciones adecuadas para las mquinas de la granja de servidores es un paso esencial para garantizar la
confiabilidad y el rendimiento adecuados de la implementacin. Unas de las consideraciones clave es que debe realizar la planeacin
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, debera haber suficientes recursos disponibles para controlar la mxima demanda esperada y, al mismo tiempo, cumplir con los
objetivos de latencia y rendimiento.
Las caractersticas principales del hardware de capacidad y rendimiento de los servidores reflejan cuatro categoras principales: potencia
de procesamiento, rendimiento del disco, capacidad de la red y capacidades de memoria de un sistema.
61
Otro aspecto que se debe tener en cuenta es el uso de mquinas virtualizadas. Una granja de servidores de SharePoint Server se puede
implementar mediante mquinas virtuales. Aunque no se haya comprobado que esto proporcione ms beneficios de rendimiento, s
proporciona beneficios de capacidad de administracin. Por lo general, no se recomienda la virtualizacin de equipos basados en SQL
Server, pero puede haber ciertos beneficios en la virtualizacin de los niveles de servidores web y servidores de aplicaciones. Para
obtener ms informacin, vea el tema sobre la planeacin de la virtualizacin (http://technet.microsoft.com/es-es/library/ff607968.aspx).
Instrucciones para la seleccin del hardware
Eleccin de procesadores
SharePoint Server 2010 solo est disponible para procesadores de 64 bits. Normalmente, un nmero mayor de procesadores le permitir
atender una mayor demanda.
En SharePoint Server 2010, a medida que se agregan ms ncleos (hemos probado hasta 24 ncleos) se incrementar la escalabilidad
de los servidores web individuales; cuantos ms ncleos tenga el servidor, ms carga podr mantener, considerando que todas las
dems caractersticas sean las mismas. En grandes implementaciones de SharePoint Server, se recomienda asignar varios servidores
web de 4 ncleos (que se pueden virtualizar) o menos servidores web ms eficaces (de 8, 16 24 ncleos).
Los requisitos de capacidad del procesador de los servidores de aplicaciones varan segn el rol del servidor y los servicios que ejecuta.
Algunas caractersticas de SharePoint Server exigen mayor potencia de procesamiento que otras. Por ejemplo, el servicio de bsqueda
de SharePoint es sumamente dependiente de la capacidad de procesamiento del servidor de aplicaciones. Para obtener ms informacin
acerca de los requisitos de recursos de las caractersticas y servicios de SharePoint Server, vea el tema sobre servicios y caractersticas
anteriormente en este documento.
Los requisitos de capacidad de procesador para SQL Server tambin dependen de las bases de datos de servicio que hospeda un
equipo basado en SQL Server. Para obtener ms informacin acerca del comportamiento tpico y los requisitos de cada base de datos,
vea Planeacin y configuracin del almacenamiento y capacidad de SQL Server (SharePoint Server 2010).
Eleccin de la memoria
Los servidores requieren distintas cantidades de memoria, segn la funcin de servidor y su rol. Por ejemplo, los servidores que ejecutan
los componentes de rastreo de bsqueda procesan datos con ms 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 caractersticas de
almacenamiento en cach de SharePoint Server 2010 pueden requerir ms memoria tambin.
En general, los requisitos de memoria del servidor web dependen considerablemente del nmero de grupos de aplicaciones habilitadas
en la granja de servidores y del nmero de solicitudes simultneas que se atienden. En la mayora de las implementaciones de
SharePoint Server de produccin, se recomienda asignar al menos 8 GB de RAM a cada servidor web y 16 GB en el caso de servidores
con ms trfico o implementaciones con varios grupos de aplicaciones configurados para su aislamiento.
62
Los requisitos de memoria de los servidores de aplicaciones tambin son diferentes; algunas caractersticas de SharePoint Server
requieren ms memoria en el nivel de aplicaciones que otras. En la mayora de las implementaciones de SharePoint Server en
produccin 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 clculo de Excel y el Servicio de bsqueda de SharePoint Server.
Los requisitos de memoria de los servidores de bases de datos son muy dependientes de los tamaos de las bases de datos. Para
obtener ms informacin acerca de la eleccin de la memoria para los equipos basados en SQL Server, vea Planeacin y configuracin
del almacenamiento y capacidad de SQL Server (SharePoint Server 2010).
Eleccin de las redes
Adems del beneficio que ofrecen a los usuarios los clientes que tienen acceso rpido a los datos a travs de la red, una granja de
servidores distribuida debe tener acceso rpido para la comunicacin entre servidores, especialmente al distribuir los servicios entre
varios servidores o al federar algunos de los servicios a otras granjas de servidores. Hay un trfico 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 fcilmente 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 trfico de usuarios finales y la otra para controlar la comunicacin 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 aplicacin de servicio deben estar lo ms cerca posible del servidor de aplicaciones
de consumo tambin. La red entre los servidores de la granja de servidores debe tener al menos de 1 Gbps de ancho de banda.
Eleccin de los discos y el almacenamiento
La administracin 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 estimacin de requisitos de datos ms alta, para permitir
el crecimiento futuro. Adems, en la mayora de los entornos de produccin, 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
trfico (E/S por segundo) que requerirn las bases de datos principales en la implementacin y asignar suficientes discos para satisfacer
ese trfico.
Para obtener ms informacin acerca de cmo elegir los discos para los servidores de bases de datos, vea Planeacin y configuracin
del almacenamiento y capacidad de SQL Server (SharePoint Server 2010).
63
Los servidores web y los servidores de aplicaciones tambin tienen requisitos de almacenamiento. En la mayora de los entornos de
produccin, 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 optimizacin

La fase de pruebas y optimizacin es un componente esencial de la administracin eficaz de la capacidad. Debe probar las arquitecturas
nuevas antes de implementarlas en produccin y llevar a cabo pruebas de aceptacin junto con los siguientes procedimientos
recomendados de supervisin para garantizar que las arquitecturas que disee 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 implementacin real. Si realiza
una actualizacin 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 caractersticas 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 preproduccin:
Cree el entorno de prueba de modo que imite la arquitectura inicial que dise en el Paso 2: Diseo.
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 sinttica 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 ms pequeo 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 implementacin en el entorno de produccin.
Prueba
Las pruebas son un factor esencial para determinar si el diseo del sistema es capaz de admitir la carga de trabajo y las caractersticas
de uso. Vea Pruebas de rendimiento para SharePoint Server 2010 para obtener ms informacin acerca de cmo probar la
implementacin de SharePoint Server 2010.
Creacin de un plan de pruebas
64
Creacin del entorno de prueba
Creacin de pruebas y herramientas
Implementacin del entorno piloto
Antes de implementar SharePoint Server 2010 en un entorno de produccin, 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 mxima esperada. En primer lugar, se recomienda probar el entorno piloto con una carga sinttica, especialmente en las
implementaciones de gran tamao, y, a continuacin, someterlo al esfuerzo de un pequeo conjunto de usuarios activos y contenido en
directo. La ventaja de analizar un entorno piloto con un pequeo grupo de usuarios en directo es la oportunidad de validar algunos de los
supuestos planteados acerca de las caractersticas de uso y el crecimiento del contenido antes de usarlo plenamente en el entorno de
produccin.
Optimizacin
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 topologa, es posible que deba revisar la solucin. Por ejemplo, si sus requisitos iniciales fueron para una sola
granja de servidores para colaboracin, bsqueda y social, es posible que deba federar algunos de los servicios, como bsqueda, a una
granja de servidores de servicios dedicados, o dividir la carga de trabajo entre ms granjas de servidores. Una alternativa consiste en
implementar una granja de servidores dedicada para la actividad social y otra para la colaboracin en equipo.
Paso 4: Implementacin
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 produccin.
La estrategia de implementacin apropiada variar en funcin del entorno y la situacin. Si bien por lo general la implementacin de
SharePoint Server est fuera del alcance de este documento, el ejercicio de planeacin de la capacidad puede plantear ciertas
actividades sugeridas. A continuacin se describen algunos ejemplos:
Implementacin de una nueva granja de servidores de SharePoint Server: el ejercicio de planeacin de la capacidad debera
haber guiado y confirmado los planes para el diseo y la implementacin de SharePoint Server 2010. En este caso, la
implementacin ser la primera implementacin amplia de SharePoint Server 2010. Habr que mover o volver a generar los
servidores y servicios que se usaron durante los ejercicios de planeacin de la capacidad en el entorno de produccin. Este es el
escenario ms sencillo ya que no es necesario realizar actualizaciones ni modificaciones en una granja de servidores existente.
65
Actualizacin de una granja de servidores de Office SharePoint Server 2007 a SharePoint Server 2010: el ejercicio de
planeacin de la capacidad debera haber validado el diseo 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 planeacin de la capacidad debera haber incluido migraciones de prueba para validar
el tiempo que llevar el proceso de actualizacin, si es necesario modificar o reemplazar cdigo personalizado, si las herramientas de
terceros necesitan actualizarse, etc. Al finalizar la planeacin de la capacidad, debera tener un diseo validado y una idea de cunto
tiempo llevar la actualizacin, as como un plan para implementar el proceso de actualizacin de forma ptima, por ejemplo, una
actualizacin en contexto, o la migracin de las bases de datos de contenido a una nueva granja de servidores. Si realiza una
actualizacin en contexto, durante la planeacin 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 planeacin debera ser una
lista de los cambios de hardware necesarios y un plan detallado para la implementacin de los cambios de hardware en la granja de
servidores. Una vez implementada la plataforma de hardware que se valid durante la planeacin de la capacidad, puede continuar
con el proceso de actualizacin a SharePoint Server 2010.
Mejora del rendimiento de una granja de servidores de SharePoint Server 2010 existente: el ejercicio de planeacin de la
capacidad debera haberle ayudado a identificar los cuellos de botella de la implementacin actual, disear formas de reducir o
eliminar dichos cuellos de botellas y validar una implementacin 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 planeacin de la capacidad y, a
continuacin, debe formularse un plan de implementacin segn los resultados de las pruebas.
Paso 5: Supervisin 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 especfica de la granja de servidores requiere
atencin y saber cmo 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 topologa o cambiar la forma en que se almacenan
los datos.
Vea Supervisin y mantenimiento de SharePoint Server 2010 para obtener una lista de las opciones de configuracin 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 supervisin, se ver afectada la cantidad de espacio en disco que requiere la base de datos
66
de uso. Una vez que el entorno sea estable y esta supervisin detallada ya no sea necesaria, se aconseja revertir la configuracin a los
valores predeterminados.
Para obtener ms informacin acerca de cmo supervisar el estado y solucionar problemas usando las herramientas de seguimiento de
estado integradas en la interfaz de Administracin central de SharePoint Server, lea los siguientes temas:
Solucin de problemas (http://technet.microsoft.com/es-es/library/ee748639.aspx)
Vea tambin
Conceptos
Otros recursos
67
En este artculo se describe cmo probar el rendimiento de Microsoft SharePoint Server 2010. La fase de prueba y optimizacin es un
componente esencial de la administracin eficaz de la capacidad. Se recomienda probar las arquitecturas nuevas antes de
implementarlas en produccin y llevar a cabo pruebas de aceptacin junto con los siguientes procedimientos recomendados de
supervisin para garantizar que las arquitecturas que se diseen 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 actualizacin
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 caractersticas 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 Planeacin de la capacidad para SharePoint
Server 2010.
Estos son los pasos secundarios recomendados que se deben seguir para la preproduccin:
Cree el entorno de prueba de modo que imite la arquitectura inicial que dise en Paso 2: Diseo.
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 sinttica 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 ms pequeo 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 produccin.
2010.
En este artculo:
68

Compruebe que el plan incluye:
Hardware que est diseado para funcionar segn los objetivos de rendimiento de produccin previstos. Siempre mida el rendimiento
de los sistemas de prueba de forma conservadora.
Si dispone de cdigo 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
produccin.
Conozca el objetivo de la prueba. Asegrese de entender cules 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
cunto tiempo llevar rastrear e indizar un conjunto de contenido? Se trata de determinar cuntas 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 cules sern los objetivos.
Entienda cmo 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 pgina. Si va a medir el rendimiento de bsqueda, le
conviene medir el tiempo de rastreo y las tasas de indizacin 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.

Una vez que haya decidido cules son los objetivos de la prueba y definido las medidas, y despus de establecer cules son los
requisitos de capacidad de la granja de servidores (en los pasos 1 y 2 de este proceso), el siguiente objetivo es disear y crear el entorno
de prueba. A menudo se subestima el esfuerzo necesario para crear un entorno de prueba. Debera intentar reproducir el entorno de
produccin con la mayor fidelidad posible. Algunas de las caractersticas y funcionalidad que debera tener en cuenta al disear el
entorno de prueba son:
69
Autenticacin: decida si la granja de servidores usar Servicios de dominio de Active Directory (AD DS), autenticacin basada en
formularios (y, en ese caso, con qu directorio), autenticacin basada en notificaciones, etc. Independientemente del directorio que
use, cuntos usuarios necesita en el entorno de prueba y cmo va a crearlos? Cuntos grupos o roles va a necesitar y cmo los
crear y rellenar? Tambin deber asegurarse de que tiene suficientes recursos asignados a los servicios de autenticacin para que
no produzcan un cuello de botella durante la prueba.
DNS: sepa qu espacios de nombres necesitar durante las pruebas. Identifique qu servidores respondern a dichas solicitudes y
asegrese 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 ms de un servidor (lo cual es normal ya que de lo contrario no tendra suficiente carga para justificar una
prueba de carga), necesitar algn tipo de solucin de equilibrio de carga. Podra usar un hardware de equilibrio de carga, o bien
algn software de equilibrio de carga, como Windows NLB. Decida qu usar y escriba toda la informacin de configuracin que
necesitar para configurar la solucin con rapidez y eficacia. Otro punto que debe recordar es que los agentes de prueba de carga
normalmente intentan resolver una direccin 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 tambin las mquinas necesarias para ejecutar las pruebas. Por lo general, necesitar como mnimo
tres servidores, aunque en algunos casos pueden necesitarse ms. Si usa Visual Studio Team System (Team Test Load Agent) para
realizar las pruebas, una mquina se usar como controlador de prueba de carga. Por lo general, se usan dos o ms mquinas como
agentes de prueba de carga. Los agentes son las mquinas 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. Tambin debe supervisar los servidores de prueba durante su ejecucin de la misma forma
en que supervisara 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 mxima que puede admitir la granja de servidores.
SQL Server: en el entorno de prueba, siga las recomendaciones de las secciones "Configuracin de SQL Server" y "Validacin y
supervisin del almacenamiento y el rendimiento de SQL Server" del artculo Planeacin y configuracin del almacenamiento y
capacidad de SQL Server (SharePoint Server 2010).
70
Validacin 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 produccin existente. Por ejemplo, puede hacer una copia de seguridad de las bases de datos de contenido
de una granja de servidores de produccin y restaurarlas en el entorno de prueba y, a continuacin, 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 pginas; no debe desprotegerse nada.
La navegacin debe ser realista; no cree ms que lo que espera usar razonablemente en produccin.
Debe tener una idea de las personalizaciones que usar el sitio de produccin. Por ejemplo, las pginas maestras, las hojas de
estilos, JavaScript, etc. deben implementarse en el entorno de prueba de la forma ms parecida posible al entorno de produccin.
Determine cuntos grupos de SharePoint y niveles de permisos va a necesitar y cmo va a asociar a los usuarios con ellos.
Averige si necesitar importar perfiles y cunto tiempo llevar el proceso.
Determine si va a necesitar audiencias y cmo va a crearlas y rellenarlas.
Determine si necesita orgenes de contenido de bsqueda 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 bsqueda 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 bsqueda ya que el procesador de consultas pasar una cierta cantidad de tiempo detectando duplicados,
lo cual no hara en un entorno de produccin con contenido real.

Despus de comprobar el funcionamiento del entorno de prueba, es momento de crear y ajustar las pruebas que se usarn para medir la
capacidad de rendimiento de la granja de servidores. En esta seccin a veces se har referencia especficamente 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 informacin 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").
71
Tambin 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 sinttica respecto de SharePoint Foundation 2010 o SharePoint Server 2010 como parte de un ejercicio de
planeacin de capacidad o de una prueba de esfuerzo previa a la actualizacin.
El Kit de pruebas de carga se incluye en el kit de herramientas de administracin 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 tendran acceso a una amplia gama de
contenido en una granja de servidores de SharePoint Server 2010 de produccin. 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 rgida para obtener
acceso a una pgina especfica, debe usar tan solo unas pocas pruebas que usen orgenes de datos que contengan las direcciones URL
de dichos elementos para obtener acceso dinmico a ese conjunto de pginas.
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 ms fcil administrar y transportar un formato de archivo CSV entre los entornos de desarrollo y de prueba. Tenga en cuenta
que la creacin de archivos CSV con dicho contenido puede requerir la creacin 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 almacn de autenticacin si usa autenticacin 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 contraseas para usuarios de prueba; stas son las cuentas de usuario con las que se
ejecutarn 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 jerarqua,
etc.), y otros contengan solo lectores, etc.
Crear una lista de frases y palabras clave de bsqueda de ejemplo
72
Rellenar los grupos y niveles de permisos de SharePoint con usuarios y grupos de Active Directory (o roles si usa autenticacin
basada en formularios)
Al crear pruebas web, existen otros procedimientos recomendados que debera observar e implementar, como por ejemplo:
Registre pruebas web simples para empezar. Estas pruebas contendrn valores codificados de forma rgida para parmetros como
direccin URL, identificador, etc. Reemplace los valores codificados de forma rgida con vnculos 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 validacin para la prueba. Por ejemplo, cuando solicite una pgina, si se produce un error, normalmente
obtendr la pgina error.aspx como respuesta. Desde la perspectiva de una prueba web aparece como si fuera una respuesta
positiva ms, ya que obtendr un cdigo de estado HTTP 200 (correcto) en la carga de los resultados de pruebas. Pero obviamente
se ha producido un error, por lo que debera seguirse de manera diferente. Crear una o varias reglas de validacin permite interceptar
cuando cierto texto se enva como respuesta de forma tal que la validacin produzca un error y la solicitud se marque como error
tambin. Por ejemplo, en Visual Studio Team System (Team Test Load Agent), una regla de validacin simple podra ser una
validacin ResponseUrl, que registra un error si la pgina que se representa despus de los redireccionamientos no es la misma
pgina de respuesta que se registr en la prueba. Tambin 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 segn los derechos del usuario actual. Por ejemplo, un administrador de una coleccin de
sitios o un usuario autenticado con derechos de aprobacin o de creacin no obtendrn resultados almacenados en cach ya que
siempre deseamos que vean la versin ms reciente del contenido. Sin embargo, los usuarios annimos obtendrn el contenido
almacenado en cach. Debe asegurarse de que los usuarios de prueba representen una combinacin de estos roles que coincida
aproximadamente con la combinacin de usuarios en el entorno de produccin. Por ejemplo, en produccin 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 pginas son realizadas por cuentas de usuarios que son administradores de colecciones de sitios sobre el contenido de la prueba.
El anlisis de las solicitudes dependientes es un atributo de Visual Studio Team System (Team Test Load Agent) que determina si el
agente de prueba debera intentar recuperar solo la pgina, o la pgina y todas las solicitudes asociadas que forman parte de la
pgina, como imgenes, hojas de estilos, scripts, etc. Durante una prueba de carga, estos elementos se suelen ignorar por varias
razones:
Cuando un usuario visita un sitio por primera vez, el explorador local suele almacenar estos elementos en la memoria cach
73
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 razn no va a usar la memoria cach BLOB, entonces podra convenirle habilitar el anlisis de solicitudes dependientes
en las pruebas. Sin embargo, esto es realmente una excepcin y no la regla general para la mayora de las implementaciones. Tenga en
cuenta que si se activa, puede inflar significativamente los nmeros de RPS notificados por el controlador de prueba. Estas solicitudes se
atienden tan rpidamente que pueden inducirle a pensar de forma errnea que hay ms capacidad disponible en la granja de servidores
que la que hay realmente.
Recuerde modelar la actividad de las aplicaciones cliente tambin. Las aplicaciones cliente, como Microsoft Word, PowerPoint, Excel
y Outlook, generan solicitudes a granjas de servidores de SharePoint Server 2010 tambin. Agregan carga al entorno enviando a los
servidores solicitudes tales como recuperar fuentes RSS, adquirir informacin 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 implementacin.
En la mayora de los casos, una prueba web debe contener una nica solicitud. Es ms fcil ajustar y solucionar los problemas del
arns de prueba y las solicitudes individuales si la prueba contiene una sola solicitud. Normalmente, las pruebas web deben contener
varias solicitudes si la operacin 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. Tambin 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. Asegrese de que cada prueba puede completarse correctamente antes de ejecutarla
en una prueba de carga ms 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 pginas individuales, carga de documentos, visualizacin 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 produccin son consultas de bsqueda, entonces en la prueba de carga debera 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
tambin la forma en que se configuran elementos como la combinacin de exploradores, la combinacin de redes, los modelos de carga
y la configuracin de ejecucin.
Hay algunos procedimientos adicionales que debera tener en cuenta e implementar para las pruebas de carga:
74
Use una proporcin de lectura y escritura razonable en las pruebas. Si se sobrecarga el nmero de escrituras en una prueba, puede
verse considerablemente afectada la capacidad de proceso general. Incluso en granjas de servidores de colaboracin, las
proporciones de lectura y escritura suelen incluir muchas ms lecturas que escrituras. Para obtener ms informacin, vea la pgina
sobre casos tcnicos prcticos 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 deberan estar realizndose durante la
prueba de carga. Por ejemplo, operaciones como la copia de seguridad y restauracin no se realizan normalmente durante una
prueba de carga. Es posible que un rastreo de bsqueda completo no se ejecute durante una prueba de carga, mientras que un
rastreo incremental puede ser normal. Debe considerar cmo se programarn estas tareas en produccin: se ejecutarn en los
momentos de mxima carga? Si no es as, entonces deberan excluirse durante las pruebas de carga, cuando se intenta determinar
la carga de estado de equilibrio mxima que puede admitir para el trfico pico.
No use tiempos de reflexin. Los tiempos de reflexin son una caracterstica 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 pgina. Por ejemplo, un usuario tpico puede
cargar una pgina, pasar tres minutos leyndola y despus hacer clic en un vnculo de la pgina para visitar otro sitio. Tratar de
modelar esto en un entorno de prueba es prcticamente imposible de hacer de forma correcta y eficaz y no agrega valor a los
resultados de las pruebas. Es difcil de modelar porque la mayora 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 publicacin, de
bsqueda, de colaboracin, etc.). En realidad, tampoco agrega valor debido a que aunque un usuario pueda hacer una pausa entre
las solicitudes de pgina, 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 vnculos de una pgina.
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 nmero de usuarios que desea simular. Esto no tiene nada que ver con los usuarios de las aplicaciones.
En realidad, se trata simplemente del nmero de subprocesos que se van a usar en los agentes de prueba de carga para generar las
solicitudes. Un error comn es pensar que si la implementacin tendr, por ejemplo, 5.000 usuarios, 5.000 es el nmero 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 planeacin de capacidad, los requisitos de uso deben basarse en el nmero de solicitudes por segundo y no
en el nmero 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 ms reproducibles y confiables en las pruebas. En Visual Studio Team
System (Team Test Load Agent) tiene la opcin de basar la carga en un nmero constante de usuarios (subprocesos, como se
explic en el punto anterior), un modelo de carga de usuarios incremental o una prueba de uso basada en objetivos. Un modelo de
75
carga incremental es cuando comienza con un nmero de usuarios menor y lo va incrementando agregando ms usuarios cada
pocos minutos. Una prueba de uso basada en objetivos es cuando se establece un umbral para un determinado contador de
diagnstico, como utilizacin de CPU, y la prueba intenta controlar la carga para mantener dicho contador entre un umbral mnimo y
mximo definidos. Sin embargo, si solo desea determinar la capacidad de proceso mxima que puede admitir la granja de servidores
de SharePoint Server 2010 durante los picos de carga, es ms eficaz y preciso simplemente elegir un modelo de carga constante.
Esto permite identificar ms fcilmente la cantidad de carga que el sistema puede admitir antes de comenzar a exceder regularmente
los umbrales que deberan 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 escribirn algunos datos en SQL
Server. Para garantizar un conjunto de resultados coherente y legtimo en cada prueba de carga, debe tener una copia de seguridad
disponible antes de ejecutar la primera prueba de carga. Una vez finalizada cada prueba de carga, se debe usar la copia de seguridad
para restaurar el contenido al estado en que se encontraba antes de iniciar la prueba.
Vea tambin
Conceptos
Otros recursos
76
En este artculo se proporciona informacin acerca de la supervisin 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 especfica de la granja de servidores requiere atencin y saber cmo 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 topologa o cambie el modo en que se almacenan los datos.
La informacin de esta seccin est dirigida a los administradores, para ayudarles a configurar manualmente los contadores de
rendimiento y otras opciones de configuracin. Para obtener ms informacin acerca del seguimiento de estado y la solucin de
problemas mediante las herramientas de seguimiento de estado integradas en la interfaz de Administracin central de SharePoint,
consulte los siguientes artculos:
2010.
En este artculo:
Configuracin de la supervisin
Eliminacin de cuellos de botella
Configuracin de la supervisin
A continuacin se proporciona una lista de las opciones de configuracin que se pueden modificar para supervisar el entorno en sus
etapas iniciales, y que ayudar a determinar si necesita realizar algn cambio. Tenga en cuenta que el aumento de la funcionalidad de
supervisin 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
supervisin detallada ya no es necesaria, puede que desee revertir las opciones de configuracin siguientes a sus valores
predeterminados.
77
Opcin Valor Notas
Proteccin de "flood" del registro de eventos Deshabilitado El valor predeterminado es

Habilitado. Se puede
deshabilitar para recopilar
la mayor cantidad de datos
de supervisin posible.
Para las operaciones
normales, debe estar
habilitado.
Programacin de trabajos del temporizador
Importacin de datos de uso de Microsoft SharePoint 5 minutos El valor predeterminado es
Foundation 30 minutos. Al disminuir
este valor, se importarn
los datos a la base de
datos de uso con mayor
frecuencia, lo cual es
especialmente til para
solucin de problemas.
normales, el valor debe ser
30 minutos.
Proveedores de diagnstico
Habilitar todos los proveedores de diagnstico Habilitado El valor predeterminado es
Deshabilitado excepto
para el proveedor de
eventos de rastreo de
Seguimiento de estado de
bsqueda. Estos
78
Opcin Valor Notas
proveedores recopilan
datos de estado de
diversos componentes y
caractersticas. Para las
operaciones normales,
puede que desee revertir
al valor predeterminado.
Establecer los intervalos de programacin "job- 1 minuto El valor predeterminado es
diagnostics-performance-counter-wfe-provider" y "job- 5 minutos. Al disminuir
diagnostics-performance-counter-sql-provider" este valor, se sondearn
los datos con mayor
frecuencia, lo cual es
especialmente til para
solucin de problemas.
normales, el valor debe ser
5 minutos.
Varios
Habilitar el seguimiento de la pila para solicitudes de Habilitado El valor predeterminado es
contenido Deshabilitado. Al habilitar
esta opcin, se realizar
un diagnstico de los
errores de las solicitudes
de contenido mediante el
seguimiento de la pila del
proceso. Para las
debe deshabilitarse.
Habilitar el panel del programador Habilitado El valor predeterminado es
79
Opcin Valor Notas
Deshabilitado. Si habilita
esta opcin, se realizar
un diagnstico de las
pginas lentas u otros
problemas mediante el
panel del programador.
Esta opcin debe
deshabilitarse para las
siempre que la solucin de
problemas ya no sea
necesaria.
Recoleccin de datos de uso
Uso de importacin de contenido Habilitado Al habilitar el registro de
Uso de exportacin de contenido este conjunto de
contadores, podr
Solicitudes de pgina
recopilar ms datos de uso
Uso de caractersticas de todo el entorno y
Uso de consulta de bsqueda comprender mejor los
Uso del inventario de sitios patrones de trfico en el
entorno.
Trabajos del temporizador
Uso de calificacin
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 automticamente a un intervalo especfico (el valor predeterminado es de 30 minutos).
De esta manera, podr consultar la base de datos de uso para recuperar los contadores y crear grficos con los resultados distribuidos
80
en el tiempo. A continuacin, 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
cdigo
Add-SPDiagnosticsPerformanceCounter -Category "Processor" -Counter "% Processor Time" -Instance "_Total" -WebFrontEnd
Existe una serie de contadores de rendimiento genricos que se deben supervisar para cualquier sistema de servidor. En la siguiente
tabla se describen estos contadores de rendimiento.
Contador de rendimiento Descripcin
Procesador Debe supervisar el rendimiento del procesador para asegurarse de

que todo el uso del procesador no se mantenga constantemente alto
(ms del 80 por ciento), ya que esto indica que el sistema no sera
capaz de controlar los flujos de actividad repentinos. En el estado
comn, 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, an haya espacio
para que los otros dos se ocupen de la carga adicional.
Interfaz de red Supervise la velocidad del envo y recepcin de datos a travs 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 lgico que debe supervisar
regularmente. El espacio disponible en disco es esencial en un
estudio de capacidad, pero tambin debe revisar el tiempo que el
disco est inactivo. Segn los tipos de aplicaciones o servicios que
ejecute en los servidores, es posible que deba revisar los tiempos
81
Contador de rendimiento Descripcin
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 paginacin Supervise la cantidad de memoria fsica disponible para la
asignacin. Si no hay suficiente memoria, se har un uso excesivo
del archivo de paginacin y se producir un aumento del nmero de
errores de pgina por segundo.
Contadores del sistema

En la tabla siguiente se proporciona informacin 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 Descripcin
Procesador
% de tiempo de procesador Muestra el uso del procesador durante un perodo 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. Tambin puede medir el uso
de cada procesador, para garantizar el rendimiento equilibrado entre
los ncleos.
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 podra no ser un
82
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 nmero de lecturas de disco por segundo.
Escrituras en disco/s El nmero de escrituras de disco por segundo.
Memoria
MB disponibles Muestra la cantidad de memoria fsica disponible para la asignacin.
Si no hay suficiente memoria, se har un uso excesivo del archivo
de paginacin y se producir un aumento del nmero de errores de
pgina por segundo.
Errores de cach/s Este contador muestra la velocidad a la que se producen errores
cuando se busca una pgina en la memoria cach del sistema de
archivos y no se encuentra. Puede tratarse de un error flexible,
cuando la pgina se encuentra en la memoria; o de o un error
severo, cuando la pgina 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
podra estar indicado por una disminucin de Lecturas
asincrnicas rpidas/s o Lecturas anticipadas/s.
Pginas por segundo Este contador muestra la velocidad a la que las pginas se leen
desde el disco o se escriben en l para resolver errores graves en la
pgina. Si aumenta, indica que hay problemas de rendimiento en
todo el sistema.
83
Archivo de paginacin
% usado y % de uso mximo El archivo de paginacin del servidor, a veces denominado archivo
de intercambio, contiene las direcciones de memoria "virtuales" en el
disco. Los errores de pgina ocurren cuando un proceso se tiene
que detener y esperar mientras se recuperan los recursos "virtuales"
del disco en la memoria. Estos sern ms frecuentes si la memoria
fsica no es la adecuada.
NIC
Total de bytes/s Se trata de la velocidad del envo y recepcin de datos a travs de
la tarjeta de interfaz de red. Es posible que tenga que investigar ms
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 tamao 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 nmero actual de subprocesos.
ASP.NET
Total de solicitudes El nmero total de solicitudes desde que se inici el servicio.
Solicitudes en cola Microsoft SharePoint Foundation 2010 proporciona los bloques de
creacin para pginas HTML que se representan en el explorador
del usuario a travs de HTTP. Este contador muestra el nmero de
84
solicitudes en espera para ser procesadas.
Tiempo de espera de la solicitud La cantidad de milisegundos que la solicitud ms reciente esper en
la cola para ser procesada. A medida que aumenta el nmero de
eventos de espera, los usuarios experimentarn una degradacin
del rendimiento de la representacin de pgina.
Solicitudes rechazadas El nmero total de solicitudes que no se ejecutaron debido a que los
recursos del servidor eran insuficientes para procesarlas. Este
contador representa el nmero de solicitudes que devuelven un
cdigo de estado HTTP 503, que indica que el servidor est
demasiado ocupado.
Solicitudes en ejecucin (_Total) El nmero de solicitudes actualmente en ejecucin.
Solicitudes por segundo (_Total) El nmero de solicitudes ejecutadas por segundo. Esto representa
la capacidad de rendimiento actual de la aplicacin. Con una carga
constante, este nmero debe permanecer dentro de un intervalo
determinado, bloqueando otros trabajos de servidor (por ejemplo, la
recoleccin de elementos no usados, el subproceso de limpieza de
cach, las herramientas de servidor externo, entre otros).
Memoria de .NET CLR
Nmero de colecciones de gen. 0 Muestra el nmero de veces que los objetos de generacin 0 (es
decir, los objetos ms recientes, asignados ltimamente) se
recopilaron como elementos no usados desde que se inici la
aplicacin. Este nmero sirve como una relacin de #Gen 0: #Gen
1: #Gen 2 para asegurarse de que el nmero de colecciones de
generacin 2 no sea muy superior al de las colecciones de
generacin 0; lo ptimo es un factor de 2.
Nmero de colecciones de gen. 1 Muestra el nmero de veces que los objetos de generacin 1 se
85
aplicacin.
Nmero de colecciones de gen. 2 Muestra el nmero de veces que los objetos de generacin 2 se
aplicacin. El contador se incrementa al final de una recoleccin de
elementos no usados de generacin 2 (tambin denominada
recoleccin completa de elementos no usados).
% de tiempo del GC Muestra el porcentaje de tiempo transcurrido que se dedic a
realizar una recoleccin de elementos no usados desde el ltimo
ciclo de recoleccin 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 aplicacin.
Este contador solo se actualiza al final de cada recoleccin 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 informacin acerca de los objetos y contadores SQL Server.
Estadsticas generales Este objeto proporciona contadores para supervisar la actividad

general de todo el servidor, por ejemplo, el nmero de conexiones
actuales y el nmero 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 nmero de conexiones de usuario en la
instancia de SQL Server. Si este nmero aumenta al 500 por ciento
86
de su lnea 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
restauracin, as como las actividades de registro de transacciones.
Supervise las transacciones y el registro de transacciones para
determinar cunta actividad de usuario se produce en la base de
datos y cunto 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 tamao del registro, los bloqueos y la
replicacin. La supervisin 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 nmero ayuda a crear una lnea base y solucionar
problemas.
Bloqueos Este objeto brinda informacin acerca de los bloqueos de SQL
Server en tipos de recursos individuales.
Nmero de interbloqueos/s Este contador muestra el nmero 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 nmero de bloqueos por segundo que no
se pudieron satisfacer inmediatamente y que tuvieron que esperar
recursos.
87
Bloqueos temporales Este objeto proporciona contadores para supervisar los bloqueos de
recursos de SQL Server internos llamados bloqueos temporales. La
supervisin 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 nmero de solicitudes de bloqueos
temporales por segundo que no pudieron concederse
inmediatamente.
Estadsticas SQL Este objeto proporciona contadores para supervisar la compilacin y
el tipo de solicitudes enviadas a una instancia de SQL Server.
Supervisar el nmero de compilaciones y nuevas compilaciones de
consulta y el nmero 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 nmero de veces que se especifica la ruta
de acceso al cdigo de compilacin por segundo.
Recompilaciones SQL/s Este contador indica el nmero de veces que se desencadenan
recompilaciones de instruccin por segundo.
Cach del plan Este objeto proporciona contadores para supervisar cmo 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
88
bsquedas de planes.
Cach del bfer Este objeto proporciona contadores para supervisar cmo usa SQL
Server la memoria para almacenar las pginas de datos, las
estructuras de datos internos y la memoria cach de
procedimientos, as como los contadores para supervisar la E/S
fsica mientras SQL Server lee y escribe pginas de base de datos.
Frecuencia de aciertos de cach del bfer Este contador muestra el porcentaje de pginas que se encontraron
en la memoria cach del bfer sin necesidad de leer el disco. La
relacin es el nmero total de aciertos de cach dividido por el
nmero total de bsquedas de cach desde que se inici una
instancia de SQL Server.
Eliminacin de cuellos de botella

Los cuellos de botella del sistema representan un punto de contencin cuando no hay suficientes recursos para atender las solicitudes de
transacciones de usuario. Pueden estar basados en hardware fsico, entorno operativo o aplicaciones. A menudo, el motivo del cuello de
botella es cdigo personalizado o soluciones de terceros ineficaces; si se revisan esos elementos, se podran obtener mejores resultados
que si se agrega hardware. Otra causa comn de los cuellos de botella es un error de configuracin de la granja de servidores o una
implementacin ineficaz de la solucin que estructura los datos de modo que se requieren ms recursos que los necesarios. Es esencial
que un administrador del sistema administre los cuellos de botella mediante la supervisin constante del rendimiento. Cuando identifica
un problema de rendimiento, debe evaluar la mejor solucin para eliminar el cuello de botella. Los contadores de rendimiento y otras
aplicaciones de supervisin del rendimiento, como System Center Operations Manager (SCOM), son las herramientas clave de
seguimiento y anlisis de problemas para que pueda desarrollar una solucin.
Resolucin de cuellos de botella fsicos
Los cuellos de botella fsicos se basan en la contencin de red, memoria, disco y procesador: demasiadas solicitudes para muy pocos
recursos fsicos. Los objetos y contadores que se describen en el tema sobre la supervisin de rendimiento indican que el problema de
rendimiento se encuentra, por ejemplo, en el procesador de hardware o ASP.NET. La resolucin de cuellos de botella requiere que
identifique el problema de rendimiento y, a continuacin, realice un cambio o varios para mitigarlo.
89
Los problemas rara vez aparecen de forma repentina; normalmente, se produce una degradacin gradual del rendimiento. Puede realizar
un seguimiento de esta degradacin si supervisa peridicamente mediante la herramienta Monitor de rendimiento o un sistema ms
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 configuracin de hardware o del sistema, una vez que
haya determinado que no estn ocasionados por un error de configuracin, soluciones de terceros o cdigo personalizado ineficaces, o
una implementacin ineficaz de la solucin. En las siguientes tablas se identifican el umbral del problema y las posibles opciones de
resolucin. Algunas de las opciones sugieren actualizaciones o modificaciones de hardware.
Objetos y contadores Problema Opciones de resolucin
Procesador
Procesador - % de tiempo de procesador Ms del 75-85% Actualizar el procesador
Aumentar el nmero de procesadores
Agregar servidores adicionales
Disco
Promedio de longitud de la cola de disco Aumento gradual, el sistema no est en un Aumentar la cantidad o la velocidad de discos
estado estable y se est realizando una Cambiar la configuracin de la matriz a franja
copia de seguridad de la cola
Mover algunos datos a un servidor alternativo
% de tiempo de inactividad Ms del 90% Aumentar el nmero de discos
Mover los datos a un servidor o disco alternativo
% de espacio disponible Menos del 30% Aumentar el nmero de discos
Memoria
MB disponibles Menos de 2 GB en un servidor web. Agregar memoria.
90
Nota:
La memoria disponible del servidor SQL Server
ser baja debido a su diseo y no siempre
indicar un problema.
Errores de cach/s Mayor que 1 Agregar memoria

Aumentar el tamao o la velocidad de la memoria
cach si es posible
Pginas por segundo Mayor que 10 Agregar memoria
Archivo de paginacin
% usado y % de uso mximo El archivo de paginacin del servidor, a Agregar memoria
veces denominado archivo de intercambio,
contiene las direcciones de memoria
"virtuales" en el disco. Los errores de
pgina ocurren cuando un proceso se
tiene que detener y esperar mientras se
recuperan los recursos "virtuales" del disco
en la memoria. Estos sern ms
frecuentes si la memoria fsica no es la
adecuada.
NIC
Total de bytes/s Ms del 40-50% de la capacidad de red. Investigar ms mediante la supervisin de Bytes
Se trata de la velocidad del envo y recibidos/s y Bytes enviados/s.
recepcin de datos a travs de la tarjeta
91
de interfaz de red. Reevaluar la velocidad de la tarjeta de interfaz de
red
Comprobar el nmero, tamao y uso de bferes
de memoria
Proceso
Espacio de trabajo Ms del 80% de la memoria total Agregar memoria
% de tiempo de procesador Ms del 75-85% Aumentar el nmero de procesadores
Redistribuir la carga de trabajo en servidores
adicionales
ASP.NET
Reciclajes del grupo de aplicaciones Varios por da, lo que produce una lentitud Asegrese de que no se han implementado
intermitente. opciones de configuracin para reciclar de manera
automtica el grupo de aplicaciones
innecesariamente a lo largo del da.
Solicitudes en cola Cientos o miles de solicitudes en cola. Implementar servidores web adicionales
El valor mximo predeterminado para este
contador es 5.000. Puede cambiar esta
configuracin en el archivo Machine.config
Tiempo de espera de la solicitud A medida que aumenta el nmero de Implementar servidores web adicionales
eventos de espera, los usuarios
experimentarn una disminucin del
rendimiento de la representacin de
pgina.
Solicitudes rechazadas Mayor que 0 Implementar servidores web adicionales
92
Vea tambin
Conceptos
Otros recursos
93
Administracin de la capacidad de SharePoint Server 2010:
restricciones y lmites del software
En este documento se describen los lmites y lmites mximos del software de Microsoft SharePoint Server 2010. Estos incluyen los
siguientes:
Lmites mximos: lmites estticos que el diseo no debe exceder.
Umbrales: lmites configurables que se pueden exceder para dar cabida a ciertos requisitos.
Lmites admitidos: lmites configurables que se han establecido en un valor probado de forma predeterminada.
Nota:
La informacin acerca de la planeacin de la capacidad que se incluye en este documento proporciona directrices que se deben tener en
cuenta durante la planeacin. Esta informacin se basa en las pruebas realizadas en Microsoft con propiedades activas. No obstante, los
resultados que se obtengan pueden variar en funcin de los equipos usados y segn las caractersticas y la funcionalidad que se
implemente en los sitios.
En este artculo:
Informacin general de lmites mximos y lmites
Lmites mximos, umbrales y lmites admitidos
Lmites y lmites mximos
Lmites por jerarqua
Lmites de aplicaciones web
Lmites de servidores web y servidores de aplicaciones
94
Lmites de bases de datos de contenido
Lmites de colecciones de sitios
Lmites de listas y bibliotecas
Lmites de columnas
Lmites de pginas
Lmites por caracterstica
Lmites de bsqueda
Lmites de servicio de perfiles de usuario
Lmites de distribucin de contenido
Lmites de blogs
Lmites de Servicios de conectividad empresarial
Lmites de flujos de trabajo
Lmites de almacn de trminos de metadatos administrados (base de datos)
Lmites de Servicios de Visio
Lmites de PerformancePoint Services
Lmites de Word Automation Services
Lmites de SharePoint Workspace
Lmites de OneNote
Lmites de Office Web Application Service
Lmites de Project Server
Informacin general de lmites mximos y lmites

Este artculo contiene informacin que le ayudar a entender los lmites de rendimiento y capacidad probados de SharePoint Server 2010
y proporciona directrices sobre la relacin de los lmites con un rendimiento aceptable. Use la informacin incluida en este artculo para
determinar si la implementacin que plane se encuentra dentro de lmites de rendimiento y capacidad aceptables y para configurar de
forma adecuada los lmites en su entorno.
95
Los resultados de las pruebas y las directrices proporcionados en este artculo se aplican a un solo conjunto o granja de servidores de
SharePoint Server 2010. Si se agregan servidores a la instalacin, es posible que no aumenten los lmites de capacidad de los objetos
enumerados en las tablas de la seccin Lmites y lmites mximos ms adelante en este tema. Por otra parte, si se agregan equipos
servidores, aumentar el rendimiento de una granja de servidores, lo que podra ser necesario para lograr un rendimiento aceptable con
muchos objetos. En algunos casos, los requisitos de nmeros elevados de objetos en una solucin podran requerir ms 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
artculo pueden estar relacionados con caractersticas u operaciones del usuario que no existen en su entorno y, por lo tanto, no se
aplican a su solucin. Solo es posible obtener datos exactos sobre su propio entorno mediante pruebas exhaustivas.
Lmites mximos, umbrales y lmites admitidos
En SharePoint Server 2010, hay ciertos lmites que son de diseo y que no se pueden exceder y otros lmites que se establecen en
valores predeterminados que el administrador de la granja de servidores puede modificar. Tambin hay ciertos lmites que no estn
representados por un valor configurable, como el nmero de colecciones de sitios por aplicacin web.
Los lmites mximos son lmites absolutos que no se pueden exceder por diseo Es importante entender estos lmites para no hacer
suposiciones incorrectas al disear una granja de servidores.
Un ejemplo de lmite mximo es el lmite de tamao de documento de 2 GB; no se puede configurar SharePoint Server para
almacenar documentos de ms de 2 GB. ste es un valor absoluto integrado y no se puede exceder por diseo.
Los umbrales son lmites 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 diseo de la granja de servidores, pero es importante
entender que al hacerlo se puede ver afectado el rendimiento de la granja adems del valor efectivo de otros lmites.
El valor predeterminado de ciertos umbrales solo se puede exceder hasta un valor mximo absoluto. Un buen ejemplo es el lmite de
tamao de documento. De forma predeterminada, el umbral de tamao de documento predeterminado est establecido es 50 MB,
pero puede modificarse para admitir un lmite mximo de 2 GB.
Los lmites admitidos definen el valor probado de un parmetro especfico. Los valores predeterminados de estos lmites se definen
mediante pruebas y representan las limitaciones conocidas del producto. Si se exceden los lmites admitidos, se pueden producir
resultados inesperados, una reduccin considerable en el rendimiento u otros efectos perjudiciales.
Algunos lmites admitidos son parmetros configurables que se establecen de forma predeterminada en el valor recomendado,
mientras que otros estn relacionados con parmetros no representados por un valor configurable.
96
Un ejemplo de un lmite admitido es el nmero de colecciones de sitios por aplicacin web. El lmite admitido es de 250.000, que es la
cantidad mxima de colecciones de sitios por aplicacin web que alcanz los niveles de referencia de rendimiento durante las pruebas.
Es importante tener en cuenta que muchos de los valores lmite que se proporcionan en este documento representan un punto en una
curva que describe una carga de recursos creciente y una reduccin concomitante en el rendimiento a medida que aumenta el valor. Por
lo tanto, si se exceden ciertos lmites, como el nmero de colecciones de sitios por aplicacin web, solo podra obtenerse una reduccin
fraccional en el rendimiento de la granja de servidores. No obstante, en la mayora de los casos, el funcionamiento a un lmite establecido
o a un nivel prximo no es un procedimiento recomendado, ya que es ms fcil alcanzar las metas aceptables de rendimiento y
confiabilidad cuando el diseo de una granja de servidores proporciona un equilibrio razonable de los valores lmite.
Las directrices de umbrales y lmites admitidos estn determinadas por el rendimiento. En otras palabras, se pueden exceder los valores
predeterminados de los lmites, pero a medida que se aumenta el valor lmite, el rendimiento de la granja de servidores y el valor efectivo
de otros lmites pueden verse afectados. Muchos de los lmites de SharePoint Server pueden modificarse, pero es importante entender
cmo se vern afectadas otras partes de la granja de servidores al modificar un determinado lmite.
En SharePoint Server 2010, los umbrales y lmites admitidos se establecen mediante pruebas y la observacin 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
lmites 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 lmite 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 caractersticas presentan una latencia inaceptablemente alta mientras que otras caractersticas siguen funcionando
con parmetros aceptables. Por lo tanto, el valor mximo asignado a la cantidad de colecciones de sitios no es absoluto, sino que se
calcula en funcin de un conjunto esperado de caractersticas de uso en el que el rendimiento de la granja de servidores en general sera
aceptable en el lmite especificado en la mayora de los casos.
Obviamente, si algunos servicios funcionan con parmetros ms altos que los usados en las pruebas de lmites, los lmites efectivos
mximos de otros servicios se reducirn. Por lo tanto, es importante ejecutar rigurosos ejercicios de administracin de la capacidad y
pruebas de escala para implementaciones especficas a fin de establecer lmites efectivos para dicho entorno.
Nota: no se describe el hardware que se us para validar los lmites 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 ingls).
97
La metfora del ecualizador
Los umbrales y lmites admitidos pueden considerarse como los controles deslizantes de un ecualizador grfico, donde cada lmite
representa una determinada frecuencia. Segn esta metfora, al aumentar el valor de un lmite, se puede reducir el valor efectivo de uno
o ms lmites.
Suponga que un control deslizante representa el nmero mximo de documentos por biblioteca, un lmite admitido con un valor probado
mximo de aproximadamente 30 millones. Sin embargo, este valor depende de otro control deslizante, que representa el tamao mximo
de los documentos de la granja de servidores y que es un umbral con un valor predeterminado de 50 MB.
Si cambia el tamao mximo de los documentos a 1 GB para admitir vdeos u otros objetos grandes, el nmero de documentos que la
biblioteca puede servir a los usuarios de forma eficiente se reduce de la misma forma. Por ejemplo, la configuracin de hardware y la
topologa de una determinada granja de servidores pueden admitir 1 milln de documentos hasta 50 MB. No obstante, la misma granja
de servidores con el mismo nmero de documentos no puede alcanzar la misma latencia y metas de rendimiento si sirve un tamao de
documento promedio mayor, ya que el lmite de tamao de archivo se estableci en 1 GB.
El grado en que se reduce el nmero mximo de documentos en este ejemplo es difcil de predecir y se basa en el nmero de archivos
grandes de la biblioteca, el volumen de datos que contienen, las caractersticas de uso de la granja de servidores y la disponibilidad de
recursos de hardware.
Lmites y lmites mximos

En esta seccin se enumeran los objetos que pueden formar parte de una solucin 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 nmero de
objetos, pero el nmero no se puede exceder sin que se produzca cierta reduccin en el rendimiento o en el valor de los lmites
relacionados. Los objetos se enumeran por mbito y por caracterstica. Se proporcionan datos de lmites, as como notas que describen
las condiciones en las que se obtiene el lmite y vnculos a informacin adicional segn corresponda.
Use las directrices incluidas en este artculo para revisar sus planes de solucin generales. Si sus planes de solucin exceden las
recomendaciones para uno o varios objetos, siga uno de estos procedimientos:
Evale la solucin para garantizar que se realizan compensaciones en otras reas.
Marque estas reas para probarlas y supervisarlas durante su implementacin.
Redisee o particione la solucin para asegurarse de que no se excedan los niveles de capacidad recomendados.
Lmites por jerarqua
En esta seccin se proporcionan lmites ordenados por la jerarqua lgica de una granja de servidores de SharePoint Server 2010.
98
Lmites de aplicaciones web
En la siguiente tabla se enumeran las recomendaciones para aplicaciones web.
Lmite Valor mximo Tipo de lmite Notas
Base de datos de contenido 300 por aplicacin web Compatible Con 300 bases de datos de
contenido por aplicacin 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 coleccin
de sitios, experimentarn una
reduccin en su rendimiento.
Recomendamos usar Windows
PowerShell para administrar la
aplicacin web cuando hay
presente un gran nmero de
bases de datos de contenido, ya
que la interfaz de administracin
se vuelve lenta y difcil de
navegar.
Zona 5 por aplicacin web Lmite mximo El nmero de zonas definido para
una granja de servidores se
codifica de forma rgida en 5. Las
zonas incluyen Predeterminada,
Intranet, Extranet, Internet y
personalizada.
Ruta de acceso administrada 20 por aplicacin web Compatible Las rutas de acceso
administradas se almacenan en
99
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 aplicacin web,
se agrega ms carga al servidor
web para cada solicitud.
Si planea exceder veinte rutas de
acceso administradas en una
aplicacin web determinada,
recomendamos probar el sistema
para comprobar si tiene un
rendimiento aceptable.
Tamao de cach de la solucin 300 MB por aplicacin web Umbral La memoria cach de la solucin
permite al servicio de InfoPath
Forms mantener soluciones en la
memoria cach a fin de acelerar
la recuperacin de las soluciones.
Si se excede el tamao de
memoria cach, las soluciones se
recuperan del disco, lo que puede
demorar los tiempos de
respuesta. Puede configurar el
tamao de la memoria cach de
solucin usando el cmdlet Set-
SPInfoPathFormsService de
Windows PowerShell. Para
obtener ms informacin, vea
100
Set-SPInfoPathFormsService.
Lmites 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 nmero mximo est determinado por las
capacidades del hardware.
Este lmite 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 caractersticas de uso (los grupos
de aplicaciones con una sola aplicacin
altamente activa pueden llegar a 10 GB o
ms)
Lmites de bases de datos de contenido

En la siguiente tabla se enumeran las recomendaciones para bases de datos de contenido.
Tamao de base de datos de contenido 200 GB por base de datos de contenido Compatible Recomendamos
101
especialmente limitar el
tamao de las bases de
datos de contenido a 200
GB para garantizar el
rendimiento del sistema.
Los tamaos 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 colaboracin, como los
centros de registros. Los
tamaos de bases de datos
ms grandes se admiten
en estos escenarios ya que
los patrones de E/S y los
formatos habituales de
estructura de datos se han
diseado y probado para
escalas de mayor tamao.
Para obtener ms
informacin acerca de
repositorios de documentos
de gran escala, vea el tema
sobre la estimacin de
requisitos de rendimiento y
capacidad para repositorios
de documentos de gran
escala, disponible en
102
Recomendaciones y
resultados de pruebas de
rendimiento y capacidad
(SharePoint Server 2010),
y el tema sobre la
escenarios habituales de
administracin de
contenido a gran escala,
disponible en Enterprise
content storage planning
(SharePoint Server 2010).
Una coleccin de sitios no
debe superar los 100 GB a
menos que sea la nica
coleccin de sitios en la
base de datos.
Colecciones de sitios por base de datos de Se recomiendan 2.000 Compatible Recomendamos
contenido 5.000 mximo especialmente limitar el
nmero 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 lmites se relacionan
con la velocidad de la
actualizacin. Cuanto ms
grande sea el nmero de
colecciones de sitios en
una base de datos, ms
lenta ser la actualizacin.
103
El lmite en el nmero de
colecciones de sitios en
una base de datos est
subordinado al lmite en el
tamao de la base de
datos de contenido que
tenga ms de una
coleccin de sitios (200
GB). En consecuencia, a
medida que aumente el
nmero de colecciones de
sitios de una base de
datos, el tamao promedio
de las colecciones de sitio
que contiene deber
reducirse.
Si se excede el lmite 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
actualizacin clara y
obtener hardware adicional
para acelerar las
actualizaciones y las
actualizaciones de software
104
que afectan a las bases de
datos.
Para establecer el nivel de
advertencia para el nmero
de sitios de una base de
datos de contenido, use el
cmdlet Set-
SPContentDatabase de
Windows PowerShell con
el parmetro -
WarningSiteCount. Para
obtener ms informacin,
vea Set-
SPContentDatabase.
Subsistema de almacenamiento remoto de El tiempo hasta el primer byte de cualquier Lmite mximo Cuando SharePoint Server
blobs (RBS) en almacenamiento conectado a respuesta del NAS no puede exceder 20 2010 se configura para
la red (NAS) milisegundos. usar RBS, y los blobs en
almacenamiento NAS,
considere el siguiente
lmite mximo.
Desde el momento en que
SharePoint Server 2010
solicita un BLOB, hasta
que recibe el primer byte
del NAS, no pueden pasar
ms de 20 milisegundos.
105
Lmites de colecciones de sitios
En la siguiente tabla se enumeran las recomendaciones para colecciones de sitios.
Sitio web 250.000 por coleccin de sitios Compatible El nmero mximo

recomendado de sitios y
subsitios es 250.000
sitios.
Puede crearse un
nmero total de sitios
web muy grande si se
anidan los subsitios. Por
ejemplo, en una
jerarqua superficial con
100 sitios, cada uno de
ellos con 1.000
subsitios, tendra un
total de 100.000 sitios
web. Una jerarqua
profunda con 100 sitios,
cada uno de ellos con
10 niveles de subsitios,
tambin contendra en
total 100.000 sitios web.
Nota: la eliminacin o
creacin de un sitio o
subsitio puede afectar
considerablemente a la
disponibilidad de un
sitio. El acceso al sitio y
a los subsitios ser
106
limitado mientras se
elimina el sitio. El intento
de crear muchos
subsitios al mismo
tiempo tambin puede
producir un error.
Tamao de la coleccin de sitios 100 GB por coleccin de sitios Compatible Una coleccin de sitios
no debe superar los 100
GB a menos que sea la
nica coleccin de sitios
en la base de datos.
Ciertas acciones de
relacionadas con las
colecciones de sitios,
como la copia de
seguridad y restauracin
de una coleccin 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 ms
informacin, vea Move-
SPSite.
107
Lmites de listas y bibliotecas
En la siguiente tabla se enumeran las recomendaciones para listas y bibliotecas. Para obtener informacin, vea las notas del producto
sobre el diseo de listas grandes y maximizacin del rendimiento de listas disponible en Recomendaciones y resultados de pruebas de
rendimiento y capacidad (SharePoint Server 2010).
Tamao de filas de lista 8.000 bytes por fila Lmite mximo Cada elemento de lista o biblioteca solo puede ocupar
8.000 bytes en total en la base de datos. 256 bytes estn
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 Lmites de columnas.
Tamao de archivos 2 GB Lmite mximo El tamao de archivo mximo predeterminado es 50 MB.
El tamao puede aumentarse hasta 2 GB, pero un
volumen elevado de archivos de gran tamao 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 estndar y jerarqua
de sitios. Este valor puede variar segn la forma en que
se organizan los documentos y carpetas, y segn el tipo y
tamao de los documentos que se almacenan.
Versiones principales 400.000 Compatible Si se excede este lmite, las operaciones de archivo
bsicas, 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
estndar, jerarquas de sitio y navegacin de metadatos.
108
Este valor puede variar segn el nmero de columnas de
la lista y el uso de la lista.
Lmite de tamao de filas 6 filas de tabla internas a la Compatible Especifica el nmero mximo de filas de tablas internas a
base de datos usadas para un la base de datos que se pueden usar para un elemento
elemento de lista o biblioteca 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 travs del modelo de
objetos nicamente. El mtodo del modelo de objetos es
SPWebApplication.MaxListItemRowStorage.
Operaciones en masa 100 elementos por operacin Lmite mximo La interfaz de usuario permite seleccionar un mximo de
en masa 100 elementos para operaciones en masa.
Umbral de bsqueda en la vista 8 operaciones de combinacin Umbral Especifica la cantidad mxima de combinaciones
de lista por consulta permitidas por consulta, tales como las basadas en las
columnas de bsqueda, persona o grupo o de estado de
flujo de trabajo. Si la consulta usa ms de ocho
combinaciones, la operacin se bloquea. Esto no se
aplica a las operaciones de un solo elemento. Cuando se
usa la vista mxima mediante el modelo de objetos (sin
especificar ningn campo de vista), SharePoint devolver
hasta las primeras ocho bsquedas.
Umbral de la vista de lista 5.000 Umbral Especifica la cantidad mxima de elementos de lista o
biblioteca que puede procesar simultneamente una
operacin 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 mxima de elementos de lista o
109
auditores y administradores biblioteca que puede procesar simultneamente una
operacin de base de datos, como una consulta, cuando
un auditor o administrador con los permisos apropiados
realiza la operacin. Esta configuracin funciona junto
con Permitir invalidacin 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
nmero de subsitios supera los 2.000. De la misma
forma, el rendimiento de la pgina Todo el contenido del
sitio y del control de vista de rbol se reducirn
considerablemente a medida que aumente el nmero de
subsitios.
Coautora en Microsoft Word y 10 editores simultneos por Umbral El nmero mximo recomendado de editores simultneos
Microsoft PowerPoint para documento es 10. El lmites mximo es 99.
archivos .docx, .pptx y .ppsx Si hay 99 coautores que tienen un mismo documento
abierto para edicin simultnea, cualquier usuario
despus del nmero 100 recibir un error de "Archivo en
uso" y deber ver una copia de solo lectura.
Ms de 10 co-editores degradarn gradualmente la
experiencia del usuario y crearn ms conflictos y los
usuarios debern pasar por ms iteraciones para que sus
cambios se carguen correctamente.
mbito de seguridad 1.000 por lista Umbral El nmero mximo de mbitos de seguridad nicos
establecidos para una lista no debe exceder 1.000.
Un mbito es el lmite mximo de seguridad de un objeto
protegible y cualquiera de sus elementos secundarios que
no tenga definido un lmite mximo de seguridad
separada. Un mbito contiene una lista de control de
acceso (ACL), pero a diferencia de las ACL de NTFS, un
110
mbito puede incluir entidades de seguridad especficas 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.
Lmites de columnas
Los datos de SharePoint Server 2010 se almacenan en tablas de SQL Server. Para permitir el nmero mximo 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 combinacin de SQL en la consulta. Para evitar una carga excesiva, de forma predeterminada se
permiten como mximo seis filas de SQL Server para un elemento de SharePoint. Este lmite lleva a una limitacin particular en el
nmero de columnas de cada tipo que se pueden incluir en una lista de SharePoint. En la siguiente tabla se describen los lmites
aplicables a cada tipo de columna.
El parmetro 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 lmite. Para obtener ms informacin, vea las notas del producto
sobre el diseo de listas grandes y maximizacin del rendimiento de listas que puede consultar en Recomendaciones y resultados de
Cada tipo de columna tiene un valor de tamao expresado en bytes. La suma de todas las columnas de una lista de SharePoint no puede
exceder 8.000 bytes. Segn el uso de columnas, los usuarios pueden llegar al lmite de 8.000 bytes antes de alcanzar la limitacin de
ajuste de filas de seis filas.
Lmite Valor mximo Tipo de Tamao por Notas

lmite columna
Lnea de texto nica 276 Umbral 28 bytes El ajuste de filas de SQL Server se realiza
despus de cada 64 columnas en una lista de
111
lmite columna
SharePoint. El valor de ajuste de fila
predeterminado de seis permite un mximo de
384 columnas de lnea de texto nica por lista de
SharePoint (6 * 64 = 384). No obstante, dado que
el lmite por elemento de lista de SharePoint es de
8.000 bytes, de los cuales 256 bytes estn
reservados para columnas de SharePoint
integradas, el lmite real es de 276 columnas de
lnea de texto nica.
Lneas de texto mltiples 192 Umbral 28 bytes El ajuste de filas de SQL Server se realiza
192 columnas de lneas de texto mltiples por lista
de SharePoint (6 * 32 = 192).
Eleccin 276 Umbral 28 bytes La envoltura de la fila de SQL Server se realiza
384 columnas de eleccin por lista de SharePoint
(6 * 64 = 384). No obstante, dado que el lmite por
elemento de lista de SharePoint es de 8.000
bytes, de los cuales 256 bytes estn reservados
para columnas de SharePoint integradas, el lmite
real es de 276 columnas de eleccin.
Nmero 72 Umbral 12 bytes El ajuste de filas de SQL Server se realiza
predeterminado de seis permite un mximo de 72
112
lmite columna
columnas de nmero por lista de SharePoint (6 *
12 = 72).
Moneda 72 Umbral 12 bytes El ajuste de las filas de SQL Server se realiza
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
columnas de fecha y hora por lista de SharePoint
(6 * 8 = 48).
Bsqueda 96 Umbral 4 bytes El ajuste de lneas de SQL Server se realiza
columnas de bsqueda 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
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
113
lmite columna
columnas de persona o grupo por lista de
SharePoint (6 * 16 = 96).
Hipervnculo o imagen 138 Umbral 56 bytes El ajuste de filas de SQL Server se realiza
192 columnas de hipervnculo o imagen por lista
de SharePoint (6 * 32 = 192). No obstante, dado
que el lmite por elemento de lista de SharePoint
es de 8.000 bytes, de los cuales 256 bytes estn
reservados para columnas de SharePoint
integradas, el lmite real es de 138 columnas de
hipervnculo o imagen.
Calculado 48 Umbral 28 bytes El ajuste de las filas de SQL Server se realiza
columnas Calculado por lista de SharePoint (6 * 8
= 48).
GUID 6 Umbral 20 bytes El ajuste de las filas de SQL Server se realiza
despus de cada columna en una lista de
columnas GUID por lista de SharePoint (6 * 1 = 6).
Int 96 Umbral 4 bytes El ajuste de las filas de SQL Server se realiza
114
lmite columna
columnas Int por lista de SharePoint (6 * 16 = 96).
Metadatos administrados 94 Umbral 40 bytes Al primer campo de metadatos administrados
para el agregado a una lista se asignan cuatro columnas:
primero, 32 Campo de bsqueda para la etiqueta real
bytes para
cada uno de Campo de texto oculto para el valor de
los cadena
siguientes Un campo de bsqueda para el detectar todo
Un campo de bsqueda para el
desbordamiento del detectar todo
Cada campo de metadatos administrados
subsiguiente agregado a una lista agrega dos
columnas ms:
Campo de bsqueda para la etiqueta real
Campo de texto oculto para el valor de
cadena
El nmero mximo de columnas de metadatos
administrados se calcula como (14 + (16 * (n-1))),
donde n es el valor de asignacin 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, Pas y Descripcin, 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 Descripcin del cliente. En general, stas son las columnas que se agregan:
115
Columna principal: un campo de texto.
Columna Id. oculta: un campo de texto multilnea.
Columnas secundarias: cada columna secundaria es un texto/nmero/expresin booleana/texto multilnea basado en el tipo de datos
de la columna secundaria definido en el modelo del Catlogo de datos profesionales. Por ejemplo, Id. podra asignarse a una
columna Nmero; Nombre podra asignarse a una columna de lnea de texto nica; Descripcin podra asignarse a una columna de
lneas de texto mltiples.
Lmites de pginas
En la siguiente tabla se enumeran las recomendaciones para pginas.
Elementos web 25 por pgina wiki o de elemento web Umbral Esta cifra es
una estimacin
basada en
elementos web
simples. La
complejidad de
los elementos
web determina
cuntos
elementos web
se pueden usar
en una pgina
sin que se vea
afectado el
rendimiento.
116
Lmites de seguridad
Nmero de grupos de SharePoint al 5.000 Compatible No es un lmite estricto pero es coherente con
que puede pertenecer un usuario las directrices de Active Directory. Hay varias
cosas que pueden afectar a este nmero:
El tamao del token de usuario
La memoria cach de grupos: SharePoint
Server 2010 tiene una tabla que
almacena en cach el nmero de grupos
a los que pertenece un usuario en cuanto
dichos grupos se usan en listas de control
de acceso (ACL).
El tiempo de comprobacin de seguridad:
a medida que aumenta el nmero de
grupos del que un usuario es miembro,
tambin aumenta el tiempo requerido
para la comprobacin de acceso.
Usuarios de una coleccin de sitios 2 millones por coleccin 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 lmite se basa en la capacidad de
administracin y facilidad de navegacin en la
interfaz de usuario.
Cuando hay muchas entradas (grupos de
seguridad de usuarios) en la coleccin de
117
sitios (ms de mil), debe usar Windows
PowerShell para administrar los usuarios en
vez de la UI. Esto proporcionar una mejor
experiencia de administracin.
Principios/usuarios de Active 5.000 por grupo de SharePoint Compatible SharePoint Server 2010 permite agregar
Directory en un grupo de SharePoint 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 ms afectadas por este lmite
son las siguientes:
Capturar usuarios para validar permisos.
Esta operacin requiere cada vez ms
tiempo a medida que aumenta el nmero
de usuarios de un grupo.
Representar la pertenencia de la vista.
Esta operacin siempre requiere tiempo.
Grupos de SharePoint 10.000 por coleccin 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: tamao del 5.000 por lista de control de acceso Compatible El tamao del mbito afecta a los datos que
mbito de seguridad (ACL) se usan para un clculo de comprobacin de
118
seguridad. Este clculo se realiza cada vez
que cambia el mbito. No hay un lmite
estricto, pero cuanto ms grande sea el
mbito, ms tiempo llevar el clculo.
Lmites por caracterstica

En esta seccin se enumeran los lmites ordenados por caracterstica.
Lmites de bsqueda
En la siguiente tabla se enumeran las recomendaciones para bsquedas.
Aplicaciones de servicio de 20 por granja de servidores Compatible Pueden implementarse varias

bsqueda de SharePoint aplicaciones de servicio de
bsqueda de SharePoint en la
misma granja de servidores, ya
que se pueden asignar bases de
datos y componentes de
bsqueda a distintos servidores.
El lmite recomendado de 20 es
inferior al lmite mximo para
todas las aplicaciones de servicio
de una granja de servidores.
Bases de datos de rastreo y 10 bases de datos de rastreo por aplicacin de Umbral La base de datos de rastreo
elementos de bases de datos servicio de bsqueda almacena los datos de rastreo
25 millones de elementos por base de datos de (tiempo/estado, etc.) acerca de
rastreo todos los elementos que se han
rastreado. El lmite admitido es de
119
10 bases de datos de rastreo por
aplicacin de servicio de
bsqueda de SharePoint.
El lmite recomendado es de 25
millones de elementos por base
de datos de rastreo (o un total de
cuatro bases de datos de rastreo
por aplicacin de servicio de
bsqueda).
Componentes de rastreo 16 por aplicacin de servicio de bsqueda Umbral El lmite recomendado por
aplicacin es de 16 componentes
de rastreo en total, a razn de dos
por base de datos de rastreo, y
dos por servidor, suponiendo que
el servidor tiene al menos ocho
procesadores (ncleos).
El nmero total de componentes
de rastreo por servidor debe ser
inferior a 128/(total de
componentes de consulta) para
minimizar la degradacin de E/S
de propagacin. Aunque se
exceda el lmite recomendado, es
posible que no aumente el
rendimiento del rastreo; de hecho,
el rendimiento de rastreo podra
bajar reducirse en funcin de los
recursos disponibles en el servidor
de rastreo, la base de datos y el
host de contenido.
120
Particiones de ndice 20 por aplicacin de servicio de bsqueda; 128 en Umbral La particin de ndice contiene un
total subconjunto del ndice de
bsqueda. El lmite recomendado
es de 20. Si se aumenta el
nmero de particiones de ndice,
cada particin contendr un
subconjunto ms pequeo 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 particin de ndice.
El lmite mximo para el nmero
total de particiones de ndice es
de 128.
Elementos indizados 100 millones por aplicacin de servicio de Compatible SharePoint Search admite
bsqueda; 10 millones por particin de ndice particiones de ndice, cada una de
las cuales contiene un
subconjunto del ndice de
bsqueda. El mximo
recomendado es de 10 millones
de elementos en cualquier
particin. El nmero mximo total
de elementos recomendado (por
ejemplo, personas, elementos de
lista, documentos, pginas web)
es de 100 millones.
Entradas de registro de rastreo 100 millones por aplicacin de bsqueda Compatible ste es el nmero de entradas de
registro individuales en el registro
121
de rastreo. Sigue el lmite de
"elementos indizados".
Base de datos de propiedades 10 por aplicacin de servicio de bsqueda;128 en Umbral La base de datos de propiedades
total almacena los metadatos de los
elementos de cada particin de
ndice asociados con ella. Una
particin de ndice puede estar
asociada con un solo almacn de
propiedades. El lmite
recomendado es de 10 bases de
datos de propiedades por
bsqueda. El lmite mximo para
particiones de ndice es de 128.
Componentes de consulta 128 por aplicacin de bsqueda; 64/(total de Umbral El nmero total de componentes
componentes de rastreo) por servidor de consulta est limitado por la
capacidad de los componentes de
rastreo de copiar archivos. El
nmero mximo 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 Umbral Si se excede este lmite, se
aplicacin de servicio de bsqueda reducir la actualizacin del
rastreo y se retrasarn los
resultados potenciales de las
consultas del mbito.
122
mbitos 200 por sitio Umbral ste es un lmite recomendado

por sitio. Si se excede este lmite,
se puede reducir la eficiencia del
rastreo y, si se agregan los
mbitos al grupo de presentacin,
puede resultar afectada la latencia
del explorador de usuario final.
Adems, la presentacin de los
mbitos en la interfaz de
administracin de bsqueda se
degrada a medida que el nmero
de mbitos excede el lmite
recomendado.
Grupos de presentacin 25 por sitio Umbral Los grupos de presentacin se
usan para la presentacin
agrupada de mbitos a travs de
la interfaz de usuario. Si se
excede este lmite, comienza a
degradarse la experiencia de
mbito en la interfaz de
administracin de bsqueda.
Alertas 1.000.000 por aplicacin de bsqueda Compatible ste es el lmite probado.
Orgenes de contenido 50 por aplicacin de servicio de bsqueda Umbral El lmite recomendado de 50
puede excederse hasta el lmite
mximo de 500 por aplicacin de
servicio de bsqueda. No
obstante, deben usarse menos
direcciones de comienzo y debe
seguirse el lmite de rastreo
123
simultneo.
Direcciones de comienzo 100 por origen de contenido Umbral El lmite recomendado puede
excederse hasta el lmite mximo
de 500 por origen de contenido.
No obstante, cuantas ms
direcciones tenga, menos
orgenes de contenido deben
usarse. Si tiene muchas
direcciones de comienzo,
recomendamos colocarlas como
vnculos en una pgina HTML y
hacer que el rastreador HTTP
rastree la pgina, siguiendo los
vnculos.
Rastreos simultneos 20 por aplicacin de bsqueda Umbral ste es el nmero de rastreos que
pueden realizarse al mismo
tiempo. Si se excede este nmero,
la velocidad de rastreo general
puede reducirse.
Propiedades rastreadas 500.000 por aplicacin de bsqueda Compatible stas son las propiedades
detectadas durante un rastreo.
Regla de impacto de rastreo 100 Umbral Lmite recomendado de 100 por
granja de servidores. La cantidad
recomendada puede excederse,
pero se degradar la presentacin
de las reglas de acceso al sitio en
la interfaz de administracin de
bsqueda. Con aproximadamente
2.000 reglas de acceso al sitio, la
124
pgina Administrar reglas de
acceso al sitio se vuelve ilegible.
Reglas de rastreo 100 por aplicacin de servicio de bsqueda Umbral Este valor puede excederse, pero
se degradar la presentacin de
las reglas de rastreo en la interfaz
de administracin de bsqueda.
Propiedades administradas 100.000 por aplicacin de servicio de bsqueda Umbral stas son las propiedades que
usa el sistema de bsqueda en las
consultas. Las propiedades
rastreadas se asignan a
propiedades administradas.
Asignaciones 100 por propiedad administrada Umbral Si se excede este lmite, puede
reducirse la velocidad de rastreo y
rendimiento de las consultas.
Eliminacin de direcciones URL 100 eliminaciones por operacin Compatible ste es el nmero mximo
recomendado de direcciones URL
que deberan quitarse del sistema
en una misma operacin.
Pginas relevantes 1 pgina de primer nivel y la menor cantidad Umbral El lmite recomendado es de una
posible de pginas de segundo y tercer nivel por pgina relevante de primer nivel y
aplicacin de servicio de bsqueda la menor cantidad posible de
pginas de segundo y tercer nivel
para lograr la relevancia deseada.
El lmite mximo es de 200 por
nivel de relevancia por aplicacin
de bsqueda, pero aunque se
agreguen ms pginas, es posible
que no se logre la relevancia
125
deseada. Agregue el sitio clave al
primer nivel de relevancia.
Agregue ms sitios clave al
segundo o tercer nivel de
relevancia, de a uno a la vez, y
evale la relevancia despus de
cada adicin para asegurarse de
que se ha logrado el efecto de
relevancia deseado.
Palabras clave: 200 por coleccin de sitios Compatible El lmite recomendado puede
excederse hasta el lmite mximo
(impuestos por ASP.NET) de
5.000 por coleccin de sitios, con
cinco opciones ms probables por
palabra clave. Si se excede este
lmite, la presentacin de palabras
clave en la interfaz de usuario de
administracin del sitio se
degradar. El lmite impuesto por
ASP.NET puede modificarse
editando los archivos Web.Config
y Client.config
(MaxItemsInObjectGraph).
Propiedades de metadatos 10.000 por elemento rastreado Lmite mximo ste es el nmero de propiedades
reconocidas de metadatos que se pueden
determinar y potencialmente
asignar o usar para consultas
cuando se rastrea un elemento.
126
Lmites 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 aplicacin de servicio Compatible Una aplicacin de

servicio de perfiles
de usuario puede
admitir hasta 2
millones de perfiles
de usuario con
funcionalidad de
caractersticas
sociales
completas. Este
nmero representa
el nmero de
perfiles que se
puede importar en
el almacn de
perfiles de
personas desde un
servicio de
directorio, y
tambin el nmero
de perfiles que una
aplicacin de
servicio de perfiles
de usuario puede
admitir sin producir
reducciones en el
rendimiento de las
127
caractersticas
sociales.
Etiquetas temticas, notas y clasificaciones 500.000.000 por base de datos social Compatible Se admiten hasta
500 millones en
total de etiquetas
temticas, 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
restauracin,
pueden presentar
una reduccin del
rendimiento al
llegar a ese punto.
Lmites de distribucin de contenido

En la siguiente tabla se enumeran las recomendaciones para la distribucin de contenido.
128
Trabajos de distribucin de 20 Compatible En el caso de trabajos simultneos en rutas de

contenido que se ejecutan en acceso conectadas a colecciones de sitios en la
diferentes rutas de acceso 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 simultneamente, recomendamos mover
las colecciones de sitios a diferentes bases de
datos de contenido de origen.
Nota:
No es posible realizar trabajos simultneos en la
misma ruta de acceso.
Si usa instantneas de SQL Server para la

distribucin de contenido, cada ruta de acceso
crea una instantnea. Esto aumenta los requisitos
de E/S de la base de datos de origen.
Para obtener ms informacin, vea el tema sobre
rutas de acceso y trabajos de distribucin.
Lmites de blogs
En la siguiente tabla se enumeran las recomendaciones para blogs.
Entradas de blog 5.000 por sitio Compatible El nmero

mximo de
129
entradas de
blog es de
5.000 por sitio.
Comentarios 1.000 por entrada Compatible El nmero
mximo de
comentarios es
de 1.000 por
entrada.
Lmites 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) Lmite mximo Nmero 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 Lmite mximo El nmero de conexiones
de sistema externo
activas/abiertas en un
determinado momento. El
valor mximo
predeterminado es de
200; el lmite mximo es
130
de 500. Este lmite se
aplica en el mbito del
servidor web,
independientemente del
tipo de sistema externo
(por ejemplo, base de
datos, ensamblado .NET,
etc.). El mximo
predeterminado se usa
para restringir el nmero
de conexiones. Una
aplicacin puede
especificar un lmite ms
grande a travs del
contexto de ejecucin; el
lmite mximo aplica el
mximo incluso para
aplicaciones que no
respetan el valor
predeterminado.
Elementos de base de datos devueltos por 2.000 por conector de base de datos Umbral Nmero de elementos por
solicitud solicitud que puede
devolver el conector de
base de datos.
El conector de la base de
datos usa el mximo
predeterminado de 2.000
para restringir el nmero
de resultados que se
pueden devolver por
pgina. Una aplicacin
131
puede especificar un
lmite ms grande a travs
del contexto de ejecucin;
el mximo absoluto aplica
el mximo incluso para
aplicaciones que no
respetan el valor
predeterminado. El lmite
mximo para este lmite
es de 1.000.000.
Lmites 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 nmero

mximo de flujos de
trabajo que se
pueden ejecutar
simultneamente
respecto de una base
de datos de
contenido, excluidas
las instancias que se
ejecutan en el servicio
del temporizador.
Cuando se alcanza
este umbral, las
nuevas solicitudes
132
para activar flujos de
trabajo se colocarn
en cola para que el
servicio de
temporizador de flujo
de trabajo las ejecute
posteriormente. A
medida que se realiza
la ejecucin sin
temporizador, se
tendrn en cuenta las
nuevas solicitudes
para determinar el
umbral. Este lmite
puede configurarse
mediante el cmdlet
Set-SPFarmConfig de
Windows PowerShell.
Para obtener ms
informacin, vea Set-
SPFarmConfig.
Nota: este lmite no
se refiere al nmero
total de instancias de
flujo de trabajo que
pueden estar en
curso sino al nmero
de instancias que se
est procesando. Si
se aumenta este
lmite, aumentar el
133
rendimiento del
comienzo y
finalizacin de tareas
de flujo de trabajo
pero tambin
aumentar la carga
de la base de datos
de contenido y los
recursos del sistema.
Tamao de lote de temporizador de flujo de 100 Umbral El nmero de eventos
trabajo que cada ejecucin
del trabajo del
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
de trabajo de
Microsoft SharePoint
Foundation.
Lmites de almacn de trminos de metadatos administrados (base de datos)

En la siguiente tabla se enumeran las recomendaciones para almacenes de trminos de metadatos administrados.
134
Nmero mximo de niveles de 7 Compatible Los trminos de un conjunto de trminos pueden

trminos anidados en un almacn representarse jerrquicamente. Un conjunto de
de trminos trminos puede tener hasta siete niveles de
trminos (un trmino principal y seis niveles de
anidacin debajo de l.)
Nmero mximo de conjuntos de 1000 Compatible Puede tener hasta 1.000 conjuntos de trminos en
trminos en un almacn de un almacn de trminos.
trminos
Nmero mximo de trminos en un 30.000 Compatible 30.000 es el nmero mximo de trminos que
conjunto de trminos puede haber en un conjunto de trminos.
Nota:
Las etiquetas adicionales correspondientes al
mismo trmino, como sinnimos y traducciones,
no se cuentan como trminos separados.
Nmero total de elementos en un 1.000.000 Compatible Un elemento es un trmino o un conjunto de

almacn de trminos trminos. La suma del nmero de trminos y
conjuntos de trminos no puede exceder
1.000.000. Las etiquetas adicionales
correspondientes al mismo trmino, como
sinnimos y traducciones, no se cuentan como
trminos separados.
135
Nota:
No se puede tener el nmero mximo de
conjuntos de trminos y el nmero mximo de
trminos simultneamente en un almacn de
trminos.
Lmites de Servicios de Visio

En la siguiente tabla se enumeran las recomendaciones para instancias de Servicios de Visio en Microsoft SharePoint Server 2010.
Lmite Valor mximo Tipo de Notas

lmite
Tamao de archivos de dibujos web 50 MB Umbral Servicios de Visio tiene una opcin de
de Visio configuracin que permite al administrador
cambiar el tamao mximo de los dibujos web que
procesa Visio.
Los tamaos de archivo ms grandes tienen los
siguientes efectos colaterales:
Aumento de la huella de memoria de Servicios
de Visio.
Aumento en el uso de la CPU.
Reduccin de la cantidad de solicitudes de
servidor de aplicaciones por segundo.
Aumento de la latencia general.
136
lmite
Aumento de la carga de la red de granjas de
servidores de SharePoint.
Tiempo de espera de reclculo de 120 segundos Umbral Servicios de Visio tiene una opcin de
dibujo web de Visio configuracin que permite al administrador
cambiar el tiempo mximo que puede pasar
recalculando un dibujo despus de actualizar los
datos.
Un mayor tiempo de espera de reclculo tiene las
siguientes consecuencias:
Reduccin de la disponibilidad de la CPU y la
memoria.
Reduccin en la cantidad de solicitudes de
aplicaciones por segundo.
Aumento de la latencia promedio en todos los
documentos.
Un menor tiempo de espera de reclculo tiene las
siguientes consecuencias:
Reduccin de la complejidad de los diagramas
que se pueden mostrar.
Aumento de la cantidad de solicitudes por
segundo.
Reduccin de la latencia promedio en todos
los documentos.
Edad de cach mnima de Servicios Edad mnima de cach: 0 a 24 horas Umbral La edad de cach mnima se aplica a diagramas
137
lmite
de Visio (diagramas conectados a conectados a datos. Determina la cantidad de
datos) tiempo que debe pasar para poder quitar el
diagrama actual de la memoria cach.
Si la edad mnima de cach se establece a un
valor muy bajo, se reducir el rendimiento y
aumentar la latencia, ya que la invalidacin de la
memoria cach suele obligar a Visio a recalcular
frecuentemente y reduce la disponibilidad de la
CPU y la memoria.
Edad de cach mxima de Servicios Edad mxima de cach: 0 a 24 horas Umbral La edad de cach mxima se aplica a diagramas
de Visio (diagramas no conectados a no conectados a datos. Este valor determina
datos) cunto tiempo se mantendr el diagrama actual
en la memoria.
Si se aumenta la edad mxima de cach, se
reduce la latencia para los dibujos comnmente
solicitados.
No obstante, si se establece la edad mxima 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 estn en la
memoria cach consumen y reducen la memoria
disponible.
Lmites de PerformancePoint Services

En la siguiente tabla se enumeran las recomendaciones para PerformancePoint Services in Microsoft SharePoint Server 2010.
138
Celdas 1.000.000 por consulta en origen de datos de Lmite mximo Un cuadro de mandos
Servicios de Excel de PerformancePoint
que llama a un origen
de datos de Servicios
de Excel est sujeto a
un lmite de no ms de
1.000.000 celdas por
consulta.
Columnas y filas 15 columnas por 60.000 filas Umbral El nmero mximo de
columnas y filas al
representar cualquier
objeto de panel de
PerformancePoint que
usa un libro de
Microsoft Excel como
origen de datos. El
nmero de filas podra
cambiar segn el
nmero de columnas.
Consulta a una lista de SharePoint 15 columnas por 5.000 filas Compatible El nmero mximo de
columnas y filas al
objeto de panel de
usa una lista de
SharePoint como
origen de datos. El
nmero de filas podra
cambiar segn el
139
nmero de columnas.
Consulta a un origen de datos de SQL Server 15 columnas por 20.000 filas Compatible El nmero mximo de
columnas y filas al
objeto de panel de
usa una tabla de SQL
Server como origen de
datos. El nmero de
filas podra cambiar
segn el nmero de
columnas.
Lmites de Word Automation Services

En la siguiente tabla se enumeran las recomendaciones para Word Automation Services.
Tamao de archivo de entrada 512 MB Lmite mximo El tamao de archivo mximo que se puede
procesar con Word Automation Services.
Frecuencia con la que se inician 1 minuto (recomendado) Umbral Este valor determina la frecuencia con la que se
conversiones (minutos) 15 minutos (predeterminado) ejecuta el trabajo del temporizador de Word
Automation Services. Un nmero menor hace que
59 minutos (lmite mximo) el trabajo del temporizador se ejecute ms
rpido. Nuestras pruebas demuestran que es ms
til ejecutar este trabajo del temporizador una vez
por minuto.
Nmero de conversiones que se Para formatos de salida PDF/XPS: Umbral El nmero de conversiones que se inician afecta
140
inician por proceso de conversin 30 x M. Para todos los dems al rendimiento de Word Automation Services.
formatos de salida: 72 x M, donde Si estos valores se establecen por encima de los
M es el valor de la frecuencia con niveles recomendados, es posible que algunos
la que se inician las conversiones elementos de conversin comiencen a producir
(minutos). errores de forma intermitente y que los permisos
del usuario expiren. Los permisos del usuario
expiran 24 horas despus del momento en que se
inicia un trabajo de conversin.
Tamao del trabajo de conversin 100.000 elementos de conversin Compatible Un trabajo de conversin incluye uno o ms
elementos de conversin, cada uno de los cuales
representa una sola conversin que se realiza en
un nico archivo de entrada en SharePoint.
Cuando se inicia un trabajo de conversin
(usando el mtodo ConversionJob.Start), el
trabajo de conversin y todos los elementos de
conversin se transmiten a un servidor de
aplicaciones que despus almacena el trabajo en
la base de datos de Word Automation Services. Si
el nmero de elementos de conversin es grande,
aumentar el tiempo de ejecucin del mtodo
Start y el nmero de bytes transmitidos al servidor
de aplicaciones.
Total de procesos de conversin N-1, donde N es el nmero de Umbral Un proceso de conversin activo puede consumir
activos ncleos en cada servidor de un solo ncleo de procesamiento. Por lo tanto, los
aplicaciones clientes no deben ejecutar ms procesos de
conversin que la cantidad de ncleos de
procesamiento que tienen sus servidores de
aplicaciones. El trabajo del temporizador de
conversin y otras actividades de SharePoint
tambin requieren el uso ocasional de un ncleo
141
de procesamiento.
Recomendamos dejar siempre 1 ncleo libre para
el trabajo del temporizador de conversin y
SharePoint.
Tamao de la base de datos de 2 millones de elementos de Compatible Word Automation Services mantiene una cola
Word Automation Services conversin persistente de elementos de conversin en su
base de datos. Cada solicitud de conversin
genera uno o varios registros.
Word Automation Services no elimina los registros
de la base de datos automticamente, por lo que
la base de datos puede crecer de forma indefinida
sin mantenimiento. Los administradores pueden
quitar manualmente el historial de trabajos de
conversin usando el cmdlet Remove-
SPWordConversionServiceJobHistory de
Windows PowerShell. Para obtener ms
informacin, vea Remove-
SPWordConversionServiceJobHistory.
Lmites de SharePoint Workspace

En la siguiente tabla se enumeran las recomendaciones para Microsoft SharePoint Workspace 2010.
Sincronizacin con SharePoint Workspace 30.000 elementos por lista Lmite mximo SharePoint
Workspace no
sincroniza las
listas que tienen
ms de 30.000
142
elementos. Esta
restriccin existe
porque el tiempo
para descargar
una lista que
tiene ms de
30.000
elementos es
muy largo y el
uso de recursos
es alto.
Sincronizacin con SharePoint Workspace Lmite de 1800 documentos en SharePoint Lmite mximo Se advierte a los
Workspace usuarios cuando
tienen ms de
500 documentos
en SharePoint
Workspace,
pero pueden
continuar
agregando
documentos.
Lmites de OneNote
En la siguiente tabla se enumeran las recomendaciones para Servicios de Microsoft OneNote.
Nmero de secciones y grupos de Vea el lmite para "Documentos" en Cada seccin se considera una
seccin en un bloc de notas de OneNote Lmites de listas y bibliotecas carpeta y un documento en la lista.
143
(en SharePoint) Cada grupo de secciones se cuenta
como una carpeta y un documento en
la lista.
Tamao mximo de una seccin Vea el lmite para el "tamao de archivo" Este mximo excluye las imgenes,
en los lmites de listas y bibliotecas archivos incrustados y copias
impresas XPS para OneNote de ms
de 100 KB. Las imgenes y los
archivos incrustados de ms de 100
KB se dividen en sus propios archivos
binarios. Esto significa que una
seccin con 100 KB de datos con tipo
y cuatro documentos incrustados de
Word de 1 MB cada uno se
considerarn una seccin de 100 KB.
Tamao mximo de una imagen, archivo Vea el lmite para el "tamao de archivo" Cada elemento se almacena como un
incrustado y copia impresa XPS de en los lmites de listas y bibliotecas archivo binario independiente y, por lo
OneNote en una seccin de OneNote. tanto, est sujeto a los lmites de
tamao de archivo. Cada operacin
de impresin de OneNote dar como
resultado un archivo binario de copia
impresa XPS, incluso si la copia
impresa contiene varias pginas.
Tamao mximo de todas las imgenes, El lmite predeterminado es el doble del Umbral Esto se aplica al contenido incrustado
archivos incrustados y copias impresas lmite de "Tamao de archivos". en una sola pgina de OneNote, no a
XPS en una sola pgina de OneNote. una seccin 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 divisin
144
del contenido incrustado en distintas
pginas y eliminando las versiones
anteriores de la pgina. Si los
usuarios tienen que ajustar este valor
(Max Hot Table Size), el lmite
efectivo es la mitad del valor absoluto
que definen (por ejemplo, si se
especifica un tamao mximo de
tabla dinmica de 400 MB, significa
que el tamao mximo de todo el
contenido incrustado en una pgina
est limitado a 200 MB).
Operaciones de combinacin Una por ncleo de CPU por servidor web Lmite OneNote combina los cambios de
mximo combinacin de varios usuarios que
son co-autores de un bloc de notas.
Si hay un ncleo de CPU disponible
para ejecutar una combinacin, se
genera una pgina de conflicto, que
obliga al usuario a realizar la
combinacin manualmente).
Este lmite se aplica si OneNote se
ejecuta como una aplicacin cliente o
como Microsoft Office Web Apps.
Lmites de Office Web Application Service

En la siguiente tabla se enumeran las recomendaciones para Office Web Apps. Los lmites de aplicaciones cliente de Office tambin se
aplican cuando una aplicacin se ejecuta como una aplicacin web.
145
Tamao 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 ncleo de Lmite mximo Es el nmero
CPU por servidor de aplicaciones (mximo de promedio medido de
ocho ncleos) representaciones que
pueden realizarse de
documentos "tpicos"
en el servidor de
aplicaciones durante
un determinado
perodo de tiempo.
Lmites de Project Server

En la siguiente tabla se enumeran las recomendaciones para Microsoft Project Server. Para obtener ms informacin acerca de cmo
planear para Project Server, vea Planning and architecture for Project Server 2010.
146
Final de tiempo del proyecto Fecha: 31/12/2049 Lmite mximo Los planes de
Project no se
pueden
extender ms
all del
31/12/2049.
Entregas por plan del proyecto 1.500 entregas Lmite mximo Los planes de
Project no
pueden
contener ms
de 1.500
entregas.
Nmero de campos de una vista 256 Lmite mximo El usuario no
puede agregar
ms de 256
campos a una
vista definida
en Project Web
App.
Nmero de clusulas en un filtro de una vista 50 Lmite mximo El usuario no
puede agregar
un filtro a una
vista que tiene
ms de 50
clusulas.
147
Performance and capacity technical case studies (SharePoint
Server 2010) (en ingls)
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 ingls).
In this section:
Publishing
Entorno de publicacin de intranet de empresa de Microsoft SharePoint Server 2010: caso prctico tcnico
Describes the published intranet environment used by employees at Microsoft.
Enterprise Intranet Collaboration
Enterprise intranet collaboration environment technical case study (SharePoint Server 2010) (en ingls)
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 ingls)
148
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 ingls)
Describes a departmental collaboration environment used by employees of one department inside Microsoft.
Divisional portal environment lab study (SharePoint Server 2010) (en ingls)
Describes lab testing performed on a similar environment to the departmental collaboration environment.
Social
Social environment technical case study (SharePoint Server 2010) (en ingls)
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.
149
Entorno de publicacin de intranet de empresa de Microsoft
SharePoint Server 2010: caso prctico tcnico
En este documento se describe una implementacin especfica de Microsoft SharePoint Server 2010. Se incluye lo siguiente:
Especificaciones del entorno del caso prctico tcnico como hardware, topologa de conjunto o granja de servidores y configuracin.
La carga de trabajo, que incluye cantidad y tipos de usuarios o clientes y caractersticas de uso del entorno.
Conjunto de datos de la granja de servidores del caso prctico tcnico, que incluye el contenido de la base de datos y los ndices de
bsqueda.
Datos de mantenimiento y rendimiento especficos del entorno.
En este artculo:
Informacin de requisitos previos
Introduccin a este entorno
Especificaciones
Carga de trabajo
Conjunto de datos
Datos de mantenimiento y rendimiento

Antes de leer este documento, asegrese de comprender los conceptos clave sobre la administracin de capacidad de SharePoint Server
2010. La siguiente documentacin le proporcionar informacin acerca del mtodo recomendado para administrar la capacidad y sobre
cmo usar eficazmente la informacin de este documento. Tambin se definen los trminos usados en todo el documento.
Para obtener ms informacin conceptual sobre el rendimiento y la capacidad que puede servirle para comprender el contexto de los
datos en este caso prctico, vea los siguientes documentos:
150
Introduccin 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
caractersticas de este entorno con las caractersticas de uso y de carga de trabajo planeadas. Si el diseo que ha planeado es similar,
puede usar la implementacin descrita en este artculo como punto de partida de su propia instalacin.
En este documento se incluye lo siguiente:
Especificaciones, entre las que se incluye el hardware, la topologa y la configuracin
Carga de trabajo, que es la demanda en la granja de servidores e incluye la cantidad de usuarios y las caractersticas de uso
Conjunto de datos, que incluye los tamaos de base de datos
Datos de mantenimiento y rendimiento especficos del entorno
Este documento forma parte de una serie de Performance and capacity technical case studies (SharePoint Server 2010) (en ingls) sobre
entornos de SharePoint en Microsoft.
151
El entorno de SharePoint Server 2010 descrito en este documento es un entorno de produccin de una compaa de gran tamao
distribuida geogrficamente. Los empleados visualizan contenido diverso, como noticias, artculos tcnicos, perfiles de empleados,
documentacin y recursos de aprendizaje. Los empleados tambin usan este entorno para llevar a cabo consultas de bsqueda en todos
los entornos de SharePoint de la compaa. Reciben a diario mensajes de correo electrnico con vnculos a artculos en el entorno y
muchos de ellos lo establecen como la pgina principal de su explorador.
Hasta 48.000 usuarios exclusivos visitan el entorno en un da 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 estn autenticados. Si bien el contenido se publica mediante un modelo
de autor en contexto de entorno nico, el procedimiento de publicacin del entorno especifica que todos los borradores del contenido
deben publicarse a la vez durante la noche fuera de horas pico.
La informacin proporcionada en este documento refleja el entorno de publicacin en la intranet empresarial en un da normal.
Especificaciones
En esta seccin se ofrece informacin detallada sobre el hardware, el software, la topologa y la configuracin del entorno del caso
prctico.
Hardware
En esta seccin 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 ms 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 administracin de capacidad en funcin de las caractersticas de uso y de carga de trabajo
planeadas. Para obtener ms informacin acerca del proceso de administracin de capacidad, vea Informacin general sobre
administracin y ajuste de tamao de la capacidad de SharePoint Server 2010.
152
Servidores web
La granja cuenta con cuatro servidores web cuyo hardware es idntico. Tres de ellos sirven contenido y el cuarto es un objetivo de
rastreo de bsqueda dedicado.
Servidor web WFE1-4
Procesadores 2 procesadores de cuatro ncleos de 2,33 GHz

RAM 32 GB
Sistema operativo Windows Server 2008 de 64 bits
Tamao de la unidad de SharePoint 300 GB
Nmero de adaptadores de red 2
Velocidad del adaptador de red 1 Gigabit
Autenticacin Windows NTLM
Tipo de equilibrador de carga Equilibrio de carga de hardware
Versin de software SharePoint Server 2010 (versin preliminar)
Servicios que se ejecutan localmente Administracin central
Correo electrnico entrante de Microsoft SharePoint Foundation
Aplicacin web de Microsoft SharePoint Foundation
Servicio de temporizador de flujo de trabajo de Microsoft SharePoint
Foundation
Servicio de configuracin del sitio y consulta de bsqueda
Bsqueda de SharePoint Server
Servicios que se consumen desde una granja de servicios Servicio de perfiles de usuario
federados Servicio web de Web Analytics
153
Servidor web WFE1-4
Servicio de conectividad a datos empresariales
Servicio web de metadatos administrados
Servidor de aplicaciones
No hay ningn servidor de aplicaciones en la granja de servidores. Los servicios locales se hospedan en los servidores web y los dems
servicios se consumen desde una granja de servicios federados.
Servidores de bases de datos
Hay un clster de SQL con dos servidores de bases de datos cuyo hardware es idntico. 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 ncleos de 2,4 GHz

RAM 32 GB
Almacenamiento y geometra (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
Autenticacin Windows NTLM
Versin de software SQL Server 2008
154
Topologa
En el siguiente diagrama se muestra la topologa de esta granja.
155
156
Configuracin
En la siguiente tabla se enumeran los valores que se modificaron y afectan al rendimiento o la capacidad del entorno.
Opcin Valor Notas
Administracin de la Habilitada La habilitacin de la memoria cach de resultados mejora la eficacia del servidor, ya que
coleccin de sitios: reduce las llamadas a la base de datos para los datos que se solicitan frecuentemente.
Cach de resultados de la
coleccin de sitios
Perfil de cach de la coleccin Intranet (sitio de La opcin Permitir que los escritores vean contenido almacenado en cach est
de sitios (seleccionar) colaboracin) activada, lo que ocasiona que se pase por alto el comportamiento normal de no permitir
a los usuarios con permisos de edicin almacenar sus pginas en la memoria cach.
Cach de objetos Habilitada: 500 El valor predeterminado es 100 MB. El aumento de este valor permite que se almacenen
(deshabilitada | n MB) MB datos adicionales en la memoria del servidor front-end web.
Servicio de uso: 5 das El valor predeterminado es 14 das. La disminucin de este valor puede ahorrar espacio
Registro de seguimiento: das en disco en el servidor donde se almacenan los archivos de registro.
para almacenar los archivos
de registro (valor
predeterminado: 14 das)
Umbral de registro de 1 segundo El valor predeterminado es 5 segundos. La disminucin de este valor puede ahorrar
consulta: ancho de banda y CPU en el servidor de bases de datos.
Base de datos de Microsoft
SharePoint Foundation:
configurar
QueryLoggingThreshold en 1
segundo
Servidor de bases de datos: 1 El valor predeterminado es 0. Para garantizar un ptimo rendimiento, se recomienda
instancia predeterminada: fehacientemente establecer el grado mximo de paralelismo en 1 para servidores de
157
Opcin Valor Notas
Grado de paralelismo mximo bases de datos que hospedan bases de datos de SharePoint Server 2010. Para obtener
ms informacin acerca de cmo establecer el grado mximo de paralelismo, vea el
tema sobre max degree of parallelism
(opcin)(http://go.microsoft.com/fwlink/?linkid=189030&clcid=0xC0A).
Carga de trabajo
En esta seccin se describe la carga de trabajo, que es la demanda en la granja de servidores e incluye la cantidad de usuarios y las
caractersticas de uso.
Promedio de solicitudes por segundo (RPS) 100

Promedio de RPS en horas pico (de 11 a. m. a 3 p. m.) 226
Nmero total de usuarios nicos por da 33.580
Promedio de usuarios simultneos 172
Mximo de usuarios simultneos 376
N total de solicitudes por da 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%
158
Agente de usuario Solicitudes Porcentaje del total
DAV 2.418 0,07%

Bsqueda (rastreo) 92.322 2,75%
OneNote 1.628 0,05%
Outlook 961 0,03%
Word 449 0,01%
Conjunto de datos
En esta seccin se describe el conjunto de datos de la granja de servidores del caso prctico, que incluye los tamaos de base de datos
y los ndices de bsqueda.
Caractersticas del conjunto de datos Valor
Tamao de base de datos (combinado) 49,9 GB

Tamao BLOB 22,2 GB
Nmero de bases de datos de contenido 3
Nmero de aplicaciones web 3
Nmero de colecciones de sitios 4
Nmero de sitios 797
Tamao de ndice de bsqueda (cantidad de elementos) 275.000
159
Datos de mantenimiento y rendimiento
En esta seccin se proporcionan los datos de mantenimiento y rendimiento especficos del entorno del caso prctico.
Contadores generales
Mtrica Valor
Disponibilidad (tiempo activo) 99,95%

Frecuencia de errores 0,05%
Promedio de memoria usada 1,08 GB
Mximo de memoria usada 2,60 GB
Porcentaje de trfico del rastreo de bsqueda (Buscar solicitudes de 6%
clientes/solicitudes totales)
Solicitudes de ASP.NET en cola 0,00
En los siguientes grficos se muestra la latencia y el uso de CPU promedio de este entorno.
160
161
En este documento, la latencia se divide en cuatro categoras. 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 ms lentos.
Contadores de la base de datos
Al interpretar las estadsticas de la base de datos para este entorno de publicacin empresarial, tenga en cuenta que la mayora de los
visitantes tienen permisos de solo lectura.
Mtrica Valor
Tasa de lectura y escritura (E/S por base de datos) 99,999:0,001
162
Mtrica Valor
Promedio de longitud de la cola de disco 0,35

Longitud de la cola de disco: lecturas 34
Longitud de la cola de disco: escrituras 2,5
Lecturas de disco/s 131,33
Escrituras en disco/s 278,33
Compilaciones SQL/s 2,36
Recompilaciones SQL/s 94,80
Bloqueos de SQL: tiempo promedio de espera 0 ms
Bloqueos de SQL: tiempo de espera de bloqueos 0 ms
Bloqueos de SQL: interbloqueos por segundo 0
Bloqueos temporales de SQL: tiempo promedio de espera 0,25 ms
Frecuencia de aciertos de cach de SQL >99%
163
Enterprise intranet collaboration environment technical case
study (SharePoint Server 2010) (en ingls)
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
Before reading this document, make sure that you understand the key concepts behind SharePoint Server 2010 capacity management.
The following documentation will help you learn about the recommended approach to capacity management and provide context for
helping you understand how to make effective use of the information in this document, and also define the terms used throughout this
document.
For more conceptual information about performance and capacity that you might find valuable in understanding the context of the data in
this technical case study, see the following documents:
164
Capacity management and sizing for SharePoint Server 2010 (en ingls)

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 ingls) about
SharePoint environments at Microsoft.
165
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 ingls).
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
166
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.
167
Application Server APP1-4
Processor(s) 4 six core @ 2.40 GHz

RAM 64 GB
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.
168
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.
169
170
Configuration
The following table enumerates settings that were changed that affect performance or capacity in the environment.
Setting Value Notes
Usage Service 5 days The default is 14 days. Lowering this setting can save disk space on
Trace Log days to store log files the server where the log files are stored.
(default: 14 days)
QueryLoggingThreshold 1 second The default is 5 seconds. Lowering this setting can save bandwidth and
SharePoint Foundation Database CPU on the database server.
change QueryLoggingThreshold
to 1 second
Database Server Default 1 The default is 0. To ensure optimal performance, we strongly
Instance recommend that you set max degree of parallelism to 1 for database
Max degree of parallelism 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
171
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
172
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

This section provides health and performance data that is specific to the Case Study environment.
General Counters
Metric Value
Availability (uptime) 99.1%

Failure Rate 0.9%
Average memory used 3.4 GB
Maximum memory used 16.1 GB
Search Crawl % of Traffic (Search client requests / total requests) 47%
ASP.NET Requests Queued 0.00
The following charts show the average CPU utilization and latency for this environment:
173
174
In this document, latency is divided into four categories. The 50th percentile latency is typically used to measure the servers
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
175
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%
176
Enterprise intranet collaboration environment lab study
(SharePoint Server 2010) (en ingls)
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

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.
177
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 ingls).
Before reading this document, make sure that you understand the key concepts behind capacity management in SharePoint Server 2010.
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.
178
Note that requests differ from page loads; each page contains several components, each of which creates one or more requests when
the page is loaded. Therefore, one page load creates several requests. Typically, authentication checks and events using insignificant
resources are not counted in RPS measurements.
Green Zone: This is the state at which the server can maintain the following set of criteria:
The server-side latency for at least 75% of the requests is less than 1 second.
All servers have a CPU Utilization of less than 50%.
Nota:
Because this lab environment did not have an active search crawl running, the database server was kept at 40% CPU Utilization or lower,
to reserve 10% for the search crawl load. This assumes Microsoft SQL Server Resource Governor is used in production to limit Search
crawl load to 10% CPU.
Failure rate is less than 0.01%.
Red Zone (Max): This is the state at which the server can maintain the following set of criteria:
HTTP request throttling feature is enabled, but no 503 errors (Server Busy) are returned.
Failure rate is less than 0. 1%.
The server-side latency is less than 3 seconds for at least 75% of the requests.
Database server CPU utilization is less than 80%, which allows for 10% to be reserved for the Search crawl load, limited by using
SQL Server Resource Governor.
AxBxC (Graph notation): This is the number of Web servers, application servers, and database servers respectively in a farm. For
example, 8x1x2 means that this environment has 8 Web servers, 1 application server, and 2 database servers.
MDF and LDF: SQL Server physical files. For more information, see Files and Filegroups Architecture.
Overview
This section provides an overview to our scaling approach, to the relationship between this lab environment and a similar case study
environment, and to our test methodology.
179
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 ingls).
Methodology and Test Notes
This document provides results from a test lab environment. Because this was a lab environment and not a production environment, we
were able to control certain factors to show specific aspects of performance for this workload. In addition, certain elements of the
production environment, listed here, were left out of the lab environment to simplify testing overhead. We do not recommend omitting
these elements for production environments.
Between test runs, we modified only one variable at a time, to make it easy to compare results between test runs.
180
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 Planeacin y configuracin del
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
181
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 servers 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)
182
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:
183
184
Configuration
To allow for the optimal performance, the following configuration changes were made in this lab environment.
Setting Value Notes
Site Collection
Blob Caching On The default is Off. Enabling Blob Caching improves server efficiency by
reducing calls to the database server for static page resources that may
be frequently requested.
Database Server Default
Instance
Max degree of parallelism 1 The default is 0. To ensure optimal performance, we strongly
recommend that you set max degree of parallelism to 1 for database
servers that host SharePoint Server databases. For more information
about how to set max degree of parallelism, see max degree of
parallelism Option(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 ingls).
Here are the details of the mix for the lab tests run against SharePoint Server 2010 compared to the production environment. Although
there are some minor differences in the workloads, both represent a typical transactional mix on an enterprise collaboration environment.
185
186
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
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:
187
The environment scaled up to four Web servers per database server. However, the increase in throughput was non-linear especially
on addition of the fourth Web server.
After four Web servers, there are no additional gains to be made in throughput by adding more Web servers because the bottleneck at
this point was the database server CPU Utilization.
The average latency was almost constant throughout the whole test, unaffected by the number of Web servers and throughput.
Nota:
The conclusions described in this section are hardware specific, and the same throughput might have been achieved by a larger number
of lower-end hardware, or a smaller number of higher-end hardware. Similarly, changing the hardware of the database server would affect
the results. To get an idea on how much of a difference the hardware of the Web servers can affect these results, see the Web Server
Scale Up section.
Results graphs and charts

In the following graphs, the x axis shows the change in the number of Web servers in the farm, scaling from one Web server (1x1x1) to
five Web servers (5x1x1).
1. Latency and RPS
The following graph shows how scaling out (adding Web servers) affects latency and RPS.
188
2. Processor utilization
The following graph shows how scaling out the Web servers affects processor utilization on the Web server(s) and the database server.
189
3. SQL Server I/O operations per section (IOPs) for MDF and LDF files
The following graphs show how the IOPs on the content databases change as the number of Web servers is scaled out. These are
measured by looking at the following performance counters:
PhysicalDisk: Disk Reads / sec
190
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 Planeacin y configuracin del almacenamiento y capacidad
de SQL Server (SharePoint Server 2010).
Maximum:
191
Green Zone:
Example of how to read these graphs:

An organization with a workload similar to that described in this document that expects 300 RPS to be their green zone, could use 3x1x1
topology, and would use approximately 600 Physical Disk reads/sec on the MDF file.
Database Server Scale Out
This section describes the test results that were obtained when we scaled out the number of database servers in this lab environment.
192
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.
193
2. Processor utilization
The following graphs show how scaling out affects processor utilization.
194
3. Memory utilization at scale out
Throughout our testing, weve 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 ingls). Additional content about
memory requirements for increased numbers of site collections is under development. Check back for new and updated content.
195
4. SQL Server I/O operations per section (IOPs) for MDF and LDF files
The following graphs show how the IOPs change as both the number of Web servers and the number of database servers is scaled out.
Maximum RPS
196
Green Zone RPS
Web server Scale Up

This section describes the test results that were obtained when we scaled up the Web servers in this lab environment.
Test methodology
Add more Web server processors, but keep the rest of the farm the same.
Analysis
Scale is linear up to eight processor cores.
197
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.
198
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.
199
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 servers
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.
200
The following graph shows the throughput when Web servers were at maximum scale out.
201
202
Departmental collaboration environment technical case study
(SharePoint Server 2010) (en ingls)
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
document.
203

This white paper describes an actual SharePoint Server 2010 environment at Microsoft. Use this document to compare with your planned
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
204
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:
information about the capacity management process, see Informacin general sobre administracin y ajuste de tamao 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.
205
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 3x146GB 15K SAS (3
2: Swap and BLOB Cache Disk 3: Logs and Temp RAID 1 Disks) Disk 1: OS
directory Disk 2: Swap and BLOB
Cache Disk 3: Logs and
Temp directory
Number of network adapters 2 2
Network adapter speed 1 Gigabit 1 Gigabit
Authentication Windows NTLM Windows NTLM
Load balancer type Hardware load balancing Hardware load balancing
Software version SharePoint Server 2010 (pre-release version) SharePoint Server 2010
(pre-release version)
Services running locally Search Query WFE3 No services
WFE4 Search crawl
target
Application Server
There are four application servers in the farm.
206
Web Server APP1-3 APP4
Processor(s) 2 quad core @ 2.33 GHz 2 quad core @ 2.33 GHz

RAM 16 GB 16 GB
Operating system Windows Server 2008, 64 bit Windows Server 2008, 64
bit
Size of the SharePoint drive 3x146GB 15K SAS (3 RAID 1 Disks) Disk 1: OS Disk 2x136GB 15K SAS (RAID
2: Swap and BLOB Cache Disk 3: Logs and Temp 0) 4x60GB SSD, SATA
directory (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 Search Crawler
except for Office Web Applications
APP2 All applications (including Office Web
Applications)
APP3 Office Web Applications
207
Database Servers
There are three database servers, one running the default SQL Server instance housing the content databases, one running the Usage
and Web Analytics databases, and one running the Search databases.
Database DB1 Default Instance DB2 DB3
Processor(s) 4 quad core @ 3.2 GHz 2 quad core @ 3.2 2 quad core
GHz @ 3.2 GHz
RAM 32 GB 16 GB 32 GB
Operating system Windows Server 2008 SP1, 64 bit Windows Server 2008 Windows
SP1, 64 bit Server 2008
SP1, 64 bit
Storage and geometry 5x146GB 15K SAS + SAN 6x450GB 15K SAS 2x136GB
Disk 1: OS (2 disk RAID 10) Directly attached 15K SAS
14x146GB 15K SAS (RAID 0)
Disk 2: Swap (2 disk RAID 10)
Disk 1: Usage logs 6x60GB
Disk 3: Direct Attached Storage (16 disk RAID 10,
and OS SSD, SATA
Temp DB data) SAS 146 GB 15K
(RAID 5)
Disk 4: Direct Attached Storage (16 disk RAID 10, Disk 2: Usage data
Disk 1: OS
Temp DB data) SAS 146 GB 15K
Disk 2:
Disk 5-15: SAN using fiber connection. When
Swap and
possible, one database per two disks. Separating
BLOB
logs and data between LUNs. 15K drives.
Cache
Disk 3:
Logs and
Temp
directory.
Solid state
drives. 6-
208
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
209
210
Configuration
The following table enumerates settings that were made that affect performance or capacity in the environment.
Setting Value Notes
Site collection: On Enabling the output cache improves server efficiency by

Object Caching (On | Off) Disabled reducing calls to the database for data that is frequently
requested.
Anonymous Cache Profile Disabled
(select) On 100GB
Anonymous Cache Profile 60 seconds
(select)
Object Cache (Off | n MB)
Cross List Query Cache
Changes (Every Time | Every
n seconds)
Site collection cache profile Intranet (Collaboration Site) Allow writers to view cached content is checked,
(select) 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: 5 days The default is 14 days. Lowering this setting can save disk
Trace Log days to store log space on the server where the log files are stored.
files (default: 14 days)
Query Logging Threshold: 1 second The default is 5 seconds. Lowering this setting can save
Microsoft SharePoint bandwidth and CPU on the database server.
Foundation Database
configure
211
Setting Value Notes
QueryLoggingThreshold to 1
second
Database Server Default 1 The default is 0. To ensure optimal performance, we
Instance: strongly recommend that you set max degree of parallelism
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

Total number of unique users per day 9186
Maximum concurrent users 322
212
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

BLOB size 1.68 TB
Total number of databases 36
213

Search index size (number of items) 4.6 million

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:
214
215
measure spikes in server response times. It means that 95% of requests are served within that response time, and therefore, 5% of the
216
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%
217
Divisional portal environment lab study (SharePoint Server
2010) (en ingls)
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

This document outlines the test methodology and results to provide guidance for capacity planning of a typical divisional portal. A
divisional portal is a SharePoint Server 2010 deployment where teams mainly do collaborative activities and some content publishing. This
document assumes a "division" to be an organization inside an enterprise with 1,000 to 10,000 employees.
Different scenarios will have different requirements. Therefore, it is important to supplement this guidance with additional testing on your
own hardware and in your own environment. If your planned design and workload resembles the environment described in this document,
you can use this document to draw conclusions about scaling your environment up and out.
When you read this document, you will understand how to do the following:
218
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
Before reading this document, make sure that you understand the key concepts behind capacity management in SharePoint Server 2010.
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%.
219
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.
220
For the purpose of these tests, all of the services databases and the content databases were put on the same instance of Microsoft
SQL Server. The usage database was maintained on a separate instance of SQL Server.
For the purpose of these tests, BLOB cache is enabled.
Search crawl traffic is not considered in these tests. But to factor in the effects of an ongoing search crawl, we modified definitions of a
healthy farm. (Green-zone definition to be 40 percent for SQL Server to allow for 10 percent tax from Search crawls. Similarly, we
used 80 percent SQL Server CPU as the criteria for max RPS.)
Test methodology
We used Visual Studio Team System for Test 2008 SP2 to perform the performance testing. The testing goal was to find the performance
characteristic of green zone, max zone and various system stages in between for each topology. Detailed definitions of "max zone" and
"green zone" are given in the Glossary as measured by specific values for performance counters, but in general, a farm configuration
performing around "max zone" breakpoint can be considered under stress, whereas a farm configuration performing "green zone"
breakpoint can be considered healthy.
The test approach was to start by using the most basic farm configuration and run a set of tests. The first test is to gradually increase the
load on the system and monitor its performance characteristic. From this test we derived the throughput and latency at various user loads
and also identified the system bottleneck. After we had this data, we identified at what user load did the farm exhibit green zone and max
zone characteristics. We ran separate tests at those pre-identified constant user loads for a longer time. These tests ensured that the farm
configuration can provide constant green zone and max zone performance at respective user loads, over longer period of time.
Later, while doing the tests for the next configuration, we scaled out the system to eliminate bottlenecks identified in previous run. We kept
iterating in this manner until we hit SQL Server CPU bottleneck.
We started off with a minimal farm configuration of 1 Web server /application server and 1 database server. Through multiple iterations,
we finally ended at 3 Web servers, 1 application server, 1 database server farm configuration, where the database server CPU was maxed
out. Below you will find a quick summary and charts of tests we performed on each iteration to establish green zone and max zone for that
configuration. That is followed by comparison of green zone and max zone for different iterations, from which we derive our
recommendations.
The SharePoint Admin Toolkit team has built a tool that is named "Load Test Toolkit (LTK)" which is publically available for customers to
download and use.
Specifications
This section provides detailed information about the hardware, software, topology, and configuration of the lab environment.
221
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) 2px4c@2.33GHz 2px4c@2.33GHz 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 Windows

Server 2008 R2 x64 Server 2008
x64
222
Server
Software version SharePoint Server 2010 and Office Web SharePoint Server SQL Server
Applications, pre-release versions 2010 and Office Web 2008 R2
Applications, pre- CTP3
release versions
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 Not
Microsoft SharePoint Foundation Web Application Excel Services applicable
Microsoft SharePoint Foundation Workflow Timer Managed Metadata
Service Web Service
Search Query and Site Settings Service Microsoft SharePoint
SharePoint Server Search Foundation Incoming
E-Mail
Foundation Web
Application
Foundation Workflow
Timer Service
PowerPoint Services
223
Server
Search Query and
Site Settings Service
SharePoint Server
Search
Visio Graphics
Services
Word Viewing Service
The table indicates which services are provisioned in the test environment. Other services such as the User Profile service and Web
Analytics are not provisioned.
Topology and configuration
The following diagram shows the topology used for the tests. We changed the number of Web servers from 1 to 2 to 3, as we moved
between iterations, but otherwise the topology remained the same.
224
225
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 1.2 75 GB

GB terabytes
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.
226
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 r 4.11%
SearchCenter
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 r 0.24%
PNG/Silverlight
Microsoft SharePoint Foundation List Check out and then check in an item w 0.83%
List - Get list r 0.83%
List - Outlook sync r 1.66%
List - Get list item changes r 2.49%
List - Update list items and adding new items w 4.34%
Get view and view collection r 0.22%
Get webs r 1.21%
227
Feature or Service Operation Read/write Percentage of
mix
Browse to Access denied page r 0.07%

View Browse to list feeds r 0.62%
Browse to viewlists r 0.03%
Browse to default.aspx (home page) r 1.70%
Browse to Upload doc to doc lib w 0.05%
Browse to List/Library's default view r 7.16%
Delete doc in doclib using DAV w 0.83%
Get doc from doclib using DAV r 6.44%
Lock and Unlock a doc in doclib using DAV w 3.32%
Propfind list by using DAV r 4.16%
Propfind site by using DAV r 4.16%
List document by using FPSE r 0.91%
Upload doc by using FPSE w 0.91%
Browse to all site content page r 0.03%
View RSS feeds of lists or wikis r 2.03%
Servicios de Excel Render small/large Excel files r 1.56%
Workspaces WXP - Cobalt internal protocol r 23.00%
Full file upload using WXP w 0.57%
228
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
229
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.
230
The following chart shows performance counter data in a 1x1 configuration.
231
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.
232
The following chart shows performance counter data in a 1x1x1 configuration.
233
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.
234
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.
235
The following chart shows performance counter data in a 2x1x1 configuration.
236
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.
237
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.
238
The following chart shows performance counter data for a 3x1x1 configuration.
239
Comparison
From the iterative tests we performed, we found out the points at which a configuration enters max zone or green zone. Heres a table of
those points.
The table and charts in this section provide a summary for all the results that were presented earlier in this article.
240
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.
241
The following chart shows a summary of latency at different configurations.
242
A note on disk I/O
Disk I/O based bottlenecks are not considered while prescribing recommendations in this document. However, it is still interesting to
observe the trend. Here are the numbers:
243
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.
244
Tests with Search incremental crawl
As we mentioned before, all the tests until now were run without Search crawl traffic. In order to provide information about how ongoing
search crawl can affect performance of a farm, we decided to find out the max user RPS and corresponding user latencies with search
crawl traffic in the mix. We added a separate Web server to 3x1x1 farm, designated as a crawl target. We saw a 17% drop in RPS
compared to original RPS exhibited by 3x1x1.
245
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 No 10%

Crawl Resource Resource
Governor 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.
246
247
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. Its not a recommended configuration for a divisional portal in
production.
Separate out content databases and services databases on separate instances of SQL Server: In the test workload used in tests,
when SQL Server was bottlenecked on CPU, only 3% of the traffic was to the services databases. Thus this step would have achieved
slightly better scale out than what we saw. But, in general, increase in scale out by separating out content databases and services
databases is directly proportional to the traffic to services database in your farm.
Separate out individual content databases on separate instances of SQL Server. In the dataset used for testing, we had 5 content
databases, all located on the same instance of SQL Server. By separating them out on different computers, you will be spreading
CPU utilization across multiple computers. Therefore, you will see much larger RPS numbers.
Finally when SQL Server is bottlenecked on CPU, adding more CPU to SQL Server can increase RPS potential of the farm almost
linearly.
248
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? Heres 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.
249
Social environment technical case study (SharePoint Server
2010) (en ingls)
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
document.
250

This white paper describes an actual SharePoint Server 2010 environment at Microsoft. Use this document to compare with your planned
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
251
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:
information about the capacity management process, see Informacin general sobre administracin y ajuste de tamao 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.
252
Web Server WFE1-3

RAM 16 GB
Operating system Windows Server 2008, 64 bit
Microsoft SharePoint Foundation Incoming E-Mail
Services consumed from a federated services farm User Profile Service
Business Data Connectivity Service
Managed Metadata Web Service
Application Server
There are two application servers in the farm, each with identical hardware.
253
Application Server APP1-4

RAM 16 GB
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.
254
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
255
256
Configuration
The following table enumerates settings that were changed that affect performance or capacity in the environment.
Setting Value Notes
Usage Service: 5 days The default is 14 days. Lowering this setting can save disk space on
Trace Log days to store log files the server where the log files are stored.
(default: 14 days)
QueryLoggingThreshold 1 second The default is 5 seconds. Lowering this setting can save bandwidth and
Microsoft SharePoint Foundation CPU on the database server.
Database configure
QueryLoggingThreshold to 1
second
Database Server Default 1 The default is 0. To ensure optimal performance, we strongly
Instance recommend that you set max degree of parallelism to 1 for database
Max degree of parallelism 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
257

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%
258
Dataset

BLOB size 1.05 TB
Search index size (number of items) 5.5 million

This section provides health and performance data that is specific to the case study environment.
General Counters
Metric Value

Failure Rate 0.39%
259
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.
260
261
measure spikes in server response times. It means that 95% of requests are served within that response time, and therefore, 5% of the
Database Counters
Metric Value
Read/Write Ratio (IO Per Database) 99.854 : 0.146

262
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%
263
Recomendaciones y resultados de pruebas de rendimiento y
capacidad (SharePoint Server 2010)
Esta seccin contiene una serie de notas del producto y artculos que describen el impacto de rendimiento y capacidad de los conjuntos
de caractersticas especficas incluidos en Microsoft SharePoint Server 2010. Estas notas del producto y artculos incluyen informacin
acerca del rendimiento y la capacidad de la caracterstica, y las pruebas de Microsoft, incluidas:
Prueba de las caractersticas de la granja de servidores
Resultados de las pruebas
Recomendaciones
Solucin de problemas de rendimiento y escalabilidad
Nota:
Las notas del producto se van a actualizar y volver a publicar como artculos. Si descarga una nota del producto desde esta pgina, es
posible que, cuando vuelva a publicarse como un artculo, contenga informacin actualizada.
Antes de leer estas notas del producto y estos artculos, es importante que conozca los conceptos clave sobre la administracin de
capacidad en SharePoint Server 2010. Para obtener ms informacin, vea Capacity management and sizing for SharePoint Server 2010
(en ingls).
La siguiente tabla describe las notas del producto y los artculos 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.
264
Asunto Descripcin
Servicios de Access Proporciona informacin orientativa sobre cmo el uso de Servicios de

Access afecta a las topologas que ejecutan SharePoint Server 2010.
Vea el artculo en Estimate performance and capacity requirements for
Access Services in SharePoint Server 2010 (en ingls).
Servicios de conectividad empresarial Proporciona informacin orientativa sobre el impacto en el uso de
recursos que tiene la utilizacin de Servicios de conectividad
empresarial en las topologas que ejecutan SharePoint Server 2010.
Descargue estas notas del producto (BCSCapacityPlanningDoc.docx).
Informacin general sobre las memorias cach Proporciona informacin 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 aplicacin empresarial.
Descargue estas notas del producto
(SharePointServerCachesPerformance.docx).
Servicios de Excel en Microsoft SharePoint Server 2010 Proporciona informacin orientativa sobre planeacin para Servicios de
Excel en Microsoft SharePoint Server 2010. Vea el artculo en Estimate
performance and capacity requirements for Excel Services in SharePoint
Server 2010 (en ingls).
InfoPath Forms Services Proporciona informacin orientativa sobre el impacto en el uso de
recursos que tiene la utilizacin de InfoPath Forms Services en las
topologas que ejecutan SharePoint Server 2010. Descargue estas
notas del producto (InfoPath2010CapacityPlanningDoc.docx).
Listas de gran tamao Proporciona informacin orientativa sobre el rendimiento de las listas y
bibliotecas de documentos de gran tamao. Este documento es
especfico para SharePoint Server 2010, aunque las limitaciones que se
mencionan tambin se aplican a Microsoft SharePoint Foundation 2010.
(DesigningLargeListsMaximizingListPerformance.docx).
265
Asunto Descripcin
Repositorios de documentos de gran escala Proporciona informacin orientativa sobre el rendimiento de los
repositorios de documentos de gran escala en relacin con SharePoint
Server 2010. Descargue estas notas del producto
(LargeScaleDocRepositoryCapacityPlanningDoc.docx).
Mis sitios y sistemas sociales Proporciona informacin orientativa sobre el impacto en el uso de
recursos que tiene la utilizacin de Mis sitios y otras caractersticas de
sistemas sociales en las topologas que ejecutan SharePoint Server
2010. Descargue estas notas del producto
(MySitesSocialComputingCapacityPlanningDoc.docx).
Office Web Apps Proporciona informacin orientativa sobre el impacto en el uso de
recursos que tiene la utilizacin de Office Web Apps en las topologas
que ejecutan SharePoint Server 2010. Descargue estas notas del
producto (OfficeWebAppsCapacityPlanningDoc.docx).
PerformancePoint Services Proporciona informacin orientativa sobre el impacto en el uso de
recursos que tiene la utilizacin de PerformancePoint Services en las
topologas que ejecutan SharePoint Server 2010. Vea el artculo en
Estimacin de los requisitos de rendimiento y capacidad de
PerformancePoint Services.
Bsqueda Proporciona informacin acerca del planeamiento de capacidad para
distintas implementaciones de bsqueda en SharePoint Server 2010,
incluidas las granjas de servidores pequeas, medianas y grandes.
(SearchforSPServer2010CapacityPlanningDoc.docx).
Si usa FAST Search Server 2010 for SharePoint como solucin del
motor de bsqueda Enterprise Search, vea Plan for performance and
capacity (FAST Search Server 2010 for SharePoint).
Servicios de Visio Proporciona informacin orientativa sobre el impacto en el uso de
recursos que tiene la utilizacin de Servicios de Visio en las topologas
266
Asunto Descripcin
que ejecutan SharePoint Server 2010. Descargue estas notas del
producto (VisioServicesCapacityPlanningDoc.docx).
Web Analytics Proporciona informacin orientativa sobre el impacto en el uso de
recursos que tiene la utilizacin del servicio de Web Analytics en las
topologas que ejecutan SharePoint Server 2010. Vea los artculos en
Capacity requirements for Web Analytics Shared Service in SharePoint
Administracin de contenido web Proporciona informacin acerca de la planeacin de rendimiento y
capacidad para una solucin de administracin de contenido web. Vea
el artculo en Estimacin de los requisitos de rendimiento y capacidad
para la administracin de contenido web en SharePoint Server 2010.
Servicios de automatizacin de Word Proporciona informacin orientativa sobre el planeamiento de capacidad
para Servicios de automatizacin de Word en SharePoint Server 2010.
Descargue estas notas del producto (WASCapacityPlanningDoc.docx).
Flujo de trabajo Proporciona informacin orientativa sobre el impacto en el uso de
recursos que tiene la utilizacin del flujo de trabajo en las topologas 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 ingls)
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:
267
Test farm characteristics
Test results
Recommendations
Troubleshooting

This section describes the dataset that was used during the testing; the workloads that were placed on the product during performance
gathering; the hardware that was used during the testing; and the topology for how that hardware was deployed.
Dataset
Servicios de Access capacity and performance is highly dependent on the makeup of the applications that are hosted on the service. The
size of tables and the complexity of queries often have the most effect on capacity and performance. The testing used representative
sizes and complexities, but every application and dataset is different. The capacity and performance will depend on the applications that
are being used, their specific complexity, and the data size.
To evaluate the capacity profile, Servicios de Access applications were simulated on a farm dedicated to Servicios de Access (no other
SharePoint tests were running). The farm contained the following representative sites:
1,500 Servicios de Access applications that have a Small size profile; 100 items maximum per list.
1,500 Servicios de Access applications that have a Medium size profile; 2,000 items maximum per list.
1,500 Servicios de Access applications that have a Large size profile; 10,000 items maximum per list.
Each application is made up of multiple lists, and the other lists are appropriately sized based on this largest list. Servicios de Access can
handle more data than 10,000 items. This number for the Large profile was chosen because it was expected that larger applications
would not be common.
The applications were evenly distributed among the following applications:
Contacts A simple contact management application, dominated by a single list.
Projects A simple task and project tracking applications, dominated by two lists (projects and tasks associated with each project).
Orders A simple order entry system, similar to the Northwind Traders sample of Microsoft Access, but scaled down, and included
many interrelated lists (orders, order details, invoices, invoice details, purchase orders, purchase order details, and so on).
268
Workload
To simulate application usage, workloads were created to perform one or more of the following operations:
Opening forms
Paging through the forms
Filtering and sorting data sheets
Updating, deleting and inserting records
Publishing application
Render reports
Each workload includes think time between user actions, ranging from 5 to 20 seconds. This differs from other SharePoint capacity
planning documents. Servicios de Access is stateful; memory cursors and record sets were maintained between user interactions. It was
important to simulate a full user session and not merely individual requests. For a single user workload, there is an average of two
requests per second.
The following table shows the percentages used to determine which application and which size of application to use.
Small Medium Large
Contacts 16% 10% 9%

Projects 18% 12% 10%
Orders 11% 8% 6%
Green and red zone definitions

For each configuration, two tests were ran to determine a green zone and a red zone. The green zone is the recommended throughput
that can be sustained. The red zone is the maximum throughput that can be tolerated for a short time, but should be avoided.
The green zone was defined as a point at which the test being run consumes at most half the bottlenecking resource. In this case, the
bottlenecking resource was %CPU on any of the three tiers: front-end Web server, application server (Access Data Services), or database
server (SQL Server). First, the bottleneck was identified for a particular configuration. If the bottleneck was Access Data Services CPU, we
made sure that the green zone test consumed CPU on the Access Data Services computers in a range between 40 and 50 percent.
269
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
270
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.
271
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
272
273
Recommended results
The following graph shows the results for recommended sustainable throughput.
274
As described earlier in this article, adding the fourth Access Data Services computer shifts the bottleneck to the front-end Web server, and
that adding a second front-end Web server resolves the resource constraint on the front-end Web server tier. This would imply, that 1x1,
1x2, and 1x3 are reasonable configurations. However, when the fourth Access Data Services computer is added, a front-end Web server
should also be added. Because scaling is in a linear manner (straight line between from 1x1 to 1x4), it can be assumed that the addition of
a seventh Access Data Services computer would also imply the addition of a third front-end Web server, and so on, to satisfy the needs of
the farm.
Remember that these results are based on a simulated work load only, and that an actual deployment should be monitored to find the
point at which additional front-end Web servers are needed to support additional Access Data Services computers. Also, the front-end
Web servers are dedicated to Servicios de Access, and in reality the front-end Web servers are likely shared with other SharePoint
workloads. The following graph shows the results.
275
The following graph shows the response time at this throughput level. The response time is very fast, at less than second on average
per request.
276
These results show that the SQL Server computer was not a bottleneck, because adding a second front-end Web server resolved the
resource shortage, and the SQL Server CPU was always less than 50 percent. However, be aware that the instance of SQL Server is
277
shared with other SharePoint services and SharePoint itself, and so the cumulative effect might drive CPU or disk I/O queue lengths to the
point that they do become a bottleneck.
Maximum
The following graph shows the results, in which throughput was pushed beyond what could be sustained.
In this graph we see that again a second front-end Web server was needed to maximum the usefulness of the fourth Access Data
Services computer. Again, your results might vary, because this is highly dependent on the applications and their usage patterns.
278
279
In this case, the response time is increased, as the overall system is under stress. However, these levels are still approximately one
second, and acceptable to most users.
It might seem odd that with four Access Data Services computers, two front-end Web servers have an increased response time than one
front-end Web server. This is because the overall throughput of the system is increased with two front-end Web servers.
280
SQL Server is again not a limiting factor here, because adding the second front-end Web server put us back on a linear scaling line.
However, we are reaching almost 90 percent CPU usage on the instance of SQL Server. Therefore, there is very little headroom
remaining. If we were to add a fifth Access Data Services computer, the SQL Server computer likely would have become the bottleneck.
281
Detailed results
The following tables show the detailed results for the recommended configurations.
282
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 1x1 1x2 1x3 1x4 2x1 2x2 2x4
tier
%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 1x1 1x2 1x3 1x4 2x1 2x2 2x4
(Access Data Services) tier
%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
283
Database server (SQL Server) 1x1 1x2 1x3 1x4 2x1 2x2 2x4
tier (single computer)
%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 1x1 1x2 1x3 1x4 2x1 2x2 2x4
tier
%CPU 13.82 24.40 41.02 43.62 6.31 12.48 26.18

284
Average application server 1x1 1x2 1x3 1x4 2x1 2x2 2x4
(Access Data Services) tier
%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) 1x1 1x2 1x3 1x4 2x1 2x2 2x4
tier (single computer)
%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
285
application and dataset is different. Therefore, the capacity and performance will depend on the applications in use, their specific
complexity, and the data size.
Hardware recommendations
Servicios de Access uses standard hardware for both front-end Web servers and application servers; no special requirements are
necessary. General SharePoint Server 2010 guidelines for CPU number, speed, and memory are applicable for computers in the
application server (Access Data Services) tier.
Scaled-up and scaled-out topologies
To increase the capacity and performance of one of the starting-point topologies, you can do one of two things. You can either scale up by
increasing the capacity of your existing servers or scale out by adding additional servers to the topology. This section describes the
general performance characteristics of several scaled-out topologies.
The sample topologies represent the following common ways to scale out a topology for an Servicios de Access scenario:
To provide for more user load, check the CPU for the existing Servicios de Access application servers. Add additional CPUs or cores,
or both, to these servers if it is possible. Add more Servicios de Access server computers as needed. This can be done to the point
that the front-end Web server has become the bottleneck, and then add front-end Web servers as needed.
In our tests, memory on the front-end Web server tier and application server (Access Data Services) tier was not a bottleneck.
Depending on the size of the result sets, memory could become an issue. However, we do not expect that to be the norm. Track the
private bytes for the Access Data Services w3wp process, as described here.
In our tests, SQL Server was not a bottleneck. However, our tests were run in isolation from other SharePoint Server 2010 services.
SQL Server CPU and disk I/O should be monitored and additional servers or spindles added as needed.
Performance-related Access Services settings
One way to control the performance characteristics of Servicios de Access is to limit the size and complexity of queries that can be
performed. Servicios de Access provides a set of configurable throttles for controlling queries. Each of the following queries can be set
through SharePoint Central Administration. (In the Application Management section, click Manage Service Applications, and then click
Servicios de Access.)
In general, how much data that has to be retrieved from SharePoint to perform a query will have a significant effect on performance. This
can be controlled in several ways. First, the inputs to a query can be limited:
Maximum Sources per Query
Maximum Records per Table
Second, the resulting size of a query can be limited:
286
Maximum Columns per Query
Maximum Rows per Query
Allow Outer Joins
In addition to the size of the query (data size in and out), the processing complexity on the data can be controlled, to reduce the CPU load
on the application server (Access Data Services) tier:
Maximum Calculated Columns per Query
Maximum Order by Clauses per Query
Obviously, the previous settings will affect the applications that can be run on the server. For example, if an application is written with 40
output columns from a query, and the settings are below this level, the application will throw a runtime error. A balance between user need
and acceptable performance must be struck, and is highly dependent on the kind of Access applications that are expected to be run on
the farm.
One additional, more extreme measure can be taken. SharePoint Server 2010 supports a set of query operations natively, which Servicios
de Access augments to cover a broader set of application scenarios. For Servicios de Access to improve queries from SharePoint, there is
the potential that a large amount of data might have to be retrieved from the SharePoint content database. Instead, Servicios de Access
can be set to stick with only query operations, which can be natively supported by SharePoint. Therefore, avoiding the data fetch required
for more complex operations:
Allow Non-Remotable Queries
Optimizations
Common bottlenecks and their causes
During performance testing, several different common bottlenecks were revealed. A bottleneck is a condition in which the capacity of a
particular constituent of a farm is reached. This causes a plateau or decrease in farm throughput.
The table in Troubleshooting later in this article lists some common bottlenecks and describes their causes and possible resolutions.
Performance monitoring
To help you determine when you have to scale up or scale out the system, use performance counters to monitor the health of the system.
Use the information in the following tables to determine which performance counters to monitor, and to which process the performance
counters should be applied.
Front-end Web servers
The following table shows performance counters and processes to monitor for Web servers in your farm.
287
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
288
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 users 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
289
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
290
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 Increase the number of CPUs or cores, or both, in the existing
large amount of processing in the Access Data Services computers. Add additional Access Data
application server tier. If a 1x1, 1x2, Services computers if possible.
or 1x3 configuration is used, the first
bottleneck encountered will likely be
the CPU on the Access Data
Services servers.
Web server CPU usage When a Web server is overloaded This issue can be resolved in one of two ways. You can add
with user requests, average CPU more Web servers to the farm to distribute user load, or you
usage will approach 100 percent. can scale up the Web server or servers by adding higher-
This prevents the Web server from speed processors.
responding to requests quickly and
can cause timeouts and error
messages on client computers.
Database server disk I/O When the number of I/O requests to Distributing data files across multiple physical drives allows
a hard disk exceeds the disks I/O for parallel I/O. The blog SharePoint Disk Allocation and Disk
291
capacity, the requests will be queued. I/O (http://go.microsoft.com/fwlink/?LinkId=129557) contains
As a result, the time to complete useful information about resolving disk I/O issues.
each request increases.
Reporting Services CPU utilization The Reporting Services process is Dedicate a computer to Reporting Services, taking load from
using a large share of the CPU the application server (Access Data Services) tier (connected
resources. mode) or the front-end Web server tier (local mode).
292
Estimate performance and capacity requirements for Excel
Services in SharePoint Server 2010 (en ingls)
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 ingls).

This section describes the dataset, workloads, hardware settings, topology, and test definitions that were used during the performance
and capacity testing of Servicios de Excel.
293
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%
294
This test farm included 2,000 SharePoint Server sites. Each site contained one small, one large, and one very large workbook. The
distribution of the workbooks on the SharePoint Server pages was 10% small workbooks and 90% large and very large workbooks.
Additionally, the test farm dataset included SharePoint Server pages that contained 1-5 Excel Web Parts.
Workload
To simulate application usage, workloads were created to perform one or more of the following operations:
Action Mix Small Workbook Large Workbook
View 50% 70%

Edit 35% 15%
Collaborative Viewing 10% 10%
Collaborative Editing 5% 5%
In addition, 17% of all the workbooks included external data. For large and very large workbooks that included external data, refreshes
were performed 80% of the time; small workbooks do not include external data.
Each workload includes think time between user actions of 10 seconds. Think time refers to user action delays that simulate how long a
user might take to perform the actions. This differs from other SharePoint Server 2010 capacity planning documents. Servicios de Excel is
stateful the workbook is maintained in memory between user interactions making it important to simulate a full user session and not
merely individual requests. On average, there are 0.2 requests per second for a single user workload.
We randomly selected one of the 2,000 sites to run the test for each workload. We used the percentages in the following table to select
application and application size, within that site.
Workbook Selection Use Percentage
Small Workbook 30%

Large Workbook 55%
295
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.
296
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.
297
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
298
299
Recommended Results
The following chart shows our results for recommended sustainable throughput.
300
The previous chart shows that there is overhead associated with adding Web front-end computers to the farm. However, this is offset as
Excel Calculation Services computers are added. A single Web front-end became the bottleneck after adding two additional Excel
Calculation Services computers. This Web front-end bottleneck reversed any benefit that was gained from the additional capacity of
adding a second and third Excel Calculation Services computer. Also notice that three Web front-end computers did not add any more
throughput, as Excel Calculation Services became the limiting factor.
301
302
Notice in the previous chart that as Web front-end computers are added, the CPU load on each computer is reduced significantly. Note
too, that with two Web front-end computers and three Excel Calculation Services computers, the CPU load is reaching the maximum seen
for a single Web front-end computer. This implies that adding another Excel Calculation Services computer would make the Web front-end
tier the limiting factor. Remember that these results are for the recommended load. This is why the CPU load is maxing out at around
35% instead of at an increased level.
Maximum Results
The following chart shows our results for maximum peak throughput.
303
304
Similar to our recommended results, we see that a single Web front-end computer is the limiting factor as we add a second and third Excel
Calculation Services computer. Also notice that exactly as with the recommended results, adding a third Web front-end computer does not
add to throughput as Excel Calculation Services is the limiting factor after the second Web front-end computer is added.
305
306
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- 33.73 37.64 33.84 14.61 23.95 36.90 7.54 13.12 21.75
end computers
Excel 1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3
Calculation
Services Tier
% CPU 30.56 34.55 31.67 26.03 45.94 68.37 20.71 38.82 63.70
(average over
all Excel
307
Excel 1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3
Calculation
Services Tier
Calculation
Services
computers)
Peak Private 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
Bytes
(maximum over
all Excel
Calculation
Services
computers)
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- 41.08 67.78 58.59 19.44 34.11 45.97 10.19 17.79 28.69
end computers
308
Excel 1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3
Calculation
Services Tier
% CPU 24.99 1844 10.96 23.57 20.56 17.77 18.97 17.04 18.10
(average over
all Excel
Calculation
Services
computers)
Peak Private 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
Bytes
(maximum
over all Excel
Calculation
Services
computers)
Scale Up Test results

We also measured the effect of adding CPUs and memory to the Excel Calculation Services tier. For these tests, a 1x1 topology was
used.
309
Our results in the previous chart show that adding additional CPUs was helpful but did not significantly affect the overall throughput.
310
311
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 users session.
312
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 > Aplicacin 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 > Aplicacin de
Servicios de Excel > Trusted Locations, and then edit the settings for each trusted location in the Workbook Properties section on the Edit
Trusted File Location page.
Maximum Workbook Size
Maximum Chart or Image Size
By default, Excel Calculation Services is limited to 10 MB or smaller workbooks and 1 MB or smaller charts/images. Obviously using larger
workbooks and larger charts/images puts more strain on the available memory of the Excel Calculation Services tier computers. However,
there may be users in your organization that need these settings to be increased for Excel Calculation Services to work with their
particular workbooks.
Session Timeout By decreasing the session time out, memory is made available for either the unused object cache or other
services faster.
313
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 Scale Up with more
throughout the user's session. A large number of memory in the Excel
workbooks, or large workbooks, can cause Excel Calculation Services tier
Calculation Services to consume all available memory computers, or Scale Out
causing the actually consumed "Private Bytes" to with the addition of more
exceed "Maximum Private Bytes." 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 Increase the number of
processing in the application tier, depending on the CPUs and/or cores in the
number and complexity of workbooks. existing Excel Calculation
Services computers, or
add Excel Calculation
314
Services computers.
Web server CPU usage When a Web server is overloaded with user requests, This issue can be resolved
average CPU usage will approach 100 percent. This in one of two ways. You
prevents the Web server from responding to requests can add Web servers to
quickly and can cause timeouts and error messages the farm to distribute user
on client computers. 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

% Processor Time Processor (_Total) Shows the percentage of
elapsed time that all
threads on the server
computer that used the
processor to execute
315
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.
316
Average Disk Queue Length PhysicalDisk(_Total) Watch for too much disk
writing because of logging.
Private Bytes Process(w3wp) Servicios de Excel caches
workbooks in memory,
until the user's session
expires (the time out for
which is configurable). If a
large amount of data is
being processed through
the Excel Calculation
Services, memory
consumption for the Excel
Calculation Services w3wp
will increase.
SQL Server
As we have previously described, Servicios de Excel is light on the SQL Server tier, as workbooks are read once into memory on the
Excel Calculation Services tier during the user's session. Follow general SharePoint Server guidelines for monitoring and troubleshooting
of the SQL Server tier.
317
Estimacin de los requisitos de rendimiento y capacidad de
PerformancePoint Services
En este artculo se describe el efecto que tiene PerformancePoint Services en las topologas que ejecutan Microsoft SharePoint Server
2010.
Nota:
Es importante tener en cuenta que las cifras de capacidad y rendimiento especficas presentadas en este artculo sern diferentes de las
cifras en entornos reales. Las cifras que se presentan estn diseadas para proporcionar un punto de partida para el diseo de un
entorno a una escala adecuada. Despus de completar el diseo inicial del sistema, pruebe la configuracin para determinar si el sistema
admitir los factores del entorno.
En este artculo:
Prueba de las caractersticas del conjunto o granja de servidores
Recomendaciones
Si desea obtener informacin general sobre el modo de planear y ejecutar la capacidad para SharePoint Server 2010, vea Capacity
management and sizing for SharePoint Server 2010 (en ingls).
Prueba de las caractersticas 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
contena un solo panel de tamao mediano. El panel contena dos filtros vinculados a un cuadro de mandos, dos grficos y una
318
cuadrcula. 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 tamao de cada elemento del panel.
Nombre Descripcin Tamao
Filtro uno Filtro de seleccin de miembros 7 miembros de dimensin

Filtro dos Filtro de seleccin de miembros 20 miembros de dimensin
Cuadro de mandos Cuadro de mandos 15 filas de miembros de
dimensin por 4 columnas
(2 KPI)
Grfico uno Grfico de lneas 3 series por 12 columnas
Grfico dos Grfico de barras apiladas 37 series por 3 columnas
Cuadrcula Cuadrcula analtica 5 filas por 3 columnas
En el panel mediano se us la plantilla de encabezado y dos columnas y los tamaos de los elementos del panel se establecieron en
tamao automtico o en un porcentaje especfico del panel. Cada elemento del panel se represent con un alto y ancho aleatorios de
entre 400 y 500 pxeles para simular las diferencias existentes entre los tamaos de ventana del explorador web. Es importante cambiar
el alto y el ancho de cada elemento del panel debido a que los grficos se representan en funcin de los tamaos de ventana del
explorador web.
Escenarios de prueba y procesos

En esta seccin se definen los escenarios de prueba y se describe el proceso de prueba que se us para cada escenario. En la seccin
"Resultados de las pruebas", ms adelante en este artculo, se proporciona informacin detallada, como los resultados de las pruebas y
parmetros especficos.
319
Nombre de la prueba Descripcin de la prueba
Represente un panel y cambie uno de los dos filtros cinco veces de 1. Represente el panel.
forma aleatoria con una pausa de 15 segundos entre las 2. Seleccione uno de los dos filtros. A continuacin, seleccione de
interacciones. 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 grfico y expndalo y 1. Represente el panel.

contrigalo cinco veces con una pausa de 15 segundos entre las 2. Seleccione un miembro aleatorio en un grfico y expndalo.
interacciones.
3. Seleccione otro miembro aleatorio en el grfico y contrigalo.
4. Seleccione otro miembro aleatorio en el grfico y expndalo.
5. Seleccione otro miembro aleatorio en el grfico y contrigalo.
Represente un panel, seleccione una cuadrcula y expndala y 1. Represente el panel. Seleccione un miembro aleatorio en una
contrigala cinco veces con una pausa de 15 segundos entre las cuadrcula y expndalo.
interacciones. 2. Seleccione otro miembro aleatorio de la cuadrcula y expndalo.
3. Seleccione otro miembro aleatorio en la cuadrcula y
contrigalo.
4. Seleccione otro miembro aleatorio de la cuadrcula y expndalo.
Se us una combinacin de pruebas nica que consisti en los siguientes porcentajes de las pruebas iniciadas.
320
Nombre de la prueba Combinacin de pruebas
Represente un panel y cambie de forma aleatoria uno de los dos 80%

filtros cinco veces.
Represente un panel, seleccione un grfico y expndalo y 10%
contrigalo cinco veces.
Represente un panel, seleccione una cuadrcula y expndala y 10%
contrigala cinco veces.
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 navegacin por las cuadrculas y los grficos por parte de los usuarios. Las pruebas
usadas en este artculo contenan una distribucin normal de pausas de 15 segundos entre las interacciones, tambin denominadas
"tiempos de reflexin", y un tiempo de reflexin 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 perodo de 15 minutos despus de un tiempo de preparacin inicial de 10 minutos.
Cada nueva iteracin de prueba selecciona una cuenta de usuario distinta de un grupo de cinco mil cuentas y una direccin IP aleatoria
(mediante el uso de conmutacin de IP de Visual Studio) de un grupo de aproximadamente 2.200 direcciones.
La combinacin de pruebas se ejecut dos veces respecto del mismo panel de tamao mediano. En la primera ejecucin, la
autenticacin del origen de datos se configur para usar la cuenta de servicio desatendida, que usa una cuenta comn para solicitar los
datos. Los resultados de datos son idnticos para varios usuarios y PerformancePoint Services puede usar almacenamiento en cach
para mejorar el rendimiento. En la segunda ejecucin, la autenticacin 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 dinmica. En esta configuracin, PerformancePoint Services
usa la identidad del usuario para solicitar los datos. Debido a que los resultados de datos podran 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 dinmica de Analysis Services y los roles de Analysis Services asignados a los usuarios y grupos de
Microsoft Windows son idnticos.
321
Configuracin de hardware y topologa
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 instalacin empresarial
predeterminada de SharePoint Server 2010.
En la tabla siguiente se enumera el hardware especfico usado para realizar las pruebas.
Servidor web Servidor de Equipo que ejecuta Equipo que ejecuta

aplicaciones SQL Server 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 Windows Windows
Server 2008 R2 Server 2008 R2 Server 2008 R2
Enterprise Enterprise Enterprise
NIC 1x1 gigabit 1x1 gigabit 1x1 gigabit 1x1 gigabit
Autenticacin NTLM y Kerberos NTLM y Kerberos NTLM y Kerberos NTLM y Kerberos
Despus 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 direccin de origen. La afinidad
de direccin de origen registra la direccin IP de origen de las solicitudes entrantes y el host de servicios en el que se equilibr la carga, y
canaliza todas las transacciones futuras al mismo host.
322
Topologa
La topologa inicial consisti en dos servidores fsicos. Uno se us como servidor web y de aplicaciones y el otro como servidor de bases
de datos. Esta topologa inicial se considera una topologa de dos mquinas (2M) o una topologa "1 por 0 por 1", en que el nmero de
servidores web dedicados aparece al comienzo de la lista, seguido de los servidores de aplicaciones dedicados y, a continuacin, los
servidores de bases de datos.
Los servidores web tambin se denominan front-end web (WFE) ms 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 lmite. Los factores restrictivos y las topologas difirieron considerablemente en funcin de la
configuracin de la autenticacin del origen de datos de cuenta de servicio desatendida o identidad de usuario con seguridad de cubo
dinmico.

Los resultados de las pruebas contienen tres medidas importantes que ayudan a definir la capacidad de PerformancePoint Services.
Medida Descripcin
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 esttico, como imgenes y hojas
de estilos.
Vistas por segundo (VPS) Total de vistas que puede representar PerformancePoint Services. Una vista es
cualquier filtro, cuadro de mandos, cuadrcula o grfico representado por
PerformancePoint Services o cualquier solicitud web a la direccin URL del
servicio de representacin que contiene RenderWebPartContent o
CreateReportHtml. Para obtener ms informacin acerca de
CreateReportHtml y RenderWebPartContent, vea el tema sobre la
especificacin del protocolo RenderingService de PerformancePoint Services
Los registros IIS de estas solicitudes pueden analizarse para ayudar a planear
323
Medida Descripcin
la capacidad de PerformancePoint Services. Adems, el uso de esta medida
proporciona un nmero que es mucho menos dependiente de la composicin
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 autenticacin de cuenta de servicio desatendida, la regla para la
proporcin 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 autenticacin de usuario, la regla para la proporcin de servidores
dedicados es un servidor web por cada cuatro o ms servidores de aplicaciones que ejecutan PerformancePoint Services.
En las topologas de ms 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 ms all del umbral deseado de
dos segundos.
En las tablas siguientes se muestra un resumen de los resultados de las pruebas para autenticacin de cuenta de servicio desatendida y
autenticacin de usuario al incrementar la escalabilidad horizontal de dos a siete servidores. Ms adelante en este documento se
incluyen resultados detallados con contadores de rendimiento adicionales.
324
Resumen de autenticacin de cuenta de servicio desatendida
Topologa (WFE x APP x SQL) Usuarios Solicitudes por Vistas por

segundo (RPS) 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 autenticacin de usuario
Topologa (WFE x APP x SQL) Usuarios Solicitudes por Vistas por

segundo (RPS) segundo
(VPS)
2M (1x0x1) 200 47 27
3M (1x1x1) 240 56 33
4M (1x2x1) 300 67 40
5M (1x3x1) 325 74 44
325
Topologas 2M y 3M
Para ayudar a explicar el costo de hardware por transaccin 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 mxima de usuarios para las topologas 2M y 3M.
Autenticacin 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
326
Autenticacin de usuario
327
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
328
Resultados de granja de servidores 3M (1x1x1)
Autenticacin de la cuenta de servicio desatendida
329
RPS 36 87 124 127

Vistas por segundo 21 52 74 75
Promedio de CPU de WFE 11% 28% 43% 46%
Nmero mximo de bytes privados de WFE del 0,7 GB 1,4 GB 2,0 2,4
proceso de trabajo de Internet Information GB GB
Services (IIS) W3WP de SharePoint Server.
Promedio de CPU de APP 25% 62% 94% 95%
Mximo de bytes privados de APP de W3WP de 5,9 GB 10,8 GB 14,1 14,6
PerformancePoint Services GB GB
330
Autenticacin por usuario
331
RPS 17 39 52 56
Mximo de bytes privados de WFE de W3WP de 0,78 GB 1,3 GB 1,6 1,9
SharePoint Server GB GB
Mximo de bytes privados de APP de W3WP de 19 GB 20,1 GB 20,5 20,9
PerformancePoint Services GB GB
332
333
Resultados para topologas de 4 o ms mquinas para autenticacin de
cuenta de servicio desatendida
Comenzando con una topologa de cuatro mquinas, se aplic carga para producir un tiempo de respuesta promedio de dos segundos
para representar un cuadro de mandos o un informe. A continuacin, se agreg un servidor adicional para resolver el factor restrictivo
(siempre CPU en el servidor web o el servidor de aplicaciones) y, a continuacin, se volvi a ejecutar la combinacin de pruebas. Esta
lgica se repiti hasta que se alcanz un total de siete servidores.
4M (1x2x1) 5M (1x3x1) 6M 7M
(2x3x1) (2x4x1)
Recuento de usuarios 840 950 1.250 1.500

RPS 196 216 292 346
Mximo de bytes privados de WFE de W3WP 2,1 GB 1,7 GB 2,1 GB 2,0 GB
de SharePoint Server
Mximo de bytes privados de APP de W3WP de 16 GB 12 GB 15 GB 15 GB
334
Resultados para topologas de 4 o ms mquinas para autenticacin de
usuario
Se repitieron las mismas pruebas para un origen de datos configurado para autenticacin de usuario. Tenga en cuenta que al agregar un
servidor de aplicaciones para crear una topologa de cuatro servidores de aplicaciones no se aument el nmero de usuarios ni las
solicitudes por segundo que admita PerformancePoint Services debido a los retrasos en las consultas que produjo Analysis Services.
3M (1x1x1) 4M (1x2x1) 5M 6M
(1x3x1) (1x4x1)

RPS 56 67 74 74
Mximo de bytes privados de WFE de W3WP 2,1 GB 1,9 GB 1,9 GB 1,5 GB
de SharePoint Server
Mximo de bytes privados de APP de W3WP de 20 GB 20 GB 20 GB 20 GB
CPU de Analysis Services 17% 44% 57% 68%
335
336
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
instalacin 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 orgenes de datos se
configuran para autenticacin 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 mximo de uso de CPU del 31% bajo el panel
con autenticacin 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 duracin 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 autenticacin 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 autenticacin de usuario y seguridad de cubo
dinmico de Analysis Services, los resultados de las consultas se almacenan una vez por cada usuario por cada vista (es decir, una
combinacin "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 funcin de los lmites de la memoria para evitar
errores de falta de espacio en memoria. El lmite de memoria predeterminado es del 60 por ciento de la memoria fsica. Despus de
alcanzar este lmite, PerformancePoint Services continu representando vistas pero los tiempos de respuesta aumentaron
considerablemente durante el breve perodo en que ASP.NET quit las entradas almacenadas en la memoria cach.
337
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 presin de memoria.
Si este contador es mayor que cero, revise la siguiente tabla para ver posibles soluciones.
Problema Solucin
El uso del procesador del servidor de aplicaciones es reducido y hay Agregue ms memoria fsica o limite la memoria cach de
otros servicios que se estn ejecutando en el servidor de ASP.NET.
aplicaciones.
El uso del procesador del servidor de aplicaciones es reducido y Si es aceptable, configure las opciones de memoria cach de
solo se est ejecutando PerformancePoint Services en el servidor ASP.NET para que la memoria cach use o agregue ms memoria.
de aplicaciones.
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 autenticacin 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 idnticos y si no se ha
configurado la seguridad de cubo dinmico. Se trata de una nueva caracterstica 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 compartirn las entradas de cach. Si no hay seguridad de cubo dinmico, los usuarios A y B, as como el usuario C, no
compartirn las entradas de la memoria cach.
Analysis Services
Durante la prueba de PerformancePoint Services con autenticacin de usuario, se cambiaron dos propiedades de Analysis Services para
mejorar el rendimiento multiusuarios. En la siguiente tabla se muestran las propiedades que se cambiaron y el nuevo valor de cada
propiedad.
338
Propiedad Analysis Services Valor
Memory \ HeapTypeForObjects 0
Memory \ MemoryHeapType 2
Estas dos opciones de memoria configuran Analysis Services para usar el montn de Windows en lugar del montn 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 ms de 30 segundos mientras que la CPU de los servidores web, de aplicaciones y de Analysis
Services se mantena baja. Para solucionar el problema, se recopil el tiempo de consulta usando vistas de administracin dinmica
(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 modificacin de la configuracin de memoria anterior.
Es importante tener en cuenta que aunque esto mejor notablemente la capacidad de proceso, segn el equipo de Analysis Services, la
modificacin de esta configuracin tiene un costo pequeo pero perceptible en las consultas de usuario nico.
Antes de cambiar cualquier propiedad de Analysis Services, vea el tema sobre la gua 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 cmo 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 situacin en la que se
alcanza la capacidad mxima de un componente determinado de una granja de servidores. Esto produce un estancamiento o una
disminucin en el rendimiento la granja de servidores. En los casos en que el intenso uso del procesador produca 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 ningn cuello de botella.
Posible cuello de botella Causa y qu supervisar Resolucin
Rendimiento del montn De manera predeterminada, Cambie Analysis Services para usar el montn de Windows. Vea la seccin
de memoria de Analysis Analysis Services usa su "Analysis Services", anteriormente en este artculo, y el tema sobre la gua de
Services propio montn de memoria rendimiento de Analysis Services de las notas del producto de SQL Server
339
en lugar del montn de 2008 (http://go.microsoft.com/fwlink/?linkid=165486&clcid=0xC0A) para obtener
Windows, que proporciona instrucciones.
un rendimiento multiusuario
deficiente. Revise los
tiempos de consulta de
Analysis Services mediante
las vistas de administracin
dinmica (DMV) para ver si
los tiempos de consulta
aumentan con la carga de
usuarios y el uso del
procesador de Analysis
Services es reducido.
Subprocesos de consulta y De manera predeterminada, Aumente el nmero de subprocesos disponibles para consultas y procesos.
procesamiento de Analysis Analysis Services limita el Vea la seccin "Analysis Services" y el tema sobre la gua de rendimiento de
Services nmero de subprocesos de Analysis Services de las notas del producto de SQL Server 2008
consulta y procesamiento (http://go.microsoft.com/fwlink/?linkid=165486&clcid=0xC0A) para obtener
de las consultas. Las instrucciones.
consultas de larga ejecucin
y las cargas de usuarios
elevadas podran usar todos
los subprocesos
disponibles. Supervise los
subprocesos inactivos y los
contadores de rendimiento
de la cola de trabajos en la
categora 2008:Threads
MSAS.
Memoria del servidor de PerformancePoint Services Agregue memoria o aumente los lmites predeterminados de la memoria cach
aplicaciones almacena en cach los de ASP.NET. Vea la seccin Consumo de memoria, anteriormente en este
340
resultados de la consulta de documento, para obtener ms informacin. Vea tambin el tema sobre la
Analysis Services y de otros configuracin de elementos de la memoria cach de ASP.NET
orgenes de datos por la (http://go.microsoft.com/fwlink/?linkid=200610&clcid=0xC0A) y la entrada de
duracin de la memoria blog de Thomas Marquardt acerca de los antecedentes de los lmites de la
cach de origen de datos. memoria cach de ASP.NET
Estos elementos pueden (http://go.microsoft.com/fwlink/?linkid=200611&clcid=0xC0A).
consumir una gran cantidad
de memoria. Supervise el
contador de rendimiento
Aplicaciones de
ASP.NET\Recortes API de
cach del grupo de
aplicaciones de
para determinar si las
eliminaciones o recortes de
la memoria cach son
forzados por ASP.NET
debido a la falta de
memoria.
Configuracin de limitacin PerformancePoint Services Si es necesario, cambie el comportamiento de limitacin de peticiones de
de peticiones de WCF se implementa como un Windows Communication Foundation (WCF). Vea el tema sobre
servicio WCF. WCF limita el comportamientos de limitacin de peticiones de WCF
nmero mximo de (http://go.microsoft.com/fwlink/?linkid=200612&clcid=0xC0A) y la entrada de
llamadas simultneas como blog de Wenlong Dong sobre la limitacin de peticiones de WCF y la
un comportamiento de escalabilidad de los servidores
limitacin de peticiones de (http://go.microsoft.com/fwlink/?linkid=200613&clcid=0xC0A).
servicio. Aunque las
consultas de larga ejecucin
podran contribuir a este
cuello de botella, es poco
341
comn que se produzca.
Supervise las llamadas del
contador de rendimiento de
WCF/Modelo de servicio
pendientes para
y comprelas con el nmero
mximo actual de llamadas
simultneas.
Supervisin del rendimiento

Para ayudarle a determinar cundo 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. Adems, puede usar la informacin 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 Grupo de Si el valor es mayor que cero, revise la seccin "Consumo de memoria".
API de cach aplicaciones de
PerformancePoint
Services
MSAS 2008:Threads/Subprocesos No disponible Si el valor es cero, revise la seccin "Analysis Services" y el tema sobre la
inactivos de grupo de consultas gua 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 seccin "Analysis Services" y el
342
Contador de rendimiento Instancia de contador Notas
cola de trabajos de grupo de tema sobre la gua de rendimiento de Analysis Services de las notas del
consultas producto de SQL Server 2008
MSAS 2008:Threads/Subprocesos No disponible Si el valor es mayor que cero, revise la seccin "Analysis Services" y el
inactivos de grupo de procesamiento tema sobre la gua de rendimiento de Analysis Services de las notas del
producto de SQL Server 2008
MSAS 2008:Threads/Longitud de No disponible Si el valor es mayor que cero, revise la seccin "Analysis Services" y el
cola de trabajos de grupo de tema sobre la gua de rendimiento de Analysis Services de las notas del
procesamiento producto de SQL Server 2008
WCF CountersServiceModelService Instancia de servicio Si el valor es mayor que cero, vea el tema sobre la limitacin de peticiones
3.0.0.0(*)\Llamadas pendientes de PerformancePoint de WCF y escalabilidad de servidores
Vea tambin
Otros recursos
Plan for PerformancePoint Services (SharePoint Server 2010)
343
Capacity requirements for Web Analytics Shared Service in
SharePoint Server 2010 (en ingls)
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:
Capacity management and sizing for SharePoint Server 2010 (en ingls)
In this article:
Introduction
Hardware specifications and topology
Capacity requirements
344
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 services capacity requirements are minimal at this level.
This article contains the capacity requirements for several application servers and Microsoft SQL Server based computers, according to
the following criteria:
Total expected site traffic (clicks, search queries, ratings).
Number of SharePoint components (Site, Site Collection, and Web Application) for each farm.
Other less significant factors which can affect the capacity requirements are summarized in Other factors later in this article.
Architectural overview
The following diagram (Figure 1) shows the flow of the site usage data from a Web browser to the analytics databases, and then back to
the Web browser as reports. The usage data is logged to the usage files on the Web servers. The usage timer job calls the Logging Web
Service to submit the raw data from the usage files. The Logging Web Service writes it to the staging database, where the raw data is
stored for seven days (this is not configurable). The Web Analytics components Log Batcher and User Behavior Analyzer clean and
process the raw data on the staging database. The Report Consolidator runs one time every 24 hours. The Report Consolidator
aggregates the raw data from the staging database on various dimensions, and then writes it to the reporting database. The aggregated
data is stored in the reporting database for a default period of 25 months (this is configurable).
345
Figure 1. SharePoint Server 2010 Web Analytics architectural overview
346
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 Administracin 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 services 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
347
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.
348
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.
349
Figure 2. Web Analytics topology
350
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.
351
Dataset description
The dataset that was selected for the test environment is a mid-sized dataset that has approximately 30,000 SharePoint components,
which includes all web applications, site collections, and sites. Other characteristics of the data that were kept constant in the environment
are also listed in the following table.
Dataset characteristics Value
Number of SharePoint components 30,000

Number of unique users 117,000
Number of unique queries 68,000
Number of unique assets 500,000
Data size in the reporting database 200 GB
The total site traffic, measured by number of clicks, search queries, and ratings, was increased as part of this case study to establish the
number of records that can be supported by the corresponding topology.
Importante:
Some typically used topologies generally exceed the capacity planning guidance. Those topologies include the following:
Team sites
My Site Web sites
Self-provisioning portals
If you anticipate that you might exceed the capacity planning guidelines, we recommend that you turn off the Web Analytics service
application. For more information about how to turn off a service application, see Starting or stopping a service.
352
Application servers
The following diagram (Figure 3) shows the daily site traffic that can be supported by one, two, or three application servers. The site traffic
is represented in millions of records (each click, search query, or rating makes up a record) each day. The yellow line represents the
expected number of records for the corresponding topology, whereas the green line represents the safe assumption for the number of
records.
353
Figure 3. Daily site traffic vs. the application servers topology
354
The application servers are not very CPU-intensive or memory intensive. Thus, the CPU and the memory usage are not summarized for
this section.
SQL Server based computers
The following diagram (Figure 4) shows the daily site traffic that can be supported that corresponds to the following configurations:
One instance of SQL Server for both staging and reporting databases (1S+R).
Two instances of SQL Server, one staging database and one reporting database (1S1R).
Three instances of SQL Server, two staging databases and one reporting database (2S1R).
The site traffic is represented in millions of records (each click, search, or rating makes up a record) each day. The yellow line represents
the expected number of records for the corresponding topology, whereas the green line represents the safe assumption for the number of
records.
355
Figure 4. Daily site traffic vs. SQL Server topology
356
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 19 192 5.78 100 13.4
for 8 processor computer
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 Administracin del rendimiento y de la capacidad (SharePoint Server 2010).
357
Remaining issues
There are current known issues that significantly affect the current performance of the Web Analytics service application for deployments
that have a large site hierarchy, which includes approximately 100,000 or more SharePoint components. This article might be updated
with the capacity requirements for larger site hierarchies when more information is available.
Vea tambin
Conceptos
Otros recursos
SharePoint 2010 Administration Toolkit (SharePoint Server 2010)
Estimacin de los requisitos de rendimiento y capacidad para la

administracin de contenido web en SharePoint Server 2010
En este artculo se proporciona una orientacin acerca de la administracin de la capacidad en los sitios de Microsoft SharePoint Server
2010 que tienen habilitada la infraestructura de publicacin. Este documento es especfico de SharePoint Server 2010 y la informacin
descrita no se aplica a SharePoint Foundation.
En este artculo se describen los siguientes escenarios:
Un sitio de publicacin en Internet: un sitio de presencia corporativa.
Este tipo de sitio se publica en Internet y permite que los usuarios annimos de Internet busquen informacin acerca de una
organizacin. Este tipo de sitio tiene personalizacin de marca y su contenido est estrictamente controlado.
Un sitio de publicacin en la intranet: un sitio de noticias internas.
Este tipo de sitio se publica en el mbito interno de una organizacin. Sirve principalmente para compartir informacin con los
usuarios autenticados de una organizacin. La informacin del sitio puede estar administrada estrictamente, aunque tambin es
posible que algunas reas se administren en menor grado.
358
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 pginas nuevas y las vinculan a otras pginas que podran ser ya existentes o no existir todava. Los sitios
wiki empresariales normalmente se publican en el mbito interno de una organizacin. Este sitio permite a las personas de una
compaa u organizacin obtener y compartir conocimientos mediante una solucin integrada y mejorada por su entorno de
SharePoint.
Tras leer este documento, comprender los siguientes conceptos:
El valor mtrico clave (rendimiento) que debe maximizar para admitir gran cantidad de operaciones de lectura.
Varios cuellos de botella posibles que son relevantes para una implementacin de SharePoint Server 2010 de administracin 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 artculo:
Mtodo y detalles de las pruebas
Implementaciones de administracin de contenido web
Optimizaciones necesarias
Resultados de las pruebas y recomendaciones
Acerca de los autores

Antes de leer este documento, asegrese de que comprende los conceptos clave relacionados con la administracin de la capacidad de
SharePoint Server 2010. La documentacin que se proporciona a continuacin le permitir conocer el mtodo recomendado para
administrar la capacidad y le ofrecer ms contexto para ayudarle a hacer un uso eficaz de la informacin de este documento.
Para obtener informacin ms conceptual sobre el rendimiento y la capacidad que puede servirle para comprender el contexto de los
datos de este artculo, vea los siguientes documentos:
Administracin de la capacidad y tamao de SharePoint Server 2010
359
Casos prcticos tcnicos de capacidad y rendimiento (SharePoint Server 2010)
Mtodo y detalles de las pruebas

En cada prueba, se extrajeron las variables que pueden existir en la vida real para mostrar recomendaciones especficas. 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 ms informacin acerca de los conceptos de la administracin de la
capacidad, vea Informacin general sobre administracin y ajuste de tamao de la capacidad de SharePoint Server 2010.
En este artculo se describe el rendimiento con las caractersticas de la coleccin de sitios, la infraestructura de publicacin de SharePoint
Server y el almacenamiento en la memoria cach de resultados. Estas caractersticas solo estn disponibles cuando la infraestructura de
publicacin de SharePoint Server est habilitada. De manera predeterminada, los portales de publicacin tienen esta caracterstica
habilitada.
Conjunto de datos
Las pruebas se realizaron con un conjunto de datos que comparte caractersticas comunes con implementaciones de administracin de
contenido web reales. Si bien la carga ha sido constante, se solicitaron distintas pginas. En la tabla siguiente se describe el conjunto de
datos que se us para estas pruebas.
Conjunto de datos
Objeto Sitio de publicacin
Tamao de las bases de datos de contenido 2,63 GB

Nmero de bases de datos de contenido 1
Nmero de colecciones de sitios 1
Nmero de aplicaciones web 1
Nmero de sitios 50
Nmero de pginas 20.000 pginas divididas en 20 carpetas con 1.000 pginas cada
una
360
Objeto Sitio de publicacin
Composicin de las pginas Pginas de artculo en HTML bsico, con referencias a dos
imgenes
Tamao de pgina 42 KB sin comprimir; 12 KB comprimida
Imgenes 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
configuracin predeterminada de comprimir los archivos de forma dinmica. Al habilitar la compresin dinmica, IIS comprime las pginas
hasta que el uso de CPU excede un umbral concreto. En ese momento, IIS deja de comprimir las pginas hasta que el uso disminuya y
ya no exceda el umbral. Las pruebas de este artculo se realizaron con la compresin siempre habilitada.
Este conjunto de datos de prueba solo us caractersticas de SharePoint Server 2010 predeterminadas incluidas con el producto. Su sitio
probablemente incluye personalizaciones adems de estas caractersticas bsicas. Por lo tanto, es importante que pruebe el rendimiento
de su propia solucin.
Hardware
La cantidad de servidores web en la granja de servidores vari por prueba, pero su hardware era idntico. 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 ncleos a 2,33 GHz

RAM 8 GB
Tamao de la unidad de SharePoint 300 GB
361
Servidor web
Velocidad del adaptador de red 1 gigabit

Autenticacin Bsica de Windows
Tipo de equilibrador de carga Equilibrio de carga de hardware
Versin de software SharePoint Server 2010 (versin preliminar)
Servicios que se ejecutan localmente Administracin central
Correo electrnico entrante de Microsoft SharePoint Foundation
Aplicacin 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 ncleos a 3,19 GHz

RAM 16 GB
Almacenamiento 15 discos de 300 GB a 15.000 RPM
Velocidad del adaptador de red 1 gigabit
Autenticacin NTLM
362
Servidor de bases de datos
Versin de software Microsoft SQL Server 2008
Glosario
En este documento encontrar algunos trminos especializados. Estos son algunos trminos 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
medicin comn de carga del servidor y de la granja de servidores.
Observe que las solicitudes difieren de las cargas de pgina; cada pgina contiene varios componentes, cada uno de los cuales crea
una o varias solicitudes cuando se carga la pgina. Por lo tanto, una carga de pgina crea varias solicitudes. Normalmente, los
eventos y las comprobaciones de autenticacin 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 administracin de contenido web

Existen dos modelos mediante los cuales se crea contenido en los sitios de publicacin de SharePoint que pueden influir en su eleccin
de una topologa de granja de servidores.
En el modelo de autor en contexto, se comparte una sola coleccin 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 da determinado. Normalmente, esta granja de servidores experimenta gran cantidad de lecturas y un nmero moderado de escrituras.
En el siguiente diagrama se muestra cmo funciona la creacin en contexto desde la perspectiva de una topologa.
363
En el modelo de distribucin de contenido, varias colecciones de sitios admiten la publicacin y creacin de contenido por separado y
de forma exclusiva. El contenido se crea y actualiza en el entorno de creacin y, a continuacin, se implementa en el entorno de
publicacin de forma programada para que puedan leerlo los visitantes. El entorno de publicacin principalmente atiende solicitudes de
lectura, excepto cuando el contenido se implementa desde el entorno de creacin. A diferencia del modelo de autor en contexto, la carga
del servidor empleada por la distribucin de contenido puede ajustarse a intervalos programados.
En el siguiente diagrama se muestra cmo funciona la distribucin de contenido desde la perspectiva de una topologa.
Estos modelos de creacin de contenido se excluyen mutuamente.

Si bien los sitios de publicacin en Internet y los sitios de publicacin en la intranet pueden usar tanto el modelo de autor en contexto
como el modelo de distribucin 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 relacin con las operaciones de lectura, ya que un mayor
porcentaje de usuarios puede editar las pginas. Las pginas wiki empresariales difieren de las pginas de artculo de publicacin y
presentan caractersticas de rendimiento diferentes.
Optimizaciones necesarias
En esta seccin se ofrece informacin para optimizar el entorno de administracin de contenido web. Para optimizar el entorno se debe
comprender cmo administrar el rendimiento, los cuellos de botella y el almacenamiento en cach.
En esta seccin:
El rendimiento es el valor mtrico clave
Cuellos de botella y su solucin
Ventajas del almacenamiento en cach
364
El rendimiento es el valor mtrico clave
El rendimiento y el tiempo de respuesta son los valores mtricos ms importantes que deben optimizarse al realizar la planeacin de la
capacidad para una implementacin de administracin 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 solucin
Un cuello de botella es aquel recurso del sistema que, cuando se agota, impide que la granja siga atendiendo otras solicitudes. En el
siguiente diagrama se muestran los elementos de una granja y los recursos que pueden convertirse en cuellos de botella y que, por lo
tanto, deben supervisarse.
365
366
Uso de CPU del servidor web
La CPU del servidor web debera ser el cuello de botella de una topologa bien ajustada, ya que es el componente ms fcil de escalar.
El equilibrador de carga redirige las solicitudes entre los servidores web y se asegura de que ningn servidor se use en un grado
considerablemente mayor que el resto.
Aunque otros usuarios pueden seguir visitando el sitio despus 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 limitarn las solicitudes y respondern con un error HTTP 503. En la siguiente ilustracin, el tiempo de
respuesta del servidor disminuye cuando se alcanza el umbral de solicitudes en espera debido a que solo se sirven los errores HTTP.
367
368
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
topologa de granja de servidores, la configuracin de la granja o el contenido de las pginas 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 situacin, 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 adicin de
servidores web a la granja de servidores no puede incrementar el rendimiento mximo 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 configuracin de cach insuficiente o pginas 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 comn es mejorar la eficacia mediante la disminucin de
las llamadas a la base de datos para los datos que se solicitan con frecuencia. Las solicitudes posteriores de una pgina 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 pgina solicitada en la memoria del servidor web. Para
obtener ms informacin 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).
369
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 ms informacin 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 vdeo, imagen, sonido y
otros archivos binarios grandes en el disco. Para obtener ms informacin acerca de la memoria cach BLOB, vea el tema sobre el
almacenamiento en memoria cach basada en disco de objetos binarios grandes
Cada una de estas memorias cach es importante para mantener un alto rendimiento. No obstante, el almacenamiento en la memoria
cach de resultados es el que causa un mayor efecto y se describe en detalle a lo largo de este artculo.
Resultados de las pruebas y recomendaciones

En esta seccin se describen las reas especficas donde se realizaron pruebas y se proporcionan las recomendaciones obtenidas como
resultado.
En esta seccin:
Efecto de la habilitacin de la memoria cach de resultados
Usuarios annimos y usuarios autenticados
Caractersticas 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 distribucin de contenido
Efecto de la instantnea de base de datos durante la exportacin de distribucin de contenido
Caractersticas del contenido
Efecto de la habilitacin de la memoria cach de resultados
La memoria cach de resultados es una caracterstica de gran valor que puede usarse para optimizar una solucin de SharePoint Server
2010 para gran cantidad de operaciones de lectura.
370
En estas pruebas, para determinar el mximo 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 topologas 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.
Proporcin de aciertos de la memoria cach de resultados
La proporcin de aciertos de la memoria cach de resultados es una medicin 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 estn almacenados en la
memoria cach.
Un error de cach se produce cuando se recibe una solicitud de datos de objeto que no estn 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 pgina puede producir un error de cach.
Pginas configuradas para no usar la memoria cach de resultados.
Pginas personalizadas, por ejemplo, pginas que contienen datos especficos del usuario actual.
Primera exploracin por clave de variante de cach de resultados.
Primera exploracin despus 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 mximo en
granjas de servidores que contienen de uno a cuatro servidores web y un servidor de bases de datos.
371
372
Nota:
El punto de datos para el mximo de RPS en una granja de servidores de 4x1 con una proporcin 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
lmite 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 topologas de granja
de servidores que contienen de uno a cuatro servidores web y un servidor de bases de datos.
Efectos de la proporcin de aciertos de la memoria cach de resultados en topologas de granja de
servidores diferentes
Proporcin Medida 1x1 2x1 4x1

de aciertos
de la
memoria
cach de
resultados
100%
Mximo de RPS 3.463 7.331 11.032

Uso de CPU de SQL Server 0% 0% 0%
95%
Mximo de RPS 2.137 3.945 5.937

Uso de CPU de SQL Server 5,93% 12,00% 21,80%
373
Proporcin Medida 1x1 2x1 4x1
de aciertos
de la
memoria
cach de
resultados
90%
Mximo de RPS 1.518 2.864 4.518

50%
Mximo de RPS 459 913 1.596

0%
Mximo de RPS 172 339 638

Conclusiones y recomendaciones sobre el efecto de la habilitacin de la memoria cach de resultados

Las proporciones de aciertos de la memoria cach de resultados ms altas provocan aumentos considerables del mximo de RPS. Por lo
tanto, se recomienda habilitar el almacenamiento en la memoria cach de resultados para optimizar la solucin de publicacin de
SharePoint Server 2010. Puede configurar la memoria cach de resultados en la pgina Configuracin de la memoria cach de
374
resultados de la coleccin de sitios. Para obtener ms informacin, vea el tema sobre la configuracin de la memoria cach de resultados
de la pgina para una coleccin 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 pgina en cach; es decir, un cierto porcentaje de pginas ya est almacenado en cach. La primera vez que un
usuario solicita una pgina que no est almacenada en cach, dicha pgina 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 proporcin de aciertos de la memoria cach del 0% simula el perodo de corta duracin durante el cual la memoria cach de
resultados habilitada se rellena despus 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 situacin
donde hay una proporcin de aciertos de la memoria cach del 0% en el perodo de corta duracin entre el reciclaje del grupo de
aplicaciones y la prxima solicitud y almacenamiento en cach de las pginas. La proporcin de aciertos de la memoria cach del 0%
tambin simula un entorno en el que el almacenamiento en la memoria cach de resultados no est habilitado.
Usuarios annimos y usuarios autenticados
En la prueba anterior se supone que todas las solicitudes en el sitio se realizan por parte de lectores annimos. Sin embargo, en su sitio,
es posible que algunos de los usuarios estn autenticados. Entre los ejemplos de escenarios de lectura autenticada se incluyen un sitio
de publicacin 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 annimos.
Perfiles de cach
Los perfiles de cach agregan configuracin que puede aplicarse a pginas, elementos de pgina, tipos de contenido y niveles de
escala en la implementacin de un sitio. Un perfil de cach define los siguientes tipos de comportamiento de cach:
El perodo de tiempo que los elementos deben permanecer en la memoria cach.
La directiva de recorte de seguridad.
La expiracin de la configuracin, como la duracin y los cambios.
Las variantes del contenido almacenado en cach, por ejemplo en funcin 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 annimos y para usuarios autenticados.
375
Para los usuarios annimos, se us el perfil de cach de resultados Internet pblico (totalmente annimo) y para los usuarios
autenticados se us el perfil de cach de resultados Extranet (sitio publicado).
En el siguiente grfico se muestran los efectos del rendimiento autenticado en el uso de CPU del servidor de bases de datos.
El modelo de autenticacin que se us es la autenticacin bsica de Windows. Si bien no se recomienda usar la autenticacin bsica de
Windows para sitios de Internet, se seleccion este mtodo de autenticacin para demostrar una sobrecarga mnima impuesta por la
autenticacin. El tamao de esta sobrecarga vara segn el mecanismo de autenticacin especfico. Al probar su implementacin,
asegrese de tener en cuenta el efecto del mecanismo de autenticacin. Para obtener ms informacin acerca de los mecanismos de
autenticacin admitidos por SharePoint Server 2010, vea Plan authentication methods (SharePoint Server 2010).
376
Conclusiones y recomendaciones sobre usuarios annimos y usuarios autenticados
Los usuarios autenticados experimentan RPS ms 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
mximo de RPS observado cuando se autentica a los usuarios es considerablemente menor que el de una granja de servidores de
acceso annimo.
Caractersticas de escalabilidad horizontal de las operaciones de lectura y escritura
Las pruebas se crearon para registrar las escrituras por hora. En este artculo, una escritura se define como la creacin y proteccin de
una nueva pgina de publicacin o la edicin y proteccin de una pgina de publicacin 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 proporcin 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 adems del rendimiento de lectura general para cada configuracin. Adems, se prob una configuracin
de solo lectura annima como lnea base, as como una configuracin con lectores autenticados mediante la autenticacin bsica 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 operacin de escritura.
En el siguiente grfico 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 prdida
de RPS cuando se incorporan escrituras.
377
378
El uso de CPU del servidor de bases de datos se increment a medida que aument la cantidad de servidores web. En el siguiente
grfico se muestra el patrn de crecimiento del uso de CPU de SQL Server en las diferentes configuraciones. Como se mencion en la
seccin Usuarios annimos y usuarios autenticados anteriormente en este artculo, la autenticacin afecta al uso de CPU del servidor de
bases de datos y esto se acenta an ms a medida que se agrega actividad de escritura (que tambin afecta al uso de CPU del servidor
de bases de datos).
379
380
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 annima, puede servir el incremento de la
escalabilidad horizontal a un mayor nmero de servidores web.
Es importante comprender que en una implementacin tpica 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 ms informacin acerca de cmo determinar
una zona verde para el uso de CPU tpico del servidor de bases de datos, vea Informacin general sobre administracin y ajuste de
tamao de la capacidad de SharePoint Server 2010.
Conclusiones y recomendaciones sobre las caractersticas de escalabilidad horizontal de las operaciones
de lectura y escritura
En los datos se muestra que el incremento de la escalabilidad horizontal del nmero 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 combinacin de
pruebas de escrituras autenticadas y lectura annima emple un aumento del 52% en el uso de CPU del servidor web en comparacin
con la combinacin de pruebas de lectura annima sin escrituras. Adems, las lecturas autenticadas agregan una gran carga de SQL
Server adicional, ya que cada carga implica comprobaciones de autenticacin adicionales, lo que requiere una ida y vuelta a SQL Server.
En el siguiente grfico se muestra el efecto del rendimiento en el uso de CPU del servidor de bases de datos.
381
382
Advertencias sobre la memoria cach de resultados
Si lo nico que debe tenerse en cuenta en la planeacin de la capacidad es maximizar las RPS, estas pruebas indicaran que la
proporcin 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 pginas, o en todas ellas, debido a requisitos de actualizacin de datos o
a restricciones de memoria.
Actualizacin 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 distribucin de contenido o (para autores autenticados) en un escenario de autor en produccin,
es posible que los autores deseen ver los cambios ms recientes inmediatamente despus de actualizar el contenido existente.
Generalmente, esto se facilita al establecer la propiedad Duracin en el perfil de cach, la cual especifica cunto tiempo una pgina
almacenada en cach persistir en la memoria cach de resultados antes de expirar. Cuando una pgina expira, se quita de la memoria
cach y una consulta posterior producir un error de cach que actualizar el contenido de la pgina.
Tambin se puede establecer la propiedad de perfil de cach Buscar cambios para que el servidor compare la hora en la que se
almacen una pgina en cach con la hora en que el contenido se modific por ltima vez en una coleccin de sitios. Una solicitud de
una pgina cuyas marcas de tiempo no coinciden ocasionar una invalidacin de cach en todas las pginas de la coleccin de sitios.
Dado que la propiedad Buscar cambios afecta a todas las pginas de una coleccin de sitios, se recomienda habilitar esta opcin
nicamente si se trata de una solucin de autor en contexto autenticada que no se actualiza frecuentemente y que es bsicamente
esttica. La combinacin de esta opcin con una larga duracin permite que todas las pginas se sirvan desde la memoria cach hasta
que se realice una actualizacin 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 pgina que todava no ha expirado, independientemente de si se
modific la pgina 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 seccin
Caractersticas 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 vaca ms seguido, lo que ocasiona una menor proporcin de aciertos de la
memoria cach de resultados.
En el siguiente grfico se muestra el efecto de la propiedad Buscar cambios en el rendimiento.
383
Se recomienda evitar la propiedad de perfil de cach de resultados Buscar cambios, excepto en casos especficos. 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 duracin, pero lo ms probable es que otros tipos de sitios observen una degradacin en RPS.
384
En funcin de sus requisitos, es posible que desee que el contenido sujeto a limitacin temporal se publique instantneamente o ms
rpido que lo permitido por la configuracin predeterminada. En este caso, debe disminuir la duracin 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 administracin 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 annimo y el almacenamiento en la memoria cach de
resultados habilitado.
En el siguiente grfico se muestra el efecto del volumen de lecturas en la CPU y en el tiempo de respuesta.
385
Conclusiones y recomendaciones sobre el efecto del volumen de lecturas en la CPU y en el tiempo de
respuesta
Como se describi en la seccin Cuellos de botella y su solucin, el tiempo de respuesta del servidor generalmente ser coherente hasta
que el servidor web reciba un volumen de solicitudes suficiente para usar completamente su CPU. Cuando la CPU del servidor web se
386
usa por completo, el tiempo de respuesta aumenta considerablemente. No obstante, la granja de servidores an podr administrar un
volumen de solicitudes adicional.
Efecto de las operaciones de escritura en el rendimiento
La proporcin de la creacin de operaciones de edicin se distribuye equitativamente en el transcurso de las pruebas. Los valores de
escrituras por hora se probaron hasta aproximadamente 500, ya que la creacin o edicin de ms de 500 pginas por hora se encuentra
fuera del intervalo en el que operaran la mayora de las implementaciones de SharePoint. En la prueba no se incluyeron los procesos
automatizados, como la distribucin de contenido, la cual se describe en la seccin Efecto de la distribucin de contenido. Es posible que
estas operaciones de creacin y edicin 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
considerara una operacin 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 bfer para las puntas de trfico, y se mantuvo este nivel de uso promedio durante el transcurso de toda la prueba. A
continuacin, 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 operacin comn, como se muestra
en el siguiente grfico, aunque la media se mantuvo dentro del intervalo de la operacin comn
387
388
Como se muestra en el grfico anterior, hay una reduccin de poca importancia en el rendimiento a medida que se agregan escrituras al
entorno. En el grfico 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 proporcin de aciertos de la memoria cach de
resultados. Por lo tanto, la relacin entre los puntos de datos no es necesariamente lineal.
La reduccin en porcentaje es ms pronunciada en las proporciones de aciertos de la memoria cach ms bajas, como se muestra en el
siguiente grfico. Las RPS de lectura generales dependen en gran parte de la proporcin de aciertos de la memoria cach,
independientemente de las escrituras.
389
390
En el siguiente grfico se muestra que el uso de CPU del servidor de bases de datos no se increment perceptiblemente al agregar
escrituras al sistema. Observe que la escala vertical es del 0% al 10% de la capacidad de CPU.
Se observ una carga de SQL Server adicional durante las operaciones de lectura, lo cual estaba previsto. No obstante, el mayor
aumento fue de un 2,06% adicional, lo que es insignificante. El uso de CPU del servidor de bases de datos promedio se mantuvo por
391
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 ms detalle en
Caractersticas de escalabilidad horizontal de las operaciones de lectura y escritura.
Durante las pruebas, tambin se midi el uso de CPU del servidor web. En el siguiente grfico 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.
392
393
No obstante, el uso de CPU medido real genera puntas cuando se llevan a cabo las escrituras, como se muestra en el siguiente grfico.
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. Adems, 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 estn previstas en un entorno real, ya que la actividad de escritura no se distribuye uniformemente, aunque generalmente se lleva
a cabo en rfagas.
394
395
Una proporcin de aciertos de la memoria cach del 90% es muy baja para una implementacin tpica. La mayora de las
implementaciones de SharePoint Server 2010 con gran cantidad de operaciones de lectura tendrn una proporcin 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 supondrn 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
configuracin tpica 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 distribucin de contenido
Una alternativa al modelo de autor en contexto, que usa un entorno nico para la edicin y la lectura, consiste en dividir el entorno nico
en dos entornos independientes (un entorno de creacin y uno de produccin) y en usar la distribucin de contenido para copiar
contenido del entorno de creacin al entorno de produccin.
En esta configuracin, en el entorno de produccin puede haber poca actividad de escritura o ninguna actividad de escritura en absoluto,
excepto cuando la distribucin 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 distribucin de contenido export 10 sitios con 500
pginas cada uno desde la coleccin de sitios de creacin como un paquete e import dicho paquete a la coleccin de sitios de
publicacin. El tamao del paquete implementado es mayor que lo observado normalmente en entornos reales con el fin de extender
bastante la duracin del trabajo de distribucin de contenido para ver resultados de las pruebas. Para obtener informacin adicional
acerca de las caractersticas del contenido implementado, vea la seccin Conjunto de datos.
Una vez finalizada la exportacin, se import el contenido en una coleccin de sitios independiente y se midi el servidor de aplicaciones
y la carga de SQL Server, adems del rendimiento, mientras la importacin se encontraba en curso. La prueba de importacin se realiz
en varias proporciones de aciertos de la memoria cach de resultados diferentes.
La observacin clave es que la importacin solo tiene un efecto menor en las RPS de lectura generales, como se muestra en el siguiente
grfico. Tambin se observ que la importacin no tuvo un efecto importante en el uso de CPU del servidor web, como se muestra en las
siguientes tablas, independientemente de la proporcin de aciertos de la memoria cach. No obstante, el efecto fue ms evidente en la
CPU de SQL Server, como se muestra en el siguiente grfico. 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 importacin.
396
397
En las siguientes tablas se muestra el efecto de la importacin de distribucin de contenido en el uso de CPU del servidor de bases de
datos y del servidor web.
Efecto de la importacin de distribucin de contenido en el uso de CPU del servidor web
Acierto de cach 100% 99% 98% 95% 90% 50% 0%
Lnea base 72,32% 73,26% 71,28% 73,53% 71,79% 68,05% 63,97%

Con la importacin 70,93% 74,45% 69,56% 74,12% 70,95% 67,93% 63,94%
Efecto de la importacin de la distribucin de contenido en el uso de CPU del servidor de bases de datos
Acierto de cach 100% 99% 98% 95% 90% 50% 0%
Lnea base 1,19% 1,64% 2,01% 3,00% 3,73% 5,40% 6,82%

Con la importacin 6,03% 6,82% 6,97% 7,96% 8,52% 10,29% 10,56%
Conclusiones y recomendaciones sobre el efecto de la distribucin de contenido

En los resultados de las pruebas se muestra que llevar a cabo operaciones de distribucin 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 perodos de trfico bajo para minimizar el efecto de la operacin en el rendimiento general y que los
tiempos de implementacin pueden controlarse principalmente en funcin de las necesidades de negocio en lugar de los requisitos de
rendimiento.
Efecto de la instantnea de base de datos durante la exportacin de distribucin de contenido
En SharePoint Server 2010, la distribucin de contenido puede configurarse para crear una instantnea de la base de datos de contenido
de origen antes de exportar su contenido. Esto protege eficazmente el proceso de exportacin de cualquier actividad de creacin que
pueda llevarse a cabo durante la exportacin. No obstante, las instantneas pueden afectar al rendimiento de escritura del servidor de
bases de datos, ya que actan como multiplicadores de las escrituras. Por ejemplo, si tiene dos instantneas de una base de datos de
origen y, a continuacin, escribe en dicha base de datos, el servidor de bases de datos copia los datos existentes en cada instantnea y,
398
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 instantnea de base de datos.
Para determinar el efecto de una instantnea en el entorno de creacin, 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 operacin de exportacin
mientras tambin se llevaba a cabo una actividad de escritura. En las siguientes tablas se muestran los resultados.
Efecto de las instantneas de base de datos durante la distribucin de contenido
Valor mtrico 4 WPH - Sin instantneas 4 WPH - Con instantneas
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 instantneas de base de datos durante la distribucin de contenido
Valor mtrico 8 WPH - Sin instantneas 8 WPH - Con instantneas
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%
399
Conclusiones y recomendaciones sobre el efecto de la instantnea de base de datos durante la
exportacin de distribucin de contenido
En los resultados de las pruebas se muestra que no hubo un efecto importante en ningn punto de datos medido con las instantneas de
base de datos. Todas las varianzas registradas se encontraron dentro del margen de error. Esto confirma que las instantneas de base
de datos pueden usarse sin consideraciones de rendimiento importantes.
Caractersticas del contenido
Las pruebas se realizaron en un solo conjunto de datos creado para responder a un conjunto especfico de preguntas. Su conjunto de
datos diferir y cambiar a lo largo del tiempo. En esta seccin se investiga cmo las caractersticas del contenido, como el nmero de
pginas de la biblioteca de pginas y las caractersticas incluidas en las pginas, pueden ayudar a tomar decisiones bien fundadas sobre
la administracin de la capacidad.
Nmero de pginas
Se prob el mximo de RPS en varios tamaos de bibliotecas de pginas. Esta prueba se llev a cabo en una topologa de 4x1 con el
almacenamiento en la memoria cach de resultados deshabilitado y con acceso annimo. Todas las pginas 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 pginas de la biblioteca en las RPS
Nmero de pginas 3 1.000 20.000
Mximo de RPS 860 801 790
El aumento del nmero de pginas a 20.000 no supuso un efecto importante en el mximo de RPS.
Campos de bsqueda multivalor
Un campo de bsqueda 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 pgina 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 pginas. Por ejemplo, las pginas pueden archivarse en categoras cuando se crean (por ejemplo,
Noticias internacionales, Inters humano y Deportes en un sitio de noticias) y la pgina maestra incluye un marcador de posicin que
mostrar al usuario en qu categora se etiquet la pgina.
400
Los campos de bsqueda multivalor hacen que se capturen ms datos cada vez que se solicita una pgina. Por lo tanto, si hay muchos
campos de bsqueda multivalor en una pgina, el rendimiento puede verse afectado.
En el siguiente grfico se muestra el efecto de los campos de bsqueda multivalor en el rendimiento.
401
En el siguiente grfico se muestra el efecto de los campos de bsqueda multivalor en el uso de recursos de la granja de servidores.
402
403
La degradacin en el mximo de RPS tiene lugar a medida que aumenta la cantidad de campos de bsqueda 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 estadsticas sobre el uso de los sitios. Para obtener
ms informacin 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 mximo 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 Diferencia

deshabilitada
Cach de resultados habilitada 3.459 3.463 4

Cach de resultados deshabilitada 629 638 9
En los resultados se muestra que la habilitacin 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.
404
Estimate performance and capacity planning for workflow in
SharePoint Server 2010 (en ingls)
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 Administracin del rendimiento y de la capacidad
Contents
Test results
Recommendations
Troubleshooting

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:
405
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 1. Associate the included MOSS Approval workflow with a list that
created 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
406
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 2px4c@2.33GHz 4px4c@2.4GHz

RAM 4 GB 16 GB
Operating system Windows Server 2008 R2 x64 Windows Server 2008 R2
407
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
408
Workflow Capacity Planning Topology
409
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
410
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
411
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.
412
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
413
414
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.
415
Task completion throughput
416
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
417
Autostart throughput as number of items and workflows increases
418
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 Million item task list Empty task list
started per second)
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.
419
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>)
420
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.
421
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.
422
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.
423
Troubleshooting
Database contention (locks) Database locks prevent multiple To help reduce the incidence of database locks, you can do
users from making conflicting the following:
modifications to a set of data. When Distribute workflows to more document libraries.
a set of data is locked by a user or
process, no other user or process Scale up the database server.
can change that same set of data Tune the database server hard disk for read/write.
until the first user or process is Methods exist to circumvent the database locking system in
complete, changing the data and SQL Server 2005, such as the NOLOCK parameter. However,
relinquishing the lock. 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 Distributing data files across multiple physical drives allows
a hard disk exceeds the disk's I/O for parallel I/O. The blog SharePoint Disk Allocation and Disk
capacity, the requests will be queued. I/O (http://go.microsoft.com/fwlink/?LinkId=129557) contains
As a result, the time to complete useful information about resolving disk I/O issues.
each request increases.
Web server CPU utilization When a Web server is overloaded This issue can be resolved in one of two ways. You can add
with user requests, average CPU Web servers to the farm to distribute user load, or you can
utilization will approach 100 percent. scale up the Web server or servers by adding faster
This prevents the Web server from processors.
responding to requests quickly and
can cause timeouts and error
messages on client computers.
424
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

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
425
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
Memory utilization Total Shows the average
utilization of system
memory.
Vea tambin
Otros recursos
Workflow Scalability and Performance in Windows SharePoint Services 3.0 (http://go.microsoft.com/fwlink/?LinkId=207353)
426
Planeacin y configuracin del almacenamiento y capacidad de
SQL Server (SharePoint Server 2010)
En este artculo se describe cmo 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 informacin acerca de la planeacin de la capacidad que se incluye en este documento ofrece instrucciones para tener en cuenta
durante la tarea de planeacin. Esta informacin se basa en las pruebas realizadas en Microsoft con propiedades activas. No obstante,
los resultados que se obtengan pueden variar en funcin de los equipos que utilice y segn las caractersticas 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 artculo se asume que est familiarizado con los conceptos presentados en Capacity management and sizing for SharePoint
Proceso de diseo y configuracin del nivel de base de datos y

almacenamiento de productos de SharePoint 2010
Se recomienda dividir el proceso de diseo de nivel de base de datos y almacenamiento en los siguientes pasos. Cada seccin
proporciona informacin detallada sobre cada paso de diseo, incluidos los requisitos de almacenamiento y los procedimientos
recomendados:
Recopilacin de los requisitos de espacio y E/S para almacenamiento y SQL Server
Eleccin de la versin y edicin de SQL Server
Diseo de la arquitectura de almacenamiento en funcin de la capacidad y los requisitos de E/S
427
Estimacin de los requisitos de memoria
Descripcin de los requisitos de la topologa de red
Configuracin de SQL Server
Validacin y supervisin del almacenamiento y rendimiento de SQL Server
Recopilacin 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 diseo del almacenamiento. La cantidad de contenido,
caractersticas y aplicaciones de servicio que se usan, el nmero 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 seccin:
Bases de datos que se usan en productos de SharePoint 2010
Descripcin de SQL Server y las operaciones IOPS
Estimacin de las necesidades de almacenamiento y de operaciones IOPS de la aplicacin principal
Estimacin de las necesidades de almacenamiento de aplicaciones de servicio y operaciones IOPS
Determinacin 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 caractersticas 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 seccin se
proporciona un resumen de las bases de datos que se instalan con SharePoint Server 2010. Para obtener informacin ms detallada, vea
Database types and descriptions (SharePoint Server 2010) y el tema sobre el modelo de base de datos
Versin y edicin del producto Bases de datos
SharePoint Foundation 2010 Configuracin

428
Contenido de Administracin central
Contenido (uno o ms)
Recoleccin de datos de mantenimiento y uso
Conectividad a datos empresariales
Servicio de registro de aplicaciones (si se actualiza desde el
Catlogo de datos profesionales de Microsoft Office SharePoint
Server 2007)
Servicio de configuracin de suscripcin (si se habilita mediante
Windows PowerShell)
Bases de datos adicionales para SharePoint Server 2010 Standard Aplicacin de servicio de bsqueda:
Edition Administracin de bsqueda
Rastreo (uno o ms)
Propiedades (una o ms)
Aplicacin de servicio de perfiles de usuario:
Perfil
Sincronizacin
Etiquetas temticas
Aplicacin de servicio de Web Analytics
Almacenamiento provisional
Informes
Almacenamiento seguro
Estado
Metadados administrados
Servicios de automatizacin de Word
Bases de datos adicionales para SharePoint Server 2010 Enterprise PerformancePoint
429
Edition
Bases de datos adicionales para Project Server 2010 Borrador
Publicada
Archivar
Informes
Bases de datos adicionales para FAST Search Server Administracin de bsqueda
Si realiza una integracin ms 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, tambin debe planear la
compatibilidad con la base de datos de la aplicacin PowerPivot y la carga adicional en el sistema. Para obtener ms informacin,
vea el tema sobre el planeamiento de la implementacin 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.
Descripcin de SQL Server y las operaciones IOPS
En cualquier servidor que hospede SQL Server, es muy importante que el servidor logre la respuesta ms rpida posible del subsistema
de E/S.
Una mayor cantidad de matrices o discos ms rpidos 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 adicin 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 mnima antes de la
implementacin y supervise los sistemas existentes.
430
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 ms informacin, 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 ms informacin acerca de la forma de analizar los requisitos de las operaciones IOPS desde una perspectiva de SQL
Server, vea el tema sobre el anlisis de las caractersticas de E/S y determinacin del tamao 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).
Estimacin de las necesidades de almacenamiento y de operaciones IOPS de la aplicacin principal
La configuracin y el almacenamiento de contenido, as como las operaciones IOPS, constituyen la capa base que debe planear en toda
implementacin de SharePoint Server 2010.
Almacenamiento de configuracin y operaciones IOPS
No son muchos los requisitos de almacenamiento para la base de datos de configuracin y la base de datos de contenido de
Administracin central. Se recomienda asignar 2 GB para la base de datos de configuracin y 1 GB para la base de datos de contenido
de Administracin central. Con el tiempo, la base de datos de configuracin puede crecer ms de 1 GB, pero no lo hace
rpidamente, aumenta alrededor de 40 MB por cada 50.000 colecciones de sitios.
Los registros de transacciones de la base de datos de configuracin pueden ser grandes; por lo tanto, se recomienda cambiar el modelo
de recuperacin de la base de datos, de completa a simple.
Nota:
Si desea usar la creacin de reflejo de la base de datos de SQL Server para proporcionar disponibilidad para la base de datos de
configuracin, debe usar el modelo de recuperacin completa.
Son mnimos los requisitos de las operaciones IOPS para la base de datos de configuracin y la base de datos de contenido de
Administracin 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 precisin.
Las pruebas y las explicaciones de la siguiente informacin estn pensadas para ayudarle a calcular las estimaciones que luego usar
para determinar el tamao inicial de su implementacin. No obstante, cuando el entorno est en ejecucin, deber revisar las
necesidades de capacidad en funcin de los datos obtenidos en el entorno activo.
431
Para obtener ms informacin acerca de nuestra metodologa de planificacin de la capacidad total, vea Capacity management and
sizing for SharePoint Server 2010 (en ingls).
Estimacin del almacenamiento de bases de datos de contenido
El siguiente proceso describe cmo estimar aproximadamente el almacenamiento necesario para las bases de datos de contenido, sin
tener en cuenta los archivos de registro:
1. Calcule el nmero esperado de documentos. Este valor se denomina D en la frmula.
La forma de calcular el nmero de documentos estar determinada por las caractersticas que se usen. Por ejemplo, para sitios web
de Mi sitio o sitios de colaboracin, se recomienda calcular el nmero esperado de documentos por usuario y multiplicarlo por el
nmero de usuarios. Para la administracin de registros o sitios de publicacin de contenido, se puede calcular el nmero de
documentos administrados y generados por un proceso.
Si va a migrar desde un sistema actual, puede que sea ms fcil 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 estimacin en funcin de esa
tasa de uso.
2. Estime el tamao promedio de los documentos que va a almacenar. Este valor se denomina S en la frmula. Puede ser til estimar
los promedios de distintos tipos o grupos de sitios. El tamao 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 nmero de elementos de lista en el entorno. Este valor se denomina L en la frmula.
Es ms difcil estimar los elementos de lista que los documentos. Normalmente, se usa una estimacin de tres veces el nmero de
documentos (D), pero esto variar en funcin de cmo piensa usar los sitios.
4. Determine el nmero aproximado de versiones. Estime el nmero promedio de versiones que tendr cualquier documento de una
biblioteca (por lo general, este valor ser mucho menor que el nmero mximo de versiones permitido). Este valor se denomina V en
la frmula.
El valor de V debe ser superior a cero.
5. Utilice la siguiente frmula para calcular el tamao de las bases de datos de contenido:
Tamao de base de datos = ((D V) S) + (10 KB (L + (V D)))
El valor de 10 KB en la frmula es una constante que estima la cantidad aproximada de metadatos requeridos por SharePoint Server
2010. Si el sistema requiere un uso importante de metadatos, quizs desee incrementar esta constante.
Por ejemplo, si desea utilizar la frmula 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 colaboracin con las siguientes caractersticas, necesitar aproximadamente 105 GB.
432
Entrada Valor
Nmero de documentos (D) 200.000

Calculado suponiendo 10.000 usuarios multiplicado por 20
documentos
Tamao promedio de documentos (S) 250 KB
Elementos de lista (L) 600.000
Nmero de versiones no actuales (V) 2
Suponiendo que el nmero mximo de versiones es 10
Tamao de base de datos = (((200.000 x 2)) 250) + ((10 KB (600.000 + (200.000 x 2))) = 110.000.000 KB o 105 GB
Caractersticas que influyen en el tamao de las bases de datos de contenido
El uso de las siguientes caractersticas de SharePoint Server 2010 puede afectar significativamente el tamao 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 cuntos documentos se eliminan por mes para
determinar el efecto que tienen las papeleras de reciclaje en el tamao de las bases de datos de contenido. Para obtener ms
informacin, vea Configure Recycle Bin settings (SharePoint Server 2010).
Auditora Los datos de auditora pueden aumentar rpidamente y usar grandes cantidades de espacio en una base de datos de
contenido, especialmente si se activa la vista de auditora. En lugar de permitir que los datos de auditora crezcan sin restricciones,
se recomienda que solo habilite la auditora 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 auditora de datos:
Estime el nmero de nuevas entradas de auditora para un sitio y multiplique ese nmero por 2 KB (por lo general, las entradas
se limitan a 4 KB, con un tamao promedio de alrededor de 1 KB).
En funcin del espacio que desee asignar, determine el nmero de das de los registros de auditora que desea conservar.
433
Office Web Apps. Si se usa Office Web Apps, la memoria cach de Office Web Apps puede afectar considerablemente el tamao de
una base de datos de contenido. De manera predeterminada, la memoria cach de Office Web Apps se configura en 100 GB. Para
obtener ms informacin acerca el tamao de la memoria cach de Office Web Apps, vea Manage the Office Web Apps cache.
Estimacin de los requisitos de operaciones de IOPS para bases de datos de contenido
Los requisitos de IOPS para bases de datos de contenido varan considerablemente en funcin de la forma en que se usa el entorno, el
espacio disponible en disco y el nmero 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 ms informacin, vea Recomendaciones y resultados de
Importante:
Las pruebas para el contenido de esta seccin an no se han completado. Vuelva a consultar para obtener ms informacin.
Estimacin de las necesidades de almacenamiento de aplicaciones de servicio y operaciones IOPS

Despus de calcular la necesidades de almacenamiento de contenido y operaciones IOPS, a continuacin, 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 cmo 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 aplicacin de servicio Recomendacin de clculo de tamao
Recoleccin de datos de mantenimiento y uso La base de datos de uso puede crecer rpidamente y con ella, los
requisitos de IOPS.
Por ejemplo, en entornos de colaboracin que usan la configuracin
de fbrica, 1 milln de solicitudes HTTP necesitan 2 GB de
almacenamiento.
434
Base de datos de la aplicacin de servicio Recomendacin de clculo de tamao
Use una de las siguientes frmulas para estimar la cantidad
requerida de operaciones IOPS:
115 visitas a la pgina/segundo
5 solicitudes HTTP
Si debe restringir el tamao de la base de datos de uso, se
recomienda que comience por registrar nicamente las solicitudes
de pgina. Tambin puede restringir el tamao 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 tamao de la base de datos de los servicios de Conectividad a
datos empresariales se ve afectada principalmente por el nmero de
tipos de contenido externo que planea admitir. Asigne 0,5 MB para
cada tipo de contenido externo. Si no sabe cuntos tipos de
contenido externo podra necesitar, se recomienda asignar 50 MB.
Los requisitos de IOPS son mnimos.
Servicio de registro de aplicaciones Asigne 1 GB nicamente si va a actualizar a partir del catlogo de
datos profesionales de Microsoft Office SharePoint Server 2007. Los
requisitos de IOPS son mnimos.
Configuracin de suscripcin Asigne 1 GB. Los requisitos de IOPS son mnimos.
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 cmo las usar. Las aplicaciones de servicio disponibles en SharePoint Server 2010 que tienen bases
de datos se enumeran en la siguiente tabla.
435
Aplicacin de servicio Recomendacin de clculo de tamao
Bsqueda La bsqueda requiere tres bases de datos. El entorno podra incluir

varias bases de datos de rastreo y propiedades.
La base de datos de administracin de bsqueda normalmente es
pequea: 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 bsqueda son importantes.
Para la base de datos de rastreo, la bsqueda requiere de 3.500
a 7.000 IOPS.
Para la base de datos de propiedades, la bsqueda requiere
2.000 IOPS.
Para obtener informacin detallada acerca de cmo calcular la
capacidad necesaria para realizar bsquedas, vea
Recomendaciones y resultados de pruebas de rendimiento y
capacidad (SharePoint Server 2010).
Perfil de usuario La aplicacin de servicio de perfiles de usuario est asociada con
las bases de datos de perfiles, de sincronizacin y de etiquetas
temticas.
Para calcular el almacenamiento necesario para las bases de datos,
use la siguiente informacin:
Perfiles. Con la configuracin de fbrica, en un entorno
configurado para usar Active Directory, la base de datos de
perfil requiere aproximadamente 1 MB por cada perfil de
usuario.
436
Sincronizacin. Con la configuracin de fbrica, en un entorno
con pocos grupos por usuario, la base de datos de
sincronizacin requiere aproximadamente 630 KB por cada
perfil de usuario. El archivo de datos ocupar el 90% del
espacio.
Etiquetas temticas. Con la configuracin de fbrica, la base de
datos de etiquetas temticas requiere aproximadamente 0,009
MB por cada etiqueta, comentario o clasificacin. Para calcular
el nmero de etiquetas y notas que los usuarios crearn, tenga
en cuenta la siguiente informacin 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 colaboracin 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
configuracin de fbrica, se han visto los siguientes tamaos para
estas bases de datos:
Nombre de la base de datos Tamao de la base de datos
Perfiles 155 Gigabytes (GB)

Sincronizacin 96 Gigabytes (GB)
Etiquetas temticas 0,66 Gigabytes (GB)
Metadatos administrados La aplicacin de servicio de metadatos administrados tiene una sola

437
base de datos. El tamao de la base de datos se ve afectado por el
nmero de tipos de contenido y palabras clave utilizados en el
sistema. Muchos entornos incluirn varias instancias de la
aplicacin de servicio de metadatos administrados. Para obtener
ms informacin acerca de cmo calcular el tamao 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 tamao de las bases de
datos; entre ellos, el perodo de retencin, el volumen diario de
datos con seguimiento y la cantidad de colecciones de sitios, sitios y
subsitios de la aplicacin web que se va a analizar. Para obtener
ms informacin acerca de cmo calcular el tamao y los requisitos
de IOPS, vea Recomendaciones y resultados de pruebas de
Almacenamiento seguro El tamao de la base de datos de la aplicacin de servicio de
almacenamiento seguro est determinado por el nmero de
credenciales en el almacn y el nmero de entradas en la tabla de
auditora. Se recomienda asignar 5 MB para cada 1.000
credenciales para la base de datos. Los requisitos de IOPS son
mnimos.
Estado La aplicacin 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 mnimos.
Servicio de automatizacin de Word La aplicacin de servicio de automatizacin de Word tiene una sola
base de datos. Se recomienda asignar 1 GB para la base de datos.
Los requisitos de IOPS son mnimos.
438
PerformancePoint La aplicacin 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 mnimos.
Determinacin 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 informacin
detallada, vea Plan for availability (SharePoint Server 2010).
Eleccin de la versin y edicin 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 edicin Enterprise de SQL Server 2008 o SQL Server
2008 R2 para aprovechar las capacidades adicionales de rendimiento, disponibilidad, seguridad y administracin que proporciona. Para
obtener ms informacin 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 caractersticas:
Compresin de copia de seguridad La compresin 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
opcin de compresin 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 tamao de las copias de seguridad de bases de datos y registros de
envo. Para obtener ms informacin, vea el tema sobre compresin de copia de seguridad (SQL Server)
439
Nota:
La compresin 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.
Aplicacin de servicio de Web Analytics Si va a utilizar la aplicacin de servicio de Web Analytics para realizar un anlisis
significativo, considere la posibilidad de usar SQL Server Enterprise Edition, de modo tal que el sistema pueda aprovechar las
ventajas de la particin de tabla.
Distribucin de contenido Si va a utilizar la caracterstica de distribucin de contenido, considere la posibilidad de usar SQL Server
Enterprise Edition, de modo que el sistema pueda aprovechar las instantneas 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
ubicacin 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 tecnologa 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 lmites 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,
segn los lmites especificados. Est disponible solo en SQL Server 2008 o SQL Server 2008 R2 Enterprise Edition. Para obtener
ms informacin acerca de cmo usar el regulador de recursos, vea el tema sobre la administracin 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 bsqueda. 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 ubicacin 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 anlisis en Excel y en el explorador mientras se actualiza automticamente esos anlisis. Forma parte de Analysis
Services de SQL Server 2008 R2 Enterprise Edition.
440
Diseo de la arquitectura de almacenamiento en funcin de la
capacidad y los requisitos de E/S
Los tipos de disco y la arquitectura de almacenamiento que seleccione para su entorno podrn afectar al rendimiento del sistema.
En esta seccin:
Eleccin de una arquitectura de almacenamiento
Eleccin de tipos de disco
Eleccin de tipos de RAID
Eleccin 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 eleccin depende de factores de la solucin 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 estacin de trabajo, sin una red de
almacenamiento intermedia. Los tipos de disco fsico 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 mximo de IOPS.
Red de rea de almacenamiento (SAN)
SAN es una arquitectura de conexin 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 organizacin.
Las ventajas del almacenamiento compartido son:
Es ms fcil reasignar el almacenamiento en disco entre los servidores.
Puede dar servicio a varios servidores.
441
No hay limitacin 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 propsito 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 administracin 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 restriccin no se aplica al proveedor local de FILESTREAM de SQL Server porque ste solo almacena datos localmente en el
mismo servidor.
Eleccin de tipos de disco

Los tipos de disco que se utilizan en el sistema pueden afectar al rendimiento y la confiabilidad. Siendo todo lo dems igual, unidades
ms grandes aumentan la media del tiempo de bsqueda. SharePoint Server 2010 admite los siguientes tipos de unidades:
Interfaz estndar de equipos pequeos (SCSI)
Serial Advanced Technology Attachment (SATA)
SCSI conectados en serie (SAS)
Canal de fibra (FC)
Electrnica integrada de dispositivos (IDE)
Unidad de estado slido (SSD) o disco Flash
Eleccin de tipos de RAID
RAID (matriz redundante de discos independientes) a menudo se utiliza para mejorar las caractersticas de rendimiento de los discos
individuales (mediante la seleccin de datos de varios discos) y para proporcionar proteccin 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 solucin RAID
especfica del proveedor con rendimiento equivalente.
442
Cuando configure una matriz RAID, asegrese de alinear el sistema de archivos con el desplazamiento proporcionado por el proveedor.
Si no puede obtener informacin del proveedor, vea el tema sobre los procedimientos recomendados de entrada y salida antes de la
implementacin de SQL Server (http://go.microsoft.com/fwlink/?linkid=105583&clcid=0xC0A).
Para obtener ms informacin acerca del aprovisionamiento de RAID y el subsistema de entrada y salida de SQL Server, vea el artculo
sobre los procedimientos recomendados de SQL Server (http://go.microsoft.com/fwlink/?linkid=168612&clcid=0xC0A).
Estimacin de los requisitos de memoria

La memoria necesaria para SharePoint Server 2010 est directamente relacionada con el tamao 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 caractersticas, es probable que los requisitos aumenten. La siguiente tabla proporciona
instrucciones sobre la cantidad de memoria recomendada.
Nota:
Nuestras definiciones de implementaciones pequeas y medianas se describen en la seccin "Arquitecturas de referencia" del artculo
Capacity management and sizing for SharePoint Server 2010 (en ingls).
Tamao combinado de bases de datos de contenido RAM recomendado para el equipo que ejecuta SQL Server
Mnimo para implementaciones pequeas de produccin 8 Gigabytes (GB)

Mnimo para implementaciones medianas de produccin 16 Gigabytes (GB)
Recomendacin de hasta 2 terabytes 32 Gigabytes (GB)
Recomendacin para el intervalo de 2 terabytes a un mximo de 5 64 Gigabytes (GB)
terabytes
443
Nota:
Estos valores son superiores a los que se recomiendan como valores mnimos para SQL Server debido a la distribucin de datos
necesaria para un entorno de SharePoint Server 2010. Para obtener ms informacin 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
Entre otros factores que pueden influir en la memoria necesaria se incluyen los siguientes:
El uso de la creacin de reflejo de SQL Server.
El uso frecuente de archivos de ms de 15 megabytes (MB).
Descripcin de los requisitos de la topologa 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 topologa 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 travs de una red que tiene una latencia mayor que 1 ms. Esta
topologa no se ha probado.
Planee una red WAN adecuada si tiene pensado usar el trasvase de registros o la creacin 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 trfico de usuario final y el otro para controlar la comunicacin con los servidores que ejecutan SQL Server.
Configuracin de SQL Server

Las secciones siguientes describen cmo planear la configuracin de SQL Server para SharePoint Server 2010.
444
En esta seccin:
Determinacin de la cantidad de instancias o servidores necesarios
Configuracin de almacenamiento y memoria
Establecimiento de opciones de SQL Server
Configuracin de bases de datos
Estimacin de la cantidad de servidores necesarios
En general, SharePoint Server 2010 se ha diseado para aprovechar las ventajas del escalado horizontal de SQL Server, es decir,
SharePoint Server 2010 tendr un mejor rendimiento con un gran nmero 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 ningn otro rol de granja de servidores ni que hospede
bases de datos de cualquier otra aplicacin, a menos que vaya a implementar el sistema en un servidor independiente.
A continuacin se brinda una gua general sobre cundo implementar un servidor adicional que ejecutar SQL Server:
Agregue un servidor de base de datos adicional si tiene ms 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 gua.
Para promover el almacenamiento seguro de credenciales cuando se ejecuta la aplicacin 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.
Configuracin 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 mnimo de 2 MB
para mejorar la memoria.
445
Siga las recomendaciones de configuracin de almacenamiento del proveedor
Para obtener un rendimiento ptimo cuando se configura una matriz de almacenamiento fsico, siga las recomendaciones de
configuracin 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 informacin gua del proveedor, se recomienda configurar el almacenamiento para SQL Server 2008 mediante
la utilidad de configuracin de disco DiskPart.exe. Para obtener ms informacin, vea el tema sobre los procedimientos recomendados de
entrada y salida antes de la implementacin (http://go.microsoft.com/fwlink/?linkid=105583&clcid=0xC0A).
Suministre la mayor cantidad de recursos posibles
Asegrese de que los canales de entrada y salida de SQL Server a los discos no estn compartidos con otras aplicaciones, como el
archivo de paginacin 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, tambin debe tener en cuenta
el acceso a la red.
Establecimiento de opciones de SQL Server
Es necesario configurar los siguientes parmetros y opciones de SQL Server antes de implementar SharePoint Server.
No habilite la creacin automtica de estadsticas en un sistema SQL Server que admite SharePoint Server. SharePoint Server
implementa estadsticas especficas y no se necesitan estadsticas adicionales. La creacin automtica de estadsticas puede
cambiar considerablemente el plan de ejecucin 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 cdigo de las sugerencias
para las consultas segn sea necesario para proporcionar el mejor rendimiento a travs de todos los escenarios.
Para asegurar un ptimo rendimiento, se recomienda fehacientemente establecer el grado mximo de paralelismo en 1 para
servidores de bases de datos que hospedan bases de datos de SharePoint Server 2010. Para obtener ms informacin acerca de
cmo establecer el grado mximo de paralelismo, vea el tema sobre la opcin max degree of parallelism
Para facilitar el mantenimiento, configure los alias de conexin de SQL Server para cada servidor de base de datos en su granja de
servidores. Un alias de conexin es un nombre alternativo que puede usarse para conectarse a una instancia de SQL Server. Para
obtener ms informacin, 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).
446
Configuracin de bases de datos
Las instrucciones siguientes describen los procedimientos recomendados para planear mientras se configura cada base de datos en el
entorno.
Separacin y asignacin 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 bsqueda
y los registros de transacciones de SQL Server 2008 en discos duros fsicos 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 ms rpidos, use la siguiente clasificacin:
1. Archivos de datos tempdb y registros de transacciones
2. Archivos de registro de transacciones de bases de datos
3. Bases de datos de bsqueda, excepto la base de datos de administracin de bsqueda
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 operacin de lectura media o la operacin
de escritura media requieren ms 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 ms rpidos.
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 ncleo y los archivos de datos de tempdb se deben establecer en el mismo tamao. Para ello, cuente
los procesadores de doble ncleo como dos CPU. Cuente cada procesador compatible con la tecnologa Hyper-Threading como una
nica CPU. Para obtener ms informacin, vea el tema en el que se explica cmo 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 pequeos 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 simultneas.
Consulte al proveedor de hardware de almacenamiento acerca de cmo configurar todos los registros y las bases de datos de
bsqueda para optimizar la escritura en su solucin de almacenamiento particular.
447
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 nmero de archivos de datos debe ser menor o igual que el nmero de CPU de ncleo. Con este fin, cuente los procesadores de
doble ncleo como dos CPU. Cuente cada procesador compatible con la tecnologa Hyper-Threading como una nica CPU.
Cree archivos de datos que tengan el mismo tamao.
Importante:
Aunque las herramientas de copia de seguridad y recuperacin 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 ubicacin, las herramientas no podrn
restaurar varios archivos de datos en una ubicacin 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 recuperacin de SQL Server. Para obtener ms
informacin acerca de cmo realizar copias de seguridad y recuperacin de SharePoint Server 2010, vea Plan for backup and recovery
Para obtener ms informacin acerca de la creacin y administracin de grupos de archivos, vea el tema sobre grupos de archivos y
archivos de bases de datos fsicas (http://go.microsoft.com/fwlink/?linkid=117909&clcid=0xC0A).
Limitacin del tamao de la base de datos de contenido para mejorar la facilidad de administracin
Considere un tamao de base de datos que permita mejorar la administracin, el rendimiento y la actualizacin del entorno.
Para ayudar a garantizar el rendimiento del sistema, es muy recomendable limitar el tamao de las bases de datos de contenido a 200
GB.
Una coleccin de sitios no debe superar los 100 GB a menos que sea la nica coleccin de sitios en la base de datos. Este lmite existe
para que se puedan utilizar las herramientas de copia de seguridad pormenorizada de SharePoint Server 2010 para mover una coleccin
de sitios a otra base de datos, si es necesario.
448
Importante:
Los tamaos 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 estticos, como sistemas de administracin de documentos de referencia y sitios del centro
de registros. Los tamaos ms 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 diseados y probados para escalas de mayor tamao.
Si el diseo requiere una base de datos ms grande que el estndar recomendado, siga estas instrucciones:
Para las bases de datos que contienen muchos archivos de gran tamao 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 vdeo o multimedia.
Para obtener ms informacin, vea Plan for remote BLOB storage (RBS) (SharePoint Server 2010).
Siga los procedimientos recomendados para ver datos de bases de datos grandes. Para obtener ms informacin, vea
Administracin de la capacidad de SharePoint Server 2010: restricciones y lmites del software.
Para obtener ms informacin 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
Administracin automtica del crecimiento de datos y archivos de registro
Se recomienda administrar automticamente 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 tamao final anticipado.
Se recomienda que habilite el crecimiento automtico por razones de seguridad. No confe en la configuracin predeterminada de
crecimiento automtico. Tenga en cuenta las siguientes instrucciones al configurar el crecimiento automtico:
Cuando se planean bases de datos de contenido que superan el tamao recomendado (200 GB), se debe establecer el valor de
crecimiento automtico de la base de datos en un nmero fijo de megabytes, en lugar de un porcentaje. Esto permite reducir la
449
frecuencia con la que SQL Server aumenta el tamao de un archivo. El aumento del tamao del archivo es una operacin de
bloqueo que implica rellenar el nuevo espacio con pginas vacas.
Establezca el valor de crecimiento automtico para la base de datos de almacn de propiedades de la aplicacin de servicio de
bsqueda en 10 por ciento.
Si no se espera que el tamao calculado de la base de datos de contenido alcance el tamao mximo recomendado de 200 GB
durante el prximo ao, establezca el tamao mximo que estima tendr la base de datos dentro de un ao, con un 20 por ciento
adicional como margen de error, mediante el uso de la propiedad ALTER DATABASE MAXSIZE. Revise peridicamente esta
configuracin para asegurarse de que sigue siendo un valor apropiado en funcin 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 mximo. Si administra el crecimiento agregando discos a una matriz RAID o asignando ms almacenamiento, supervise el
tamao del disco para evitar quedarse sin espacio.
Validacin y supervisin del almacenamiento y rendimiento de SQL

Server
Pruebe si la solucin 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 solucin de copia de seguridad que va a usar para asegurarse de que la copia de seguridad del sistema pueda hacerse
durante el perodo de mantenimiento disponible. Si la solucin de copia de seguridad no puede cumplir los SLA que su negocio requiere,
considere la posibilidad de usar una solucin 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,
proporcin de aciertos en cach y subsistema de E/S. Cuando parezca que uno o varios de los componentes estn lentos o
sobrecargados, analice la estrategia adecuada en funcin de la carga de trabajo actual y prevista. Para obtener ms informacin, vea el
tema sobre la solucin de problemas de rendimiento en SQL Server 2008 (http://go.microsoft.com/fwlink/?linkid=168448&clcid=0xC0A).
En la seccin 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. Tambin se indican los valores aproximados de buen estado para
cada contador.
Para obtener ms informacin acerca de cmo supervisar el rendimiento y usar contadores de rendimiento, vea el tema sobre la
supervisin del rendimiento (http://go.microsoft.com/fwlink/?linkid=189032&clcid=0xC0A).
450
Contadores de SQL Server para supervisar
Supervise los siguientes contadores de SQL Server para garantizar el buen estado de los servidores:
Estadsticas generales Este objeto proporciona contadores para supervisar la actividad general de todo el servidor, por ejemplo, el
nmero de conexiones actuales y el nmero 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 nmero de conexiones de usuario del equipo que ejecuta SQL Server. Si
este nmero aumenta al 500 por ciento de su lnea 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 restauracin, as como las actividades de registro de transacciones. Supervise las transacciones y el registro de
transacciones para determinar cunta actividad de usuario se est produciendo en la base de datos y cunto est creciendo el
registro de transacciones. La cantidad de actividad de usuario puede determinar el rendimiento de la base de datos y afectar al
tamao del registro, a los bloqueos y a la rplica. 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 nmero sirve ms para su lnea base y para solucionar problemas.
Bloqueos Este objeto brinda informacin 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 nmero de bloqueos por segundo que no se pudieron satisfacer
inmediatamente y que tuvieron que esperar recursos.
Nmero de interbloqueos/s Este contador muestra el nmero 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 supervisin 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:
451
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 nmero de solicitudes de bloqueos temporales que no se
concedieron inmediatamente.
Estadsticas SQL Este objeto proporciona contadores para supervisar la compilacin y el tipo de solicitudes enviadas a una instancia
de SQL Server. Supervisar el nmero de compilaciones y nuevas compilaciones de consulta y el nmero 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 nmero de veces que se especifica la ruta de acceso del cdigo de compilacin
por segundo.
Recompilaciones SQL/s Este contador indica el nmero de recompilaciones de instrucciones por segundo.
Administrador de bfer Este objeto proporciona contadores para supervisar cmo utiliza SQL Server la memoria para almacenar las
pginas de datos, las estructuras de datos internos y la memoria cach de procedimientos, as como los contadores para supervisar
la E/S fsica mientras SQL Server lee y escribe pginas de base de datos. Considere la posibilidad de supervisar los siguientes
contadores:
Proporcin de aciertos en cach del bfer
Este contador muestra el porcentaje de pginas encontradas en la memoria cach del bfer sin necesidad de leer en el disco. La
relacin es el nmero total de aciertos de cach dividido por el nmero total de bsquedas de cach a travs de los ltimos miles
de accesos a la pgina. Como la lectura de la memoria cach es mucho menos costosa que la lectura del disco, es deseable que
esta proporcin sea alta. Por lo general, es posible aumentar la proporcin de aciertos de cach del bfer si aumenta la cantidad
de memoria disponible para SQL Server.
Cach del plan Este objeto proporciona contadores para supervisar cmo 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:
Proporcin de aciertos en cach
Este contador indica la proporcin entre aciertos en cach y bsquedas de planes.
Contadores de servidor fsico para supervisar
Supervise los siguientes contadores para asegurar el buen estado de los equipos que ejecutan SQL Server:
452
Procesador: % tiempo de procesador: _Total Este contador muestra el porcentaje de tiempo en que el procesador ejecuta
procesos de una aplicacin 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
ncleo.
Memoria: Mbytes disponibles Este contador muestra la cantidad de memoria fsica, 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 fsica disponible.
Memoria: Pginas/s Este contador muestra la velocidad con que se leen o escriben las pginas en el disco para resolver errores
graves de las pginas. Supervise este contador para asegurarse de que permanece por debajo de 100.
Para obtener ms informacin y conocer mtodos de resolucin de problemas de la memoria, vea el tema sobre el uso de la memoria de
supervisin 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 medicin.
Disco fsico: % 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 fsico: % de tiempo de disco es alto (ms del 90 por ciento), compruebe el
contador Disco fsico: longitud actual de la cola de disco para ver cuntas solicitudes del sistema estn esperando acceso al
disco. El nmero de solicitudes de E/S en espera debera mantenerse en no ms de 1,5 a 2 veces el nmero de cilindros que
componen el disco fsico.
Disco lgico: 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 pronsticos y tendencias de crecimiento.
Disco lgico: Bytes de lectura de disco/s y Disco lgico: 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.
453
Disco lgico: 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 ms grandes pueden
producir un pequeo aumento en la latencia.
Disco lgico: 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 ms grandes pueden
producir un pequeo aumento en la latencia.
Disco lgico: 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 ms bajos son mejores. Los valores mayores
de 2 por disco podran indicar un cuello de botella y debern ser investigados. Esto quiere decir que un valor de hasta 8 se podra
aceptar para una unidad lgica (LUN) formada por 4 discos. Los cuellos de botella pueden crear un trabajo acumulado que se puede
extender ms all del servidor actual que est teniendo acceso al disco y generar largos perodos de espera para los usuarios. Las
posibles soluciones para el cuello de botella consisten en agregar ms discos a la matriz RAID, reemplazar los discos existentes por
discos ms rpidos o mover algunos datos a otros discos.
Disco lgico: 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 difcil de medir debido a la virtualizacin 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 combinacin 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 lgico: Promedio de segundos de disco/lectura y Disco lgico: Promedio de segundos de disco/escritura Estos
contadores muestran el tiempo medio, en segundos, de una operacin 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 especfica de su hardware, vea la documentacin de su proveedor o use la herramienta de pruebas comparativas del
subsistema de disco SQLIO para calcularla. Para obtener ms informacin, vea el tema sobre la herramienta de pruebas
comparativas del subsistema de disco SQLIO (http://go.microsoft.com/fwlink/?linkid=105586&clcid=0xC0A).
Disco lgico: Promedio de segundos de disco/lectura Este contador muestra el tiempo medio, en segundos, de una
operacin de lectura del disco. En un sistema bien ajustado, los valores ideales oscilan entre 1 y 5 milisegundos (ms) para los
registros (lo idneo es 1 milisegundo en una matriz de cach) y entre 4 y 20 ms para los datos (lo idneo es menos de 10 ms). Se
pueden producir latencias superiores en horas de mxima actividad, pero si los valores elevados se registran con frecuencia,
deber investigar la causa.
454
Disco lgico: Promedio de segundos de disco/escritura Este contador muestra el tiempo medio, en segundos, de una
operacin de escritura del disco. En un sistema bien ajustado, los valores ideales oscilan entre 1 y 5 milisegundos (ms) para los
registros (lo idneo es 1 milisegundo en una matriz de cach) y entre 4 y 20 ms para los datos (lo idneo es menos de 10 ms). Se
pueden producir latencias superiores en horas de mxima 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 frmulas que se indican en la siguiente tabla para determinar la velocidad de entrada o salida en el
disco.
Nivel RAID Frmula
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 fsicos y sus contadores estn establecidos en los
valores que se muestran en la tabla siguiente:
Contador Valor
Promedio de segundos de disco/lectura 80

Disco lgico: 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 situacin, tiene un cuello de botella de E/S lmite.
455
Otras herramientas de supervisin
Tambin puede supervisar la latencia de los discos y analizar las tendencias mediante la vista de administracin dinmica
sys.dm_io_virtual_file_stats en SQL Server 2008. Para obtener ms informacin, vea sys.dm_io_virtual_file_stats (Transact-SQL)
456

Share PT Serv Plan Cap

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Share PT Serv Plan Cap

Cargado por

Copyright:

Formatos disponibles

Planeacin de la capacidad para Microsoft SharePoint Server 2010

Cmo obtener ayuda ....................................................................................................................................................................................... 10

Administracin del rendimiento y de la capacidad (SharePoint Server 2010) ................................................................................................ 11

Planeacin de la capacidad para SharePoint Server 2010 ............................................................................................................................. 47

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

Supervisin y mantenimiento de SharePoint Server 2010 .............................................................................................................................. 77

Estimacin de los requisitos de rendimiento y capacidad de PerformancePoint Services ........................................................................... 318

Quin debera leer los artculos de administracin de capacidad?

Cuatro aspectos bsicos de rendimiento

Administracin de capacidad frente a planeacin de capacidad

Restricciones y lmites del software

Diferencias clave entre SharePoint Server 2010 y Office SharePoint

Servicio de SharePoint XXX XXX XX XXX XXX

InfoPath Forms Services XX XX XX XX X X X

Servicio de SharePoint Foundation El servicio de SharePoint principal de colaboracin de contenido. En implementaciones de

Office Web Apps XXX XX

Diferenciadores clave de implementacin de SharePoint Server 2010

Implementacin de una granja de servidores pequea

Caractersticas de la carga de trabajo Valor

Promedio de RPS por da

Explorador web: Office Web Apps

Tamao de la base de datos (en GB)

Servidores web Virtual 4 4 ncleos 8 N/A 400 GB N/A

Determinacin de la arquitectura inicial

Paso 3: Piloto, prueba y optimizacin

Paso 5: Supervisin y mantenimiento

Creacin de un plan de pruebas

Creacin del entorno de prueba

Creacin de pruebas y herramientas

Proteccin de "flood" del registro de eventos Deshabilitado El valor predeterminado es

Contador de rendimiento Descripcin

Procesador Debe supervisar el rendimiento del procesador para asegurarse de

Contadores del sistema

Objetos y contadores Descripcin

Contadores SQL Server

Objetos y contadores Descripcin

Estadsticas generales Este objeto proporciona contadores para supervisar la actividad

Eliminacin de cuellos de botella

Objetos y contadores Problema Opciones de resolucin

Errores de cach/s Mayor que 1 Agregar memoria

Informacin general de lmites mximos y lmites

Lmites y lmites mximos

Lmite Valor mximo Tipo de lmite Notas

Lmites de servidores web y servidores de aplicaciones

Lmite Valor mximo Tipo de lmite Notas

Lmites de bases de datos de contenido

Lmite Valor mximo Tipo de lmite Notas

Lmite Valor mximo Tipo de lmite Notas

Sitio web 250.000 por coleccin de sitios Compatible El nmero mximo

Lmite Valor mximo Tipo de lmite Notas

Lmite Valor mximo Tipo de Tamao por Notas

Lmite Valor mximo Tipo de lmite Notas

Lmite Valor mximo Tipo de lmite Notas

Lmites por caracterstica

Lmite Valor mximo Tipo de lmite Notas

Aplicaciones de servicio de 20 por granja de servidores Compatible Pueden implementarse varias

mbitos 200 por sitio Umbral ste es un lmite recomendado

Lmite Valor mximo Tipo de lmite Notas

Perfiles de usuario 2.000.000 por aplicacin de servicio Compatible Una aplicacin de

Lmites de distribucin de contenido

Trabajos de distribucin de 20 Compatible En el caso de trabajos simultneos en rutas de

Si usa instantneas de SQL Server para la

Lmite Valor mximo Tipo de lmite Notas