Você está na página 1de 366

Planejamento de capacidade para SharePoint

Server 2010
Microsoft Corporation
Publicado em: janeiro de 2011
Autor: equipe de servidores e do Microsoft Office System (itspdocs@microsoft.com)

Resumo
Este manual fornece informaes sobre o planejamento de requisitos de capacidade e
desempenho para a implantao do Microsoft SharePoint Server 2010. Os tpicos
incluem dimensionamento, teste de desempenho, limites de software e anlises de
capacidade. As audincias deste guia so especialistas em aplicativos de negcios,
especialistas em linha de negcios, arquitetos da informao, generalistas em TI,
gerentes de programa e especialistas em infraestrutura que planejam uma soluo
baseada no SharePoint Server 2010. Este manual faz parte de um conjunto de quatro
guias de planejamento que fornecem abrangentes informaes de planejamento de TI
para o SharePoint Server.
Para obter mais informaes sobre o planejamento da arquitetura de uma implantao
do SharePoint Server 2010, consulte Planning guide for server farms and environments
for Microsoft SharePoint Server 2010
(http://go.microsoft.com/fwlink/?linkid=189513&clcid=0x416).
Para obter informaes sobre o planejamento de sites e solues criados com o uso do
SharePoint Server, consulte Planning guide for sites and solutions for Microsoft
SharePoint Server 2010, Part 1
(http://go.microsoft.com/fwlink/?linkid=196150&clcid=0x416) e Planning guide for sites
and solutions for Microsoft SharePoint Server 2010, Part 2
(http://go.microsoft.com/fwlink/?linkid=208024&clcid=0x416).
O contedo deste guia uma cpia do contedo selecionado na biblioteca tcnica do
SharePoint Server 2010 (http://go.microsoft.com/fwlink/?linkid=181463&clcid=0x416) a
partir da data de publicao. Para obter o contedo mais atual, consulte a biblioteca
tcnica na Web.

Este documento fornecido "no estado em que se encontra". As informaes e as


exibies expressas neste documento, incluindo URLs e outras referncias a sites da
Internet, podem ser alteradas sem aviso prvio. Voc assume o risco inerente sua
utilizao.
Alguns exemplos citados neste documento so fornecidos somente como ilustrao e
so fictcios. No h nenhuma inteno, nem por deduo, de qualquer associao ou
conexo real.
Este documento no oferece a voc quaisquer direitos legais sobre propriedade
intelectual em qualquer produto da Microsoft. Este documento pode ser copiado e usado
para fins internos e de referncia.
2011 Microsoft Corporation. Todos os direitos reservados.
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 e
Windows Vista so marcas registradas ou marcas comerciais da Microsoft Corporation
nos Estados Unidos e/ou em outros pases.

Contedo
Planejamento de capacidade para SharePoint Server 2010 .......................................... 1
Obtendo ajuda ..................................................................................................................... 7
Gerenciamento de desempenho e capacidade (SharePoint Server 2010) ........................ 8
Capacity management and sizing for SharePoint Server 2010 (em ingls) ..................... 10
Viso geral do gerenciamento da capacidade e dimensionamento do SharePoint Server
2010 ............................................................................................................................... 11
Glossrio ........................................................................................................................ 11
Quem deve ler os artigos sobre gerenciamento de capacidade? ................................. 12
Quatro fundamentos de desempenho ........................................................................... 14
Gerenciamento de capacidade versus planejamento de capacidade ........................... 19
Superdimensionamento versus subdimensionamento .................................................. 21
Limites e delimitadores de software .............................................................................. 22
Principais diferenas: SharePoint Server 2010 versus Office SharePoint Server 200724
Diferenciadores de chave de implantao do SharePoint Server 2010 ........................ 32
Arquiteturas de referncia ............................................................................................. 34
Consulte tambm ........................................................................................................... 38
Planejamento de capacidade para SharePoint Server 2010 ............................................ 40
Etapa 1: Modelo ............................................................................................................. 40
Etapa 2: Design ............................................................................................................. 49
Etapa 3: Piloto, Teste e Otimizao .............................................................................. 53
Etapa 4: Implantao ..................................................................................................... 55
Etapa 5: Monitorao e Manuteno ............................................................................. 56
Consulte tambm ........................................................................................................... 56
Testes de desempenho para SharePoint Server 2010..................................................... 57
Criar um plano de teste ................................................................................................. 58
Criar o ambiente de teste .............................................................................................. 58
Crie testes e ferramentas .............................................................................................. 60
Consulte tambm ........................................................................................................... 64
Monitorando e mantendo o SharePoint Server 2010 ....................................................... 66
Configurando o monitoramento ..................................................................................... 66
Removendo afunilamentos ............................................................................................ 77
Consulte tambm ........................................................................................................... 80
Gerenciamento de capacidade do SharePoint Server 2010: limites de software ............ 81
Viso geral de delimitadores e limites ........................................................................... 82

Limites e delimitadores .................................................................................................. 84


Performance and capacity technical case studies (SharePoint Server 2010) (em ingls)
..................................................................................................................................... 129
Ambiente de publicao na intranet da empresa do Microsoft SharePoint Server 2010:
anlise tcnica ............................................................................................................. 131
Informaes sobre pr-requisitos ................................................................................ 131
Introduo a este ambiente ......................................................................................... 131
Especificaes ............................................................................................................. 132
Carga de trabalho ........................................................................................................ 137
Conjunto de dados ....................................................................................................... 137
Dados de integridade e desempenho .......................................................................... 138
Enterprise intranet collaboration environment technical case study (SharePoint Server
2010) (em ingls) ......................................................................................................... 141
Prerequisite information ............................................................................................... 141
Introduction to this environment .................................................................................. 141
Specifications ............................................................................................................... 142
Health and Performance Data ..................................................................................... 148
Enterprise intranet collaboration environment lab study (SharePoint Server 2010) (em
ingls) .......................................................................................................................... 151
Introduction to this environment .................................................................................. 151
Glossary ....................................................................................................................... 152
Overview ...................................................................................................................... 153
Specifications ............................................................................................................... 154
Results and Analysis ................................................................................................... 160
Departmental collaboration environment technical case study (SharePoint Server 2010)
(em ingls) ................................................................................................................... 172
Prerequisite information ............................................................................................... 172
Introduction to this environment .................................................................................. 172
Specifications ............................................................................................................... 173
Workload ...................................................................................................................... 180
Dataset......................................................................................................................... 180
Health and Performance Data ..................................................................................... 181
Divisional portal environment lab study (SharePoint Server 2010) (em ingls) ............. 184
Introduction to this environment .................................................................................. 184
Glossary ....................................................................................................................... 185
Overview ...................................................................................................................... 186
Specifications ............................................................................................................... 187
Results and analysis .................................................................................................... 193
About the authors ........................................................................................................ 207

Social environment technical case study (SharePoint Server 2010) (em ingls) ........... 208
Prerequisite information ............................................................................................... 208
Introduction to this environment .................................................................................. 208
Specifications ............................................................................................................... 209
Workload ...................................................................................................................... 214
Dataset......................................................................................................................... 215
Health and Performance Data ..................................................................................... 215
Recomendaes e resultados de testes de desempenho e capacidade (SharePoint
Server 2010) ................................................................................................................ 219
Estimate performance and capacity requirements for Access Services in SharePoint
Server 2010 (em ingls) .............................................................................................. 222
Test farm characteristics.............................................................................................. 222
Test results .................................................................................................................. 225
Recommendations ....................................................................................................... 235
Troubleshooting ........................................................................................................... 240
Estimate performance and capacity requirements for Excel Services in SharePoint Server
2010 (em ingls) .......................................................................................................... 242
Test farm characteristics.............................................................................................. 242
Test Results ................................................................................................................. 245
Recommendations ....................................................................................................... 255
Estimar os requisitos de desempenho e capacidade dos Servios PerformancePoint . 261
Caractersticas do farm de teste .................................................................................. 261
Cenrios e processos de teste .................................................................................... 262
Configurao e topologia de hardware ........................................................................ 264
Resultados do teste ..................................................................................................... 265
Topologias 2C e 3C ..................................................................................................... 267
Resultados para mais de 4C com autenticao da Conta de Servio sem Superviso
.................................................................................................................................. 271
Resultados para mais de 4C com autenticao por usurio ....................................... 272
Recomendaes .......................................................................................................... 273
Analysis Services ......................................................................................................... 275
Afunilamentos comuns e suas causas ........................................................................ 275
Monitoramento de desempenho .................................................................................. 278
Consulte tambm ......................................................................................................... 279
Capacity requirements for Web Analytics Shared Service in SharePoint Server 2010 (em
ingls) .......................................................................................................................... 281
Introduction .................................................................................................................. 281
Hardware specifications and topology ......................................................................... 284
Capacity requirements ................................................................................................. 288
Consulte tambm ......................................................................................................... 292

Estimar os requisitos de desempenho e capacidade do Gerenciamento de contedo da


Web no SharePoint Server 2010 ................................................................................. 293
Informaes sobre pr-requisitos ................................................................................ 294
Detalhes e abordagem do teste .................................................................................. 294
Implantaes de Gerenciamento de Contedo da Web ............................................. 297
O que otimizar ............................................................................................................. 297
Resultados do teste e recomendaes ....................................................................... 302
Sobre os autores ......................................................................................................... 324
Estimate performance and capacity planning for workflow in SharePoint Server 2010 (em
ingls) .......................................................................................................................... 325
Test farm characteristics.............................................................................................. 325
Test results .................................................................................................................. 329
Recommendations ....................................................................................................... 335
Troubleshooting ........................................................................................................... 338
Consulte tambm ......................................................................................................... 341
Planejamento e configurao de armazenamento e capacidade do SQL Server
(SharePoint Server 2010) ............................................................................................ 342
Processo de design e configurao do armazenamento e da camada do banco de
dados dos Produtos SharePoint 2010 ..................................................................... 342
Coletar requisitos de armazenamento e de espao e E/S do SQL Server ................. 343
Escolher a verso e a edio do SQL Server ............................................................. 352
Projetar a arquitetura de armazenamento com base em requisitos de capacidade e E/S
.................................................................................................................................. 353
Estimar requisitos de memria .................................................................................... 355
Entender os requisitos de topologia de rede ............................................................... 356
Configurar o SQL Server ............................................................................................. 357
Validar e monitorar o desempenho do armazenamento e do SQL Server ................. 361

Obtendo ajuda
Todo esforo foi dedicado para garantir a preciso deste guia. Este contedo tambm
est disponvel online na TechNet Library do Office System, portanto, se encontrar
algum problema, veja se h atualizaes em:
http://technet.microsoft.com/pt-br/office/bb267342
Se no encontrar a sua resposta no contedo online, envie um email para a equipe de
contedo de servidores e do Microsoft Office System:
itspdocs@microsoft.com
Se a sua dvida for relacionada aos produtos do Microsoft Office, e no ao contedo
deste guia, pesquise o Centro de Ajuda e Suporte da Microsoft ou a Base de Dados de
Conhecimento Microsoft pelo site:
http://support.microsoft.com/?ln=pt-br

Gerenciamento de desempenho e
capacidade (SharePoint Server 2010)
Planejamento de desempenho e capacidade o processo de mapeamento do design da
soluo do Microsoft SharePoint Server 2010 para um tamanho de farm e conjunto de
hardware que oferea suporte s suas metas de negcios.
Artigos relevantes sobre planejamento de capacidade e desempenho do Project
Server 2010 esto disponveis na biblioteca de documentos do Project Server, em Plan
for performance and capacity (Project Server 2010).
Os artigos nesta seo incluem:
Viso geral do gerenciamento da capacidade e dimensionamento do SharePoint
Server 2010
Este artigo o orienta pelos conceitos envolvidos no gerenciamento da capacidade e
no dimensionamento dos farms do SharePoint 2010 e apresenta uma viso geral do
processo de planejamento.
Planejamento de capacidade para SharePoint Server 2010
Este artigo inclui etapas e procedimentos detalhados para planejamento da
capacidade dos farms do SharePoint 2010.
Monitorando e mantendo o SharePoint Server 2010
Este artigo apresenta informaes sobre como manter e monitorar o desempenho
dos farms do SharePoint 2010.
Testes de desempenho para SharePoint Server 2010
Este artigo apresenta diretrizes para teste de desempenho dos farms do SharePoint
2010.
Gerenciamento de capacidade do SharePoint Server 2010: limites de software
Este artigo mostra o ponto de partida do planejamento de desempenho e
capacidade do sistema. Ele inclui os resultados do teste de desempenho e
capacidade, alm de diretrizes para um desempenho aceitvel.
Performance and capacity technical case studies (SharePoint Server 2010) (em
ingls)
Este artigo inclui links para os principais artigos tcnicos de estudo de caso que
apresentam os detalhes de desempenho e capacidade para ambientes especficos
que executam o SharePoint Server 2010.
Recomendaes e resultados de testes de desempenho e capacidade (SharePoint
Server 2010)
Este artigo inclui links para artigos que apresentam os resultados de testes e as
recomendaes para conjuntos de recursos especficos no SharePoint Server 2010.
Planejamento e configurao de armazenamento e capacidade do SQL Server
(SharePoint Server 2010)
8

Este artigo descreve um processo para planejar o armazenamento e a capacidade


do SQL Server para uma implantao do SharePoint Server 2010.
Os recursos a seguir tambm podem ser teis no planejamento da capacidade:
Determine hardware and software requirements (SharePoint Server 2010)

Diagramas tcnicos:

Topologias para o SharePoint Server 2010

Arquiteturas de pesquisa do Microsoft SharePoint Server 2010

Criar arquiteturas de pesquisa para o Microsoft SharePoint Server 2010

Planejamento do ambiente de pesquisa para o Microsoft SharePoint Server 2010


Para baixar esses modelos, consulte Technical diagrams (SharePoint Server
2010).

Capacity management and sizing for


SharePoint Server 2010 (em 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:
Viso geral do gerenciamento da capacidade e dimensionamento do SharePoint
Server 2010

Planejamento de capacidade para SharePoint Server 2010

Testes de desempenho para SharePoint Server 2010

Monitorando e mantendo o SharePoint Server 2010

10

Viso geral do gerenciamento da


capacidade e dimensionamento do
SharePoint Server 2010
Este artigo oferece uma viso geral de como planejar e gerenciar com eficincia a
capacidade de ambientes do Microsoft SharePoint Server 2010. Ele tambm descreve
como manter um bom entendimento das necessidades de capacidade e dos recursos da
sua implantao, pela anlise do desempenho e dos dados de volume. Tambm analisa
os principais impactos de aplicativos que afetam a capacidade, incluindo as
caractersticas e o uso de contedo.
O Gerenciamento de capacidade um processo contnuo porque nenhuma
implementao permanece esttica em relao ao contedo e ao uso. Voc precisa se
planejar para o crescimento e a alterao, de forma que o seu ambiente baseado no
SharePoint Server 2010 possa continuar a oferecer uma soluo de negcios eficiente.
O Planejamento de Capacidade a nica parte do ciclo de gerenciamento de
capacidade. o conjunto de atividades inicial que traz o arquiteto de design para o ponto
onde h uma arquitetura inicial que, na opinio do arquiteto, servir melhor
implantao do SharePoint Server 2010. O modelo de gerenciamento de capacidade
inclui etapas adicionais para ajudar voc a validar e ajustar a arquitetura inicial, alm de
oferecer um loop de comentrios para replanejamento e otimizao do ambiente de
produo at que ele possa oferecer suporte aos objetivos de design com opes ideais
de hardware, topologia e configurao
Neste artigo:
Glossrio

Quem deve ler os artigos sobre gerenciamento de capacidade?

Quatro fundamentos de desempenho

Gerenciamento de capacidade versus planejamento de capacidade

Superdimensionamento versus subdimensionamento

Limites e delimitadores de software

Principais diferenas: SharePoint Server 2010 versus Office SharePoint Server 2007

Diferenciadores de chave de implantao do SharePoint Server 2010

Arquiteturas de referncia

Glossrio
Os termos especializados a seguir so usados na documentao de gerenciamento de
capacidade do SharePoint Server 2010.
RPS Solicitaes por segundo. O nmero de solicitaes recebidas por um farm ou
servidor em um segundo. uma medida comum de carga de servidor e de farm. O
nmero de solicitaes processadas por um farm maior do que o nmero de
11

carregamentos de pgina e de interaes de usurio final. Isso acontece porque


cada pgina contm vrios componentes, cada um criando uma ou mais solicitaes
quando a pgina carregada. Algumas solicitaes so mais leves do que outras no
que diz respeito a custos de transao. Em nossos testes de laboratrio e
documentos de estudo de caso, removemos 401 solicitaes e respostas
(handshakes de autenticao) das solicitaes que foram usadas para calcular o
RPS porque elas tiveram um impacto insignificante nos recursos do farm.

Horrios de pico A hora ou horas durante o dia quando a carga do farm est em
seu mximo.

Carga de pico A carga diria mxima mdia no farm, medida em RPS.

Picos de Carga Picos de carga transitrios que acontecem fora do horrio de pico.
Podem ser causados por aumentos no planejados em trfego de usurios, taxas de
transferncia menores no farm por causa de operaes administrativas ou
combinaes desses fatores.

Aumentar a escala Aumentar a escala significa adicionar recursos como


processadores ou memrias a um servidor.

Expandir Expandir significa adicionar mais servidores a um farm.

Quem deve ler os artigos sobre


gerenciamento de capacidade?
Considere as perguntas a seguir para determinar se voc deve ler este contedo.

Avaliando o SharePoint Server 2010


Eu sou um profissional de TI ou tomador de decises de negcios e procuro uma
soluo para problemas de negcios especficos. O SharePoint Server 2010 uma
opo para a minha implantao. Ele pode oferecer recursos e escalabilidade que
atendam aos meus requisitos especficos?
Para obter informaes sobre como o SharePoint Server 2010 se dimensiona para
atender s demandas de solues especficas e como determinar o hardware que ser
necessrio para oferecer suporte aos seus requisitos, consulte as sees a seguir neste
artigo:
Principais diferenas: SharePoint Server 2010 versus Office SharePoint Server 2007
Limites e delimitadores de software
Para obter informaes sobre como avaliar o SharePoint Server 2010 seus requisitos de
negcios especficos, consulte os seguintes artigos:
Product evaluation for SharePoint Server 2010

Gerenciamento de capacidade do SharePoint Server 2010: limites de software

Atualizando do Office SharePoint Server 2007


No momento, estou usando o Office SharePoint Server 2007. O que mudou no
SharePoint Server 2010 e o que devo considerar se resolver atualizar? Que efeito a
atualizao tem no desempenho e no dimensionamento da minha topologia?
Para obter informaes sobre como os fatores de desempenho e capacidade so
diferentes para o Office SharePoint Server 2007 e o SharePoint Server 2010, consulte a
seo a seguir, mais adiante neste artigo:
12

Principais diferenas: SharePoint Server 2010 versus Office SharePoint Server 2007
Para obter informaes sobre consideraes de atualizao mais gerais e como planejar
e executar uma atualizao do Office SharePoint Server 2007, consulte o artigo a seguir:
Upgrading to SharePoint Server 2010

Ajustando e otimizando um ambiente de produo baseado no


SharePoint
Implantei o SharePoint Server 2010 e desejo ter certeza de que possuo o hardware e a
topologia apropriados. Como validar minha arquitetura e fazer a devida manuteno?
Para obter informaes sobre contadores de monitoramento e desempenho para farms
do Microsoft SharePoint Server 2010, consulte o seguinte artigo:
Monitorando e mantendo o SharePoint Server 2010
Para obter informaes sobre como usar as ferramentas de monitoramento de
integridade internas da interface da Administrao Central, consulte o seguinte artigo:
Health Monitoring (SharePoint Server 2010)
Implantei o SharePoint Server 2010 e estou tendo problemas de desempenho. Como
solucionar os problemas e otimizar meu ambiente?
Para obter informaes sobre contadores de monitoramento e desempenho para farms
do Microsoft SharePoint Server 2010, consulte o seguinte artigo:
Monitorando e mantendo o SharePoint Server 2010
Para obter informaes sobre como solucionar problemas usando as ferramentas de
monitoramento de integridade internas da interface da Administrao Central, consulte o
seguinte artigo:
Solving Problems and Troubleshooting (SharePoint Server 2010)
Para obter uma lista de artigos de gerenciamento de capacidade disponveis para vrios
servios e recursos especficos do SharePoint Server 2010 (mais artigos sero
adicionados quando forem disponibilizados), consulte o seguinte artigo:
Recomendaes e resultados de testes de desempenho e capacidade (SharePoint
Server 2010)
Para obter informaes sobre dimensionamento e desempenho, consulte o seguinte
artigo:
Planejamento e configurao de armazenamento e capacidade do SQL Server
(SharePoint Server 2010)
Para obter informaes sobre o RBS (Remote BLOB Storage), consulte o seguinte
artigo:
Plan for remote BLOB storage (RBS) (SharePoint Server 2010)

O comeo do fim
Quero saber tudo sobre o gerenciamento de capacidade do SharePoint Server 2010. Por
onde comear?
Para obter informaes sobre os conceitos gerais por detrs do gerenciamento de
capacidade e links para a documentao e recursos adicionais, consulte o seguinte
artigo:
Gerenciamento de desempenho e capacidade (SharePoint Server 2010)

13

Para obter informaes adicionais sobre gerenciamento de capacidade, consulte os


seguintes artigos complementares a este artigo de viso geral:
Planejamento de capacidade para SharePoint Server 2010

Testes de desempenho para SharePoint Server 2010

Monitorando e mantendo o SharePoint Server 2010


Agora, voc deve ter boas noes bsicas sobre os conceitos. Para obter informaes
sobre os limites do SharePoint Server 2010, consulte o seguinte artigo:
Gerenciamento de capacidade do SharePoint Server 2010: limites de software
Quando estiver pronto para identificar uma topologia inicial para o seu ambiente baseado
no SharePoint Server 2010, voc poder consultar a biblioteca de estudos de casos
tcnicos para encontrar aquele que mais corresponde aos seus requisitos. Para obter
uma lista de estudos de caso (mais estudos de caso sero adicionados quando forem
disponibilizados), consulte o seguinte artigo:
Performance and capacity technical case studies (SharePoint Server 2010) (em
ingls)
Para obter uma lista de artigos de gerenciamento de capacidade disponveis para vrios
servios e recursos especficos do SharePoint Server 2010 (mais artigos sero
adicionados quando forem disponibilizados), consulte o seguinte artigo:
Recomendaes e resultados de testes de desempenho e capacidade (SharePoint
Server 2010)
Para obter informaes sobre dimensionamento e desempenho, consulte o seguinte
artigo:
Planejamento e configurao de armazenamento e capacidade do SQL Server
(SharePoint Server 2010)
Para obter informaes sobre o RBS (Remote BLOB Storage), consulte o seguinte
artigo:
Plan for remote BLOB storage (RBS) (SharePoint Server 2010)
Para obter informaes sobre o monitoramento da integridade e como solucionar
problemas usando as ferramentas de monitoramento de integridade internas da interface
da Administrao Central, consulte o seguinte artigo:
Health Monitoring (SharePoint Server 2010)
Solving Problems and Troubleshooting (SharePoint Server 2010)
Para obter informaes sobre as diretrizes de ajuste fino do desempenho geral e uma
variedade de assuntos de desempenho e capacidade especficos (mais artigos sero
adicionados quando forem disponibilizados), consulte o seguinte artigo:
Use search administration reports (SharePoint Server 2010)
Para obter mais informaes sobre como virtualizar servidores baseados no SharePoint
Server 2010, consulte o seguinte artigo:
Virtualization planning (SharePoint Server 2010)

Quatro fundamentos de desempenho


O planejamento da capacidade tem como foco estes quatro principais aspectos do
dimensionamento da sua soluo:
14

Latncia Para fins de gerenciamento de capacidade, a latncia definida como a


durao entre o momento em que um usurio inicia uma ao, como clicar em um
hiperlink, e o momento at que o ltimo byte transmitido ao aplicativo cliente ou
navegador da Web.

Taxa de transferncia A taxa de transferncia definida como o nmero de


solicitaes simultneas que um servidor ou farm de servidores pode processar.

Escala de dados A Escala de dados definida como o tamanho total dos dados e
do contedo que o sistema pode hospedar. A estrutura e a distribuio de bancos de
dados de contedo tem um efeito significativo no tempo que o sistema leva para
processar solicitaes (latncia) e o nmero de solicitaes simultneas que ele
pode servir (taxa de transferncia).

Legibilidade A legibilidade uma medida da capacidade do sistema de cumprir os


objetivos definidos para a latncia e a taxa de transferncia ao longo do tempo.
O principal objetivo do gerenciamento da capacidade do seu ambiente estabelecer e
manter um sistema que atenda aos objetivos de latncia, taxa de transferncia, Escala
de dados e confiabilidade da sua organizao.

Latncia
A Latncia, tambm conhecida como latncia percebida pelo usurio final, composta
por trs componentes principais:
O tempo que leva para o servidor receber e processar a solicitao.

O tempo que leva para a solicitao e a resposta do servidor serem transferidas pela
rede.

O tempo que leva para a resposta ser renderizada no aplicativo cliente.


Organizaes diferentes definem objetivos de latncia diferentes com base em requisitos
de negcios e expectativas do usurio. Algumas organizaes aceitam latncia de vrios
segundos, enquanto outras exigem transaes muito rpidas. A otimizao de
transaes muito rpidas normalmente muito cara e requer clientes e servidores mais
poderosos, verses mais recentes de navegadores e de aplicativos clientes, solues de
rede com grande largura de banda e, possivelmente, investimentos em desenvolvimento
e ajuste fino de pginas.
Alguns fatores principais que contribuem para latncias mais longas percebidas pelo
usurio final, bem como exemplos de alguns problemas comuns, esto descritos na lista
a seguir. Esses fatores so especialmente relevantes em cenrios nos quais os clientes
esto geograficamente distantes do farm de servidores ou esto acessando o farm por
uma conexo de rede com pouca largura de banda.
Recursos, servios ou parmetros de configurao que no estejam otimizados
podem atrasar o processamento de solicitaes e a latncia de impacto para clientes
remotos e locais. Para obter mais informaes, consulte Taxa de
transfernciaConfiabilidade, mais adiante neste documento.

Pginas da Web que geram solicitaes desnecessrias ao servidor para o


download de dados e recursos necessrios. A otimizao incluiria baixar o nmero
mnimo de recursos para desenhar uma pgina, reduzindo o tamanho das imagens,
armazenando os recursos estticos em pastas que permitam o acesso annimo,
clusterizando solicitaes e permitindo a interatividade de pgina enquanto recursos
so baixados assincronamente do servidor. Essas otimizaes so importantes para
a obteno de uma experincia de navegador de primeira visita aceitvel.
15

O volume excessivo de dados transmitidos pela rede contribui para a degradao da


latncia e da taxa de transferncia. Por exemplo, quando possvel, as imagens e
outros objetos em uma pgina devem usar um formato compactado, como .png ou
.jpg, em vez de bitmaps.

Pginas de Web que no so otimizadas para cargas de pgina de segundo acesso.


O PLT (tempo de carregamento da pgina) aprimora os carregamentos de pgina no
segundo acesso porque alguns recursos de pgina so armazenados em cache no
cliente, e o navegador s precisa baixar o contedo dinmico que no est
armazenado em cache. Latncias de carregamento de pgina em segundo acesso
inaceitveis quase sempre so causadas por configurao incorreta do cache BLOB
(Binary Large Object) ou porque o cache do navegador est desabilitado em
computadores clientes. As otimizaes incluiriam o armazenamento em cache
correto dos recursos no cliente.

Pginas da Web com cdigo JavaScript personalizado no otimizado. Isso pode


tornar a renderizao da pgina no cliente mais lenta. A otimizao poderia atrasar o
processamento de JavaScript no cliente at que o resto da pgina fosse carregado
e, preferencialmente, chamando scripts em vez da adio de JavaScript embutido.

Taxa de transferncia
Taxa de transferncia descrita pelo nmero de solicitaes que um farm de servidores
pode processar em uma unidade de tempo e tambm costuma ser usada para medir a
escala de operaes que se espera que o sistema mantenha com base no tamanho da
organizao e de suas caractersticas de uso. Todas as operaes tm um custo
especfico em recursos do farm de servidores. Compreender a demanda e implantar
uma arquitetura de farm que possa satisfazer consistentemente a demanda exige a
estimativa da carga esperada e o teste da arquitetura sob carga para validar se essa
latncia no estar abaixo do esperado quando a simultaneidade for alta e o sistema
estiver sob stress.
Alguns exemplos comuns de condies de baixa taxa de transferncia incluem:
Recursos de hardware inadequados Quando o farm recebe mais solicitaes do
que pode processar simultaneamente, algumas solicitaes so enfileiradas, o que
atrasa cumulativamente o processamento de cada solicitao subsequente at que
a demanda seja reduzida o suficiente para que a fila seja limpa. Alguns exemplos de
otimizao de um farm para sustentar a taxa de transferncia mais alta incluem:

Garantir que os processadores em servidores do farm no sejam


sobrecarregados. Por exemplo, se o uso de CPU durante os horrios de pico ou
de picos de carga exceder consistentemente 80%, adicione mais servidores ou
redistribua os servios para outros servidores do farm.

Verifique se h memria suficiente em servidores e aplicativos e servidores Web


para conter o cache completo. Isso ajudar a evitar chamadas ao banco de
dados para servir solicitaes de contedo no armazenado em cache.

Verifique se os servidores de banco de dados esto livres de afunilamentos. Se


o total de IOPS de disco disponvel for insuficiente para oferecer suporte
demanda de pico, adicione mais discos ou redistribua os bancos de dados para
discos subutilizados. Consulte a seo Removendo afunilamentos, do artigo de
monitoramento e manuteno dos Produtos e Tecnologias do SharePoint Server
2010, para obter mais informaes.
16

Se a adio de recursos a computadores existentes for insuficiente para resolver


problemas de taxa de transferncia, adicione servidores e redistribua os
recursos e servios afetados aos novos servidores.

Pginas da Web personalizadas no otimizadas A adio de cdigo


personalizado a pginas usadas com frequncia em um ambiente de produo
uma causa comum de problemas de taxa de transferncia. A adio de cdigo
personalizado pode gerar viagens de ida e volta adicionais aos servidores de banco
de dados ou servios Web para servir solicitaes de dados. A personalizao de
pginas usadas com pouca frequncia pode no causar um impacto significativo na
taxa de transferncia, mas o cdigo bem otimizado pode diminuir a taxa de
transferncia do farm se for solicitado milhares de vezes ao dia. Os administradores
do SharePoint Server podem habilitar o Painel de Desenvolvimento para identificar
cdigo personalizado que requer otimizao. Alguns exemplos de otimizao de
cdigo personalizado incluem:

Minimizar o nmero de solicitaes ao servio Web e consultas SQL.

Busque o mnimo necessrio dos dados em cada viagem ao servidor de banco


de dados, minimizando o nmero de viagens de ida e volta necessrias.

Evite a adio de cdigo personalizado a pginas usadas com frequncia.

Use ndices quando estiver recuperando uma quantidade de dados filtrada.

Solues no confiveis A implantao de cdigo personalizado em pastas bin


pode fazer com que o desempenho do servidor fique lento. Sempre que uma pgina
com cdigo no confivel for solicitada, o SharePoint Server 2010 dever executar
verificaes de segurana antes que ela possa ser carregada. A menos que haja um
motivo especfico para a implantao de cdigo no confivel, instale assemblies
personalizados no GAC para evitar a verificao de segurana desnecessria.

Escala de dados
Escala de dados o volume de dados que o servidor ou o farm de servidores pode
armazenar atendendo aos objetivos de latncia e taxa de transferncia. Geralmente,
quanto maior o volume de dados do farm, maior o impacto na taxa de transferncia e na
experincia do usurio gerais. O mtodo usado para distribuir dados nos discos e
servidores de banco de dados tambm pode afetar a latncia e a taxa de transferncia
do farm.
Dimensionamento de banco de dados, arquitetura de dados e hardware de servidor de
banco de dados suficiente so muito importantes para uma soluo de banco de dados
ideal. Em uma implantao ideal, os bancos de dados de contedo so dimensionados
de acordo com orientao de limites e so distribudos por discos fsicos para que as
solicitaes no sejam enfileiradas por causa do sobrecarregamento de disco, e os
servidores de banco de dados so capazes de oferecer suporte a cargas de pico e picos
inesperados sem excederem os limites de utilizao de recursos.
Alm disso, determinadas operaes podem bloquear determinadas tabelas durante a
operao. Um exemplo disso uma grande excluso de site, que pode fazer com que
tabelas relacionadas no banco de dados de contedo onde reside o site sejam
bloqueadas at que a operao de excluso seja concluda.
Alguns exemplos de otimizao de um farm para obteno de melhor desempenho de
dados e de armazenamento incluem:

17

Verificar se os bancos de dados esto distribudos adequadamente pelos servidores


de banco de dados e se os recursos de servidor de banco de dados so suficientes
para oferecer suporte ao volume e distribuio de dados.

Volumes de banco de dados separados em LUNs (unidades lgicas exclusivas),


consistindo em eixos de disco fsico exclusivos. Use vrios discos com baixo tempo
de busca e configuraes de RAID apropriadas para satisfazer demandas de
armazenamento de servidor de banco de dados.

Voc pode usar o RBS (Remote BLOB Storage) se o tamanho total contiver vrios
BLOBS (Binary Large Objects). O RBS pode oferecer os seguintes benefcios:

Dados BLOB podem ser armazenados em dispositivos de armazenamento mais


baratos, que so configurados para administrar o armazenamento simples.

A administrao do repositrio BLOB controlada por um sistema projetado


especificamente para trabalhar com dados BLOB.

Os recursos do servidor de banco de dados so liberados para operaes de


banco de dados.
Esses benefcios no so gratuitos. Antes de implementar o RBS com o
SharePoint Server 2010, voc deve avaliar se esses benefcios potenciais
superam os custos e as limitaes da implementao e manuteno do RBS.
Para obter mais informaes, consulte Plan for remote BLOB storage (RBS)
(SharePoint Server 2010).
Para obter informaes sobre como planejar a escala de dados, consulte Planejamento
e configurao de armazenamento e capacidade do SQL Server (SharePoint Server
2010).

Confiabilidade
Confiabilidade a medida agregada da capacidade do farm de servidores de atender
aos objetivos de latncia, taxa de transferncia e capacidade de dados estabelecidos
com o passar do tempo. Um farm confivel aquele para o qual o tempo de ativao, a
capacidade de resposta, a taxa de falha e a frequncia e amplitude de picos de latncia
esto dentro dos objetivos e requisitos operacionais estabelecidos. Um farm confivel
tambm pode manter consistentemente os objetivos de latncia e taxa de transferncia
durante a carga de pico e o horrio de pico, ou quando ocorrem operaes do sistema,
como rastreamento ou backups dirios.
Um fator fundamental na sustentao da confiabilidade o efeito de operaes
administrativas comuns sobre os objetivos de desempenho. Durante determinadas
operaes, como a recriao de ndices de banco de dados, a manuteno de trabalhos
de timer ou a excluso de vrios sites com um grande volume de contedo, o sistema
pode ser incapaz de processar solicitaes do usurio com rapidez. Nesse caso, a
latncia e a taxa de transferncia de solicitaes do usurio final podem ser afetadas. O
impacto no farm depende da frequncia e do custo de transao dessas operaes
menos comuns e se elas so executadas durante o horrio normal de operao.
Alguns exemplos de como manter o sistema confivel incluem:
Agendar trabalhos de timer de uso intenso de recursos e tarefas administrativas para
os horrios que no sejam de pico.

Aumentar a escala de hardware em servidores de farm existentes ou expandir


adicionando servidores Web, servidores de aplicativos ou servidores de banco de
dados adicionais.
18

Distribuir os servios e recursos de uso intenso para servidores dedicados. Voc


tambm pode usar um balanceador de carga de hardware para direcionar o trfego
especfico de recurso para um servidor Web dedicado a recursos ou servios
especficos.

Gerenciamento de capacidade versus


planejamento de capacidade
O gerenciamento de capacidade amplia o conceito de planejamento de capacidade para
expressar a abordagem cclica em que a capacidade de uma implantao do SharePoint
Server 2010 continuamente monitorada e otimizada para acomodar as condies e os
requisitos em constante transformao.
O SharePoint Server 2010 oferece maior flexibilidade e pode ser configurado para
manter cenrios de uso em uma ampla variedade de pontos de escala diferentes. No
h uma nica arquitetura de implantao. Dessa forma, os designers de sistema e
administradores devem compreender os requisitos de seus ambientes especficos.

Modelo de gerenciamento de capacidade do SharePoint Server 2010

19

Etapa 1: Modelo Modelagem o processo pelo qual voc decide as solues


fundamentais para as quais deseja que seu ambiente oferea suporte e estabelece
todas as mtricas e parmetros importantes. A sada do exerccio de modelagem
deve ser uma lista de todos os dados fundamentais de que voc precisa para
projetar seu ambiente.

Compreenda a carga de trabalho e o conjunto de dados esperados.


20

Defina objetivos de desempenho e confiabilidade do farm.

Analise os logs do IIS do SharePoint Server 2010.

Etapa 2: Design Depois de coletar os dados na Etapa 1, voc poder projetar seu
farm. As sadas so a arquitetura de dados e as topologias fsicas e lgicas.

Determine sua arquitetura de ponto de partida.

Selecione seu hardware.

Etapa 3: Piloto, teste e otimizao Se voc projetou uma nova implantao,


precisa implantar um ambiente piloto para testar suas caractersticas de carga de
trabalho e uso esperado. Para um farm existente, os testes so aconselhveis
quando grandes alteraes estiverem sendo feitas na infraestrutura, mas a
otimizao regular baseada em resultados de monitoramento pode ser necessria
para manter os objetivos de desempenho. A sada desta fase a anlise dos
resultados de teste em relao aos objetivos e uma arquitetura otimizada capaz de
manter os objetivos de desempenho e capacidade estabelecidos.

Piloto Implante um ambiente piloto.

Teste Teste em relao aos objetivos de latncia e taxa de transferncia.

Otimizao Obtenha os resultados do teste e faa qualquer alterao


necessria nos recursos e na topologia do farm.

Etapa 4: Implantao Esta etapa descreve a implementao do farm, ou a


implantao de alteraes em um farm existente. A sada para um novo design
uma implantao concluda em produo, incluindo todas as migraes de contedo
e de usurios. A sada para um farm existente so mapas do farm revisados e
atualizaes feitas nos planos de manuteno.

Etapa 5: Monitoramento e manuteno Esta etapa descreve como configurar o


monitoramento e como prever e identificar afunilamentos e executar atividades
regulares de manuteno e reduo de afunilamentos.

Superdimensionamento versus
subdimensionamento
Superdimensionamento descreve uma abordagem ao design do farm na qual os
objetivos so atingidos sem a utilizao total de hardware, e os recursos do farm do
SharePoint Server so significativa e consistentemente subutilizados. Em uma
implantao superdimensionada, memria, CPU e outros indicadores dos recursos do
farm mostram que ele pode servir bem demanda com menos recursos. A desvantagem
do superdimensionamento so os maiores gastos em hardware e manuteno e o fato
de ela poder impor grandes demandas de energia e de espao.
Subdimensionamento descreve uma abordagem ao design do farm na qual os objetivos
de desempenho e capacidade no podem ser atingidos porque os recursos de hardware
no farm do SharePoint Server so utilizados em excesso. O subdimensionamento de um
farm feito algumas vezes para reduzir custos de hardware, mas geralmente resulta em
alta latncia, o que resulta em uma experincia de usurio insuficiente, baixa satisfao,
escalonamentos frequentes, altos custos de suporte e gastos desnecessrios com
soluo de problemas e ajustes finos do ambiente.

21

Ao projetar seu farm, verifique se ele pode atender aos objetivos de desempenho e de
capacidade estabelecidos, tanto sob cargas de pico regulares como para picos
inesperados. O design, os testes e a otimizao ajudaro voc a garantir que o seu farm
tenha o hardware correto.
Para manter os objetivos de desempenho e acomodar o crescimento, sempre mais
desejvel ter mais recursos do que o necessrio para atingir seus objetivos. O custo do
investimento em excesso em hardware geralmente menor do que as despesas
acumuladas em relao soluo de problemas causados pelo subdimensionamento.
Sempre dimensione um sistema para responder adequadamente durante a demanda de
pico, que pode ser diferente para servios especficos em ocasies especficas. Para
estimar com eficincia os requisitos de capacidade, voc precisa identificar o pior caso
de perodo de demanda para todos os recursos.
O farm tambm deve ser capaz de oferecer suporte a picos inesperados, como quando
anncios so feitos em toda a organizao e um nmero inesperadamente grande de
usurios acessa um site ao mesmo tempo. Durante esses perodos de alta demanda, os
usurios experimentaro alta latncia e no obtero a resposta do farm, a menos que
haja recursos de farm suficientes para satisfazer a carga maior no farm.
A capacidade do farm tambm deve ser revisitada quando usurios adicionais forem
provisionados na empresa. Situaes como uma fuso ou aquisio, caracterizadas por
novos funcionrios ou membros acessando o farm, podem ter efeitos negativos sobre o
desempenho se no forem planejadas ou estimadas com antecedncia.

Zonas operacionais: Zona Verde e Zona Vermelha


Quando descrevemos a carga de um sistema de produo, nos referimos a dois estados
operacionais principais: o estado de "Zona Verde", no qual o sistema est operando sob
o intervalo de carga normal e esperado, e o estado de "Zona Vermelha", que um
estado no qual o farm experimenta muitas demandas transitrias de recursos, que s
podem ser mantidas por perodos limitados at que haja falhas e outros problemas de
desempenho e de confiabilidade.
Zona Verde o estado no qual o servidor ou farm est operando sob condies de
carga normais, at as cargas de pico dirias esperadas. Um farm operando nesse
intervalo deve ser capaz de manter tempos de resposta e latncia nos parmetros
aceitveis.
Zona Vermelha O intervalo de operao no qual a carga maior do que a carga de
pico normal, mas ainda possvel servir solicitaes por um perodo limitado. Esse
estado caracterizado por latncia maior do que o normal e possveis falhas causadas
pela saturao de afunilamentos do sistema.
O principal objetivo do design de farm implantar um ambiente que possa oferecer
suporte consistentemente carga da Zona Vermelha sem um falha no servio e dentro
dos objetivos de latncia e taxa de transferncia.

Limites e delimitadores de software


No SharePoint Server 2010, h determinados limites que, por design, no podem ser
excedidos e outros limites definidos como valores padro que podem ser alterados pelo
administrador do farm. H tambm certos limites que no so representados por um
valor configurvel, como o nmero de conjuntos de sites por aplicativo Web.

22

Delimitadores so limites absolutos que no podem ser excedidos por padro.


importante entend-los para garantir que voc no faa pressuposies incorretas ao
projetar seu farm.
Um exemplo de delimitador o limite de tamanho do documento de 2 GB. No
possvel configurar o SharePoint Server 2010 para armazenar documentos com mais de
2 GB. Esse um valor absoluto interno que no pode ser excedido por padro.
Limites so aqueles que possuem um valor padro que no pode ser excedido, a menos
que o valor seja modificado. Em determinadas circunstncias, limites podem ser
excedidos para acomodar variaes no design do farm. Entretanto, importante
entender que isso pode afetar o desempenho do farm, alm do valor efetivo de outros
limites.
O valor padro de certos limites s pode ser excedido at um valor mximo absoluto.
Um bom exemplo disso novamente o limite de tamanho de documento. Por padro, o
limite de tamanho de documento definido como 50 MB, mas pode ser alterado para dar
suporte ao valor mximo de 2 GB.
Limites com suporte definem o valor testado para um determinado parmetro. Os valores
padro para esses limites foram definidos por meio de testes e representam as
limitaes conhecidas do produto. Se os limites com suporte forem excedidos, isso
poder causar resultados inesperados, prejudicar o desempenho de maneira significativa
ou provocar outros efeitos nocivos.
Alguns limites com suporte so os parmetros configurveis definidos por padro como
o valor recomendado, enquanto outros limites esto relacionados a parmetros que no
so representados por um valor configurvel.
Um exemplo de limite com suporte o nmero de conjuntos de sites por aplicativo Web.
O limite com suporte de 500.000, que o maior nmero de conjuntos de sites por
aplicativo Web que atenderam aos parmetros de comparao durante os testes.
importante observar que muitos dos valores limites fornecidos neste documento
representam um ponto em uma curva que descreve uma carga crescente de recursos e
a consequente degradao no desempenho medida que o valor aumenta. Portanto, se
forem excedidos determinados limites, como o nmero de conjuntos de sites por
aplicativo Web, isso poder resultar apenas em uma reduo fracionria no desempenho
do farm. No entanto, na maioria dos casos, operar em um limite estabelecido ou prximo
a ele no uma prtica recomendada, pois as metas de desempenho e confiabilidade
aceitveis so alcanadas mais facilmente quando o design de um farm possibilita um
equilbrio razovel dos valores limites.
Limites e diretrizes de limites com suporte so determinados pelo desempenho. Em
outras palavras, voc pode exceder os valores padro dos limites, mas, medida que
aumentar o valor limite, o desempenho do farm e o valor efetivo de outros limites
podero ser afetados. Muitos limites no SharePoint Server 2010 podem ser alterados.
No entanto, importante entender como a alterao de um determinado limite afeta
outras partes do farm.
Se voc contatar o Servio de Atendimento ao Cliente Microsoft sobre um sistema de
produo que no atende s especificaes mnimas de hardware publicadas como
descrito em Hardware and software requirements (SharePoint Server 2010), o suporte
ser limitado at que o sistema seja atualizado para os requisitos mnimos.

Como limites so estabelecidos


No SharePoint Server 2010, limites e limites com suporte so estabelecidos por meio de
testes e da observao do comportamento do farm sob cargas crescentes, at o ponto
23

em que os servios e as operaes do farm atingirem seus limites operacionais efetivos.


Alguns servios e componentes do farm podem dar suporte a uma carga maior do que
outros. Dessa forma, em alguns casos, voc deve atribuir um valor limite com base na
mdia de vrios fatores.
Por exemplo, as observaes sobre o comportamento do farm sob carga quando
conjuntos de sites so adicionados indicam que certos recursos apresentam latncia
inaceitavelmente alta, enquanto outros recursos ainda esto operando dentro dos
parmetros aceitveis. Portanto, o valor mximo atribudo ao nmero de conjuntos de
sites no absoluto, sendo calculado com base em um conjunto esperado de
caractersticas de uso em que o desempenho geral do farm seria aceitvel dentro do
limite especfico na maioria das circunstncias.
Se outros servios estiverem operando de acordo com parmetros que sejam mais
elevados do que aqueles usados para testar os limites, os limites mximos efetivos de
outros servios sero reduzidos. Assim, importante executar um gerenciamento
rigoroso da capacidade e dimensionar os exerccios de testes para implantaes
especficas, de forma a estabelecer limites efetivos para esse ambiente.
Para obter mais informaes sobre delimitadores e limites e como eles afetam o
processo de gerenciamento de capacidade, consulte Gerenciamento de capacidade do
SharePoint Server 2010: limites de software.

Principais diferenas: SharePoint Server 2010


versus Office SharePoint Server 2007
O SharePoint Server 2010 oferece um conjunto de recursos mais valioso e um modelo
de topologia mais flexvel do que as verses anteriores. Antes de usar essa arquitetura
mais complexa para oferecer recursos e funcionalidade mais poderosos aos seus
usurios, considere com cuidado seus efeitos na capacidade e no desempenho do farm.
No Office SharePoint Server 2007, existem quatro servios principais que podem ser
habilitados em SSPs (Provedores de Servios Compartilhados): Servio de Pesquisa,
Servio de Clculo do Excel, Servio de Perfil de Usurio e Servio de Catlogo de
Dados Corporativos. Adicionalmente, existe um conjunto de clientes relativamente menor
que pode fazer interface diretamente com o Office SharePoint Server 2007.
No SharePoint Server 2010, h mais servios disponveis, conhecidos como SSAs
(Aplicativos de Servio do SharePoint), e o SharePoint Server 2010 oferece uma
variedade muito maior de aplicativos clientes que podem interagir com o farm, incluindo
vrios aplicativos novos do Office, dispositivos mveis, ferramentas de designer e
navegadores. Alguns exemplos de como interaes de clientes expandidas causam um
impacto nas consideraes de capacidade incluem:
O SharePoint Server 2010 inclui aplicativos sociais que se integram ao Outlook, o
que permite que os clientes do Outlook 2010 exibam informaes sobre destinatrios
de email que so extradas do farm do SharePoint Server quando mensagens de
email so visualizadas no cliente do Outlook. Isso introduz um novo conjunto de
padres de trfego e de carga de servidor que deve ser levado em considerao.

Alguns novos recursos de clientes do Microsoft Office 2010 atualizam dados


automaticamente em relao ao farm do SharePoint Server, mesmo quando os
aplicativos clientes esto abertos, mas no esto sendo ativamente usados. Esses
clientes, como o SharePoint Workspace e o OneNote, tambm introduziro alguns
24

novos padres de trfego e de carga de servidor que devem ser levados em


considerao.

Os novos recursos de interatividade da Web do SharePoint Server 2010, como o


Office Web Apps, que permite a edio de arquivos do Office diretamente do
navegador, usam chamadas AJAX que introduzem alguns novos padres de trfego
e de carga de servidor que devem ser levados em considerao.
No Office SharePoint Server 2007, o cliente principal usado para interagir com o servidor
era o navegador da Web. Dado o conjunto de recursos mais sofisticado do SharePoint
Server 2010, espera-se um aumento nas solicitaes gerais por segundo (RPS). Alm
disso, espera-se que o percentual de solicitaes vindas do navegador seja menor do
que no Office SharePoint Server 2007, o que abre espao para o percentual crescente
de novo trfego vindo de outros clientes, uma vez que eles esto sendo amplamente
adotados na organizao.
Adicionalmente, o SharePoint Server 2010 apresenta nova funcionalidade, como o
suporte a vdeo inserido nativo, que pode adicionar stress ao farm. Algumas
funcionalidades tambm foram expandidas para oferecer suporte a uma escala maior do
que verses anteriores.
A seo a seguir descreve essas interaes de cliente, servios e recursos e suas
implicaes de desempenho e capacidade gerais no sistema que voc deve considerar
ao projetar sua soluo.
Para obter mais informaes sobre como atualizar para o SharePoint Server 2010,
consulte Upgrading to SharePoint Server 2010.

Servios e recursos
A tabela a seguir oferece uma descrio geral simplificada dos requisitos de recursos
para os diferentes servios em cada camada. As clulas em branco indicam que o
servio no executado naquela camada ou no causa impacto sobre ela.
X indica custo mnimo ou insignificante no recurso. O servio pode compartilhar esse
recurso com outros servios.
XX indica custo mdio no recurso. O servio poderia compartilhar esse recurso com
outros servios com impacto mnimo.
XXX indica alto custo no recurso. Geralmente, o servio no deve compartilhar esse
recurso com outros servios.
Para obter mais informaes sobre como planejar bancos de dados do SQL Server,
consulte Planejamento e configurao de armazenamento e capacidade do SQL Server
(SharePoint Server 2010).
Para obter uma lista de artigos de gerenciamento de capacidade disponveis para vrios
servios e recursos especficos do SharePoint Server 2010 (mais artigos sero
adicionados quando forem disponibilizados), consulte Recomendaes e resultados de
testes de desempenho e capacidade (SharePoint Server 2010).

Aplicativo de
Servio

CPU do
servidor
Web

RAM do CPU do
RAM do
CPU IOPS Armazenamento
servidor servidor
servidor de do
do
do SQL Server
Web
de
aplicativos: SQL SQL
aplicativos
Server Server

Servio do
SharePoint

XXX

XXX

XX
25

XXX XXX

Aplicativo de
Servio

CPU do
servidor
Web

RAM do CPU do
RAM do
CPU IOPS Armazenamento
servidor servidor
servidor de do
do
do SQL Server
Web
de
aplicativos: SQL SQL
aplicativos
Server Server

Foundation
XX

Servio da
Administrao
Central
Servio de Log * XX

XX

XX

XXX XXX

XXX

XXX

XXX

XXX

XX

XX

XXX

XX

XX
Servio de
Clculo do Excel

XX

XXX

Servio do Visio * X

XXX

XXX

XXX

XX

Servio de Perfil X
de Usurio

XX

XX

XX

XXX XXX XX

Servio de
Metadados
Gerenciados *

XX

XX

XX

Servio do Web
Analytics *

Servio de
Pesquisa do
SharePoint

XXX

XX

Aplicativo de
X
servio de
Exibio do Word
*
Servio
PowerPoint *

Servio do
Access *

XX

XXX XXX XXX

XX

XXX XXX XXX

XX
Servio de
Conectividade de
Dados
Corporativos *

XX

XXX

XXX

Servio do
InfoPath Forms

XX

XX

XX

XX

Servio de
Converso do
Word

XXX

XX

26

Aplicativo de
Servio

CPU do
servidor
Web

Aplicativo de
XX
Servio do
PerformancePoint
*

RAM do CPU do
RAM do
CPU IOPS Armazenamento
servidor servidor
servidor de do
do
do SQL Server
Web
de
aplicativos: SQL SQL
aplicativos
Server Server

XX

XXX

XXX

XXX XXX XX

Solues de rea X
Restrita *

XXX

XXX

Recursos de fluxo XXX


de trabalho *

XXX

Servio de Timer XX

XX

XX

XX

PowerPivot *

XXX

XXX

Servio do
Project *

XX

XX

XXX

Observao:
Um asterisco indica um novo servio no SharePoint Server 2010.

Servio do SharePoint Foundation O principal servio do SharePoint para


colaborao de contedo. Em grandes implantaes do SharePoint Server,
recomendamos que voc aloque servidores Web redundantes com base na carga de
trfego esperada, dimensione adequadamente os computadores baseados no SQL
Server que serviro os bancos de dados de contedo e aloque adequadamente o
armazenamento com base no tamanho do farm.

Servio da Administrao Central O servio de administrao. Esse servio tem


requisitos de capacidade relativamente pequenos. Recomendamos que voc o
habilite em vrios servidores do farm para garantir a redundncia.

Servio de Log O servio que registra os indicadores de uso e integridade para


fins de monitoramento. um servio de gravao intensa e pode exigir um espao
em disco relativamente grande, dependendo do nmero de indicadores e da
frequncia com que so registrados em log. Em grandes implantaes do
SharePoint Server 2010, recomendamos que voc isole o banco de dados de uso
dos bancos de dados de contedo em computadores baseados no SQL Server
diferentes.

Aplicativo de Servio de Pesquisa do SharePoint O aplicativo de servio


compartilhado que oferece recursos de indexao e consulta. Geralmente, um
servio de uso relativamente intenso de recursos que pode ser dimensionado para
servir implantaes de contedo muito grandes. Em grandes implantaes do
SharePoint Server, em que a pesquisa empresarial muito importante,
27

recomendamos que voc use um "farm de servios" separado para hospedar


aplicativos de servio de pesquisa, com recursos de banco de dados dedicados, use
vrios servidores de aplicativos para servir funes de pesquisa especficas
(rastreamento ou consulta) e servidores Web de destino dedicados nos farms de
contedo para garantir uma taxa de transferncia aceitvel para rastreamento e
consulta. Voc tambm pode habilitar Aplicativos de Servio FAST como Aplicativo
de Servio de Pesquisa. Opte por criar um ou mais Conectores de Pesquisa FAST
para a indexao de contedo com o FAST Search Server 2010 for SharePoint e
crie outra SSA (Consulta de Pesquisa FAST) para consultar contedo rastreado
pelos Conectores de Pesquisa FAST.

Aplicativo de Servio de Exibio do Word A habilitao desse servio permite


que voc exiba documentos do Word diretamente do navegador. O servio
adicionando quando voc instala o Office Web Apps junto com o SharePoint Server
2010. Esse servio exige que um servidor de aplicativos prepare os arquivos
originais para a exibio em navegador. Em grandes implantaes do SharePoint
Server, recomendamos que voc expanda o servio em vrios servidores de
aplicativos para obter redundncia e taxa de transferncia.
Observao:
A edio em navegador para o Word e o OneNote estar habilitada quando voc instalar
o Office Web Apps no farm do SharePoint Server 2010. No entanto, esse recurso
executado nos servidores Web do farm e no usa qualquer aplicativo de servio.

Aplicativo de Servio do PowerPoint Esse servio exibe e permite que os


usurios editem arquivos do PowerPoint diretamente no navegador, alm de permitir
que voc transmita e compartilhe apresentaes do PowerPoint ao vivo. Esse
servio adicionado quando voc instala o Office Web Apps no SharePoint Server
2010. Ele exige que um servidor de aplicativos prepare os arquivos originais para a
exibio em navegador. Em grandes implantaes do SharePoint Server, nas quais
ele se tornar um recurso de uso frequente, recomendamos que voc implante vrios
servidores de aplicativos para garantir redundncia e taxa de transferncia
aceitveis e adicione mais servidores Web quando a Transmisso do PowerPoint
tambm for usada com frequncia.

Aplicativo de Servio de Clculo do Excel Esse servio exibe planilhas do Excel


diretamente no navegador e executa clculos do Excel no servidor. Tambm habilita
a edio de planilhas diretamente do navegador quando voc instala o Office Web
Apps no SharePoint Server 2010. Em grandes implantaes do SharePoint Server,
nas quais ele se tornar um recurso de uso frequente, recomendamos que voc
aloque um nmero suficiente de servidores de aplicativos com RAM suficiente para
garantir desempenho e taxa de transferncia aceitveis.

PowerPivot para SharePoint O servio para exibir planilhas habilitadas para


PowerPivot do Excel diretamente no navegador. Em grandes implantaes do
SharePoint Server, nas quais ele se tornar um recurso de uso frequente,
recomendamos que voc aloque um nmero suficiente de servidores de aplicativos
com RAM e CPU suficientes para garantir desempenho e taxa de transferncia
aceitveis. Para obter mais informaes, consulte o artigo sobre requisitos de
hardware e software (PowerPivot para SharePoint).
28

Aplicativo de Servio do Visio O servio para exibir diagramas dinmicos do


Visio diretamente no navegador. Esse servio tem uma dependncia do Aplicativo
de Servio de Controle de Sesso, que exige um banco de dados do SQL Server
relativamente pequeno. O servio do Visio exige que um servidor de aplicativos
prepare os arquivos originais do Visio para a exibio em navegador. Em grandes
implantaes do SharePoint Server, nas quais ele se tornar um recurso de uso
frequente, recomendamos que voc expanda o servio para vrios servidores de
aplicativos com CPU e RAM suficientes para garantir desempenho e taxa de
transferncia aceitveis.

Aplicativo de Servio do Access O servio para hospedar solues do Access no


SharePoint Server 2010. Em grandes implantaes do SharePoint Server, nas quais
ele se tornar um recurso de uso frequente, recomendamos que voc expanda o
servio para vrios servidores de aplicativos com RAM suficiente para desempenho
e taxa de transferncia aceitveis. O servio do Access usa Reporting Services
SQL, o que exigir um banco de dados do SQL Server que possa ser co-localizado
com outros bancos de dados.

Aplicativo de Servio de Perfil de Usurio O servio que impulsiona os cenrios


sociais no SharePoint Server 2010 e que habilita Meus Sites, Marcao, Notas e
sincronizao de Perfis com diretrios e outros recursos sociais. O servio de perfil
exige trs bancos de dados de uso relativamente intensivo: os bancos de dados de
sincronizao, de Perfil e de Marcao Social. Esse servio dependente do
Servio de Metadados Gerenciados. Em grandes implantaes do SharePoint
Server, considere a distribuio desse servio por um farm de servios
compartilhados e dimensione corretamente a camada de servidor de banco de
dados para garantir desempenho aceitvel das transaes comuns e de trabalhos
de sincronizao de diretrios.

Aplicativo de Servio de Metadados Gerenciados O servio que impulsiona o


repositrio central de metadados e que permite a sindicalizao de tipos de
contedo na empresa. O servio pode ser federado para um farm de servios
dedicados. Requer um banco de dados que pode ser co-localizado com outros
bancos de dados.

Aplicativo de Servio do Web Analytics O servio que agrega e armazena


estatsticas sobre caractersticas de uso do farm. Esse servio tem demandas
relativamente altas de recursos e armazenamento do SQL Server. O servio pode
ser federado para um farm de servios dedicados. Em grandes implantaes do
SharePoint Server, recomendamos que voc isole os bancos de dados do Web
Analytics de outros bancos de dados muito importantes ou de uso intensivo de
recursos hospedando-os em servidores de banco de dados diferentes.

Aplicativo de Servio de Conexo de Dados Corporativos O servio que


permite a integrao de vrios aplicativos de linha de negcios organizacionais ao
SharePoint Server 2010. Esse servio exige que um aplicativo de servio mantenha
conexes de dados a recursos externos. Em grandes implantaes do SharePoint
Server, nas quais ele um recurso de uso frequente, recomendamos que voc
aloque um nmero suficiente de servidores de aplicativos que tenham RAM
suficiente para desempenho aceitvel.

Aplicativo de Servio do InfoPath Forms O servio que habilita formulrios


baseados em navegador no SharePoint Server 2010 e a integrao com o aplicativo
29

cliente do InfoPath para a criao de formulrios. Esse servio exige um servidor de


aplicativos e tem uma dependncia do Aplicativo de Servio de Controle de Sesso,
que exige um banco de dados relativamente pequeno. Esse servio pode ser colocalizado com outros servios e tem requisitos de capacidade relativamente
pequenos que podem crescer, dependendo da frequncia de uso desse recurso.

Aplicativo de Servio do Word Automation O servio que permite a converso


de arquivos do Word de um formato, como .doc, para outro formato, como .docx ou
.pdf. Esse servio exige um servidor de aplicativos. Em grandes implantaes do
SharePoint Server, nas quais ele se tornar um recurso de uso frequente,
recomendamos que voc expanda o servio para vrios servidores de aplicativos
com recursos de CPU suficientes para atingir a taxa de transferncia aceitvel. Esse
servio tambm exige um banco de dados relativamente pequeno para manter a fila
de trabalhos de converso.

Aplicativo de Servio do PerformancePoint O servio que habilita os recursos de


BI do PerformancePoint no SharePoint Server 2010 e permite que voc crie
visualizaes analticas. Esse servio exige um servidor de aplicativos e um banco
de dados. Em grandes implantaes do SharePoint Server, nas quais ele se tornar
um recurso de uso frequente, recomendamos que voc aloque RAM suficiente para
os servidores de aplicativos para obter desempenho e taxa de transferncia
aceitveis.

Aplicativo de Servio do Project O servio que habilita todos os recursos de


planejamento e controle do Microsoft Project Server 2010, alm do SharePoint
Server 2010. Esse servio exige um servidor de aplicativos e um banco de dados de
uso relativamente intenso. Em grandes implantaes do SharePoint Server, nas
quais ele se tornar um recurso de uso frequente, voc dever dedicar um servidor de
banco de dados para o banco de dados do Project Server e at mesmo considerar
um farm do SharePoint Server dedicado para as solues gerenciadas do Project
Server.

Servio de Timer O processo responsvel pela execuo de vrias tarefas


agendadas nos diferentes servidores do farm. Existem vrios trabalhos de timer
executados pelo sistema, alguns executados em todos os servidores, e alguns
executados somente em servidores especficos, dependendo da funo do servidor.
Alguns desses trabalhos de timer fazem uso intensivo de recursos e podem criar
carga no servidor local e nos servidores de banco de dados, dependendo da
atividade e de quanto contedo eles operam. Em grandes implantaes do
SharePoint Server, nas quais os trabalhos de timer causam potencialmente impacto
na latncia do usurio final, recomendamos que voc dedique um servidor para
isolar a execuo dos trabalhos mais intensivos.

Fluxo de Trabalho O recurso que habilita fluxos de trabalho integrados no


SharePoint Server 2010 e executa fluxos de trabalho no servidor Web. A utilizao
de recursos depende da complexidade dos fluxos de trabalho e do nmero total de
eventos com os quais eles lidam. Em grandes implantaes do SharePoint Server,
nas quais ele se tornar um recurso de uso frequente, voc dever considerar a
adio de servidores Web ou o isolamento de um servidor para manipular somente o
servio de timer do fluxo de trabalho de forma a garantir que o trfego de usurio
final no seja afetado e que as operaes de fluxo de trabalho no sejam atrasadas.
30

Solues de rea Restrita O servio que permite o isolamento de cdigo


personalizado para recursos dedicados do farm. Em grandes implantaes do
SharePoint Server, nas quais ele se tornar um recurso de uso frequente, voc
dever considerar a dedicao de servidores Web adicionais se o cdigo
personalizado comear a causar impacto no desempenho do servidor.

Novas interaes de aplicativos clientes com o SharePoint Server


2010
Esta seo descreve algumas das novas interaes entre cliente e servidor que tm
suporte no SharePoint Server 2010 e suas implicaes de planejamento e capacidade.
A tabela a seguir oferece uma descrio geral simplificada da carga tpica que esses
novos recursos introduzem no sistema:
X indica carga mnima ou insignificante nos recursos do sistema
XX indica carga mdia nos recursos do sistema
XXX indica carga alta nos recursos do sistema

Cliente

Trfego

Carga

Office Web Apps

XXX

XX

Transmisso do PowerPoint

XXX

Aplicativo cliente do Word e do


PowerPoint 2010

XX

Aplicativo cliente do OneNote

XXX

XXX

Outlook Social Connector

XX

XX

SharePoint Workspace

XXX

XX

Office Web Apps A exibio e edio na Web de arquivos do Word, PowerPoint,


Excel e OneNote um subconjunto de solicitaes de navegador, com
caractersticas de trfego ligeiramente diferentes, esse tipo de interao introduz
uma carga relativamente alta de trfego necessrio para habilitar recursos como a
coautoria. Em grandes implantaes do SharePoint Server, nas quais esses
recursos forem habilitados, voc dever esperar carga adicional nos servidores Web.

Transmisso do PowerPoint O conjunto de solicitaes associado exibio ao


vivo de apresentaes do PowerPoint em um navegador da Web outro
subconjunto de solicitaes de navegador. Durante sesses de transmisso ao vivo
do PowerPoint, os clientes participantes solicitam alteraes do servio. Em grandes
implantaes do SharePoint Server, nas quais ele for um recurso de uso frequente,
voc dever esperar carga adicional nos servidores Web.

Aplicativos clientes do Word e do PowerPoint 2010 Os clientes do Word e do


PowerPoint 2010 possuem novos recursos que aproveitam as vantagens do farm do
SharePoint Server. Um exemplo a coautoria de documentos, na qual todos os
aplicativos clientes que participam de uma sesso de coautoria carregam e baixam
atualizaes com frequncia para e do servidor. Em grandes implantaes do
31

SharePoint Server, nas quais ele for um recurso de uso frequente, voc dever
esperar carga adicional nos servidores Web.

Aplicativo cliente do OneNote 2010 O cliente do OneNote 2010 interage com o


farm do SharePoint Server de uma forma semelhante verso anterior do OneNote
e usa o SharePoint Server 2010 para compartilhar e habilitar a coautoria de blocos
de notas do OneNote. Esse cenrio introduz carga no SharePoint Server 2010,
mesmo quando o cliente est aberto, mas no est sendo ativamente usado. Em
grandes implantaes do SharePoint Server, nas quais ele for um recurso de uso
frequente, voc dever esperar carga adicional nos servidores Web.

Aplicativo cliente do Outlook 2010 O Outlook 2010 tem um novo recurso o


Outlook Social Connector que aproveita as vantagens do farm do SharePoint
Server (esse componente tambm pode ser adicionado a verses anteriores do
Outlook). Esse recurso permite que voc exiba atividade social solicitada do farm
SharePoint Server diretamente em emails. Em grandes implantaes do SharePoint
Server, nas quais esse recurso estiver habilitado, voc dever esperar carga
adicional nos servidores Web.

SharePoint Workspace Os clientes do SharePoint Workspace 2010 possuem


novos recursos que aproveitam as vantagens do farm do SharePoint Server e
permitem que voc sincronize sites, listas e bibliotecas de documentos para que o
cliente os utilize de forma offline. O SharePoint Workspace 2010 se sincroniza
regularmente com os objetos de servidor anexados quando o cliente est em
execuo, independentemente de estar sendo usado ativamente. Em grandes
implantaes do SharePoint Server, nas quais ele for um recurso de uso frequente,
voc dever esperar carga adicional nos servidores Web.

Diferenciadores de chave de implantao do


SharePoint Server 2010
Cada implantao do SharePoint Server 2010 tem um conjunto fundamental de
caractersticas que o tornaro exclusivo e diferente de outros farms. Esses
diferenciadores fundamentais podem ser descritos por estas quatro categorias principais:
Especificao Descreve o hardware do farm, alm de sua topologia e
configurao.

Carga de trabalho Descreve a demanda no farm, incluindo o nmero e as


caractersticas de uso.

Conjunto de dados Descreve os tamanhos e a distribuio de contedo.

Integridade e desempenho Descreve o desempenho do farm em relao a


objetivos de latncia e taxa de transferncia.

Especificaes
Hardware
Hardware so os recursos fsicos do computador, como processadores, memria e
discos rgidos. O hardware tambm inclui componentes fsicos de rede, como NICs
(placas de interface de rede), cabos, switches, roteadores e balanceadores de carga de
hardware. Muitos problemas de desempenho e de capacidade podem ser resolvidos
garantindo que o hardware correto seja usado. Por outro lado, um nico erro de
32

aplicao de recurso de hardware, como memria insuficiente em um servidor, pode


afetar o desempenho de todo o farm.
Topologia
A topologia a distribuio e os interrelacionamentos de hardware e componentes do
farm. Existem dois tipos de topologias:
Topologia lgica O mapa de componentes de software, como servios e recursos
de um farm.
Topologia fsica O mapa de servidores e recursos fsicos.
Normalmente, o nmero de usurios e de caractersticas de uso determinam a topologia
fsica de um farm, e requisitos de negcios, como a necessidade de suporte a recursos
especficos para cargas esperadas, orientam a topologia lgica
Configurao
Usamos o termo configurao para descrever configuraes de software e como os
parmetros so definidos. Alm disso, a configurao refere-se a cache, RBS, como os
limites configurveis so definidos e qualquer parte do ambiente de software que possa
ser definido ou modificado para atender a requisitos especficos.

Carga de trabalho
Carga de trabalho define as caractersticas operacionais fundamentais do farm, incluindo
a base de usurios, simultaneidade, recursos em uso e os agentes de usurio ou
aplicativos clientes usados para a conexo com o farm.
Recursos diferentes do SharePoint Server possuem custos associados diferentes nos
recursos do farm. A popularidade de recursos mais exigentes pode causar um impacto
potencialmente significativo no desempenho e na integridade do sistema. Compreender
a sua demanda esperada e as caractersticas de uso permitir que voc dimensione sua
implementao corretamente e reduza o risco de executar o sistema constantemente em
uma condio no ntegra.
Base de Usurios
A base de usurios de um aplicativo baseado no SharePoint Server uma combinao
de nmero total de usurios e como eles esto distribudos geograficamente. Alm
disso, na base de usurios total, existem subgrupos de usurios que podem usar
determinados recursos ou servios de forma mais intensa do que outros grupos. A
simultaneidade de usurios definida como o percentual total de usurios usando
ativamente o sistema em um determinado momento. Os indicadores que definem a base
de usurios incluem o nmero total de usurios exclusivos e o nmero de usurios
simultneos.
Caractersticas de Uso
O desempenho de um farm pode ser afetado no s pelo nmero de usurios
interagindo com o sistema, como tambm por suas caractersticas de uso. Duas
organizaes com o mesmo nmero de usurios podem ter requisitos significativamente
diferentes com base na frequncia em que os usurios acessam os recursos do farm e
se recursos e servios de uso intensivo esto habilitados no farm. Os indicadores que
descrevem as caractersticas de uso incluem a frequncia de operaes exclusivas, a
mistura operacional geral (a proporo entre operaes de leitura e gravao e de
operaes administrativas) e os padres de uso e carga em relao a novos recursos
habilitados no farm (como os sites Meu Site, Pesquisa Fluxos de Trabalho e o Office
Web Apps).
33

Conjunto de Dados
O volume de contedo armazenado no sistema e as caractersticas da arquitetura na
qual ele est armazenado podem ter um efeito significativo sobre a integridade e o
desempenho gerais do sistema. Compreender o tamanho, a frequncia de acesso e a
distribuio dos dados permitir que voc dimensione corretamente o armazenamento
no sistema e evite que ele se torne o afunilamento que atrasa interaes de usurios
com servios do farm, alm de afetar a experincia do usurio final.
Para estimar corretamente e projetar a arquitetura de armazenamento de uma soluo
baseada no SharePoint Server, voc precisa conhecer o volume de dados que
armazenar no sistema e quantos usurios esto solicitando dados de diferentes fontes
de dados. O volume do contedo um elemento importante da capacidade de
dimensionamento de disco, porque pode influenciar o desempenho de outros recursos,
alm de afetar potencialmente a latncia e a largura de banda disponvel da rede. Os
indicadores que definem o conjunto de dados incluem o tamanho total do contedo, o
nmero total de documentos, o nmero total de conjuntos de sites e os tamanhos mdio
e mximo do conjunto de sites.

Integridade e desempenho
A integridade do farm do SharePoint Server , basicamente, uma medida simplificada ou
pontuao que reflete a confiabilidade, a estabilidade e o desempenho do sistema. A
qualidade do desempenho do farm em relao aos objetivos depende basicamente dos
trs primeiros diferenciadores. A pontuao de integridade e desempenho pode ser
controlada e descrita por uma destilao de um conjunto de indicadores. Para obter mais
informaes, consulte Monitorando e mantendo o SharePoint Server 2010. Esses
indicadores incluem o tempo de ativao do sistema, a latncia percebida pelo usurio,
taxas de falha de pgina e os indicadores de utilizao de recursos (CPU, RAM).
Qualquer alterao significativa de hardware, topologia, configurao, carga de trabalho
ou conjunto de dados pode variar significativamente a confiabilidade e a capacidade de
resposta do sistema. A pontuao de integridade pode ser usada para controlar o
desempenho com o passar do tempo e para avaliar como as condies de operao em
alterao ou as modificaes do sistema afetam a confiabilidade do farm.

Arquiteturas de referncia
O SharePoint Server 2010 um produto complexo e poderoso, e no h uma soluo de
arquitetura de tamanho nico. Cada implantao do SharePoint Server exclusiva e
definida por suas caractersticas de uso e de dados. Todas as organizaes precisam
executar um processo completo de gerenciamento de capacidade e aproveitar
efetivamente as vantagens da flexibilidade que o sistema do SharePoint Server 2010
oferece para a personalizao de uma soluo dimensionada de forma correta que
atenda melhor s necessidades organizacionais.
O conceito de arquitetura de referncia destina-se a descrever e ilustrar as principais
categorias diferentes de implantaes do SharePoint Server e no para fornecer uma
receita para arquitetos usarem para projetar suas solues. Esta seo se concentra na
descrio dos vetores nos quais as implantaes do SharePoint Server so geralmente
dimensionadas.
As arquiteturas relacionadas aqui so oferecidas como uma maneira til de compreender
os diferenciadores gerais entre essas categorias genricas e para distingui-las por
fatores de custo geral e por escala de esforo.
34

Implantao de servidor nico


A arquitetura de implantao de servidor nico consiste em um servidor que executa o
SharePoint Server 2010 e uma verso com suporte do SQL Server. Essa arquitetura
pode ser apropriada para fins de avaliao, desenvolvedores ou para uma implantao
departamental isolada que no seja de misso crtica com apenas alguns usurios. No
entanto, no recomendamos seu uso em um ambiente de produo.

Implantao de farm pequeno


Uma implantao de farm pequeno consiste em um nico servidor de banco de dados ou
cluster e um ou dois computadores baseados no SharePoint Server 2010. As principais
caractersticas de arquitetura incluem redundncia e failover limitados e um conjunto
mnimo de recursos do SharePoint Server habilitados.
Um farm pequeno til para servir somente a implantaes limitadas, com um conjunto
mnimo de aplicativos de servio habilitados, uma base de usurios relativamente
pequena e uma carga de uso relativamente baixa (poucas solicitaes por minuto at
muito poucas solicitaes por segundo) e um volume relativamente pequeno de dados
(10 ou mais gigabytes).

Implantao de farm mdio


Essa arquitetura introduz a diviso da topologia em trs camadas: servidores Web
dedicados, servidores de aplicativos dedicados e um ou mais servidores de banco de
dados ou clusters. A separao da camada de servidor de front-end da camada de
servidor de aplicativos permite maior flexibilidade em isolamento de servios e auxilia o
balanceamento de carga no sistema.

35

Essa no a arquitetura mais comum e inclui um amplo espectro de topologias de


servio e de tamanhos de farm. Uma implantao de farm mdio til para servir
ambientes com:
Vrios aplicativos de servio distribudos em vrios servidores. Um conjunto tpico de
recursos poderia incluir o Servio do Office Web Apps, o Servio de Perfil de
Usurio, o Servio de Metadados Gerenciados e o Servio de Clculo do Excel.

Uma base de usurios de dezenas de milhares de usurios e uma carga de 10 a 50


solicitaes por segundo.

Um repositrio de dados de um ou dois terabytes.

Implantao de farm grande


Implantaes de farm grande introduzem a diviso de servios e solues entre vrios
farms e uma expanso adicional das camadas em um nico farm. Vrios servios do
SharePoint Server podem ser implantados em um farm de servios dedicados que serve
solicitaes de vrios farms de consumo. Nessas arquiteturas grandes, tipicamente
existem servidores Web, vrios servidores de aplicativos, dependendo da caracterstica
de uso de cada um dos servios locais (no compartilhados) e vrios servidores
baseados no SQL Server ou clusters do SQL Server, dependendo do tamanho do
36

contedo e dos bancos de dados de servios de aplicativo habilitados no farm. Esperase que as arquiteturas de farm grande sirvam implantaes com:
Vrios aplicativos de servio federados e consumidos do farm de servios
dedicados, normalmente o Servio de Perfil de Usurio, Pesquisa, servio de
Metadados Gerenciados e Web Analytics.

A maioria dos outros aplicativos de servio habilitada localmente.

Uma base de usurios no intervalo de centenas de milhares de usurios.

Uma carga de uso no intervalo de centenas de solicitaes por segundo.

Um conjunto de dados no intervalo de dezenas ou mais de terabytes.

37

Consulte tambm
Conceitos
Planejamento de capacidade para SharePoint Server 2010
Testes de desempenho para SharePoint Server 2010
Monitorando e mantendo o SharePoint Server 2010
Gerenciamento de capacidade do SharePoint Server 2010: limites de software
38

Recomendaes e resultados de testes de desempenho e capacidade (SharePoint


Server 2010)
Performance and capacity technical case studies (SharePoint Server 2010) (em ingls)

Outros recursos
Hardware and software requirements (SharePoint Server 2010)

39

Planejamento de capacidade para


SharePoint Server 2010
Este artigo descreve como planejar a capacidade de um farm do Microsoft SharePoint
Server 2010. Com uma boa estimativa e um bom entendimento do planejamento e
gerenciamento da capacidade, voc pode aplicar seu conhecimento para dimensionar o
sistema. Dimensionamento o termo usado para descrever a seleo e configurao da
arquitetura de dados apropriada, topologia lgica e fsica e hardware para uma
plataforma de soluo. H diversas consideraes de uso e gerenciamento da
capacidade que afetam o modo como voc deve determinar as opes mais adequadas
de hardware e configurao.
Antes de ler este artigo, leia Viso geral do gerenciamento da capacidade e
dimensionamento do SharePoint Server 2010.
Neste artigo, descrevemos as etapas que devem ser seguidas para garantir um
gerenciamento de capacidade eficaz em seu ambiente. Cada etapa exige algumas
informaes para que sua execuo seja bem-sucedida e tem um conjunto de resultados
finais que voc vai usar na etapa subsequente. Para cada etapa, esses requisitos e
resultados finais esto descritos em tabelas.
Neste artigo:
Etapa 1: Modelo

Etapa 2: Design

Etapa 3: Piloto, Teste e Otimizao

Etapa 4: Implantao

Etapa 5: Monitorao e Manuteno

Etapa 1: Modelo
A modelagem do seu ambiente baseado no SharePoint Server 2010 comea com a
anlise das solues existentes e a estimativa da demanda e das metas esperadas para
a implantao que pretende configurar. Comece coletando informaes sobre a base de
usurios, os requisitos de dados, as metas de latncia e produtividade e documente os
recursos do SharePoint Server que deseja implantar. Use esta seo para compreender
os dados que deve coletar, como colet-los e us-los nas etapas seguintes.

Compreender a carga de trabalho e o conjunto de dados esperados


O dimensionamento adequado de uma implementao do SharePoint Server 2010
requer estudo e compreenso das caractersticas da demanda esperada pela sua
soluo. A compreenso da demanda requer a capacidade de descrever tanto as
caractersticas da carga de trabalho, como nmero de usurios e operaes utilizadas
mais frequentemente, quanto as caractersticas do conjunto de dados, como
dimensionamento e distribuio de contedo.
Esta seo pode ajudar a compreender algumas mtricas e parmetros especficos que
devem ser coletados e os mecanismos que podem ser usados para a coleta.
40

Carga de trabalho
A carga de trabalho descreve a demanda qual o sistema dever atender, a base de
usurios e as caractersticas de uso. A tabela a seguir apresenta algumas mtricas
fundamentais teis na determinao da carga de trabalho. possvel usar esta tabela
para registrar essas mtricas medida que so coletadas.

Caractersticas da Carga de
Trabalho

Valor

Mdia do RPS dirio


Mdia do RPS no horrio de pico
Nmero total de usurios
exclusivos por dia
Mdia diria de usurios
simultneos
Usurios simultneos no horrio de
pico
Nmero total de solicitaes por dia
Distribuio da carga de trabalho
esperada

Nmero de solicitaes por dia

Navegador da Web Rastreamento de Pesquisa


Navegador da Web - Interao
Geral de Colaborao
Navegador da Web - Interao
Social
Navegador da Web - Interao
Geral
Navegador da Web - Office Web
Apps
Clientes do Office
Cliente do OneNote
SharePoint Workspace
Sincronizao de RSS do Outlook
Outlook Social Connector
Outras interaes (Aplicativos
Personalizados/servios Web)
41

Usurios simultneos mais comum medir a simultaneidade das operaes


executadas no farm de servidores como o nmero de usurios distintos que geram
solicitaes em determinado intervalo de tempo. As mtricas principais so a mdia
diria e os usurios simultneos na carga de pico.

Solicitaes por segundo (RPS) RPS um indicador normalmente usado para


descrever a demanda do farm de servidores expressada no nmero de solicitaes
processadas pelo farm por segundo, mas sem diferenciar entre o tipo ou o tamanho
das solicitaes. A base de usurios de cada organizao gera uma carga no
sistema a uma taxa que depende das caractersticas de uso exclusivas da
organizao. Consulte a seo Glossrio em Viso geral do gerenciamento da
capacidade e dimensionamento do SharePoint Server 2010 para obter mais
informaes sobre este termo.

Total de solicitaes dirias Total de solicitaes dirias um bom indicador da


carga geral qual o sistema deve atender. mais comum medir todas as
solicitaes, exceto as solicitaes de handshake de autenticao (status HTTP 401)
em um perodo de 24 horas.

Total de usurios dirios Total de usurios outro indicador fundamental da


carga geral qual o sistema deve atender. Essa medida o nmero real de usurios
exclusivos em um perodo de 24 horas, e no o nmero total de funcionrios da
organizao.
Observao:
O nmero total de usurios dirios pode indicar o crescimento potencial da carga no
farm. Por exemplo, se o nmero de usurios potenciais for de 100 mil funcionrios, 15 mil
usurios dirios indicam que a carga pode crescer significativamente com o tempo,
medida que cresce a adoo dos usurios.

Distribuio da Carga de Trabalho Compreender a distribuio das solicitaes


com base nos aplicativos clientes que interagem com o farm pode ajudar a prever a
tendncia esperada e as alteraes de carga aps a migrao para o SharePoint
Server 2010. Conforme os usurios fazem a transio para as verses mais
recentes do cliente, como o Office 2010, e comeam a usar os novos recursos,
esperado o crescimento de novos padres de carga, RPS e solicitaes totais. Para
cada cliente, podemos descrever o nmero de usurios distintos que o utilizam em
determinado intervalo de tempo do dia e a quantidade de solicitaes totais que o
cliente ou o recurso gera no servidor.
Por exemplo, o grfico a seguir mostra um instantneo de um ambiente interno real
da Microsoft que trabalha com uma soluo social tpica. Neste exemplo, possvel
ver que a maior parte da carga gerada pelo rastreador de pesquisa e pela
navegao na Web comum do usurio final. possvel tambm observar que existe
uma carga significativa que foi introduzida pelo novo recurso Outlook Social
Connector (6,2% das solicitaes).

42

43

Estimando sua carga de trabalho de produo


44

Na estimativa da produtividade necessria que seu farm precisa manter, comece


estimando a combinao de transaes que ser usada no farm. Concentre-se na
anlise das transaes utilizadas mais frequentemente s quais o sistema atender,
conhecendo a frequncia com que elas sero usadas e por quantos usurios. Isso o
ajudar a validar no futuro se o farm ser capaz de manter essa carga no teste de prproduo.
O diagrama a seguir descreve a relao entre a carga de trabalho e a carga no sistema:

Para estimar sua carga de trabalho esperada, colete as seguintes informaes:


Identifique as interaes do usurio, como navegaes comuns de pginas da Web,
downloads e carregamentos de arquivos, modos de exibio e edies do Office
Web Application no navegador, interaes de coautoria, sincronizaes de sites do
SharePoint Workspace, Conexes Sociais do Outlook, sincronizao de RSS (no
Outlook ou outros visualizadores), Transmisses do PowerPoint, blocos de
anotaes compartilhados do OneNote, pastas de trabalho compartilhadas do
45

Servio do Excel, aplicativos compartilhados do Servio do Access e outros.


Consulte a seo Servios e recursos do artigo Viso geral do gerenciamento da
capacidade e dimensionamento do SharePoint Server 2010 para obter mais
informaes. Mantenha o foco na identificao das interaes que podem ser
exclusivas sua implantao e reconhea o impacto esperado desse tipo de carga.
Alguns exemplos podem ser o uso significativo de Formulrios do InfoPath, Clculos
do Servio do Excel e solues semelhantes dedicadas.

Identifique as operaes de sistema, como rastreamentos incrementais de Pesquisa,


backups dirios, trabalhos de timer de sincronizao de perfis, processamento do
Web Analytics, registro dos trabalhos de timer e outros.

Calcule o nmero total de usurios esperados por dia que utilizaro cada recurso,
obtenha os usurios simultneos esperados e as Solicitaes de alto nvel por
segundo. H algumas suposies a fazer, como a simultaneidade presente e o fator
de RPS por usurios simultneos que diferente entre os recursos. Convm usar a
tabela de carga de trabalho apresentada anteriormente nesta seo para suas
estimativas. importante focar os horrios de pico, em vez da produtividade mdia.
Planejando a atividade de pico, voc capaz de dimensionar adequadamente a sua
soluo baseada no SharePoint Server 2010.
Caso tenha uma soluo do Office SharePoint Server 2007 existente, voc poder
extrair os arquivos de log do IIS ou recorrer a outras ferramentas de monitoramento da
Web para entender melhor alguns comportamentos esperados da soluo existente, ou
consulte as instrues na seo a seguir para obter mais detalhes. Se no estiver
migrando de uma soluo existente, preencha a tabela usando estimativas aproximadas.
Nas etapas subsequentes, ser preciso validar suas suposies e ajustar o sistema.

Analisando os logs do IIS do SharePoint Server 2010


Para descobrir as mtricas principais relacionadas a uma implantao do SharePoint
Server 2010 existente, como a quantidade de usurios ativos, como eles utilizam o
sistema, que tipo de solicitaes esto chegando e de que tipo de cliente elas so
originadas, necessrio extrair os dados dos logs ULS e do IIS. Uma das maneiras mais
fceis de adquirir esses dados usar o Analisador de Logs, uma ferramenta avanada
da Microsoft disponvel gratuitamente para download. O Analisador de Logs capaz de
ler e gravar em uma variedade de formatos de texto e binrios, incluindo todos os
formatos do IIS.
Para obter informaes detalhadas sobre como analisar o uso do SharePoint Server
2010 por meio do Analisador de Logs, leia o artigo sobre como analisar o uso dos
Produtos e Tecnologias do Microsoft SharePoint
(http://www.microsoft.com/downloads/en/details.aspx?familyid=f159af68-c3a3-413c-a3f72e0be6d5532e&displaylang=en).
possvel baixar o Analisador de Logs 2.2 pelo site
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=890CD06B-ABF8-4C2591B2-F8D975CF8C07&displayLang=en.

Conjunto de dados
O conjunto de dados descreve o volume de contedo armazenado no sistema e como
ele pode ser distribudo no repositrio de dados. A tabela a seguir apresenta algumas
mtricas fundamentais teis na determinao do conjunto de dados. possvel usar esta
tabela para registrar essas mtricas medida que so coletadas.
46

Objeto

Valor

Tamanho do BD (em GB)


Nmero de BDs de Contedo
Nmero de conjuntos de sites
Nmero de aplicativos web
Nmero de sites
Tamanho do ndice de pesquisa (nmero de
itens)
Nmero de documentos
Nmero de listas
Tamanho mdio dos sites
Tamanho do maior site
Nmero de perfis de usurio

Tamanho do contedo Saber o tamanho do contedo que voc espera


armazenar no sistema do SharePoint Server 2010 importante para o planejamento
e a arquitetura do armazenamento do sistema, e tambm para o dimensionamento
adequado da soluo de Pesquisa que vai rastrear e indexar esse contedo. O
tamanho do contedo est descrito no espao total em disco. Se estiver migrando
contedo de uma implantao existente, voc pode achar simples identificar o
tamanho total que vai mover; enquanto no planejamento, voc deve deixar espao
para o crescimento com o passar do tempo, baseado na tendncia prevista.

Nmero total de documentos Alm do tamanho dos dados, importante


acompanhar o nmero geral de itens. O sistema reage de forma diferente quando
100 GB dos dados so constitudos de 50 arquivos de 2 GB cada ou de 100.000
arquivos de 1 KB cada. Em implantaes maiores, quanto menor o estresse em um
nico item, melhor o desempenho. Um contedo amplamente distribudo, como
vrios arquivos menores entre diversos sites e conjuntos de sites, mais fcil de ser
atendido do que somente uma biblioteca grande de documentos com arquivos muito
grandes.

Tamanho mximo do conjunto de sites importante identificar qual a maior


unidade de contedo que voc vai armazenar no SharePoint Server 2010.
Geralmente, isso uma necessidade organizacional que o impede de dividir essa
unidade de contedo. O tamanho mdio de todos os conjuntos de sites e o nmero
total estimado de conjuntos de sites so indicadores adicionais que o ajudam a
identificar a arquitetura de dados de sua preferncia.

Caractersticas de dados dos aplicativos de servio Alm de analisar as


necessidades de armazenamento do repositrio de contedo, analise e calcule os
tamanhos de outros repositrios do SharePoint Server 2010, incluindo:

Tamanho total do ndice de Pesquisa


47

O tamanho total do banco de dados de perfil com base no nmero de usurios no


repositrio de perfil

O tamanho total do banco de dados social com base no nmero esperado de


marcas, colegas e atividades

O tamanho do repositrio de metadados

O tamanho do banco de dados de uso

O tamanho do banco de dados do Web Analytics


Para obter mais informaes sobre como estimar os tamanhos de banco de dados,
consulte Planejamento e configurao de armazenamento e capacidade do SQL Server
(SharePoint Server 2010).

Definindo as metas de desempenho e confiabilidade do farm


Um dos resultados finais da Etapa 1: Modelo o bom entendimento das metas de
desempenho e confiabilidade mais adequadas s necessidades da sua organizao.
Uma soluo do SharePoint Server projetada adequadamente deve ser capaz de atingir
os "quatro noves" (99,99%) de durao da operao com capacidade de resposta do
servidor em milsimos de segundo.
Os indicadores usados para descrever o desempenho e a confiabilidade do farm podem
incluir:
Disponibilidade do servidor Geralmente, descrita pela porcentagem de durao
da operao geral do sistema. Convm acompanhar qualquer tempo de inatividade
inesperado e comparar a disponibilidade geral com a meta definida para a
organizao. As metas so normalmente descritas por alguns noves (isto , 99%,
99,9%, 99,99%).

Capacidade de resposta do servidor O tempo que leva para o farm atender s


solicitaes um bom indicador para acompanhar a integridade do farm. Esse
indicador normalmente chamado de latncia do servidor, e comum usar a
latncia mdia ou mediana (50 percentil) das solicitaes dirias que so atendidas.
As metas so normalmente descritas em milsimos de segundo ou em segundos.
Observe que se a sua organizao tem uma meta para atender pginas do
SharePoint Server 2010 em menos de dois segundos, o objetivo do servidor precisa
estar em milsimos de segundo para dar tempo para a pgina atingir o cliente pela
rede e tempo para a renderizao no navegador. Em geral, tempos mais longos de
resposta do servidor so uma indicao de farm com problemas, j que
normalmente resultam em impacto na produtividade, e o RPS raramente conseguir
acompanhar se voc gastar mais de um segundo na maioria das solicitaes no
servidor.

Capacidade de pico do servidor Outro bom indicador de latncia no servidor que


vale a pena acompanhar o comportamento dos 5% das solicitaes mais lentas de
todas. As solicitaes mais lentas em geral so aquelas que chegam ao sistema
quando ele est sob uma carga maior ou, mais comumente, so as solicitaes
impactadas por atividades menos frequentes que ocorrem durante a interao dos
usurios com o sistema. Um sistema ntegro aquele que tambm tem as
solicitaes mais lentas sob controle. A meta aqui semelhante Capacidade de
Resposta do Servidor exceto que, para atingir a resposta em milsimos de segundo
na capacidade de pico do servidor, voc precisar construir o sistema com muitos
recursos sobressalentes para lidar com os picos de carga.
48

Utilizao de recursos do sistema Outros indicadores comuns usados para


acompanhar a integridade do sistema so uma coleo de contadores de sistema
que indicam a integridade de cada servidor na topologia do farm. Os indicadores
utilizados mais frequentemente so % de utilizao da CPU e Memria Disponvel;
porm, h vrios contadores adicionais que podem ajudar a identificar um sistema
com problemas. Voc encontra mais detalhes na Etapa 5: Monitorao e
Manuteno.

Etapa 2: Design
Agora que j concluiu a coleta de alguns fatos ou estimativas sobre a soluo que
precisa entregar, voc est pronto para comear a prxima etapa de criao de uma
arquitetura proposta prevista para atender demanda esperada.
No fim desta etapa, voc dever ter sua topologia fsica criada e um layout para a
topologia lgica, de forma que seja capaz de realizar todas as ordens de compra
necessrias.
As especificaes de hardware e o nmero de computadores esquematizados esto
totalmente relacionados. Para tratar de uma carga especfica, h vrias solues que
voc pode escolher para implantao. comum usar um pequeno conjunto de
computadores fortes (dimensionamento vertical) ou um conjunto maior de computadores
menores (dimensionamento horizontal). Cada soluo tem suas vantagens e
desvantagens quando se trata de capacidade, redundncia, potncia, custo, espao e
outras consideraes.
recomendvel comear esta etapa determinando a arquitetura e topologia. Defina
como pretende esquematizar os diferentes farms e servios em cada farm e, em
seguida, escolha as especificaes de hardware para cada servidor individual em seu
design. possvel tambm executar este processo identificando as especificaes de
hardware esperadas para implantao (muitas organizaes esto restritas a
determinados padres da empresa) e, na sequncia, definir a arquitetura e topologia.
Use a tabela a seguir para registrar seus parmetros de design. Os dados includos so
apenas exemplos e no devem ser utilizados para dimensionar seu farm. Sua inteno
demonstrar como usar esta tabela com seus prprios dados.

Funo

Tipo
Processamentos RAM IOPS
Tamanho Unidade
Nmero de
(Padro
necessrio do disco de
computadores
SO+Log dados
ou virtual)

Servidores
Web

Virtual

4 ncleos

Servidor de
banco de
dados de
contedo

Padro

1 cluster

48
4 ncleos
qudruplos 2.33
(GHz)

49

N/A

400 GB N/A

2 mil

400 GB 20
discos
de 300
GB
A 15
mil
RPM

Funo

Tipo
Processamentos RAM IOPS
Tamanho Unidade
Nmero de
(Padro
necessrio do disco de
computadores
SO+Log dados
ou virtual)

Servidores de Virtual
aplicativos

4 ncleos

16

N/A

400 GB N/A

Servidor Web Virtual


de Destino de
Rastreamento
de Pesquisa

4 ncleos

N/A

400 GB N/A

Servidor de
Consulta de
Pesquisa

Padro

32
2 ncleos
qudruplos 2.33
(GHz)

N/A

400 GB 500 GB

Servidor do Padro
Rastreador
de Pesquisa

16
2 ncleos
qudruplos 2.33
(GHz)

400

400 GB N/A

Servidor de Padro
banco de
dados de
Rastreamento
de Pesquisa

1 cluster

48
4 ncleos
qudruplos 2.33
(GHz)

4 mil
100 GB
(ajustado
para
leitura)

16
discos
de 150
GB a
15 mil
RPM

Banco de
Padro
dados de
Repositrio
de
Propriedades
de Pesquisa
+ Servidor de
banco de
dados de
administrao

1 cluster

48
4 ncleos
qudruplos 2.33
(GHz)

2 mil
100 GB
(ajustado
para
gravao)

16
discos
de 150
GB a
15 mil
RPM

Determinar a arquitetura de ponto de partida


Esta seo descreve como selecionar uma arquitetura de ponto de partida.
Ao implantar o SharePoint Server 2010, voc pode escolher dentre vrias topologias
para implementar a soluo. possvel implantar um servidor nico ou dimensionar
vrios servidores em um farm do SharePoint Server com servidores de banco de dados
clusterizados ou espelhados e servidores de aplicativos discretos para diversos servios.
Posteriormente, voc selecionar as configuraes de hardware baseadas nos requisitos
de cada uma das funes, com base nas necessidades de capacidade, disponibilidade e
redundncia.
Comece analisando as diferentes arquiteturas de referncia e descubra a estrutura do
seu farm, decida se vai dividir a soluo em vrios farms ou federar alguns servios,
como pesquisa, em um farm dedicado. Consulte a seo Arquiteturas de referncia
50

em Viso geral do gerenciamento da capacidade e dimensionamento do SharePoint


Server 2010 para obter mais informaes.

Estudos de caso tcnicos do SharePoint Server 2010


As diretrizes de gerenciamento de capacidade para o SharePoint Server 2010 incluem
um nmero de estudos de caso tcnicos de ambientes de produo existentes que
apresentam uma descrio detalhada dos ambientes de produo baseados no
SharePoint Server. Outros estudos de caso tcnicos sero publicados com o tempo; eles
serviro como referncia para criar um ambiente baseado no SharePoint Server para
fins especficos.
possvel usar estes estudos de caso como referncia ao criar a arquitetura das
solues do SharePoint Server, principalmente se achar a descrio desses
diferenciadores-chave especficos da implantao parecidos com as demandas e metas
da soluo que est arquitetando.
Estes documentos descrevem as seguintes informaes para cada estudo de caso
registrado:
Especificaes, como hardware, topologia e configurao do farm;

Carga de trabalho, incluindo a base de usurios e as caractersticas de uso;

Conjunto de dados, incluindo tamanhos de contedos, caractersticas e distribuio


do contedo;

Integridade e desempenho, incluindo um conjunto de indicadores registrados


descrevendo as caractersticas de confiabilidade e desempenho do farm.
Para obter mais informaes, baixe os documentos relevantes da pgina de estudos de
caso tcnicos sobre desempenho e capacidade (http://technet.microsoft.com/ptbr/library/cc261716.aspx).

Selecionar o hardware
A seleo das especificaes corretas para os computadores do farm uma etapa
crucial para garantir confiabilidade e desempenho adequados sua implantao. Um
conceito fundamental que voc deve ter em mente o planejamento para a carga de
pico e os horrios de pico; em outras palavras, quando o farm est operando em
condies de carga mdia, deve haver recursos suficientes disponveis para atender
maior demanda esperada e ainda atingir as metas de latncia e produtividade.
Os recursos bsicos de hardware de capacidade e desempenho dos servidores refletem
as quatro principais categorias: potncia de processamento, desempenho do disco,
capacidade da rede e recursos de memria do sistema.
Outra considerao utilizar computadores virtualizados. Um farm do SharePoint Server
pode ser implantado usando computadores virtuais. Embora no se tenha notado
nenhum benefcio de desempenho com isso, existem alguns benefcios de
gerenciamento. A virtualizao de computadores baseados no SQL Server em geral no
recomendada, mas podem haver alguns benefcios ao se virtualizar as camadas do
servidor Web e do servidor de aplicativos. Para obter mais informaes, consulte o artigo
sobre planejamento da virtualizao (http://technet.microsoft.com/pt-br/library/71c203cd7534-47b0-9122-657d72ff0080(Office.14).aspx).

Diretrizes de seleo de hardware


Escolhendo processadores
51

O SharePoint Server 2010 s est disponvel para processadores de 64 bits. Em geral,


mais processadores lhe permitiro atender a uma demanda maior.
No SharePoint Server 2010, servidores Web individuais sero dimensionados medida
que voc adicionar mais ncleos (testamos at 24 ncleos); quanto mais ncleos o
servidor tiver, mais carga ele poder sustentar, em condies normais. Em grandes
implantaes do SharePoint Server, recomendado alocar vrios servidores Web de 4
ncleos (que podem ser virtualizados) ou menos servidores Web mais fortes (8, 16, 24
ncleos).
Os requisitos de capacidade do processador dos servidores de aplicativos so diferentes
dependendo da funo do servidor e dos servios que esto sendo executados. Alguns
recursos do SharePoint Server exigem maior potncia de processamento que outros.
Por exemplo, o Servio de Pesquisa do SharePoint altamente dependente da potncia
de processamento do servidor de aplicativos. Para obter mais informaes sobre os
requisitos de recursos e servios do SharePoint Server, consulte Servios e recursos
anteriormente neste documento.
Os requisitos de capacidade do processador para o SQL Server tambm dependem dos
bancos de dados de servio que est hospedado em um computador baseado no SQL
Server. Para obter mais informaes sobre o comportamento comum e os requisitos de
cada banco de dados, consulte Planejamento e configurao de armazenamento e
capacidade do SQL Server (SharePoint Server 2010).

Escolhendo a memria
Os servidores exigem quantidades variadas de memria, de acordo com a funo do
servidor. Por exemplo, os servidores que executam os componentes de rastreamento de
Pesquisa processaro os dados mais rapidamente se tiverem uma grande quantidade de
memria, pois os documentos so lidos na memria para o processamento. Servidores
Web que utilizam vrios dos recursos de cache do SharePoint Server 2010 tambm
podem exigir mais memria.
Em geral, os requisitos de memria do servidor Web so altamente dependentes do
nmero de pools de aplicativos habilitados no farm e do nmero de solicitaes
simultneas que esto sendo atendidas. Na maioria das implantaes de produo do
SharePoint Server, recomendvel alocar no mnimo 8 GB de RAM em cada servidor
Web, com uma recomendao de 16 GB para servidores com maior trfego ou
implantaes com vrios pools de aplicativos configurados para isolamento.
Os requisitos de memria dos servidores de aplicativos tambm so diferentes: alguns
recursos do SharePoint Server apresentam maior requisito de memria na camada do
aplicativo do que outros. Na maioria das implantaes de produo do SharePoint
Server, recomendvel alocar no mnimo 8 GB de RAM em cada servidor de aplicativos;
servidores de aplicativos de 16 GB, 32 GB e 64 GB so comuns quando muitos servios
de aplicativo esto habilitados no mesmo servidor, ou quando servios altamente
dependentes da memria, como o Servio de Clculo do Excel e o Servio de Pesquisa
do SharePoint Server, esto habilitados.
Os requisitos de memria dos servidores de banco de dados so totalmente
dependentes dos tamanhos dos bancos de dados. Para obter mais informaes sobre
como escolher a memria para seus computadores baseados no SQL Server, consulte
Planejamento e configurao de armazenamento e capacidade do SQL Server
(SharePoint Server 2010).

Escolhendo redes
52

Alm do benefcio oferecido aos usurios quando os clientes tm acesso rpido aos
dados pela rede, um farm distribudo deve ter acesso rpido para comunicao entre
servidores. Isso verdade principalmente quando voc distribui os servios por vrios
servidores ou faz a federao de alguns dos servios para outros farms. Existe um
trfego significativo no farm pela camada do servidor Web, do servidor de aplicativos e
do servidor de banco de dados, e a rede pode facilmente se transformar em um
afunilamento sob determinadas condies, como lidar com arquivos muito grandes ou
cargas muito elevadas.
Os servidores Web e os servidores de aplicativos devem ser configurados com pelo
menos duas placas de interface de rede (NICs): uma NIC para tratar do trfego do
usurio final e outra para tratar da comunicao entre servidores. A latncia de rede
entre os servidores pode ter um impacto significativo no desempenho, por isso,
importante manter menos de 1 milissegundo de latncia de rede entre o servidor Web e
os computadores baseados no SQL Server que hospedam os bancos de dados de
contedo. Os computadores baseados no SQL Server que hospedam cada banco de
dados de aplicativo de servio devem estar o mais prximo possvel tambm do servidor
de aplicativos de consumo. A rede entre os servidores do farm deve ter no mnimo 1
Gbps de largura de banda.

Escolhendo discos e armazenamento


O gerenciamento de disco no simplesmente uma funo para fornecer espao
adequado aos seus dados. Avalie a demanda e o crescimento constante e verifique se a
arquitetura de armazenamento no est deixando o sistema mais lento. Verifique
sempre se voc tem no mnimo 30% de capacidade adicional em cada disco, acima da
sua maior estimativa de requisitos de dados, para deixar espao para um crescimento
futuro. Alm disso, na maioria dos ambientes de produo, a velocidade do disco (IOps)
fundamental para fornecer produtividade suficiente para atender s demandas de
armazenamento dos servidores. Voc deve estimar a quantidade de trfego (IOps) que
os bancos de dados principais vo precisar na sua implantao e alocar discos
suficientes para satisfazer o trfego.
Para obter mais informaes sobre como escolher discos para servidores de banco de
dados, consulte Planejamento e configurao de armazenamento e capacidade do SQL
Server (SharePoint Server 2010).
Os servidores Web e de aplicativos tambm tm requisitos de armazenamento. Na
maioria dos ambientes de produo, recomendvel alocar no mnimo 200 GB de
espao em disco para o SO e os arquivos temporrios e 150 GB de espao em disco
para os logs.

Etapa 3: Piloto, Teste e Otimizao


O estgio de teste e otimizao um componente crtico do gerenciamento de
capacidade eficaz. Teste as novas arquiteturas antes de implant-las na produo e
conduza um teste de aceitao em conjunto com as seguintes prticas recomendadas
de monitoramento para garantir que as arquiteturas criadas atinjam as metas de
desempenho e capacidade. Dessa forma, voc identifica e otimiza possveis
afunilamentos antes que eles afetem os usurios em uma implantao dinmica. Se
voc est atualizando de um ambiente do Office SharePoint Server 2007 e pretende
fazer alteraes na arquitetura, ou est estimando a carga do usurio dos novos
recursos do SharePoint Server, o teste importante principalmente para verificar se o
53

seu novo ambiente baseado no SharePoint Server vai atender s metas de desempenho
e capacidade.
Aps testar o seu ambiente, voc pode analisar os resultados do teste para determinar
quais alteraes so necessrias para atingir as metas de desempenho e capacidade
estabelecidas na Etapa 1: Modelo.
Estas so as subetapas recomendadas que voc deve seguir para pr-produo:
Crie o ambiente de teste imitando a arquitetura inicial criada na Etapa 2: Design.

Popule o armazenamento com o conjunto de dados ou parte do conjunto de dados


que voc identificou na Etapa 1: Modelo.

Submeta o sistema a uma carga sinttica que represente a carga de trabalho que
voc identificou na Etapa 1: Modelo.

Execute testes, analise os resultados e otimize a arquitetura.

Implante a arquitetura otimizada em seu data center e distribua um piloto a um grupo


menor de usurios.

Analise os resultados do piloto, identifique possveis afunilamentos e otimize a


arquitetura. Refaa o teste, se necessrio.

Implante no ambiente de produo.

Teste
O teste um fator crtico para estabelecer a capacidade do seu design de sistema em
oferecer suporte s caractersticas de carga de trabalho e uso. Consulte Testes de
desempenho para SharePoint Server 2010 para obter informaes detalhadas sobre
como testar sua implantao do SharePoint Server 2010.
Criar um plano de teste

Criar o ambiente de teste

Criar Testes e Ferramentas

Implantar o ambiente piloto


Antes de implantar o SharePoint Server 2010 em um ambiente de produo,
importante primeiro implantar um ambiente piloto e testar completamente o farm para
verificar se ele atende s metas de capacidade e desempenho para sua carga de pico
esperada. recomendvel testar primeiro o ambiente piloto com carga sinttica,
principalmente para grandes implantaes, e depois submet-lo a um pequeno grupo de
usurios ativos e contedo dinmico. A vantagem de analisar um ambiente piloto com
um pequeno grupo de usurios ativos a oportunidade de validar algumas suposies
feitas sobre as caractersticas de uso e o crescimento do contedo antes de entrar
totalmente em produo.

Otimizar
Se voc no conseguir atender s metas de capacidade e desempenho dimensionando
o hardware do seu farm ou fazendo alteraes na topologia, considere revisar a sua
soluo. Por exemplo, se os requisitos iniciais eram referentes a um nico farm para
colaborao (de Pesquisa e Social), convm federar alguns dos servios, como a
pesquisa em um farm de servios dedicado, ou dividir a carga de trabalho entre mais
farms. Uma alternativa implantar um farm dedicado para colaborao social e outro
para colaborao de equipe.

54

Etapa 4: Implantao
Aps executar os ltimos testes e confirmar que a arquitetura selecionada capaz de
atingir s metas de desempenho e capacidade estabelecidas na Etapa 1: Modelo, voc
poder implantar o ambiente baseado no SharePoint Server 2010 para produo.
A estratgia de distribuio apropriada varia de acordo com o ambiente e a situao.
Embora a implantao do SharePoint Server no geral est fora do escopo deste
documento, h algumas atividades sugeridas que podem se revelar por meio do
exerccio de planejamento da capacidade. Veja a seguir alguns exemplos:
Implantando um novo farm do SharePoint Server: o exerccio de planejamento da
capacidade deve ter planos orientados e verificados para o design e a implantao
do SharePoint Server 2010. Neste caso, a distribuio ser a primeira implantao
ampla do SharePoint Server 2010. Ela exige mover ou reconstruir os servidores e
servios usados durante os exerccios de planejamento da capacidade para
produo. Este o cenrio mais direto, pois no existe nenhuma atualizao ou
modificao necessria para um farm existente.

Atualizando um farm do Office SharePoint Server 2007 para o SharePoint


Server 2010: o exerccio de planejamento da capacidade deve validar o design de
um farm capaz de atender s demandas existentes e de ser dimensionado para
satisfazer crescente demanda e uso de um farm do SharePoint Server 2010. Parte
do exerccio de planejamento da capacidade deve incluir migraes de teste para
validar quanto tempo levar o processo de atualizao, se algum cdigo
personalizado precisa ser modificado ou substitudo, se alguma ferramenta de
terceiros precisa de atualizao, etc. Na concluso do planejamento da capacidade,
voc dever ter um design validado, saber quanto tempo ele levar para ser
atualizado e ter um plano sobre a melhor maneira de se trabalhar com o processo de
atualizao, por exemplo, uma atualizao in-loco ou uma migrao de bancos de
dados de contedo para um novo farm. Se estiver realizando uma atualizao inloco, durante o planejamento da capacidade voc deve ter percebido que h a
necessidade de hardware adicional ou atualizado, alm de consideraes em
relao ao tempo de inatividade. Parte do resultado do exerccio de planejamento
deve ser uma lista das alteraes de hardware necessrias e um plano detalhado
para implantao das alteraes de hardware primeiro no farm. Depois que a
plataforma de hardware validada durante o planejamento da capacidade estiver no
local, voc poder continuar com o processo de atualizao para o SharePoint
Server 2010.

Melhorando o desempenho de um farm existente do SharePoint Server 2010: o


exerccio de planejamento da capacidade deve ajud-lo a identificar os
afunilamentos em sua implementao atual, apresentar maneiras de reduzir ou
eliminar esses afunilamentos e validar uma implementao aperfeioada que atenda
aos requisitos de negcios dos servios do SharePoint Server. H diversas maneiras
de se resolver os problemas de desempenho, desde algo simples como realocar
servios para o hardware existente, atualizar o hardware existente ou adicionar outro
hardware at adicionar outros servios a ele. As diferentes abordagens devem ser
testadas e validadas durante o exerccio de planejamento da capacidade e, em
seguida, um plano de implantao deve ser formulado de acordo com os resultados
do teste.
55

Etapa 5: Monitorao e Manuteno


Para manter o desempenho do sistema, monitore seu servidor para identificar possveis
afunilamentos. Para um monitoramento eficaz, voc deve conhecer os indicadoreschave que lhe mostraro se determinada parte do seu farm requer ateno e como
interpretar esses indicadores. Se achar que seu farm est operando fora das metas
definidas, voc poder ajust-lo adicionando ou removendo recursos de hardware,
modificando a topologia ou alterando a maneira como os dados so armazenados.
Consulte Monitorando e mantendo o SharePoint Server 2010 para ver uma lista de
configuraes que voc pode modificar para monitorar o ambiente em seus primeiros
estgios, o que o ajudar a determinar se alguma alterao ser necessria. Lembre-se
de que ampliar seus recursos de monitoramento afetar o espao em disco requerido
pelo banco de dados de uso. Depois que o ambiente estiver estvel e o monitoramento
detalhado no for mais necessrio, convm reverter as configuraes a seguir aos seus
padres.
Para obter mais informaes sobre monitoramento da integridade e soluo de
problemas por meio das ferramentas de monitoramento da integridade internas da
interface da Administrao Central do SharePoint Server, leia o seguinte artigo sobre:
Health Monitoring (SharePoint Server 2010)
Soluo de problemas (http://blogs.msdn.com/b/ecm/archive/2010/06/22/variationspropagate-pages-on-your-terms.aspx)

Consulte tambm
Conceitos
Viso geral do gerenciamento da capacidade e dimensionamento do SharePoint Server
2010
Testes de desempenho para SharePoint Server 2010
Monitorando e mantendo o SharePoint Server 2010
Planejamento e configurao de armazenamento e capacidade do SQL Server
(SharePoint Server 2010)

Outros recursos
Health Monitoring (SharePoint Server 2010)

56

Testes de desempenho para SharePoint


Server 2010
Este artigo descreve como testar o desempenho do Microsoft SharePoint Server 2010. A
fase de testes e otimizao um componente crucial do gerenciamento de capacidade
efetivo. Voc deve testar novas arquiteturas antes de implant-las em produo e deve
realizar testes de aceitao em conjunto com as prticas recomendadas de
monitoramento a seguir, para garantir que as arquiteturas que voc projetar cumpram as
metas de desempenho e capacidade. Isso permite identificar e otimizar afunilamentos
em potencial antes que eles afetem os usurios em uma implantao dinmica. Se voc
estiver atualizando de um ambiente do Microsoft Office SharePoint Server 2007 e
planejar alteraes na arquitetura ou se estiver estimando a carga do usurio dos novos
recursos do SharePoint Server 2010, os testes sero particularmente importantes para
garantir que o novo ambiente baseado no SharePoint Server 2010 cumpra as metas de
desempenho e capacidade.
Aps testar o ambiente, voc pode analisar os resultados do teste para determinar as
alteraes que precisam ser feitas de modo a cumprir as metas de desempenho e
capacidade que voc estabeleceu na Etapa 1: Modelo de Planejamento de capacidade
para SharePoint Server 2010.
Estas so as subetapas recomendadas para a pr-produo:
Criar o ambiente de teste que reflete a arquitetura inicial projetada por voc em
Etapa 2: Design.

Popular o armazenamento com o conjunto de dados ou parte do conjunto de dados


que voc identificou na Etapa 1: Modelo.

Realizar um teste de estresse do sistema com uma carga sinttica que representa a
carga de trabalho que voc identificou na Etapa 1: Modelo.

Executar testes, analisar os resultados e otimizar arquitetura.

Implantar a arquitetura otimizada no data center e introduzir um piloto com um


conjunto de usurios menor.

Analisar os resultados do piloto, identificar possveis afunilamentos e otimizar a


arquitetura. Testar novamente, se necessrio.

Implantar no ambiente de produo.


Antes de ler este artigo, voc deve ler Viso geral do gerenciamento da capacidade e
dimensionamento do SharePoint Server 2010.
Neste artigo:
Criar um plano de teste

Criar o ambiente de teste

Crie testes e ferramentas

57

Criar um plano de teste


Verifique se o plano inclui:
Hardware projetado para operar de acordo com as metas de desempenho de
produo esperadas. Sempre mea o desempenho dos sistemas de teste de forma
cautelosa.

Se voc tem um componente ou cdigo personalizado, importante testar primeiro o


desempenho desses componentes em isolamento para validar seu desempenho e
estabilidade. Depois que eles estiverem estveis, voc dever testar o sistema com
os componentes instalados e comparar o desempenho com o farm sem esses itens
instalados. Componentes personalizados frequentemente so uma das principais
causas de problemas de desempenho e confiabilidade em sistemas de produo.

Conhea o objetivo dos testes. Entenda antecipadamente quais so seus objetivos


de testes. Eles se destinam a validar o desempenho de alguns novos componentes
personalizados que foram desenvolvidos para o farm? Voc deseja verificar quanto
tempo levar para rastrear e indexar um conjunto de contedo? necessrio
determinar a quantas solicitaes por segundo o farm pode dar suporte? Pode haver
muitos objetivos diferentes durante um teste, e a primeira etapa no desenvolvimento
de um bom plano de teste consiste em decidir quais so seus objetivos.

Entenda como medir sua meta de teste. Se voc estiver interessado em medir a
capacidade de produtividade do farm, por exemplo, convm medir o RPS e a
latncia de pgina. Se estiver medindo o desempenho de pesquisa, convm medir o
tempo de rastreamento e as taxas de indexao de documentos. Se o seu objetivo
de testes for bem entendido, isso o ajudar a definir claramente os principais
indicadores de desempenho que voc precisar validar para concluir os testes.

Criar o ambiente de teste


Depois que os objetivos de teste tiverem sido decididos, as medidas tiverem sido
definidas e voc tiver determinado os requisitos de capacidade do farm (nas etapas 1 e 2
deste processo), o prximo objetivo ser projetar e criar o ambiente de teste. O esforo
para criar um ambiente de teste muitas vezes subestimado. Ele deve duplicar o
ambiente de produo, tanto quanto possvel. Alguns dos recursos e funcionalidade que
voc deve considerar ao projetar o ambiente de teste so:
Autenticao Decida se o farm usar o AD DS (Servios de Domnio Active
Directory), autenticao baseada em formulrios (e, em caso afirmativo, com qual
diretrio), autenticao baseada em declaraes etc. Independentemente do
diretrio que voc estiver usando, quantos usurios sero necessrios no ambiente
de teste e como voc os criar e popular? Quantos grupos ou funes sero
necessrios e como voc os criar e popular? Tambm preciso garantir que haja
recursos suficientes alocados para os servios de autenticao, para que eles no
se tornem um afunilamento durante o teste.

DNS Saiba quais so os namespaces de que voc necessitar durante os testes.


Identifique os servidores que respondero s solicitaes. Verifique se incluiu um
plano com os endereos IP que sero usados por cada servidor e quais entradas
DNS voc ter de criar.
58

Balanceamento de carga Pressupondo que voc esteja usando mais de um


servidor (o que normalmente seria o caso, ou voc provavelmente no teria carga
suficiente para justificar os testes de carga), ser necessrio algum tipo de soluo
de balanceamento de carga. Pode se tratar de um dispositivo de balanceamento de
carga de hardware ou voc pode usar balanceamento de carga de software, como o
Windows NLB. Determine a opo que voc utilizar e anote todas as informaes
de configurao de que precisar para configur-la de forma rpida e eficiente.
Outro item a ser lembrado que, geralmente, os agentes de teste de carga tentam
resolver o endereo para uma URL apenas uma vez a cada 30 minutos. Isso
significa que voc no deve usar um arquivo de hosts local ou o DNS round robin
para balanceamento de carga, pois os agentes de teste provavelmente acabaro
indo para o mesmo servidor para cada solicitao, em vez de equilibrar a carga entre
todos os servidores disponveis.

Servidores de teste Ao planejar o ambiente de teste, alm de precisar planejar os


servidores para o farm do SharePoint Server 2010, voc tambm precisa planejar os
computadores necessrios para executar os testes. Tipicamente, isso incluir trs
servidores, no mnimo, pode ser necessrio um nmero maior. Se voc estiver
usando o Visual Studio Team System (Team Test Load Agent) para realizar o teste,
um computador ser utilizado como controlador de teste de carga. Geralmente h
dois ou mais computadores que so utilizados como agentes de teste de carga. Os
agentes so os computadores que obtm as instrues do controlador de teste
sobre o que deve ser testado e emitem as solicitaes para o farm do SharePoint
Server 2010. Os resultados do teste so armazenados em um computador baseado
no SQL Server. Voc no deve usar o mesmo computador baseado no SQL Server
que usado para o farm do SharePoint Server 2010, pois a gravao dos dados de
teste distorcer os recursos disponveis do SQL Server para o farm do SharePoint
Server 2010. Tambm preciso monitorar os servidores de teste ao executar os
testes, da mesma forma como voc monitoraria os servidores no farm do SharePoint
Server 2010 ou controladores de domnio etc., para garantir que os resultados do
teste sejam representativos do farm que voc est configurando. s vezes, os
prprios agentes de carga ou o o prprio controlador podem se tornar o
afunilamento. Se isso ocorrer, a produtividade indicada no teste normalmente no
ser o mximo ao qual o farm pode dar suporte.

SQL Server No ambiente de teste, siga as diretrizes das sees "Configurar o


SQL Server" e "Validar e monitorar o armazenamento e o desempenho do SQL
Server" no artigo Planejamento e configurao de armazenamento e capacidade do
SQL Server (SharePoint Server 2010).

Validao do conjunto de dados Ao decidir o contedo em relao ao qual voc


executar os testes, lembre-se de que, na melhor das hipteses, voc usar dados
de um sistema de produo existente. Por exemplo, possvel fazer backup dos
bancos de dados de contedo de um farm de produo, restaur-los no ambiente de
teste e, em seguida, anexar os bancos de dados para levar o contedo para o farm.
Sempre que executa testes com dados de amostra ou fictcios, voc corre o risco de
obter resultados distorcidos, devido s diferenas no corpus de contedo.
Se for necessrio criar dados de exemplo, voc dever ter em mente algumas
consideraes ao criar o contedo:
Todas as pginas devem ser publicadas; no deve ser feito check-out de nada
59

A navegao deve ser realista; no crie um volume superior ao que seria razovel
esperar para o uso na produo.

Voc deve ter uma ideia das personalizaes que o site de produo usar. Por
exemplo, pginas mestras, folhas de estilo, JavaScript etc. devem ser
implementados no ambiente de teste da maneira mais semelhante possvel ao
ambiente de produo.

Determine de quantos grupos do SharePoint e/ou nveis de permisso voc


precisar e como associar usurios a eles.

Determine se precisar realizar importaes de perfil e quanto tempo isso levar.

Determinar se precisar de Audincias e como as criar e popular.

Determine se precisar de fontes de contedo de pesquisa adicionais e o que ser


necessrio para cri-las. Se no for preciso cri-las, determine se voc ter acesso
rede para poder rastre-las.

Determine se voc tem dados de amostra suficientes documentos, listas, itens de


lista etc. Se no tiver, crie um plano para a maneira como voc criar esse contedo.

Tenha um plano para garantir que haja contedo exclusivo suficiente para testar a
pesquisa de forma adequada. Um erro comum carregar o mesmo documento
talvez centenas ou mesmo milhares de vezes para bibliotecas de documentos
diferentes com nomes diferentes. Isso pode afetar o desempenho de pesquisa, pois
o processador de consultas gastar tempo excessivo com a deteco de duplicatas,
o que no ocorreria em um ambiente de produo com o contedo real.

Crie testes e ferramentas


Depois que o ambiente de teste estiver funcional, ser o momento de criar e ajustar os
testes que sero utilizados para medir a capacidade de desempenho do farm. Esta
seo far algumas referncias especificamente ao Visual Studio Team System (Team
Test Load Agent), mas muitos dos conceitos so aplicveis independentemente da
ferramenta de teste de carga que voc usar. Para obter mais informaes sobre o Visual
Studio Team System, consulte Visual Studio Team System at MSDN
(http://msdn.microsoft.com/pt-br/library/fda2bad5.aspx" ).
Voc tambm pode usar o LTK (Kit de Teste de Carga) do SharePoint em conjunto com
o VSTS para testes de carga de farms do SharePoint 2010. O Kit de Teste de Carga
gera um teste de carga do Visual Studio Team System 2008 baseado em logs do IIS do
Windows SharePoint Services 3.0 e do Microsoft Office SharePoint Server 2007. O teste
de carga do VSTS pode ser usado para gerar carga sinttica em relao ao SharePoint
Foundation 2010 ou SharePoint Server 2010, como parte de um exerccio de
planejamento de capacidade ou um teste de estresse pr-atualizao.
O Kit de Teste de Carga est includo no Microsoft SharePoint 2010 Administration
Toolkit v1.0, disponvel no Centro de Download da Microsoft
(http://www.microsoft.com/downloads/en/details.aspx?FamilyId=718447d8-0814-427a81c3-c9c3d84c456e&displaylang=en).
Um critrio fundamental para o sucesso dos testes consiste em poder simular
efetivamente uma carga de trabalho realista, mediante a gerao de solicitaes em
uma ampla gama dos dados de site de teste, assim como os usurios acessariam uma
ampla gama de contedo em um farm de produo do SharePoint Server 2010. Para
fazer isso, normalmente voc precisar criar os testes de tal forma que eles sejam
60

controlados por dados. Em vez de criar centenas de testes individuais embutidos em


cdigo para o acesso a uma pgina especfica, voc deve usar apenas alguns testes
que utilizem fontes de dados contendo as URLs dos itens para acessar dinamicamente o
conjunto de pginas.
No Visual Studio Team System (Team Test Load Agent), uma fonte de dados pode ter
diversos formatos, mas o formato de arquivo CSV geralmente o mais fcil de gerenciar
e transportar entre ambientes de desenvolvimento e de teste. Lembre-se de que a
criao de arquivos CSV com esse contedo pode exigir a criao de ferramentas
personalizadas para enumerar o ambiente baseado em SharePoint Server 2010 e
registrar as vrias URLs que esto sendo usadas.
Talvez voc precise usar ferramentas para tarefas como:
Criar usurios e grupos no Active Directory ou outro repositrio de autenticao, se
voc estiver usando autenticao baseada em formulrios

Enumerar URLs de sites, listas e bibliotecas, itens de lista, documentos etc. e


coloc-las em arquivos CSV para testes de carga

Carregar documentos de exemplo em diversas bibliotecas de documentos e sites

Criar conjuntos de sites, webs, listas, bibliotecas, pastas e itens de lista

Criando Meus Sites

Criar arquivos CSV com nomes de usurio e senhas para usurios de teste; essas
so as contas de usurio com as quais os testes de carga sero executados. Deve
haver vrios arquivos, de modo que, por exemplo, alguns contenham apenas
usurios administradores, outros contenham outros usurios com privilgios
elevados (como autor/colaborador, gerente de hierarquia etc.) e outros sejam
apenas leitores etc.

Criar uma lista de palavras-chave e frases de pesquisa de exemplo

Popular grupos do SharePoint e nveis de permisso com usurios e grupos do


Active Directory (ou funes, se voc estiver usando a autenticao baseada em
formulrios)
Ao criar os testes da Web, h outras prticas recomendadas que voc deve observar e
implementar. So elas:
Grave testes da Web simples como ponto de partida. Esses testes contero valores
embutidos em cdigo para parmetros como URL, IDs etc. Substitua os valores
embutidos em cdigo por links dos arquivos CSV. A vinculao de dados desses
valores no Visual Studio Team System (Team Test Load Agent) extremamente
fcil.

Sempre tenha regras de validao para o teste. Por exemplo, ao ser solicitada uma
pgina, se ocorrer um erro, muitas vezes voc obter a pgina error.aspx como
resposta. De uma perspectiva de teste da Web, essa parece ser apenas outra
resposta positiva, pois voc obtm um cdigo de status HTTP 200 (bem-sucedido)
nos resultados do teste de carga. Contudo, obviamente ocorreu um erro; portanto,
isso deve ser rastreado de forma diferente. A criao de uma ou mais regras de
validao permite que voc intercepte quando determinado texto enviado como
resposta, para que a validao falhe e a solicitao seja marcada como tendo
sofrido uma falha. Por exemplo, no Visual Studio Team System (Team Test Load
Agent), uma regra de validao simples poderia ser uma validao responseURL
ela gravar uma falha se a pgina que renderizada aps redirecionamentos no
61

for a mesma pgina de resposta que foi gravada no teste. Voc tambm pode
adicionar uma regra FindText que gravar uma falha se encontrar as palavras
"acesso negado ", por exemplo, na resposta.

Use vrios usurios em diferentes funes para os testes. Certos comportamentos,


como o cache de sada, funcionam de forma diferente dependendo dos direitos do
usurio atual. Por exemplo, um administrador de conjunto de sites ou um usurio
autenticado com direitos de aprovao ou criao no obtero resultados
armazenados em cache, pois sempre queremos que eles vejam a verso mais atual
do contedo. Usurios annimos, no entanto, obtero o contedo armazenado em
cache. Voc precisa garantir que os usurios de teste constituam uma mistura
dessas funes, correspondendo aproximadamente mistura de usurios no
ambiente de produo. Por exemplo, na produo, provavelmente h apenas dois
ou trs administradores de conjuntos de sites; portanto, voc no deve criar testes
em que 10% das solicitaes de pgina sejam feitos por contas de usurios de
administradores de conjuntos de sites para o contedo de teste.

A anlise de solicitaes dependentes um atributo de um Visual Studio Team


System (Team Test Load Agent) que determina se o agente de teste deve tentar
recuperar apenas a pgina ou a pgina e todas as solicitaes associadas que
fazem parte dela, como imagens, folhas de estilo, scripts etc. Nos testes de carga,
geralmente esses itens so ignorados por algumas razes:

Depois que um usurio acessa um site pela primeira vez, esses itens geralmente
so armazenados em cache pelo navegador local

Esses itens normalmente no vm do SQL Server em um ambiente baseado no


SharePoint Server 2010. Com o cache BLOB ativado, eles so atendidos pelos
servidores Web, em vez disso, para que no gerem carga do SQL Server.
Se voc tem regularmente uma alta porcentagem de usurios de primeira vez em seu
site, se desabilitou o cache do navegador ou se, por algum motivo, no pretende usar o
cache BLOB, talvez faa sentido habilitar a anlise de solicitaes dependentes nos
testes. No entanto, essa realmente uma exceo, no a regra para a maioria das
implementaes. Lembre-se de que se, voc ativar esse recurso, isso poder aumentar
significativamente os nmeros de RPS relatados pelo controlador de teste. Essas
solicitaes so atendidas to rapidamente que podem lev-lo a pensar,
enganadamente, que h mais capacidade disponvel no farm do que a capacidade real.
Lembre-se de modelar tambm a atividade de aplicativos cliente. Aplicativos cliente,
como Microsoft Word, PowerPoint, Excel e Outlook, tambm geram solicitaes para
farms do SharePoint Server 2010. Eles adicionam carga ao ambiente enviando ao
servidor solicitaes como recuperao de RSS feeds, aquisio de informaes
sociais, solicitao de detalhes sobre estrutura de sites e listas, sincronizao de
dados etc. Esses tipos de solicitaes devero ser includos e modelados se voc
tiver esses clientes em sua implementao.

Na maioria dos casos, um teste da Web deve conter uma nica solicitao. mais
fcil ajustar e solucionar problemas do agente de teste e solicitaes individuais se o
teste contm uma nica solicitao. Os testes da Web normalmente precisam conter
vrias solicitaes quando a operao que esto simulando composta por vrias
solicitaes. Por exemplo, para testar esse conjunto de aes, voc precisar de um
teste com diversas etapas: fazer check-out de um documento, edit-lo, fazer checkin dele e public-lo. Tambm necessrio o estado de reserva entre as etapas por
62

exemplo, a mesma conta de usurio deve ser usada para fazer o check-out, realizar
as edies e fazer o check-in do documento. Para operaes com vrias etapas que
exigem que o estado seja mantido entre cada etapa, a melhor opo utilizar vrias
solicitaes em um nico teste da Web.

Teste cada teste da Web individualmente. Verifique se cada teste pode ser
concludo com xito antes de execut-lo em um teste com carga maior. Confirme se
todos os nomes de aplicativos Web so resolvidos e se as contas de usurio usadas
no teste tm direitos suficientes para executar o teste.
Testes da Web incluem as solicitaes de pginas individuais, o carregamento de
documentos, a exibio de itens de lista etc. Todos esses itens so reunidos em testes
de carga. Um teste de carga aquele em que voc rene todos os diferentes testes da
Web que sero executados. Pode ser atribuda uma porcentagem de tempo para a
execuo de cada teste da Web por exemplo, se verificasse que 10% das solicitaes
em um farm de produo so consultas de pesquisa, no teste de carga voc configuraria
um teste da Web de consulta para ser executado por 10% do tempo. No Visual Studio
Team System (Team Test Load Agent), os testes de carga tambm so usados para
configurar itens como combinao de navegadores, combinao de redes, padres de
carga e configuraes de execuo.
Existem algumas prticas recomendadas adicionais que devem ser observadas e
implementadas nos testes de carga:
Use uma taxa razovel de leitura/gravao nos testes. A sobrecarga do nmero de
gravaes em um teste pode afetar significativamente a produtividade global do
teste. Mesmo em farms de colaborao, as taxas de leitura/gravao costumam ter
muito mais leituras do que gravaes. Para obter mais informaes, consulte a
pgina sobre estudos de caso tcnicos de desempenho e capacidade
(http://technet.microsoft.com/pt-br/library/cc261716.aspx).

Considere o impacto de outras operaes com uso intensivo de recursos e decida se


elas devem ocorrer durante o teste de carga. Por exemplo, operaes como backup
e restaurao geralmente no so realizadas durante um teste de carga.
Normalmente, um rastreamento de pesquisa completo pode no ser executado
durante um teste de carga, enquanto um rastreamento incremental pode ser normal.
Voc precisa considerar como essas tarefas sero agendadas na produo: elas
sero executadas em horrios de pico? Se no forem, ento provavelmente devero
ser excludas durante os testes de carga, quando voc tentar determinar a carga de
estado estvel mxima qual pode dar suporte para o trfego de pico.

No use tempos de raciocnio. Tempos de raciocnio so um recurso do Visual


Studio Team System (Team Test Load Agent) que permite simular o tempo de pausa
dos usurios entre os cliques em uma pgina. Por exemplo, um usurio tpico pode
carregar uma pgina, l-la por trs minutos e, em seguida, clicar em um link nela
para visitar outro site. quase impossvel tentar modelar isso corretamente em um
ambiente de teste e, de fato, no agregado valor ao resultado do teste. algo
difcil de modelar porque a maioria das organizaes no tem uma maneira de
monitorar usurios diferentes e o tempo que eles gastam entre cliques em diferentes
tipos de sites do SharePoint (como publicao versus pesquisa versus colaborao
etc.) Isso tambm no agrega valor porque, embora um usurio possa fazer uma
pausa entre solicitaes de pgina, os servidores baseados no SharePoint Server
2010 no o fazem. Simplesmente recebem um fluxo constante de solicitaes que
podem ter altos e baixos ao longo do tempo, mas eles no permanecem ociosos
63

aguardando enquanto cada usurio faz uma pausa entre os cliques em links em uma
pgina.

Entenda a diferena entre usurios e solicitaes. O Visual Studio Team System


(Team Test Load Agent) tem um padro de carga em que pede que voc digite o
nmero de usurios para a simulao. Isso no tem relao alguma com os usurios
do aplicativo; trata-se apenas do nmero de threads que sero usados nos agentes
de teste de carga para gerar solicitaes. Um erro comum pensar que, se a
implantao ter 5.000 usurios, por exemplo, ento 5000 o nmero que dever
ser usado no Visual Studio Team System (Team Test Load Agent) no ! Essa
uma das muitas razes pelas quais, ao serem estimados os requisitos de
planejamento de capacidade, os requisitos de uso devem ser baseados no nmero
de solicitaes por segundo, no no nmero de usurios. Em um teste de carga do
Visual Studio Team System (Team Test Load Agent), voc ver que, muitas vezes,
possvel gerar centenas de solicitaes por segundo usando apenas 50 a 75
"usurios" do teste de carga.

Use um padro de carga constante para obter os resultados de testes mais


confiveis e reproduzveis. No Visual Studio Team System (Team Test Load Agent),
voc tem a opo de basear a carga em um nmero constante de usurios (threads,
conforme explicado no ponto anterior), um padro de carga de nvel de usurios ou
um teste de uso baseado em metas. Um padro de carga de nvel aquele em que
voc comea com um nmero menor de usurios e, em seguida, "sobe um nvel"
adicionando usurios a cada poucos minutos. Um teste de uso com base em metas
aquele em que voc estabelece um limite para um contador de diagnstico, como
utilizao de CPU, e testa as tentativas para direcionar a carga de modo a manter
esse contador entre os limites mnimo e mximo que voc define para ele. No
entanto, se voc estiver apenas tentando determinar a produtividade mxima que o
farm do SharePoint Server 2010 pode sustentar durante a carga de pico, ser mais
eficaz e preciso selecionar apenas um padro de carga constante. Isso permite
identificar mais facilmente a quantidade de carga que o sistema pode aceitar antes
de comear a exceder regularmente os limites que devem ser mantidos em um farm
ntegro.
Sempre que executar um teste de carga, lembre-se de que ele est alterando dados no
banco de dados. Independentemente de se tratar de carregamento de documentos,
edio de itens de lista ou apenas registro de atividade no banco de dados de uso,
dados sero gravados no SQL Server. Para garantir um conjunto consistente e legtimo
de resultados de teste em cada teste de carga, voc deve ter um backup disponvel
antes de executar o primeiro teste de carga. Aps a concluso de cada teste de carga, o
backup dever ser usado para restaurar o contedo de volta maneira como era antes
de ser iniciado o teste.

Consulte tambm
Conceitos
Viso geral do gerenciamento da capacidade e dimensionamento do SharePoint Server
2010
Planejamento de capacidade para SharePoint Server 2010
Monitorando e mantendo o SharePoint Server 2010
64

Planejamento e configurao de armazenamento e capacidade do SQL Server


(SharePoint Server 2010)

Outros recursos
Health Monitoring (SharePoint Server 2010)

65

Monitorando e mantendo o SharePoint


Server 2010
Este artigo fornece informaes sobre contadores de desempenho e monitoramento de
farms do Microsoft SharePoint Server 2010. Para manter o desempenho do sistema do
SharePoint Server 2010, voc deve monitorar o servidor para identificar possveis
afunilamentos. Para que voc possa monitorar de forma eficaz, necessrio
compreender os indicadores-chave que o informaro se uma parte especfica do farm
exigem ateno e saber interpretar esses indicadores. Se achar que o farm est
operando fora das metas definidas, voc poder ajust-lo adicionando ou removendo
recursos de hardware, modificando a topologia ou alterando a forma como os dados so
armazenados.
As informaes contidas nesta seo se destinam a ajudar os administradores a
configurar manualmente os contadores de desempenho e outras configuraes. Para
obter mais informaes sobre monitoramento de integridade e soluo de problemas
usando as ferramentas de monitoramento de integridade internas interface da
Administrao Central do SharePoint, leia os seguintes artigos:
Health Monitoring (SharePoint Server 2010)
Solving Problems and Troubleshooting (SharePoint Server 2010)
Antes de ler este artigo, voc deve ler Viso geral do gerenciamento da capacidade e
dimensionamento do SharePoint Server 2010.
Neste artigo:
Configurando o monitoramento

Removendo afunilamentos

Configurando o monitoramento
A seguir, h uma lista das configuraes que voc pode modificar para monitorar o
ambiente nos estgios iniciais, o que ajudar a determinar se so necessrias
alteraes. Tenha em mente que o aumento dos recursos de monitoramento afetar a
quantidade de espao em disco de que o banco de dados de uso necessitar. Uma vez
que o ambiente esteja estvel e o monitoramento detalhado no seja mais necessrio,
convm reverter as configuraes a seguir aos padres.

Configurao

Valor

Observaes

Proteo contra Saturao do Log Desabilitado


de Eventos

66

O valor padro
Habilitado. Ele
pode ser
desabilitado para
coletar a
quantidade

Configurao

Valor

Observaes

mxima possvel
de dados de
monitoramento.
Para operaes
normais, deve
ser habilitado.
Agenda do Trabalho de Timer
Importao de Dados de Uso de
Microsoft SharePoint Foundation

5 minutos

O valor padro
de 30 minutos.
Se essa
configurao for
reduzida, os
dados sero
importados para
o banco de
dados de uso
com mais
frequncia. Isso
particularmente
til na soluo de
problemas. Para
operaes
normais, o valor
deve ser de 30
minutos.

Habilitado

O valor padro
Desabilitado,
exceto para o
provedor
"Monitoramento
da Integridade da
Pesquisa Eventos de
Rastreamento".
Esses
provedores
coletam de
dados de
integridade para
vrios recursos e
componentes.
Para operaes
normais, convm
reverter ao

Provedores de Diagnstico
Habilitar todos os provedores de
diagnstico

67

Configurao

Valor

Observaes

padro.
Definir intervalos de agendamento 1 minuto
de "job-diagnostics-performancecounter-wfe-provider" e "jobdiagnostics-performance-countersql-provider"

O valor padro
de cinco
minutos. Se
essa
configurao for
reduzida, o
polling dos dados
poder ser
realizado com
mais frequncia.
Isso
particularmente
til na soluo de
problemas. Para
operaes
normais, o valor
deve ser de
cinco minutos.

Diversos
Habilitar rastreamento de pilha
para solicitaes de contedo

Habilitado

O valor padro
Desabilitado. Se
essa
configurao for
habilitada,
permitir o
diagnstico de
falhas de
solicitaes de
contedo usando
o rastreamento
de pilha de
processos. Para
operaes
normais, ela
deve ser
desabilitada.

Habilitar o Painel do
Desenvolvedor

Habilitado

O valor padro
Desabilitado. Se
essa
configurao for
habilitada,
permitir o
diagnstico de
pginas lentas ou

68

Configurao

Valor

Observaes

outros problemas
usando o Painel
do
Desenvolvedor.
Para operaes
normais e uma
vez que a
soluo de
problemas no
seja mais
necessria, ela
deve ser
desabilitada.
Coleta de Dados de Uso
Uso de Importao de Contedo

Habilitado

Uso de Exportao de Contedo


Solicitaes de Pgina
Uso de Recursos
Uso de Consultas de Pesquisa
Uso de Inventrio de Site
Trabalhos de Timer
Uso de Classificao

A habilitao dos
logs desse
conjunto de
contadores
permite coletar
mais dados de
uso em todo o
ambiente e
compreender
melhor os
padres de
trfego no
ambiente.

Contadores de desempenho
Se estiver utilizando o banco de dados de uso, voc poder adicionar os contadores de
desempenho que o ajudam a monitorar e avaliar o desempenho do farm para o banco de
dados de uso, de tal forma que eles sejam registrados automaticamente em um intervalo
especfico (30 minutos, por padro). Dessa forma, voc pode consultar o banco de
dados de uso para recuperar esses contadores e criar um grfico dos resultados ao
longo do tempo. A seguir h um exemplo do uso do cmdlet AddSPDiagnosticsPerformanceCounter do PowerShell para adicionar o contador %
Tempo de Processador ao banco de dados de uso. Isso s precisa ser executado em um
dos servidores Web:
Cdigo
da
cpia
Add-SPDiagnosticsPerformanceCounter -Category "Processor" -Counter "%
Processor Time" -Instance "_Total" -WebFrontEnd

69

H diversos contadores de desempenho genricos que voc deve monitorar para


qualquer sistema de servidor. A tabela a seguir os descreve.

Contador de Desempenho

Descrio

Processador

Voc deve monitorar o desempenho do


processador para garantir que a totalidade
de seu uso no permanea
consistentemente elevada (acima de 80 por
cento), pois isso indica que o sistema no
seria capaz de lidar com picos de atividade
repentinos. Alm disso, no estado comum,
voc no ver um efeito domin em que, um
componente falhar, causar problemas nos
demais componentes. Por exemplo, se tiver
trs servidores Web, voc dever garantir
que a CPU mdia em todos os servidores
esteja abaixo de 60%, de modo que, se um
deles falhar, os outros dois ainda possam
assumir a carga adicional.

Interface de rede

Monitore a taxa qual os dados so


enviados e recebidos atravs da placa de
interface de rede. A taxa deve permanecer
abaixo de 50% da capacidade da rede.

Discos e Cache

H diversas opes de disco lgico que


voc deve monitorar regularmente. O
espao em disco disponvel essencial em
qualquer estudo de capacidade, mas voc
tambm deve analisar o tempo pelo qual o
disco est ocioso. Dependendo dos tipos de
aplicativos ou servios em execuo no
servidor, voc pode examinar os tempos de
leitura e gravao de disco. Filas estendidas
para as funes de gravao ou leitura
afetaro o desempenho. O cache tem
grande impacto sobre as operaes de
leitura e gravao. Voc deve monitorar se
h maior nmero de falhas de cache.

Arquivo de Memria e Paginao

Monitore a quantidade de memria fsica


disponvel para alocao. Se houver
memria insuficiente, isso levar ao uso
excessivo do arquivo de paginao e a um
aumento no nmero de falhas de pgina por
segundo.

70

Contadores do Sistema
A tabela a seguir fornece informaes sobre contadores e objetos do sistema que voc
pode adicionar ao conjunto de contadores monitorados no banco de dados de uso
utilizando o SPDiagnosticPerformanceCounter em um servidor Web.

Objetos e contadores

Descrio

Processador
% Tempo de Processador

Mostra o uso do processador ao longo de


um perodo de tempo. Se o uso for
consistentemente elevado demais, voc
poder verificar que o desempenho est
sendo prejudicado. Lembre-se de contar
"Total", em sistemas multiprocessador.
Voc tambm pode medir a utilizao em
cada processador, para garantir um
desempenho equilibrado entre os ncleos.

Disco
- Comprimento Mdio da Fila de Disco

Mostra o nmero mdio de solicitaes de


leitura e gravao que foram enfileiradas
para o disco selecionado durante o intervalo
de amostragem. Um comprimento de fila de
disco maior pode no ser um problema,
desde que as leitura/gravaes de disco no
sejam prejudicadas e o sistema esteja
funcionando em um estado estvel, sem
aumentar as filas.

Comprimento Mdio da Fila de Leitura de


Disco

O nmero mdio de solicitaes de leitura


que esto na fila.

Comprimento Mdio da Fila de Gravao de O nmero mdio de solicitaes de


Disco
gravao que esto na fila.
Leituras de Disco/s

O nmero de leituras de disco por segundo.

Gravaes de Disco/s

O nmero de gravaes em disco por


segundo.

Memria
- Mbytes Disponveis

Mostra a quantidade de memria fsica


disponvel para alocao. Se houver
memria insuficiente, isso levar ao uso
excessivo do arquivo de paginao e a um
aumento no nmero de falhas de pgina por
segundo.
71

Objetos e contadores

Descrio

- Falhas de Cache/s

Este contador mostra a taxa qual ocorrem


falhas quando uma pgina procurada no
cache do sistema de arquivos e no
encontrada. Pode se tratar de uma falha
leve, quando a pgina encontrada na
memria, ou de uma falha grave, quando a
pgina est em disco.
O uso efetivo do cache para operaes de
leitura e gravao pode ter um efeito
significativo no desempenho do servidor.
Voc deve monitorar se h maios falhas de
cache, o que indicado por uma reduo
em Leituras Rpidas Assncronas/s ou
Leituras Antecipadas/s.

- Pginas/s

Esse contador mostra a taxa qual as


pginas so lidas ou gravadas em disco,
para resolver falhas de pgina graves. Se o
valor aumentar, isso indicar problemas de
desempenho em todo o sistema.

Arquivo de Paginao
- % Usado e % Pico de Uso

O arquivo de paginao do servidor, s


vezes chamado de arquivo de troca, tem
endereos de memria "virtuais" em disco.
Falhas de pgina ocorrem quando um
processo precisa parar e esperar enquanto
recursos "virtuais" necessrios so
recuperados do disco para a memria. Elas
sero mais frequentes se a memria fsica
for inadequada.

NIC
- Total de Bytes/s

Essa a taxa qual os dados so enviados


e recebidos atravs da placa de interface de
rede. Talvez seja necessrio continuar a
investigar, caso essa taxa seja superior a
40-50% da capacidade da rede. Para
ajustar a investigao, monitore Bytes
recebidos/s e Bytes Enviados/s.

Processo
- Conjunto de Trabalho

Este contador indica o tamanho atual (em


bytes) do conjunto de trabalho de
determinado processo. Essa memria
reservada para o processo, mesmo que no
72

Objetos e contadores

Descrio

esteja em uso.
- % Tempo de Processador

Esse contador indica a porcentagem de


tempo de processador que usada por
determinado processo.

Contagem de Threads (_Total)

O nmero atual de threads.

ASP.NET
Total de Solicitaes

O nmero total de solicitaes desde que o


servio foi iniciado.

Solicitaes Enfileiradas

O Microsoft SharePoint Foundation 2010


fornece os blocos de construo de pginas
HTML que so renderizadas no navegador
do usurio atravs de HTTP. Esse contador
mostra o nmero de solicitaes
aguardando para serem processadas.

Tempo de Espera da Solicitao

O nmero de milissegundos que a


solicitao mais recente aguardou na fila
para processamento. medida que
aumenta o nmero de eventos de espera,
os usurios experimentam desempenho de
renderizao de pginas degradado.

Solicitaes Rejeitadas

O nmero total de solicitaes no


executadas devido a recursos insuficientes
do servidor para process-las. Esse
contador representa o nmero de
solicitaes que retornam um cdigo de
status 503 HTTP, indicando que o servidor
est muito ocupado.

Solicitaes em Execuo (_Total)

O nmero de solicitaes em execuo no


momento.

Solicitaes/s (_Total)

O nmero de solicitaes executadas por


segundo. Isso representa a produtividade
atual do aplicativo. Sob carga constante,
esse nmero deve permanecer dentro de
determinado intervalo, com exceo de
outro trabalho do servidor (como coleta de
lixo, threads de limpeza de cache,
ferramentas de servidor externas e assim
por diante).

Memria .NET CLR


N de Coletas da Ger. 0

Exibe o nmero de vezes que os objetos da


73

Objetos e contadores

Descrio

gerao 0 (ou seja, os objetos mais novos e


alocados mais recentemente) foram
submetidos a coleta de lixo desde que o
aplicativo foi iniciado. Esse nmero til
como uma razo de Gerao 0: Gerao 1:
Gerao 2 para garantir que o nmero de
conjuntos da Gerao 2 no exceda em
muito os conjuntos da Gerao 0,
otimamente por um fator de 2.
N de Coletas da Ger. 1

Exibe o nmero de vezes que os objetos da


gerao 1 foram submetidos a coleta de lixo
desde que o aplicativo foi iniciado.

N de Coletas da Ger. 2

Exibe o nmero de vezes que os objetos da


gerao 2 foram submetidos a coleta de lixo
desde que o aplicativo foi iniciado. O
contador incrementado ao final de uma
coleta de lixo da gerao 2 (tambm
chamada de coleta de lixo completa).

% Tempo na Coleta de Lixo

Exibe a porcentagem de tempo que foi


gasto na execuo de uma coleta de lixo
desde o ltimo ciclo de coleta de lixo. Esse
contador geralmente indica o trabalho feito
pelo coletor de lixo para recolher e
comprimir memria em nome do aplicativo,
sendo atualizado apenas ao final de cada
coleta de lixo. Ele no uma mdia; seu
valor reflete o ltimo valor observado. Esse
contador deve ser inferior a 5% em
operao normal.

Contadores do SQL Server


A tabela a seguir fornece informaes sobre objetos e contadores do SQL Server.

Objetos e contadores

Descrio

Estatsticas Gerais

Esse objeto fornece contadores para


monitorar a atividade em todo o servidor
geral, como o nmero de conexes atuais e
o nmero de usurios que se conectam e
desconectam por segundo de
computadores que executam uma instncia
do SQL Server.

Conexes de Usurio

Esse contador mostra a quantidade de


74

Objetos e contadores

Descrio

conexes de usurio em sua instncia do


SQL Server. Se esse nmero crescer
500 por cento em relao linha de base,
talvez haja uma reduo do desempenho.
Bancos de Dados

Esse objeto fornece contadores para


monitorar operaes de cpia em massa,
produtividade de backup e restaurao e
atividades de log de transaes. Monitore
as transaes e o log de transaes para
determinar o volume de atividades dos
usurios no banco de dados e o quanto o
log de transaes est ficando cheio. O
volume de atividades dos usurios pode
determinar o desempenho do banco de
dados e afetar o tamanho do log, o bloqueio
e a replicao. Monitorar a atividade de log
de baixo nvel para medir a atividade dos
usurios e o uso de recursos pode ajud-lo
a identificar afunilamentos de desempenho.

Transaes/s

Esse contador mostra a quantidade de


transaes por segundo em determinado
banco de dados ou em toda a instncia do
SQL Server. Esse nmero serve para ajudlo a criar uma linha de base e solucionar
problemas.

Bloqueios

Esse objeto fornece informaes sobre


bloqueios do SQL Server em tipos de
recursos individuais.

Nmero de Deadlock/s

Esse contador mostra o nmero de


deadlocks no SQL Server por segundo.
Esse valor normalmente deve ser 0.

Tempo de Espera Mdio (ms)

Este contador mostra a quantidade mdia


de tempo de espera para cada solicitao
de bloqueio que resultou em uma espera.

Tempo de Espera de Bloqueio (ms)

Esse contador mostra o tempo total de


espera para bloqueios no ltimo segundo.

Esperas de Bloqueio/s

Este contador mostra o nmero de


bloqueios por segundo que no puderam
ser atendidos imediatamente e precisaram
esperar recursos

Travas

Esse objeto fornece contadores para


monitorar bloqueios internos de recursos do
75

Objetos e contadores

Descrio

SQL Server chamados travas. O


monitoramento de travas para determinar a
atividade dos usurios e o uso de recursos
pode ajud-lo a identificar afunilamentos de
desempenho.
Tempo Mdio de Espera de Trava (ms)

Esse contador mostra o tempo mdio de


espera de trava para solicitaes de trava
que precisaram esperar.

Esperas de Trava/s

Esse contador mostra o nmero de


solicitaes de trava por segundo que no
puderam ser atendidas imediatamente.

Estatsticas SQL

Esse objeto fornece contadores para


monitorar a compilao e o tipo de
solicitaes enviadas a uma instncia do
SQL Server. O monitoramento do nmero
de compilaes e recompilaes de
consultas e do nmero de lotes recebidos
por uma instncia do SQL Server indica a
rapidez com que o SQL Server est
processando as consultas de usurios e a
eficincia com que o otimizador de consulta
est processando as consultas.

Compilaes de SQL/s

Esse contador indica o nmero de vezes


que o caminho de cdigo de compilao
inserido por segundo.

Recompilaes de SQL/s

Esse contador indica o nmero de vezes


que recompilaes de declarao so
disparadas por segundo.

Cache de Planos

Esse objeto fornece contadores para


monitorar como o SQL Server usa a
memria para armazenar objetos como
procedimentos armazenados, instrues
Transact-SQL ad-hoc e preparadas e
gatilhos.

Taxa de Acertos do Cache

Esse contador indica a taxa entre acertos e


pesquisas de cache para planos.

Cache do buffer

Este objeto fornece contadores para


monitorar como o SQL Server usa a
memria para armazenar pginas de dados,
estruturas de dados internas e o cache de
procedimento, bem como contadores para
monitorar a E/S fsica enquanto o SQL
76

Objetos e contadores

Descrio

Server l e grava pginas de banco de


dados.
Taxa de Acertos do Cache do Buffer

Esse contador mostra a porcentagem de


pginas encontradas no cache do buffer
sem a necessidade de leitura do disco. A
taxa o nmero total de acertos de cache
dividido pelo nmero total de pesquisas de
cache desde que uma instncia do SQL
Server foi iniciada.

Removendo afunilamentos
Os afunilamentos do sistema representam um ponto de conteno em que no h
recursos suficientes para atender s solicitaes de transaes do usurio. Elas podem
ser de hardware fsico, ambiente operacional ou baseadas em aplicativos. Muitas vezes,
a razo para o afunilamentos consiste em um cdigo personalizado ineficiente ou em
solues de terceiros, e um exame desses itens poderia render melhores resultados do
que a adio de hardware. Outra causa comum de afunilamentos a configurao
incorreta do farm ou uma implementao de soluo ineficiente que estrutura os dados
de uma maneira que requer mais recursos do que o necessrio. Para um administrador
de sistema, essencial gerenciar os afunilamentos monitorando constantemente o
desempenho. Ao identificar um problema de desempenho, voc deve avaliar a melhor
resoluo para remover o afunilamento. Os contadores de desempenho e outros
aplicativos de monitoramento de desempenho, como o SCOM (System Center
Operations Manager), so as principais ferramentas de monitoramento e anlise de
problemas, para que voc possa desenvolver uma soluo.

Resoluo de afunilamentos fsicos


Os afunilamentos fsicos so baseados em conteno de processador, disco, memria e
rede: muitas solicitaes esto disputando muito poucos recursos fsicos. Os objetos e
contadores descritos no tpico Monitorando o desempenho indicam que o problema de
desempenho est localizado, por exemplo, no processador de hardware ou ASP.NET.
Para a resoluo de afunilamentos, voc deve identificar o problema e fazer uma ou
mais alteraes que atenuam o problema de desempenho.
Os problemas raramente acontecem de forma instantnea; em geral, h uma gradual
degradao do desempenho que voc poder rastrear se realizar o monitoramento
regularmente, usando sua ferramenta de monitor de desempenho ou um sistema mais
sofisticado, como o SCOM. Para ambas as opes, em diferentes graus, possvel
inserir solues em um alerta, em forma de texto de aconselhamento ou comandos com
script.
Talvez voc tenha que resolver problemas de afunilamento fazendo alteraes em
configuraes de hardware ou do sistema, aps determinar que os problemas no so
causados por configurao incorreta, cdigo personalizado ineficiente ou solues de
terceiros ou uma implementao de soluo ineficiente. As tabelas a seguir identificam
limites de problemas e possveis opes de resoluo. Algumas das opes sugerem
modificaes ou atualizaes de hardware.
77

Objetos e contadores

Problema

Opes de resoluo

Processador
Processador - % Tempo de Mais de 75-85%
Processador

Atualizar o processador
Aumentar o nmero de
processadores
Adicionar servidor(es)

Disco
Comprimento Mdio da Fila Aumentando gradualmente; Aumentar o nmero ou a
o sistema no est em um velocidade dos discos
de Disco
estado de equilbrio e a fila Alterar configurao de matriz
est aumentando
para distribuio
Mover alguns dados para um
servidor alternativo
% Tempo Ocioso

Mais de 90%

Aumentar o nmero de discos


Mover dados para um disco ou
servidor alternativo

% de Espao Livre

Menos de 30%

Aumentar o nmero de discos


Mover dados para um disco ou
servidor alternativo

Memria
Mbytes Disponveis

Menos de 2 GB em um
servidor Web.

Adicionar memria.
Observao:
A memria disponvel do SQL
Server ser baixa, por design, e
isso nem sempre indica um
problema.

Falhas de Cache/s

Mais de 1

Adicionar memria
Aumente a velocidade ou o
tamanho do cache, se possvel
Mover dados para um disco ou
servidor alternativo

Pginas/s

Mais de 10

Adicionar memria

Arquivo de Paginao
78

Objetos e contadores

Problema

Opes de resoluo

% Usado e % Pico de Uso O arquivo de paginao do Adicionar memria


servidor, s vezes
chamado de arquivo de
troca, tem endereos de
memria "virtuais" em
disco. Falhas de pgina
ocorrem quando um
processo precisa parar e
esperar enquanto recursos
"virtuais" necessrios so
recuperados do disco para
a memria. Elas sero mais
frequentes se a memria
fsica for inadequada.
NIC
Total de Bytes/s

Mais de 40-50% da
Continuar a investigar
capacidade da rede. Essa monitorando Bytes recebidos/s
a taxa qual os dados so e Bytes Enviados/s
enviados e recebidos
Reavaliar a velocidade da placa
atravs da placa de
de rede de interface
interface de rede.
Verificar o nmero, tamanho e
uso de buffers de memria

Processo
Conjunto de Trabalho

Mais de 80% da memria


total

% Tempo de Processador Mais de 75-85%.

Adicionar memria
Aumentar o nmero de
processadores
Redistribuir a carga de trabalho
para servidores adicionais

ASP.NET
Reciclagens do Pool de
Aplicativos

Vrias por dia, causando


lentido intermitente.

Verifique se voc no
implementou configuraes que
reciclam automaticamente o
pool de aplicativos sem
necessidade ao longo de todo o
dia.

Solicitaes Enfileiradas

Centenas ou milhares de
solicitaes enfileiradas.

Implementar servidores Web


adicionais
O mximo padro para esse
contador 5.000, e voc pode
alterar essa configurao no

79

Objetos e contadores

Problema

Opes de resoluo

arquivo Machine.config
Tempo de Espera da
Solicitao

medida que aumenta o


nmero de eventos de
espera, os usurios
experimentam
desempenho de
renderizao de pginas
degradado.

Implementar servidores Web


adicionais

Solicitaes Rejeitadas

Mais de 0

Implementar servidores Web


adicionais

Consulte tambm
Conceitos
Viso geral do gerenciamento da capacidade e dimensionamento do SharePoint Server
2010
Testes de desempenho para SharePoint Server 2010
Planejamento de capacidade para SharePoint Server 2010
Planejamento e configurao de armazenamento e capacidade do SQL Server
(SharePoint Server 2010)

Outros recursos
Health Monitoring (SharePoint Server 2010)

80

Gerenciamento de capacidade do
SharePoint Server 2010: limites de
software
Este documento descreve os delimitadores de software e os limites do Microsoft
SharePoint Server 2010. Entre eles, podemos incluir:
Delimitadores: limites estticos que no podem ser excedidos por design

Limites: limites configurveis que podem ser excedidos para atender a requisitos
especficos

Limites com suporte: limites configurveis que foram definidos por padro como
um valor testado.
Observao:

As informaes de planejamento de capacidade neste documento fornecem diretrizes


que voc deve usar no seu planejamento. Elas se baseiam em testes realizados na
Microsoft em propriedades dinmicas. No entanto, os resultados obtidos por voc
provavelmente variaro com base no equipamento usado e nos recursos e na
funcionalidade implementados para seus sites.
Neste artigo:
Viso geral de delimitadores e limites

Delimitadores, limites e limites com suporte

Como os limites so estabelecidos

Limites e delimitadores

Limites por hierarquia

Limites de aplicativos Web

Servidor Web e limites de servidor de aplicativos

Limites de bancos de dados de contedo

Limites de conjuntos de sites

Limites de listas e bibliotecas

Limites de colunas

Limites de pginas

Limites por recurso

Limites de pesquisa

Limites de Servio de Perfil de Usurio

Limites de implantao de contedo


81

Limites de blog

Limites de Servios Corporativos de Conectividade

Limites de fluxos de trabalho

Limites de repositrios de termos de Metadados Gerenciados (bancos de dados)

Limites dos Servios do Visio

Limites dos Servios PerformancePoint

Limites do Word Automation Services

Limites do SharePoint Workspace

Limites do OneNote

Limites do Servio Office Web Applications

Limites do Project Server

Viso geral de delimitadores e limites


Este artigo contm informaes para ajud-lo a entender os limites de desempenho e
capacidade testados do SharePoint Server 2010; alm disso, oferece diretrizes sobre
como os limites esto relacionados ao desempenho aceitvel. Use as informaes deste
artigo para determinar se a implantao planejada se enquadra nos limites aceitveis de
desempenho e capacidade e para configurar adequadamente os limites em seu
ambiente.
Os resultados dos testes e as diretrizes fornecidas neste artigo aplicam-se a um farm
nico do SharePoint Server 2010. A adio de servidores instalao pode no
aumentar os limites de capacidade dos objetos listados nas tabelas da seo Limites e
delimitadores, mais adiante neste tpico. Por outro lado, a adio de computadores
servidores aumenta a taxa de transferncia de um farm de servidores, o que pode ser
necessrio para a obteno de um desempenho aceitvel com muitos objetos. Em
alguns casos, os requisitos para um alto nmero de objetos em uma soluo podem
exigir mais servidores no farm.
Observe que h muitos fatores capazes de afetar o desempenho em um determinado
ambiente, e cada um deles pode faz-lo em reas diferentes. Alguns dos resultados de
testes e das recomendaes deste artigo podem estar relacionados a recursos ou a
operaes do usurio inexistentes no seu ambiente e, assim, talvez no sejam aplicveis
sua soluo. Somente testes completos podem fornecer dados exatos relacionados ao
seu ambiente especfico.

Delimitadores, limites e limites com suporte


No SharePoint Server 2010, h determinados limites que, por design, no podem ser
excedidos e outros limites definidos como valores padro que podem ser alterados pelo
administrador do farm. H tambm certos limites que no so representados por um
valor configurvel, como o nmero de conjuntos de sites por aplicativo Web.
Delimitadores so limites absolutos que no podem ser excedidos por design.
importante entend-los para garantir que voc no faa pressuposies incorretas
ao projetar seu farm.
Um exemplo de delimitador o limite de tamanho do documento de 2 GB. No
possvel configurar o SharePoint Server para armazenar documentos com mais de 2
GB. Esse um valor absoluto interno que no pode ser excedido por design.
82

Limites so aqueles que possuem um valor padro que no pode ser excedido, a
menos que o valor seja modificado. Em determinadas circunstncias, limites podem
ser excedidos para acomodar variaes no design do farm, mas importante
entender que isso pode afetar o desempenho do farm, alm do valor efetivo de
outros limites.
O valor padro de certos limites s pode ser excedido at um valor mximo absoluto.
Um bom exemplo disso o limite de tamanho de documento. Por padro, o limite de
tamanho de documento definido como 50 MB, mas pode ser alterado para dar
suporte ao limite mximo de 2 GB.
Limites com suporte definem o valor testado para um determinado parmetro. Os
valores padro para esses limites foram definidos por meio de testes e representam
as limitaes conhecidas do produto. Se os limites com suporte forem excedidos,
isso poder causar resultados inesperados, prejudicar o desempenho de maneira
significativa ou provocar outros efeitos nocivos.
Alguns limites com suporte so os parmetros configurveis definidos por padro
com o valor recomendado, enquanto outros limites com suporte esto relacionados a
parmetros que no so representados por um valor configurvel.
Um exemplo de limite com suporte o nmero de conjuntos de sites por aplicativo Web.
O limite com suporte de 250.000, que o maior nmero de conjuntos de sites por
aplicativo Web que atenderam aos parmetros de comparao durante os testes.
importante estar ciente de que muitos dos valores limites fornecidos neste documento
representam um ponto em uma curva que descreve uma carga crescente de recursos e
a consequente reduo no desempenho medida que o valor aumenta. Portanto, se
forem excedidos determinados limites, como o nmero de conjuntos de sites por
aplicativo Web, isso poder resultar apenas em uma reduo fracionria no desempenho
do farm. No entanto, na maioria dos casos, operar em um limite estabelecido ou prximo
a ele no uma prtica recomendada, pois as metas de desempenho e confiabilidade
aceitveis so alcanadas mais facilmente quando o design de um farm possibilita um
equilbrio razovel dos valores limite.
Limites e diretrizes de limites com suporte so determinados pelo desempenho. Em
outras palavras, voc pode exceder os valores padro dos limites, mas, medida que
aumentar o valor limite, o desempenho do farm e o valor efetivo de outros limites
podero ser afetados. Muitos limites no SharePoint Server podem ser alterados, mas
importante entender como a alterao de um determinado limite afeta outras partes do
farm.

Como os limites so estabelecidos


No SharePoint Server 2010, limites e limites com suporte so estabelecidos por meio de
testes e da observao do comportamento do farm sob cargas crescentes, at o ponto
em que os servios e as operaes do farm atingirem seus limites operacionais efetivos.
Alguns servios e componentes do farm podem dar suporte a uma carga maior do que
outros, de modo que, em alguns casos, voc deve atribuir um valor limite com base na
mdia de vrios fatores.
Por exemplo, as observaes sobre o comportamento do farm sob carga quando
conjuntos de sites so adicionados indicam que certos recursos apresentam latncia
inaceitavelmente alta, enquanto outros recursos ainda esto operando dentro dos
parmetros aceitveis. Portanto, o valor mximo atribudo ao nmero de conjuntos de
sites no absoluto, sendo calculado com base em um conjunto esperado de
83

caractersticas de uso em que o desempenho geral do farm seria aceitvel dentro do


limite especfico na maioria das circunstncias.
Obviamente, se alguns servios estiverem operando de acordo com parmetros que
sejam mais elevados do que aqueles usados para testar os limites, os limites mximos
efetivos de outros servios sero reduzidos. Assim, importante executar um
gerenciamento rigoroso da capacidade e dimensionar os exerccios de testes para
implantaes especficas, de forma a estabelecer limites efetivos para esse ambiente.
Observao: no descrevemos o hardware que foi usado para validar os limites neste
documento, pois os limites foram coletados em vrios farms e ambientes. Para obter
descries dos farms usados nos testes, consulte Recomendaes e resultados de
testes de desempenho e capacidade (SharePoint Server 2010) e Performance and
capacity technical case studies (SharePoint Server 2010) (em ingls).

A metfora do equalizador
Voc pode considerar limites e limites com suporte como controles deslizantes em um
equalizador grfico, em que cada limite representa uma certa frequncia. Nessa
metfora, se for aumentado o valor de um limite, isso poder diminuir o valor efetivo de
um ou mais outros limites.
Imagine que um controle deslizante represente o nmero mximo de documentos por
biblioteca, um limite com suporte com um valor mximo testado de cerca de 30 milhes.
No entanto, esse valor depende de outro controle deslizante, que representa o tamanho
mximo de documentos no farm, um limite com valor padro de 50 MB.
Se voc alterar o tamanho mximo de documento para 1 GB para acomodar vdeos ou
outros objetos grandes, o nmero de documentos que a biblioteca pode fornecer aos
usurios com eficincia ser reduzido de maneira correspondente. Por exemplo, a
configurao de hardware e a topologia de um determinado farm podem dar suporte a
um milho de documentos, correspondendo a at 50 MB. No entanto, o mesmo farm
com o mesmo nmero de documentos no poder atender s mesmas metas de latncia
e taxa de transferncia se o farm estiver servindo um tamanho mdio de documento
maior, j que o tamanho limite foi definido como 1 GB.
O grau de reduo do nmero mximo de documentos neste exemplo difcil de prever
e se baseia no nmero de arquivos grandes na biblioteca, no volume de dados que eles
contm, nas caractersticas de uso do farm e na disponibilidade de recursos de
hardware.

Limites e delimitadores
Esta seo lista os objetos que podem fazer parte de uma soluo e fornece diretrizes
para o desempenho aceitvel de cada tipo de objeto. Desempenho aceitvel significa
que o sistema, da maneira como foi testado, pode dar suporte a esse nmero de objetos,
mas o nmero no pode ser excedido sem que ocorra uma certa reduo do
desempenho ou do valor dos limites relacionados. Os objetos so listados por escopo e
por recurso. Dados de limites so fornecidos, juntamente com observaes que
descrevem as condies em que o limite obtido e links para informaes adicionais,
sempre que estiverem disponveis.
Use as diretrizes contidas neste artigo para rever os planos gerais da sua soluo. Se
esses planos excederem as diretrizes recomendadas para um ou mais objetos, execute
uma ou mais das seguintes aes:
Avalie a soluo para garantir que haja compensaes em outras reas.
84

Sinalize essas reas para testes e monitoramento medida que criar sua
implantao.

Reprojete ou particione a soluo para garantir que voc no exceda as diretrizes de


capacidade.

Limites por hierarquia


Esta seo fornece limites organizados pela hierarquia lgica de um farm do SharePoint
Server 2010.

Limites de aplicativos Web


A tabela a seguir lista as diretrizes recomendadas para aplicativos Web.

Limite

Valor mximo

Tipo de
limite

Observaes

Banco de dados de
contedo

300 por aplicativo Web

Com
suporte

Com 300 bancos de


dados de contedo por
aplicativo Web, no so
afetadas as operaes de
usurios finais, como
abertura de sites ou de
conjuntos de sites.
Porm, operaes
administrativas, como a
criao de um novo
conjunto de sites, tero
seu desempenho
reduzido. recomendvel
usar o Windows
PowerShell para
gerenciar o aplicativo
Web quando houver um
grande nmero de
bancos de dados de
contedo, pois a interface
de gerenciamento tornase lenta e difcil de
navegar.

Zona

5 por aplicativo Web

Delimitador O nmero de zonas


definidas para um farm
embutido em cdigo
como cinco. As zonas
so Padro, Intranet,
Extranet, Internet e
Personalizada.

Caminho gerenciado

20 por aplicativo Web

Com
suporte

85

Os caminhos
gerenciados so
armazenados em cache

Limite

Tipo de
limite

Valor mximo

Observaes

no servidor Web, e os
recursos da CPU so
usados para processar
solicitaes recebidas em
relao lista de
caminhos gerenciados.
Se for excedido o total de
20 caminhos gerenciados
por aplicativo Web, ser
adicionada carga ao
servidor Web para cada
solicitao.
Se voc planeja exceder
20 caminhos gerenciados
em um determinado
aplicativo Web,
recomendvel testar se o
sistema apresentar
desempenho aceitvel.
Tamanho de cache de
soluo

300 MB por aplicativo


Web

Limite

O cache de soluo
permite que o servio
InfoPath Forms
mantenha as solues
em cache, para acelerar
a recuperao das
mesmas. Se o tamanho
do cache for excedido, as
solues sero
recuperadas do disco, o
que poder tornar os
tempos de resposta mais
lentos. Voc pode
configurar o tamanho do
cache de soluo por
meio do cmdlet SetSPInfoPathFormsService
do Windows PowerShell.
Para obter mais
informaes, consulte
SetSPInfoPathFormsService.

Servidor Web e limites de servidor de aplicativos


A tabela a seguir lista as diretrizes recomendadas para servidores Web no farm.
86

Limite

Valor mximo

Tipo de Observaes
limite

Pools de aplicativos

10 por servidor Web

Com O nmero mximo


suporte determinado pelos recursos
de hardware.
Esse limite depende em
grande parte dos seguintes
itens:
A quantidade de
memria RAM alocada
para os servidores Web

A carga de trabalho que


o farm est servindo, ou
seja, a base de usurios
e as caractersticas de
uso (um nico pool de
aplicativos extremamente
ativo pode atingir 10 GB
ou mais)

Limites de bancos de dados de contedo


A tabela a seguir lista as diretrizes recomendadas para bancos de dados de contedo.

Limite

Valor mximo

Tipo de
limite

Observaes

Tamanho do banco de
dados de contedo

200 GB por banco de


dados de contedo

Com
suporte

altamente
recomendvel limitar
o tamanho dos
bancos de dados de
contedo a 200 GB
para ajudar a
garantir o
desempenho do
sistema.
H suporte para
tamanhos de bancos
de dados de
contedo de at
1 terabyte somente
para grandes
repositrios de um
nico site e

87

Limite

Tipo de
limite

Valor mximo

Observaes

arquivamentos com
E/S e padres de
uso no
colaborativos, como
sites da Central de
Registros. H
suporte para
tamanhos de bancos
de dados maiores
nesses cenrios
porque seus padres
de E/S e formatos
tpicos de estrutura
de dados foram
projetados e
testados em escalas
maiores. Para obter
mais informaes
sobre repositrios de
documentos em
grande escala,
consulte a seo
sobre estimativa de
requisitos de
desempenho e
capacidade para
repositrios de
documentos em
grande escala,
disponvel em
Recomendaes e
resultados de testes
de desempenho e
capacidade
(SharePoint Server
2010), e a seo
Cenrios comuns de
gerenciamento de
contedo em grande
escala, disponvel
em Enterprise
content storage
planning (SharePoint
Server 2010).
Um conjunto de sites
no deve ultrapassar
100 GB, a menos
88

Limite

Tipo de
limite

Valor mximo

Observaes

que haja apenas um


conjunto de sites no
banco de dados.
Conjuntos de sites por
banco de dados de
contedo

2.000 recomendados
Mximo de 5.000

Com
suporte

altamente
recomendvel limitar
o nmero de
conjuntos de sites
em um banco de
dados de contedo
para 2000. No
entanto, h suporte
para at 5000
conjuntos de sites
em um banco de
dados.
Esses limites
referem-se
velocidade de
atualizao. Quanto
maior for o nmero
de conjuntos de sites
em um banco de
dados, mais lenta
ser a atualizao.
O limite quanto ao
nmero de conjuntos
de sites em um
banco de dados est
subordinado ao
limite de tamanho de
um banco de dados
de contedo que
tenha mais de um
conjunto de sites
(200 GB). Portanto,
medida que o
nmero de conjuntos
de sites em um
banco de dados
aumentar, o
tamanho mdio dos
conjuntos de sites
nele contidos dever
diminuir.
Se voc exceder o
limite de 2000

89

Limite

Tipo de
limite

Valor mximo

Observaes

conjuntos de sites, o
tempo de inatividade
durante as
atualizaes poder
ser mais longo. Se
voc planeja exceder
2000 conjuntos de
sites,
recomendvel ter
uma estratgia clara
de atualizao e
obter hardware
adicional para
acelerar as
atualizaes e as
atualizaes de
software que afetam
os bancos de dados.
Para definir o nvel
de alerta para o
nmero de sites em
um banco de dados
de contedo, use o
cmdlet SetSPContentDatabase
do Windows
PowerShell com o
parmetro WarningSiteCount.
Para obter mais
informaes,
consulte SetSPContentDatabase.
Subsistema de
Delimitador Quando o
O tempo at o primeiro
armazenamento RBS
SharePoint Server
byte de qualquer resposta
(Remote BLOB Storage) no do NAS no pode exceder
2010 estiver
Armazenamento NAS
configurado para
20 milissegundos
(Network Attached Storage)
usar o RBS, e os
BLOBs residirem no
armazenamento
NAS, considere o
delimitador a seguir.
Do momento em que
o SharePoint Server
2010 solicita um
BLOB at o
90

Limite

Tipo de
limite

Valor mximo

Observaes

momento em que ele


recebe o primeiro
byte do NAS, no
podem decorrer
mais de 20
milissegundos.

Limites de conjuntos de sites


A tabela a seguir lista as diretrizes recomendadas para conjuntos de sites.

Limite

Valor mximo

Tipo de
limite

Observaes

Site

250.000 por conjunto de


sites

Com
suporte

O nmero mximo
recomendado de
sites e subsites
de 250.000 sites.
Voc pode criar um
nmero total
bastante grande de
sites aninhando os
subsites. Por
exemplo, em uma
hierarquia
superficial, com
100 sites, cada um
com 1.000
subsites, voc teria
um total de
100.000 sites. Ou
ento, uma
hierarquia
profunda com 100
sites, cada um com
10 nveis de
subsites, tambm
conteria um total
de 100.000 sites.
Observao: a
excluso ou a
criao de um site
ou subsite pode
afetar de maneira
significativa a

91

Limite

Tipo de
limite

Valor mximo

Observaes

disponibilidade de
um site. O acesso
ao site e aos
subsites ser
limitado enquanto
o site est sendo
excludo. A
tentativa de criar
vrios subsites ao
mesmo tempo
tambm poder
falhar.
Tamanho de conjunto de
sites

100 GB por conjunto de


sites

Limites de listas e bibliotecas


92

Com
suporte

Um conjunto de
sites no deve
ultrapassar
100 GB, a menos
que haja apenas
um conjunto de
sites no banco de
dados.
Certas aes de
conjuntos de sites,
como
backup/restaurao
de conjuntos de
sites ou o cmdlet
Move-SPSite do
Windows
PowerShell,
causam grandes
operaes do
Microsoft SQL
Server, que
podero afetar o
desempenho ou
falhar se outros
conjuntos de sites
estiverem ativos no
mesmo banco de
dados. Para obter
mais informaes,
consulte MoveSPSite.

A tabela a seguir lista as diretrizes recomendadas para listas e bibliotecas. Para obter
mais informaes, consulte o white paper sobre o design de grandes listas e
maximizao do desempenho de listas, disponvel em Recomendaes e resultados de
testes de desempenho e capacidade (SharePoint Server 2010).

Limite

Valor mximo

Tipo de
limite

Tamanho de
linha de lista

8.000 bytes por Limite


linha

Tamanho do
arquivo

2 GB

Documentos

30.000.000 por Com


biblioteca
suporte

Voc pode criar bibliotecas de documentos


muito grandes aninhando pastas ou usando
a hierarquia de sites e modos de exibio
padro. Esse valor pode variar dependendo
da forma como os documentos e as pastas
so organizados e conforme o tipo e o
tamanho dos documentos armazenados.

Verses
principais

400.000

Se voc exceder esse limite, operaes de


arquivo bsicas, como abrir ou salvar
arquivos, excluir e exibir o histrico de
verses, talvez no tenham xito.

Itens

30.000.000 por Com


lista
suporte

Voc pode criar listas muito grandes usando


modos de exibio padro, hierarquias de
sites e a navegao de metadados. Esse
valor pode variar dependendo do nmero de
colunas na lista e da utilizao da lista.

Limite de
tamanho de
linhas

6 linhas de
Com
tabela internas suporte
ao banco de
dados usadas
para uma lista
ou um item da
biblioteca

Especifica o nmero mximo de linhas de


tabela internas ao banco de dados que
podem ser usadas para uma lista ou um
item da biblioteca. Para acomodar listas
amplas com vrias colunas, cada item pode
ser quebrado em vrias linhas de tabela
internas, at seis linhas por padro. Isso

Observaes

Cada item da biblioteca ou lista pode ocupar


apenas um total de 8000 bytes no banco de
dados. So reservados 256 bytes para
colunas internas, o que deixa 7.744 bytes
para colunas de usurios finais. Para obter
detalhes sobre o espao consumido por
cada tipo de campo, consulte Limites de
colunas.

Delimitador O tamanho de arquivo padro mximo de


50 MB. Ele pode ser aumentado para at 2
GB; no entanto, um alto volume de arquivos
muito grandes pode afetar o desempenho
do farm.

Com
suporte

93

Limite

Valor mximo

Tipo de
limite

Observaes

configurvel por administradores de farm


somente por meio do modelo de objeto. O
mtodo de modelo de objeto
SPWebApplication.MaxListItemRowStorage.
Operaes em 100 itens por
operao em
massa
massa

Delimitador A interface do usurio permite que no


mximo 100 itens sejam selecionados para
operaes em massa.

Limite de
8 operaes de Limite
pesquisa no
juno por
modo de
consulta
exibio de lista

Especifica o nmero mximo de junes


permitidas por consulta, como aquelas
baseadas em pesquisa, pessoa/grupo ou
colunas de status do fluxo de trabalho. Se a
consulta usar mais de oito junes, a
operao ser bloqueada. Isso no se aplica
a operaes de item nico. Quando voc
usa o modo de exibio mximo por meio do
modelo de objeto (sem especificar campos
de modo de exibio), o SharePoint retorna
at as primeiras oito pesquisas.

Limite do modo 5.000


de exibio de
lista

Limite

Especifica o nmero mximo de itens na


lista ou biblioteca que uma operao de
banco de dados, como uma consulta, pode
processar de uma nica vez, fora da janela
de tempo diria definida pelo administrador
durante a qual as consultas so irrestritas.

Limite do modo 20.000


de exibio de
lista para
auditores e
administradores

Limite

Especifica o nmero mximo de itens na


lista ou biblioteca que uma operao de
banco de dados, como uma consulta, pode
processar de uma nica vez quando feita
por um auditor ou administrador com as
permisses apropriadas. Essa configurao
funciona em conjunto com Permitir
Substituio do Modelo do Objeto.

Subsite

2.000 por modo Limite


de exibio de
site

A interface para enumerar os subsites de


um determinado site no funciona
adequadamente quando o nmero de
subsites ultrapassa 2.000. Da mesma
forma, a pgina Todo o Contedo do Site e
o desempenho do controle de exibio de
rvore diminuiro significativamente
medida que o nmero de subsites
aumentar.

Coautoria no

10 editores

O nmero mximo recomendado de

Limite

94

Limite

Valor mximo

Tipo de
limite

Observaes

editores simultneos 10. O limite 99.

Microsoft Word simultneos por


e no Microsoft documento
PowerPoint
para arquivos
.docx, .pptx e
.ppsx

Se houver 99 coautores com um nico


documento aberto para edio simultnea,
qualquer usurio aps o centsimo ver um
erro do tipo "Arquivo em uso" e dever
exibir uma cpia somente leitura.
Se houver mais de 10 coeditores, isso
prejudicar progressivamente a uma
experincia do usurio, com a ocorrncia de
mais conflitos, e os usurios tero que
passar por mais iteraes para que suas
alteraes sejam carregadas com xito.

Escopo de
segurana

1.000 por lista

Limite

O nmero mximo de escopos de


segurana exclusivos definidos para uma
lista no deve exceder 1.000.
Um escopo o limite de segurana para um
objeto protegvel e quaisquer de seus filhos
que no tenham um limite de segurana
separado definido. Um escopo contm uma
ACL (Lista de Controle de Acesso), mas,
diferentemente de outras ACLs de NTFS,
um escopo pode incluir entidades de
segurana especficas do SharePoint
Server. Os membros de uma ACL para um
escopo podem incluir usurios do Windows,
contas de usurio que no sejam de
usurios do Windows (como contas
baseadas em formulrios), grupos do Active
Directory ou grupos do SharePoint.

Limites de colunas
Os dados do SharePoint Server 2010 so armazenados em tabelas do SQL Server. Para
permitir o nmero mximo de colunas possveis em uma lista do SharePoint, o
SharePoint Server criar vrias linhas no banco de dados quando os dados no
couberem em uma nica linha. Isso chamado de disposio de linhas.
Sempre que uma linha disposta no SQL Server, uma carga de consulta adicional
colocada no servidor quando esse item consultado, porque uma instruo Join SQL
deve ser includa na consulta. Para impedir uma carga excessiva, por padro, so
permitidas no mximo seis linhas do SQL Server para um item do SharePoint. Esse
limite causa uma limitao especfica quanto ao nmero de colunas de cada tipo que
podem ser includas em uma lista do SharePoint. A tabela a seguir descreve os limites
para cada tipo de coluna.

95

O parmetro de disposio de linhas pode ser aumentado acima de seis, mas isso pode
resultar em carga excessiva no servidor. recomendvel realizar testes de desempenho
antes de exceder esse limite. Para obter mais informaes, consulte o white paper sobre
o design de listas grandes e a maximizao do desempenho de listas, que pode ser
acessado em Recomendaes e resultados de testes de desempenho e capacidade
(SharePoint Server 2010).
Cada tipo de coluna tem um valor de tamanho listado em bytes. A soma de todas as
colunas em uma lista do SharePoint no pode exceder 8.000 bytes. Dependendo do uso
das colunas, os usurios podem atingir o limite de 8.000 bytes antes de atingirem o limite
de disposio de seis linhas.

Limite

Valor mximo

Tipo Tamanho por Observaes


de
coluna
limite

Linha nica de
texto

276

Limite 28 bytes

A disposio de linhas do SQL


Server ocorre aps cada 64
colunas em uma lista do
SharePoint. O valor de
disposio padro de seis
linhas permite um mximo de
384 colunas de linha de texto
nica por lista do SharePoint (6
* 64 = 384). No entanto, como
o limite por item de lista do
SharePoint de 8000 bytes,
dos quais 256 bytes so
reservados para colunas
internas do SharePoint, o limite
real de 276 colunas de linha
de texto nica.

Vrias linhas de
texto

192

Limite 28 bytes

A disposio de linhas do SQL


Server ocorre aps cada 32
colunas em uma lista do
SharePoint. O valor de
disposio padro de seis
linhas permite um mximo de
192 colunas com vrias linhas
de texto por lista do SharePoint
(6 * 32 = 192).

Opo

276

Limite 28 bytes

A disposio de linhas do SQL


Server ocorre aps cada 64
colunas em uma lista do
SharePoint. O valor de
disposio padro de seis
linhas permite um mximo de
384 colunas de Opo por lista

96

Limite

Valor mximo

Tipo Tamanho por Observaes


de
coluna
limite

do SharePoint (6 * 64 = 384);
porm, como o limite por item
de lista do SharePoint de
8000 bytes, dos quais 256
bytes so reservados para
colunas internas do
SharePoint, o limite real deve
ser de 276 colunas de opes.
Nmero

72

Limite 12 bytes

A disposio de linhas do SQL


Server ocorre aps cada 12
colunas em uma lista do
SharePoint. O valor de
disposio padro de seis
linhas permite um mximo de
72 colunas de Nmero por lista
do SharePoint (6 * 12 = 72).

Moeda

72

Limite 12 bytes

A disposio de linhas do SQL


Server ocorre aps cada 12
colunas em uma lista do
SharePoint. O valor de
disposio padro de seis
linhas permite um mximo de
72 colunas de Moeda por lista
do SharePoint (6 * 12 = 72).

Data e Hora

48

Limite 12 bytes

A disposio de linhas do SQL


Server ocorre aps cada oito
colunas em uma lista do
SharePoint. O valor de
disposio padro de seis
linhas permite um mximo de
48 colunas de Data e Hora por
lista do SharePoint (6 * 12 =
48).

Pesquisa

96

Limite 4 bytes

A disposio de linhas do SQL


Server ocorre aps cada 16
colunas em uma lista do
SharePoint. O valor de
disposio padro de seis
linhas permite um mximo de
96 colunas de Pesquisa de
valor nico por lista do
SharePoint (6 * 16 = 96).

97

Limite

Valor mximo

Tipo Tamanho por Observaes


de
coluna
limite

Sim/No

96

Limite 5 bytes

A disposio de linhas do SQL


Server ocorre aps cada 16
colunas em uma lista do
SharePoint. O valor de
disposio padro de seis
linhas permite um mximo de
96 colunas de Sim/No por lista
do SharePoint (6 * 16 = 96).

Pessoa ou grupo 96

Limite 4 bytes

A disposio de linhas do SQL


Server ocorre aps cada 16
colunas em uma lista do
SharePoint. O valor de
disposio padro de seis
linhas permite um mximo de
96 colunas de Pessoa ou
Grupo por lista do SharePoint
(6 * 16 = 96).

Hiperlink ou
imagem

138

Limite 56 bytes

A disposio de linhas do SQL


Server ocorre aps cada 32
colunas em uma lista do
SharePoint. O valor de
disposio padro de seis
linhas permite um mximo de
192 colunas de Hiperlink ou
Imagem por lista do SharePoint
(6 * 32 = 192); porm, como o
limite por item de lista do
SharePoint de 8000 bytes,
dos quais 256 bytes so
reservados para colunas
internas do SharePoint, o limite
real deve ser de 138 colunas
de Hiperlink ou Imagem.

Calculada

48

Limite 28 bytes

A disposio de linhas do SQL


Server ocorre aps cada oito
colunas em uma lista do
SharePoint. O valor de
disposio padro de seis
linhas permite um mximo de
48 colunas de Calculada por
lista do SharePoint (6 * 8 = 48).

GUID

Limite 20 bytes

A disposio de linhas do SQL


Server ocorre aps cada

98

Limite

Valor mximo

Tipo Tamanho por Observaes


de
coluna
limite

coluna em uma lista do


SharePoint. O valor de
disposio padro de seis
linhas permite um mximo de
seis colunas de GUID por lista
do SharePoint (6 * 1 = 6).
Inteiros

96

Limite 4 bytes

Metadados
gerenciados

94

Limite 40 bytes
So alocadas quatro colunas
para a
para o primeiro campo de
primeira e Metadados Gerenciados
32 bytes
adicionado a uma lista:
para cada Um campo de pesquisa
uma
para a marca real
subsequente
Um campo de texto oculto
para o valor da cadeia de
caracteres

A disposio de linhas do SQL


Server ocorre aps cada 16
colunas em uma lista do
SharePoint. O valor de
disposio padro de seis
linhas permite um mximo de
96 colunas de Inteiros por lista
do SharePoint (6 * 16 = 96).

Um campo de pesquisa
para o mecanismo de
coleta

Um campo de pesquisa
para transmisso do
mecanismo de coleta
Cada campo de Metadados
Gerenciados subsequente
adicionado a uma lista adiciona
duas colunas:
Um campo de pesquisa
para a marca real

Um campo de texto oculto


para o valor da cadeia de
caracteres
O nmero mximo de colunas
de Metadados Gerenciados
calculado como (14 (16 * (n1))), em que n o valor de
99

Limite

Valor mximo

Tipo Tamanho por Observaes


de
coluna
limite

mapeamento de linha (o
padro 6).
As colunas de dados externos seguem o conceito de uma coluna primria e colunas
secundrias. Ao adicionar uma coluna de dados externa, voc pode selecionar alguns
campos secundrios do tipo de contedo externo que deseja adicionar lista. Por
exemplo, no caso do Tipo de Contedo Externo "Cliente", que tem campos como "ID",
"Nome", "Pas" e "Descrio", ao adicionar uma coluna de Dados Externos do tipo
"cliente" a uma lista, voc pode adicionar campos secundrios para mostrar a "ID", o
"Nome" e a "Descrio" do Cliente. Em geral, estas so as colunas adicionadas:
Coluna primria: um campo de texto.

Coluna de Id Oculta: um campo de texto multilinha.

Colunas secundrias: cada coluna secundria um texto/nmero/Booliano/texto


multilinha que se baseia no tipo de dados da coluna secundria, conforme definido
no modelo de Catlogo de Dados Corporativos. Por exemplo, a ID pode ser
mapeada para uma coluna de Nmero; o Nome pode ser mapeado para uma coluna
de Texto com uma linha; a Descrio pode ser mapeada para uma coluna de Texto
com vrias linhas.

Limites de pginas
A tabela a seguir lista as diretrizes recomendadas para pginas.

Limite

Valor mximo

Web parts

25 por wiki ou pgina de Web Limite


parts

100

Tipo de
limite

Observaes

Esse valor
uma
estimativa
com base em
Web Parts
simples. A
complexidade
das Web
parts
determina
quantas
delas podem
ser usadas
em uma
pgina antes
que o
desempenho
seja afetado.

Limites de segurana
Limite

Tipo de Observaes
limite

Valor mximo

Com Esse no um imite rgido,


suporte mas consistente com as
diretrizes do Active Directory.
H vrios itens que afetam
esse nmero:

5.000
Nmero de grupos do
SharePoint aos quais um
usurio pode pertencer

Usurios em um conjunto 2 milhes por conjunto


de sites
de sites

O tamanho do token de
usurio

O cache de grupos: o
SharePoint Server 2010
tem uma tabela que
armazena em cache o
nmero de grupos aos
quais um usurio
pertence, assim que
estes grupos so usados
em ACLs).

O tempo da verificao
de segurana: medida
que aumenta o nmero
de grupos dos quais um
usurio membro, o
tempo necessrio para a
verificao de acesso
tambm aumenta.

Com Voc pode adicionar milhes


suporte de pessoas a seu site
usando grupos de segurana
do Microsoft Windows para
gerenciar a segurana, em
vez de usar usurios
individuais.
Esse limite se baseia na
capacidade de
gerenciamento e na
facilidade de navegao na
interface do usurio.
Quando h muitas entradas
(grupos de segurana de
usurios) no conjunto de
sites (mais de mil), voc deve

101

Limite

Tipo de Observaes
limite

Valor mximo

usar o Windows PowerShell


para gerenciar os usurios,
em vez da interface do
usurio. Isso proporcionar
uma melhor experincia de
gerenciamento.
Princpios/Usurios do
Active Directory em um
grupo do SharePoint

Grupo do SharePoint

5.000 por grupo do


SharePoint

10.000 por conjunto de


sites

Com O SharePoint Server 2010


suporte permite adicionar usurios ou
grupos do Active Directory a
um grupo do SharePoint.
A existncia de at 5.000
usurios (ou grupos ou
usurios do Active Directory)
em um grupo do SharePoint
proporciona desempenho
aceitvel.
As atividades mais afetadas
por esse limite so:

A busca de usurios para


validar permisses. Essa
operao se torna
gradativamente mais
longa, com o crescimento
no nmero de usurios
em um grupo.

Renderizao da
associao do modo de
exibio. Essa operao
sempre levar tempo.

Com Acima de 10.000 grupos, o


suporte tempo necessrio para
executar operaes aumenta
significativamente. Isso se
aplica particularmente
adio de um usurio a um
grupo existente, criao de
um novo grupo e
renderizao de modos de
exibio de grupos.

Entidade de segurana: 5.000 por ACL (Lista de Com O tamanho do escopo afeta
suporte os dados que so usados
tamanho do Escopo de Controle de Acesso)
Segurana
para um clculo de
102

Limite

Tipo de Observaes
limite

Valor mximo

verificao de segurana.
Esse clculo ocorre sempre
que o escopo alterado. No
h um limite rgido, mas
quanto maior for o escopo,
mais tempo levar o clculo.

Limites por recurso


Esta seo lista os limites classificados por recurso:

Limites de pesquisa
A tabela a seguir lista as diretrizes recomendadas para Pesquisa.

Limite

Tipo de
limite

Observaes

Aplicativos de
20 por farm
servio de pesquisa
do SharePoint

Com
suporte

Vrios aplicativos do
servio de pesquisa do
SharePoint podem ser
implantados no mesmo
farm, pois voc pode
atribuir componentes de
pesquisa e bancos de
dados a servidores
separados. O limite
recomendado de 20
menor que o limite
mximo para todos os
aplicativos de servio em
um farm.

Bancos de dados
de rastreamento e
Itens de bancos de
dados

Limite

O banco de dados de
rastreamento armazena
dados de rastreamento
(tempo/status etc.) sobre
todos os itens que foram
rastreados. O limite com
suporte de 10 bancos de
dados de rastreamento
por aplicativo de servio
de Pesquisa do
SharePoint.
O limite recomendado
de 25 milhes de itens por
banco de dados de
rastreamento (ou um total

Valor mximo

10 bancos de dados de
rastreamento por aplicativo
de servio de pesquisa
25 milhes de itens por
banco de dados de
rastreamento

103

Limite

Tipo de
limite

Valor mximo

Observaes

de quatro bancos de
dados de rastreamento
por aplicativo de servio
de pesquisa).
Componentes de
rastreamento

16 por aplicativo de servio


de pesquisa

Limite

O limite recomendado por


aplicativo um total de 16
componentes de
rastreamento, com dois
por banco de dados de
rastreamento e dois por
servidor, presumindo-se
que o servidor tenha, pelo
menos, oito
processadores (ncleos).
O nmero total de
componentes de
rastreamento por servidor
deve ser inferior a
128/(total de
componentes de consulta)
para minimizar a
degradao de E/S de
propagao. Se o limite
recomendado for
excedido, isso poder no
aumentar o desempenho
de rastreamento, na
verdade, o desempenho
de rastreamento poder
diminuir com base nos
recursos disponveis no
servidor de rastreamento,
banco de dados e host de
contedo.

Parties de
indexao

20 por aplicativo de servio


de pesquisa; total de 128

104

Limite

A partio de ndice
contm um subconjunto
do ndice de aplicativo de
servio de pesquisa. O
limite recomendado de
20. Se for aumentado o
nmero de parties de
ndice, cada partio
conter um subconjunto
menor do ndice,
reduzindo a memria

Limite

Tipo de
limite

Valor mximo

Observaes

RAM e o espao em disco


necessrios no servidor
de consulta que hospeda
o componente de consulta
atribudo partio de
ndice. O limite para o
nmero total de parties
de ndice de 128.
Itens indexados

100 milhes por aplicativo de Com


suporte
servio de pesquisa; 10
milhes por partio de ndice

A Pesquisa do SharePoint
d suporte a parties de
ndice, cada uma das
quais contendo um
subconjunto do ndice de
pesquisa. O mximo
recomendado de 10
milhes de itens em
qualquer partio. O
nmero mximo total de
itens recomendado (por
exemplo, pessoas, itens
de lista, documentos,
pginas da Web) de 100
milhes.

Entradas do log de 100 milhes por aplicativo de Com


rastreamento
suporte
pesquisa

Esse o nmero de
entradas de log
individuais no log de
rastreamento. Ele seguir
o limite de "itens
indexados".

Bancos de dados
de propriedade

O banco de dados de
propriedade armazena os
metadados de itens em
cada partio de ndice
associada a ele. Uma
partio de ndice s pode
ser associada a um
repositrio de
propriedades. O limite
recomendado de 10
bancos de dados de
propriedade por aplicativo
de servio de pesquisa. O
limite para parties de
ndice de 128.

10 por aplicativo de servio


de pesquisa; total de 128

105

Limite

Limite

Valor mximo

Tipo de
limite

Observaes

Componentes de
consulta

128 por aplicativo de


pesquisa; 64/(total de
componentes de
rastreamento) por servidor

Limite

O nmero total de
componentes de consulta
limitado pela capacidade
dos componentes de
rastreamento de copiar
arquivos. O nmero
mximo de componentes
de consulta por servidor
limitado pela capacidade
dos componentes de
consulta de absorver
arquivos propagados dos
componentes de
rastreamento.

Regras de escopo

100 regras de escopo por


escopo, total de 600 por
aplicativo de servio de
pesquisa

Limite

Se esse limite for


excedido, isso reduzir a
atualizao do
rastreamento e atrasar
resultados potenciais de
consultas de escopo.

Escopos

200 por site

Limite

Esse o limite
recomendado por site. Se
esse limite for excedido,
isso poder reduzir a
eficincia do rastreamento
e, se os escopos forem
adicionados ao grupo de
exibio, isso afetar a
latncia de navegador do
usurio final. Alm disso,
a exibio dos escopos na
interface de administrao
de pesquisa prejudicada
medida que o nmero
de escopos passa do
limite recomendado.

Limite

Grupos de exibio so
utilizados para uma
exibio agrupada de
escopos por meio da
interface do usurio. Se
esse limite for excedido,
isso comear a
prejudicar a experincia

Grupos de exibio 25 por site

106

Limite

Tipo de
limite

Valor mximo

Observaes

de escopo na interface de
administrao de
pesquisa.
Com
suporte

Esse o limite testado.

Fontes de contedo 50 por aplicativo de servio


de pesquisa

Limite

O limite recomendado de
50 pode ser excedido at
o limite de 500 por
aplicativo de servio de
pesquisa. No entanto,
devem ser usados menos
endereos iniciais, e o
limite de rastreamento
simultneo deve ser
seguido.

Endereos iniciais

100 por fonte de contedo

Limite

O limite recomendado
pode ser excedido at o
limite de 500 por origem
de contedo. No entanto,
quanto mais endereos
iniciais houver, menos
fontes de contedo
devero ser usadas.
Quando h muitos
endereos iniciais,
recomendvel coloc-los
como links em uma
pgina HTML e rastrear
essa pgina com o
rastreador HTTP,
seguindo os links.

Rastreamentos
simultneos

20 por aplicativo de pesquisa Limite

Este o nmero de
rastreamentos em
andamento ao mesmo
tempo. Se esse nmero
for excedido, isso poder
fazer com que a taxa de
rastreamento geral
diminua.

Propriedades
rastreadas

500.000 por aplicativo de


pesquisa

Com
suporte

Estas so propriedades
descobertas durante um
rastreamento.

Regra de impacto

100

Limite

Limite recomendado de

Alertas

1.000.000 por aplicativo de


pesquisa

107

Limite

Tipo de
limite

Valor mximo

de rastreamento

Observaes

100 por farm. A


recomendao pode ser
excedida, porm, a
exibio das regras de
visitas do site na interface
de administrao de
pesquisa prejudicada.
Em cerca de 2000 regras
de visitas do site, a pgina
Gerenciar Regras de
Visitas do Site torna-se
ilegvel.

Regras de
rastreamento

100 por aplicativo de servio Limite


de pesquisa

Esse valor pode ser


excedido; no entanto, a
exibio das regras de
rastreamento na interface
de administrao de
pesquisa prejudicada.

Propriedades
gerenciadas

100.000 por aplicativo de


servio de pesquisa

Limite

Estas so propriedades
utilizadas pelo sistema de
pesquisa em consultas.
Propriedades rastreadas
so mapeadas para
propriedades
gerenciadas.

Mapeamentos

100 por propriedade


gerenciada

Limite

Se esse limite for


excedido, isso poder
diminuir a velocidade de
rastreamento e o
desempenho de consulta.

Com
suporte

Esse o nmero mximo


recomendado de URLs
que devem ser removidas
do sistema em uma
operao.

Remoes de URL 100 remoes por operao

Pginas
autoritativas

1 pgina de nvel superior e o Limite


mnimo de pginas de
segundo e terceiro nvel por
aplicativo de servio de
pesquisa

O limite recomendado
de uma pgina autoritativa
de nvel superior e o
menor nmero possvel de
pginas de segundo e
terceiro nvel para obter a
relevncia desejada.
O limite de 200 por nvel

108

Limite

Tipo de
limite

Valor mximo

Observaes

de relevncia por
aplicativo de pesquisa,
mas a adio de pginas
pode no proporcionar a
relevncia desejada.
Adicione o site principal
ao primeiro nvel de
relevncia. Adicione mais
sites principais no
segundo ou terceiro nvel
de relevncia, um de cada
vez, e avalie a relevncia
aps cada adio para
garantir que o efeito de
relevncia desejado seja
obtido.
Palavras-chave

200 por conjunto de sites

Com
suporte

Propriedades de
metadados
reconhecidas

10.000 por item rastreado

Delimitador Esse o nmero de


propriedades de
metadados que podem
ser determinadas e
potencialmente mapeadas
ou usadas para consultas
quando um item
rastreado.

Limites de Servio de Perfil de Usurio


109

O limite recomendado
pode ser excedido at o
limite mximo (imposto
pelo ASP.NET) de 5000
por conjunto de sites, com
cinco Melhores Opes
por palavra-chave. Se
voc exceder esse limite,
a exibio de palavraschave na interface do
usurio de administrao
de site ser prejudicada.
Para modificar o limite
imposto pelo ASP.NET,
edite os arquivos
Web.Config e
Client.config
(MaxItemsInObjectGraph).

A tabela a seguir lista as diretrizes recomendadas para o Servio de Perfil de Usurio.

Limite

Valor mximo

Tipo de
limite

Observaes

Perfis de usurios

2.000.000 por aplicativo de


servio

Com
suporte

Um aplicativo
de servio de
perfil de
usurio pode
dar suporte a
at dois
milhes de
perfis de
usurio com
funcionalidade
completa de
recursos
sociais. Esse
nmero
representa o
nmero de
perfis que
podem ser
importados
para o
repositrio de
perfis de
pessoas de
um servio de
diretrio e
tambm o
nmero de
perfis aos
quais um
aplicativo de
servio de
perfil de
usurio pode
dar suporte
sem
prejudicar o
desempenho
dos recursos
sociais.

Com
suporte

H suporte
para um total
de at 500
milhes de

Etiquetas de contedo social, 500.000.000 por banco de


observaes e classificaes dados social

110

Limite

Valor mximo

Tipo de
limite

Observaes

etiquetas de
contedo
social,
observaes e
classificaes
em um banco
de dados
social, sem
reduo
significativa
de
desempenho.
No entanto,
as operaes
de
manuteno
do banco de
dados, como
backup e
restaurao,
podem
apresentar
reduo de
desempenho
nesse ponto.

Limites de implantao de contedo


A tabela a seguir lista as diretrizes recomendadas para implantao de contedo.

Limite

Tipo de Observaes
limite

Valor mximo

Trabalhos de
20
implantao de
contedo executados
em caminhos diferentes

Com Para trabalhos de execuo


suporte simultnea em caminhos que
esto conectados a conjuntos
de sites no mesmo banco de
dados de contedo de origem,
h maior risco de deadlocks no
banco de dados. Para trabalhos
que devem ser executados
simultaneamente,
recomendvel mover os
conjuntos de sites para bancos
de dados de contedos de
origem diferentes.
111

Limite

Tipo de Observaes
limite

Valor mximo

Observao:
No possvel haver trabalhos
em execuo simultnea no
mesmo caminho.
Se voc estiver usando
instantneos do SQL Server
para implantao de contedo,
cada caminho criar um
instantneo. Isso aumenta os
requisitos de E/S para o banco
de dados de origem.
Para obter mais informaes,
consulte Sobre trabalhos e
caminhos de implantao.

Limites de blog
A tabela a seguir lista as diretrizes recomendadas para blogs.

Limite

Valor mximo

Tipo de limite Observaes

Posts de blog

5000 por site

Com suporte O nmero


mximo de
posts de
blog de
5000 por
site.

Comentrios

1000 por post

Com suporte O nmero


mximo de
comentrios
de 1000
por post.

Limites de Servios Corporativos de Conectividade


A tabela a seguir lista as diretrizes recomendadas para Servios Corporativos de
Conectividade.

Limite

Tipo de
limite

Valor mximo

112

Observaes

Limite

Valor mximo

Tipo de
limite

ECTs (Tipos de Contedo


Externo) (na memria)

5000 por servidor Web (por Limite


locatrio)

Conexes externas do
sistema

500 por servidor Web

Delimitador Nmero de
conexes do
sistema externas
ativas/abertas em
um determinado
ponto no tempo. O
valor mximo
padro de 200; o
limite de 500.
Esse limite
imposto no escopo
do Servidor Web,
independentemente
do tipo de sistema
externo (por
exemplo, banco de
dados, assembly
.NET e assim por
diante). O mximo
padro usado
para restringir o
nmero de
conexes. Um
aplicativo pode
especificar um
limite maior por
meio do contexto
de execuo; o
limite impe o
mximo at mesmo
para aplicativos
que no respeitam
o padro.

Itens de banco de dados


retornados por solicitao

2.000 por conector de


banco de dados

Limite

113

Observaes

Nmero total de
definies de ECT
(tipo de contedo
externo)
carregadas na
memria em um
determinado ponto
no tempo em um
servidor Web.

Nmero de itens
por solicitao que
o conector de

Limite

Tipo de
limite

Valor mximo

Observaes

banco de dados
pode retornar.
O padro mximo
de 2.000 usado
pelo conector de
banco de dados
para restringir o
nmero de
resultados que
podem ser
retornados por
pgina. O aplicativo
pode especificar
um limite maior por
meio do contexto
de execuo; o
Mximo Absoluto
impe o mximo
mesmo para
aplicativos que no
respeitam o padro.
O limite para esse
valor de
1.000.000.

Limites de fluxos de trabalho


A tabela a seguir lista as diretrizes recomendadas para fluxos de trabalho.

Limite

Valor mximo

Limite de adiamento de fluxo 15


de trabalho

114

Tipo de
limite

Observaes

Limite

O nmero
mximo de
fluxos de
trabalho que
podem ser
executados em
relao a um
banco de
dados de
contedo ao
mesmo tempo
15, excluindo
as instncias
em execuo

Limite

Valor mximo

Tipo de
limite

Observaes

no servio de
timer. Quando
esse limite
atingido, novas
solicitaes
para ativar
fluxos de
trabalho so
colocadas em
fila para serem
executadas
pelo servio de
timer de fluxo
de trabalho
mais tarde.
Quando a
execuo no
relacionada ao
timer
concluda, as
novas
solicitaes
so contadas
em relao a
esse limite. O
limite pode ser
configurado
por meio do
cmdlet SetSPFarmConfig
do Windows
PowerShell.
Para obter
mais
informaes,
consulte SetSPFarmConfig.
Observao:
esse limite no
se refere ao
nmero total
de instncias
de fluxos de
trabalho que
esto em
andamento.
Em vez disso,
115

Limite

Valor mximo

Tipo de
limite

Observaes

ele o nmero
de instncias
que esto
sendo
processadas.
Se o limite for
aumentado,
isso aumentar
a taxa de
transferncia
de inicializao
e concluso de
tarefas de fluxo
de trabalho,
mas tambm
aumentar a
carga em
relao ao
banco de
dados de
contedo e aos
recursos do
sistema.
Tamanho de lote de timer de 100
fluxo de trabalho

Limite

116

O nmero de
eventos que
cada execuo
do trabalho de
timer de fluxo
de trabalho
selecionar e
entregar aos
fluxos de
trabalho. Esse
nmero pode
ser
configurado
por meio do
Windows
PowerShell.
Para permitir
eventos
adicionais,
voc pode
executar
instncias
adicionais do

Limite

Valor mximo

Tipo de
limite

Observaes

Servio de
Timer do Fluxo
de Trabalho do
Microsoft
SharePoint
Foundation.

Limites de repositrios de termos de Metadados Gerenciados


(bancos de dados)
A tabela a seguir lista as diretrizes recomendadas para repositrios de termos de
metadados gerenciados.

Limite

Valor mximo

Tipo de Observaes
limite

Nmero mximo de
nveis de termos
aninhados em um
repositrio de termos

Com Os termos em um conjunto de


suporte termos podem ser
representados de forma
hierrquica. Um conjunto de
termos pode ter at sete nveis
de termos (um termo pai e seis
nveis de aninhamento abaixo
dele).

1000
Nmero mximo de
conjuntos de termos em
um repositrio de
termos

Com Pode haver at 1000 conjuntos


suporte de termos em um repositrio de
termos.

30.000
Nmero mximo de
termos em um conjunto
de termos

Com O nmero mximo de termos


suporte em um conjunto de termos
30.000.
Observao:
Rtulos adicionais para o
mesmo termo, como sinnimos
e tradues, no contam como
termos separados.

Nmero total de itens


em um repositrio de
termos

Com Um item um termo ou um


suporte conjunto de termos. A soma do
nmero de termos e conjuntos

1.000.000

117

Limite

Tipo de Observaes
limite

Valor mximo

de termos no pode exceder


1.000.000. Rtulos adicionais
para o mesmo termo, como
sinnimos e tradues, no
contam como termos
separados.
Observao:
No pode haver o nmero
mximo de conjuntos de termos
e o nmero mximo de termos
simultaneamente em um
repositrio de termos.

Limites dos Servios do Visio


A tabela a seguir lista as diretrizes recomendadas para instncias dos Servios do Visio
no Microsoft SharePoint Server 2010.

Limite

Tipo Observaes
de
limite

Valor mximo

Tamanho de arquivo de 50 MB
desenhos da Web do
Visio

Limite Os Servios do Visio tm uma


definio de configurao que
permite que o administrador
altere o tamanho mximo de
desenhos da Web que o Visio
processa.
Tamanhos de arquivo maiores
tm os seguintes efeitos
colaterais:
Aumento do volume de
memria dos Servios do
Visio.

118

Aumento do uso da CPU.

Reduo das solicitaes


de servidor de aplicativos
por segundo.

Aumento da latncia total.

Limite

Tipo Observaes
de
limite

Valor mximo

Tempo limite de
reclculo de desenhos
da Web do Visio

120 segundos

Aumento da carga de rede


de farm do SharePoint.

Limite Os Servios do Visio tm uma


definio de configurao que
permite que o administrador
altere o tempo mximo que
pode ser gasto no reclculo de
um desenho aps uma
atualizao de dados.
Um tempo limite maior de
reclculo causa:

Reduo na disponibilidade
da CPU e da memria.

Reduo das solicitaes


de aplicativos por segundo.

Aumento da latncia mdia


para todos os documentos.
Um tempo limite menor de
reclculo causa:

Reduo da complexidade
dos diagramas que podem
ser exibidos.

Aumento das solicitaes


por segundo.

Diminuio da latncia
mdia para todos os
documentos.

Idade mnima do cache Idade mnima do cache: Limite A idade mnima do cache se
0 a 24 horas
aplica a diagramas conectados
do Servios do Visio
a dados. Ela determina o
(diagramas conectados
primeiro momento em que o
a dados)
diagrama atual pode ser
removido do cache.
A definio da Idade Mnima do
Cache com um valor muito
baixo reduzir a taxa de
transferncia e aumentar a
latncia, pois a invalidao do
cache muitas vezes fora o Visio
119

Limite

Tipo Observaes
de
limite

Valor mximo

a recalcular com frequncia e


reduz a disponibilidade da CPU
e da memria.
Idade mxima do cache Idade mxima do cache: Limite
0 a 24 horas
do Servios do Visio
(diagramas no
conectados a dados)

A idade mxima do cache se


aplica a diagramas no
conectados a dados. Esse valor
determina por quanto tempo o
diagrama atual deve ser
mantido na memria.
O aumento da Idade Mxima do
Cache diminui a latncia para
desenhos solicitados com
frequncia.
No entanto, a definio da Idade
Mxima do Cache com um valor
muito alto aumenta a latncia e
diminui a taxa de transferncia
para os itens que no esto
armazenados em cache, pois os
itens j em cache consomem e
reduzem a memria disponvel.

Limites dos Servios PerformancePoint


A tabela a seguir lista as diretrizes recomendadas para os Servios PerformancePoint no
Microsoft SharePoint Server 2010.

Limite

Valor mximo

Tipo de
limite

Clulas

1.000.000 por consulta em


uma fonte de dados dos
Servios do Excel

Delimitador Um scorecard do
PerformancePoint
que chama uma
fonte de dados
dos Servios do
Excel est sujeito
a um limite
mximo de
1.000.000 clulas
por consulta.

Colunas e linhas

15 colunas por 60.000 linhas Limite


120

Observaes

O nmero

Limite

Valor mximo

Tipo de
limite

Observaes

mximo de
colunas e linhas
ao renderizar
qualquer objeto
de painel do
PerformancePoint
que use uma
pasta de trabalho
do Microsoft
Excel como fonte
de dados. O
nmero de linhas
pode ser alterado
em funo do
nmero de
colunas.
Consulta em uma lista do
SharePoint

15 colunas por 5000 linhas

Com
suporte

O nmero
mximo de
colunas e linhas
ao renderizar
qualquer objeto
de painel do
PerformancePoint
que use uma lista
do SharePoint
como fonte de
dados. O nmero
de linhas pode
ser alterado em
funo do nmero
de colunas.

Consulta em uma fonte de


dados do SQL Server

15 colunas por 20000 linhas Com


suporte

O nmero
mximo de
colunas e linhas
ao renderizar
qualquer objeto
de painel do
PerformancePoint
que use uma
fonte de dados
de tabela do SQL
Server. O nmero
de linhas pode
ser alterado em
funo do nmero
de colunas.

121

Limites do Word Automation Services


A tabela a seguir lista as diretrizes recomendadas para o Word Automation Services.

Limite

Valor mximo

Tamanho do
512 MB
arquivo de entrada

Observaes

Delimitador Tamanho mximo de arquivo que


pode ser processado pelo Word
Automation Services.
Limite

Essa configurao determina a


frequncia com que o trabalho de
timer do Word Automation Services
executado. Um nmero mais baixo
torna mais rpida a execuo do
trabalho de timer. Nossos testes
mostram que mais til executar o
trabalho de timer uma vez por minuto.

Nmero de
converses a
iniciar por
processo de
converso

Para formatos de Limite


sada PDF/XPS:
30 x M. Para todos
os outros formatos
de sada: 72 x
M, em que M o
valor da
Frequncia para
iniciar converses
(minutos)

O nmero de converses a iniciar


afeta a taxa de transferncia do Word
Automation Services.
Se estes valores forem definidos
como mais elevados do que os nveis
recomendados, alguns itens de
converso podero comear a falhar
de forma intermitente, e as
permisses de usurio podero
expirar. As permisses de usurio
expiram 24 horas a partir do momento
em que um trabalho de converso
iniciado.

Tamanho do
trabalho de
converso

100.000 itens de
converso

Um trabalho de converso inclui um


ou mais itens de converso, cada um
dos quais representa uma nica
converso a ser realizada em um
nico arquivo de entrada no
SharePoint. Quando um trabalho de
converso iniciado (usando o
mtodo ConversionJob.Start), esse
trabalho e todos os itens de converso
so transmitidos para um servidor de
aplicativos que, em seguida,
armazena o trabalho no banco de
dados do Word Automation Services.
Um grande nmero de itens de
converso aumentar o tempo de

Frequncia para
iniciar as
converses
(minutos)

1 minuto
(recomendado)

Tipo de
limite

15
minutos (padro)
59 minutos (limite)

Com
suporte

122

Limite

Valor mximo

Tipo de
limite

Observaes

execuo do mtodo Start e o nmero


de bytes transmitidos ao servidor de
aplicativos.
Total de processos N-1, em que N o Limite
de converso
nmero de ncleos
ativos
em cada servidor
de aplicativos

Um processo de converso ativo pode


consumir um nico ncleo de
processamento. Portanto, os clientes
no devem executar mais processos
de converso do que o nmero de
ncleos de processamento existentes
em seus servidores de aplicativos. O
trabalho de timer de converso e
outras atividades do SharePoint
tambm exigem o uso ocasional de
um ncleo de processamento.
recomendvel deixar sempre um
ncleo livre para uso pelo trabalho de
timer de converso e pelo SharePoint.

Tamanho de
banco de dados
do Word
Automation
Services

2 milhes de itens Com


suporte
de converso

O Word Automation Services mantm


uma fila persistente de itens de
converso em seu banco de dados.
Cada solicitao de converso gera
um ou mais registros.
O Word Automation Services no
exclui registros do banco de dados
automaticamente; assim, o banco de
dados pode crescer indefinidamente
sem manuteno. Os administradores
podem remover manualmente o
histrico de trabalhos de converso
usando o cmdlet RemoveSPWordConversionServiceJobHistory
do Windows PowerShell. Para obter
mais informaes, consulte RemoveSPWordConversionServiceJobHistory.

Limites do SharePoint Workspace


A tabela a seguir lista as diretrizes recomendadas para o Microsoft SharePoint
Workspace 2010.

Limite

Valor mximo

Tipo de limite Observaes

Sincronizao do SharePoint
Workspace

30.000 itens por lista

Delimitador O
SharePoint

123

Limite

Tipo de limite Observaes

Valor mximo

Workspace
no
sincroniza
listas que
tenham mais
de 30.000
itens. Essa
restrio
existe
porque o
tempo
necessrio
para baixar
uma lista
que tenha
mais de
30.000 itens
muito
longo, e a
utilizao de
recursos
elevada.
Sincronizao do SharePoint
Workspace

Limite de 1800 documentos no Delimitador Os usurios


SharePoint Workspace
so
avisados
quando h
mais de 500
documentos
no
SharePoint
Workspace,
mas podem
continuar a
adicionar
documentos.

Limites do OneNote
A tabela a seguir lista as diretrizes recomendadas para os Servios do Microsoft
OneNote.

Limite

Valor mximo

Nmero de Sees e Consulte o limite para


Grupos de Sees em "Documentos" em
um Bloco de Anotaes Limites de lista e
124

Tipo de
limite

Observaes

Cada seo conta como uma


pasta e um documento na
lista. Cada grupo de sees

Limite

Valor mximo

Tipo de
limite

do OneNote (no
SharePoint)

biblioteca

conta como uma pasta e um


documento na lista.

Tamanho mximo de
uma seo

Consulte o limite para


"Tamanho de arquivo"
em Limites de lista e
biblioteca

Esse valor mximo exclui


imagens, arquivos inseridos
e impresses XPS do
OneNote com mais de 100
KB. Imagens e arquivos
inseridos com mais de 100
KB so separados em seus
prprios arquivos binrios.
Isso significa que uma seo
com 100 KB de dados
digitados e quatro
documentos do Word
inseridos com 1 MB cada
sero considerados uma
seo de 100 KB.

Tamanho mximo de
uma imagem, arquivo
inserido e impresso
XPS do OneNote em
uma seo do
OneNote.

Consulte o limite para


"Tamanho de arquivo"
em Limites de lista e
biblioteca

Cada item armazenado


como um arquivo binrio
separado e, assim, est
sujeito a limites de tamanho
de arquivo. Cada operao
de impresso no OneNote
resultar em um binrio de
impresso XPS, mesmo que
a impresso contenha vrias
pginas.

Tamanho mximo de
todas as imagens,
arquivos inseridos e
impresses XPS em
uma nica pgina do
OneNote.

Limite
O limite padro o
dobro do limite de
"Tamanho de arquivo".

Isso se aplica ao contedo


inserido em uma nica
pgina do OneNote e no
uma Seo ou Bloco de
Anotaes. Se os usurios
tiverem esse problema,
vero o seguinte erro no
OneNote:
jerrcStorageUrl_HotTableFull
(0xE0000794). Os usurios
podem resolver o problema
dividindo o contedo inserido
em pginas diferentes e
excluindo as verses
anteriores da pgina. Se os
usurios precisarem ajustar
esse valor ("Tamanho

125

Observaes

Limite

Tipo de
limite

Valor mximo

Observaes

Mximo de Tabela Ativa"), o


limite efetivo ser a metade
do valor absoluto definido
por eles (por exemplo, se for
especificado um tamanho
mximo de tabela ativa de
400 MB, isso significa que o
tamanho mximo de todo o
contedo inserido em uma
pgina ser limitado a 200
MB).
Operaes de
mesclagem

Delimitador O OneNote mescla


Uma por ncleo de
alteraes combinadas de
CPU por servidor Web
vrios usurios que esto
realizando a coautoria de um
bloco de anotaes. Se
nenhum ncleo de CPU
estiver disponvel para
executar uma mesclagem,
uma pgina de conflito ser
gerada em vez disso, o que
forar o usurio a executar
a mesclagem manualmente.
Esse limite aplicvel quer o
OneNote esteja sendo
executado como um
aplicativo cliente, quer esteja
sendo executado como um
Microsoft Office Web Apps.

Limites do Servio Office Web Applications


A tabela a seguir lista as diretrizes recomendadas para o Office Web Apps. Os limites de
aplicativos clientes do Office tambm so aplicveis quando um aplicativo est sendo
executado como um aplicativo Web.

Limite

Valor mximo

Tipo de
limite

Observaes

Tamanho do cache

100 GB

Limite

Espao
disponvel
para
renderizar
documentos,
criados como

126

Limite

Valor mximo

Tipo de
limite

Observaes

parte de um
banco de
dados de
contedo. Por
padro, o
cache
disponvel
para
renderizar
documentos
de 100 GB.
No
recomendvel
aumentar o
cache
disponvel.
Renderizaes

Uma por documento por


segundo por ncleo de CPU
por servidor de aplicativos
(mximo de oito ncleos)

Delimitador Esse o
nmero
mdio
medido de
renderizaes
de
documentos
"tpicos" que
podem ser
executadas
no servidor
de aplicativos
em um
perodo de
tempo.

Limites do Project Server


A tabela a seguir lista as diretrizes recomendadas para o Microsoft Project Server. Para
obter mais informaes sobre como planejar o Project Server, consulte Planning and
architecture for Project Server 2010.

Limite

Valor mximo

Tipo de limite Observaes

Horrio do final do projeto

Data: 31/12/2049

Delimitador

127

Planos do
Project no
podem
ultrapassar
a data de

Limite

Valor mximo

Tipo de limite Observaes

31/12/2049.
Produtos por plano de projeto 1500 produtos

Nmero de campos em um
modo de exibio

256

Nmero de clusulas em um 50
filtro para um modo de exibio

128

Delimitador

Planos do
Project no
podem
conter mais
de 1500
produtos.

Delimitador

Um usurio
no pode
ter mais de
256 campos
adicionados
a um modo
de exibio
que tenha
sido
definido no
Project Web
App.

Delimitador

Um usurio
no pode
adicionar
um filtro a
um modo
de exibio
que
contenha
mais de 50
clusulas.

Performance and capacity technical case


studies (SharePoint Server 2010) (em
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 (em ingls).
In this section:
Publishing

Ambiente de publicao na intranet da empresa do Microsoft SharePoint Server


2010: anlise tcnica
Describes the published intranet environment used by employees at Microsoft.
Enterprise Intranet Collaboration

Enterprise intranet collaboration environment technical case study (SharePoint


Server 2010) (em 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)
(em ingls)
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) (em ingls)
129

Describes a departmental collaboration environment used by employees of one


department inside Microsoft.
Divisional portal environment lab study (SharePoint Server 2010) (em ingls)
Describes lab testing performed on a similar environment to the departmental
collaboration environment.
Social

Social environment technical case study (SharePoint Server 2010) (em 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.

130

Ambiente de publicao na intranet da


empresa do Microsoft SharePoint Server
2010: anlise tcnica
Este documento descreve uma implantao especfica do Microsoft SharePoint Server
2010. Ele inclui:
Especificaes de ambiente de estudo tcnico de caso, como hardware, topologia
do farm e configurao

Carga de trabalho que inclui nmero e tipos de usurios ou clientes e caractersticas


de utilizao de ambiente

Conjunto de dados de farm de estudo tcnico de caso que inclui contedo de banco
de dados e ndices de Pesquisa

Dados de integridade e desempenho especficos do ambiente


Neste artigo:
Informaes sobre pr-requisitos

Introduo a este ambiente

Especificaes

Carga de trabalho

Conjunto de dados

Dados de integridade e desempenho

Informaes sobre pr-requisitos


Antes de ler este documento, voc deve entender os principais conceitos subjacentes ao
gerenciamento de capacidade do SharePoint Server 2010. A seguinte documentao o
ajudar a conhecer a abordagem recomendada para o gerenciamento da capacidade e
fornecer contexto que o ajudar a entender como fazer uso eficaz das informaes
deste documento, alm de definir os termos usados em todo o documento.
Para obter mais informaes conceituais sobre desempenho e capacidade, que possam
ser teis para a compreenso do contexto dos dados deste estudo tcnico de caso,
consulte os seguintes documentos:
Viso geral do gerenciamento da capacidade e dimensionamento do SharePoint
Server 2010

Gerenciamento de capacidade do SharePoint Server 2010: limites de software

Introduo a este ambiente


Este white paper descreve um ambiente real do SharePoint Server 2010 na Microsoft.
Use esse documento para comparao com as suas caractersticas de carga de trabalho
131

e uso planejados. Se o design planejado for semelhante, voc poder usar a


implantao aqui descrita como ponto de partida para sua prpria instalao.
Este documento inclui:
Especificaes, que incluem hardware, topologia e configurao

Carga de trabalho, que a demanda no farm que inclui a quantidade de usurios e


as caractersticas de utilizao

Conjunto de dados que inclui tamanhos de bancos de dados

Dados de integridade e desempenho especficos do ambiente


Este documento faz parte de uma srie de Performance and capacity technical case
studies (SharePoint Server 2010) (em ingls) sobre ambientes do SharePoint na
Microsoft.

O
ambiente do SharePoint Server 2010 descrito neste documento um ambiente de
produo de uma grande empresa multinacional. Os funcionrios exibem contedo
variado, como notcias, artigos tcnicos, perfis de funcionrios, documentao e
recursos de treinamento. Esse ambiente tambm usado pelos funcionrios para
realizar consultas em todos os ambientes do SharePoint dentro da empresa. Os
funcionrios recebem emails diariamente com links para artigos sobre o ambiente e
muitos dos funcionrios definem esse ambiente como a home page do seu navegador.
Cerca de 48.000 usurios exclusivos visitam o ambiente em um dia movimentado,
gerando at 345 solicitaes por segundo (RPS) nos horrios de pico. Como um site
de intranet, todos os usurios so autenticados. Embora o contedo seja publicado
usando um modelo de autor no local de ambiente nico, o procedimento de publicao
do ambiente especifica que todo o contedo de rascunho seja publicado no mesmo
horrio, noite, fora dos horrios de pico.
As informaes fornecidas neste documento refletem o ambiente de publicao da
intranet da empresa em um dia normal.

Especificaes
Esta seo traz informaes detalhadas sobre hardware, software, topologia e
configurao do ambiente do estudo de caso.

Hardware
132

Esta seo traz detalhes sobre os computadores servidores usados nesse ambiente.
Observao:
O ambiente dimensionado para acomodar compilaes de pr-lanamento do
SharePoint Server 2010 e de outros produtos. Portanto, o hardware implantado tem
maior capacidade que o necessrio para atender a demanda que geralmente ocorre
nesse ambiente. Esse hardware s descrito para dar mais contexto ao ambiente e
serve como ponto de partida para ambientes semelhantes.
importante direcionar seu gerenciamento de capacidade de acordo com a carga de
trabalho planejada e as caractersticas de utilizao. Para obter mais informaes sobre
o processo de gerenciamento da capacidade, consulte Viso geral do gerenciamento da
capacidade e dimensionamento do SharePoint Server 2010.

Servidores Web
H quatro servidores Web no farm, cada um deles com hardware idntico. Trs para
contedo e o quarto dedicado ao destino do rastreamento da pesquisa.

Servidor Web

WFE1-4

Processador(es)

2 ncleos qudruplos a 2.33 GHz

RAM

32 GB

Sistema operacional

Windows Server 2008, 64 bits

Tamanho da unidade do SharePoint

300 GB

Quantidade de adaptadores de rede

Velocidade do adaptador de rede

1 Gigabit

Autenticao

Windows NTLM

Tipo de balanceador de carga

Balanceamento de carga do hardware

Verso do software

SharePoint Server 2010 (verso de prlanamento)

Servios em execuo no local

Administrao Central
Email de Entrada do Microsoft SharePoint
Foundation
Aplicativo Web do Microsoft SharePoint
Foundation
Servio de Timer do Fluxo de Trabalho do
Microsoft SharePoint Foundation
Servio de Consulta de Pesquisa e
Configuraes do Site
Pesquisa do SharePoint Server
133

Servidor Web

WFE1-4

Servios consumidos de um farm de


servios federados

Servio de Perfil de Usurio


Servio Web do Web Analytics
Servio Conectividade de Dados
Corporativos
Servio Web de Metadados Gerenciados

Servidor de aplicativos
No h nenhum servidor de aplicativos no farm. Os servios locais so hospedados nos
servidores Web. Outros servios so consumidos de um farm de servios federados.

Servidores de bancos de dados


H um cluster SQL com dois servidores de bancos de dados, cada um deles com
hardware idntico. Um dos servidores ativo e o outro passivo para fins de
redundncia.

Servidor de Banco de Dados

DB1-2

Processador(es)

4 ncleos qudruplos a 2.4 GHz

RAM

32 GB

Sistema operacional

Windows Server 2008, 64 bits

Armazenamento e geometria

(1,25 TB * 6) + 3 TB
Discos 1-4: Dados SQL
Disco 5: Logs
Disco 6: TempDB

Quantidade de adaptadores de rede

Velocidade do adaptador de rede

1 Gigabit

Autenticao

Windows NTLM

Verso do software

SQL Server 2008

Topologia
O seguinte diagrama mostra a topologia desse farm.

134

Configurao
135

A tabela abaixo enumera configuraes que foram alteradas e que afetam o


desempenho ou a capacidade do ambiente.

Configurao

Valor

Observaes

Administrao de Ativado
Conjunto de
Sites:
Cache de sada do
conjunto de sites

Habilitar o cache de sada aumenta a eficincia do


servidor, reduzindo chamadas no banco de dados em
busca de dados frequentemente solicitados.

Perfil do cache do Intranet


conjunto de sites (Site de
(selecionar)
Colabora
o)

A opo Permitir que os autores exibam o contedo


armazenado em cache est selecionada, ignorando o
comportamento comum de no deixar que as pessoas
com permisso de edio tenham suas pginas
armazenadas em cache.

Cache de Objetos Ativado O padro 100 MB. O aumento dessa configurao


(Desativado | n
500 MB permite o armazenamento de mais dados na memria do
MB)
servidor Web front-end.
Servio de Uso:
Log de
Rastreamento
dias para
armazenar
arquivos de log
(padro: 14 dias)

5 dias

O padro 14 dias. Baixar essa configurao pode liberar


espao em disco no servidor onde os arquivos de log
esto armazenados.

Limite de Registro 1 segundo O padro 5 segundos. Baixar essa configurao pode


de Consulta em
economizar largura de banda e CPU no servidor do
Log:
banco de dados.
Microsoft
SharePoint
Foundation Banco
de dados
configurar
QueryLoggingThre
shold para 1
segundo
Servidor de
1
Banco de Dados
Instncia Padro:
Grau mximo de
paralelismo

O padro 0. Para garantir um desempenho ideal,


altamente recomendvel definir o grau mximo de
paralelismo como 1 para servidores de banco de dados
que hospedam bancos de dados do SharePoint Server
2010. Para obter mais informaes sobre como definir o
grau mximo de paralelismo, consulte Opo max degree
of
parallelism(http://go.microsoft.com/fwlink/?linkid=189030&
clcid=0x416).
136

Carga de trabalho
Esta seo descreve a carga de trabalho, que a demanda no farm que inclui a
quantidade de usurios e as caractersticas de utilizao.

Caractersticas da Carga de Trabalho

Valor

Mdia de Solicitaes por Segundo (RPS)

100

Mdia de RPS no horrio de pico (11h 15h)

226

Quantidade total de usurios diferentes por 33.580


dia
Mdia de usurios simultneos

172

Mximo de usurios simultneos

376

Quantidade total de solicitaes por dia

3.800.000

Esta tabela mostra o nmero de solicitaes para cada agente de usurio.

Agente de Usurio

Solicitaes

Porcentagem do
Total

Navegador

3.261.563

97,09%

DAV

2.418

0,07%

Pesquisa (rastreamento)

92.322

2,75%

OneNote

1.628

0,05%

Outlook

961

0,03%

Word

449

0,01%

Conjunto de dados
Esta seo descreve o conjunto de dados do farm de estudo de caso que inclui
tamanhos de bancos de dados e ndices de Pesquisa.

Caractersticas do Conjunto de Dados

Valor

Tamanho do banco de dados (combinado)

49,9 GB
137

Caractersticas do Conjunto de Dados

Valor

Tamanho do BLOB

22,2 GB

Quantidade de bancos de dados de


contedo

Nmero de aplicativos Web

Nmero de conjuntos de sites

Nmero de sites

797

Tamanho do ndice de pesquisa (nmero de 275.000


itens)

Dados de integridade e desempenho


Esta seo traz dados de integridade e desempenho especficos do ambiente do estudo
de caso.

Contadores Gerais
Mtrica

Valor

Disponibilidade (tempo de ativao)

99,95%

Taxa de Falha

0,05%

Mdia de memria usada

1,08 GB

Mximo de memria usada

2,60 GB

% de Rastreamento de Pesquisa de Trfego 6%


(solicitaes de clientes de pesquisa/total de
solicitaes)
Solicitaes ASP.NET na Fila

0,00

Os grficos abaixo mostram a utilizao mdia de CPU e a latncia desse ambiente.

138

Neste documento, a latncia dividida em quatro categorias. 50% da latncia


geralmente so usados para medir a capacidade de resposta do servidor. Isto significa
que metade das solicitaes so atendidas dentro desse tempo de resposta. 95% da
latncia geralmente so usados para medir picos nos tempos de resposta do servidor.
139

Isto significa que 95% das solicitaes so atendidas dentro desse tempo de resposta e,
portanto, 5% das solicitaes tm tempos de resposta mais lentos.

Contadores de Bancos de Dados


Ao interpretar estatsticas de bancos de dados para esse ambiente de publicao da
empresa, preciso saber que a maioria dos visitantes tem permisses somente leitura.

Mtrica

Valor

Proporo Leitura/Gravao (E/S por Banco 99,999:0,001


de Dados)
Comprimento Mdio da Fila de Disco

0,35

Comprimento da Fila de Disco: Leituras

34

Comprimento da Fila de Disco: Gravaes

2,5

Leituras de disco/segundo

131,33

Gravaes de disco/segundo

278,33

Compilaes SQL/segundo

2,36

Recompilaes SQL/segundo

94,80

Bloqueios SQL: Tempo Mdio de Espera

0 ms

Bloqueios SQL: Tempo de Espera de


Bloqueio

0 ms

Bloqueios SQL: Deadlocks por Segundo

Travas SQL: Tempo Mdio de Espera

0,25 ms

Taxa de Acertos do Cache SQL

>99%

140

Enterprise intranet collaboration


environment technical case study
(SharePoint Server 2010) (em 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

Prerequisite information
Before reading this document, make sure that you understand the key concepts behind
SharePoint Server 2010 capacity management. The following documentation will help
you learn about the recommended approach to capacity management and provide
context for helping you understand how to make effective use of the information in this
document, and also define the terms used throughout this document.
For more conceptual information about performance and capacity that you might find
valuable in understanding the context of the data in this technical case study, see the
following documents:
Capacity management and sizing for SharePoint Server 2010 (em ingls)

Gerenciamento de capacidade do SharePoint Server 2010: limites de software

Introduction to this environment


This white paper describes an actual SharePoint Server 2010 environment at Microsoft.
Use this document to compare to your planned workload and usage characteristics. If
141

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) (em ingls) about SharePoint environments at Microsoft.

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.

142

Observao:
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
(em 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

RAM

32 GB

OS

Windows Server 2008, 64 bit

Size of the SharePoint drive

205 GB

Number of network adapters

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
143

Web Server

WFE1-4

Business Data Connectivity Service


Managed Metadata Web Service

Application Server
There are four application servers in the farm, each with identical hardware.

Application Server

APP1-4

Processor(s)

4 six core @ 2.40 GHz

RAM

64 GB

OS

Windows Server 2008, 64 bit

Size of the SharePoint drive

300 GB

Number of network adapters

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

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.

Database Server

DB1-2

Processor(s)

4 quad core @ 2.4 GHz

RAM

32 GB

OS

Windows Server 2008, 64-bit

Storage and geometry

(1.25 TB * 7) + 3 TB
144

Database Server

DB1-2

Disk 1-4: SQL Data


Disk 5: Logs
Disk 6: TempDB
Number of network adapters

Network adapter speed

1 Gigabit

Authentication

Windows NTLM

Software version

SQL Server 2008

Topology
The following diagram shows the topology for this farm.

145

Configuration
146

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 the server where the log files are
Trace Log days to store
stored.
log files (default: 14 days)
QueryLoggingThreshold 1
The default is 5 seconds. Lowering this setting can
second
save bandwidth and CPU on the database server.
SharePoint Foundation
Database change
QueryLoggingThreshold
to 1 second
1
Database Server
Default Instance
Max degree of parallelism

The default is 0. To ensure optimal performance, we


strongly recommend that you set max degree of
parallelism to 1 for database servers that host
SharePoint Server 2010 databases. For more
information about how to set max degree of
parallelism, see max degree of parallelism
Option(http://go.microsoft.com/fwlink/?LinkId=189030).

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

Workload Characteristics

Value

Average Requests per Second (RPS)

157

Average RPS at peak time (11 AM-3 PM)

350

Total number of unique users per day

69,702

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%

147

User Agent

Requests

Percentage of
Total

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

Number of content databases

87

Number of Web applications

Number of site collections

34,423

Number of sites

101,598

Search index size (number of items)

23 million

Health and Performance Data


This section provides health and performance data that is specific to the Case Study
environment.

General Counters
Metric

Value

Availability (uptime)

99.1%

Failure Rate

0.9%

Average memory used

3.4 GB

Maximum memory used

16.1 GB

Search Crawl % of Traffic (Search client


requests / total requests)

47%

148

Metric

Value

ASP.NET Requests Queued

0.00

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

149

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

Disk Queue Length: Reads

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%

150

Enterprise intranet collaboration


environment lab study (SharePoint
Server 2010) (em 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:
Introduction to this environment

Glossary

Overview

Specifications

Results and Analysis

Introduction to this environment


This document provides guidance about scaling out and scaling up servers in a
SharePoint Server 2010 enterprise intranet collaboration solution, based on a testing
environment at Microsoft. Capacity planning informs decisions on purchasing hardware
and making system configurations to optimize your solution.
Different scenarios have different requirements. Therefore, it is important to supplement
this guidance with additional testing on your own hardware and in your own environment.
If your planned design and workload resembles the environment described in this
document, you can use this document to draw conclusions about scaling your
environment up and out.
This document includes the following:
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


151

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) (em ingls).
Before reading this document, make sure that you understand the key concepts behind
capacity management in SharePoint Server 2010. The following documentation will help
you learn about the recommended approach to capacity management and provide
context for helping you understand how to make effective use of the information in this
document, and also define the terms used throughout this document.
Viso geral do gerenciamento da capacidade e dimensionamento do SharePoint
Server 2010
Gerenciamento de capacidade do SharePoint Server 2010: limites de software
Also, we encourage you to read the following:
Planejamento e configurao de armazenamento e capacidade do SQL Server
(SharePoint Server 2010)

Glossary
There are some specialized terms that you will encounter in this document. Here are
some key terms and their definitions.
RPS: Requests per second. The number of requests received by a farm or server in
one second. This is a common measurement of server and farm load.
Note that requests differ from page loads; each page contains several components,
each of which creates one or more requests when the page is loaded. Therefore, one
page load creates several requests. Typically, authentication checks and events
using insignificant resources are not counted in RPS measurements.
Green Zone: This is the state at which the server can maintain the following set of
criteria:

The server-side latency for at least 75% of the requests is less than 1 second.

All servers have a CPU Utilization of less than 50%.


Observao:
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:
152

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.

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

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

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 Planejamento e configurao de
armazenamento e capacidade do SQL Server (SharePoint Server 2010).

Specifications
This section provides detailed information about the hardware, software, topology, and
configuration of the lab environment.

Hardware
The following sections describe the hardware that was used in this lab environment.

Web and Application servers


There are from one to eight Web servers in the farm, plus one Application server.

Web Server

WFE1-8 and APP1

Processor(s)

2 quad-core 2.33 GHz processors

RAM

8 GB

Operating system

Windows 2008 Server R2

Size of the SharePoint drive

80 GB

Number of network adapters

Network adapter speed

1 Gigabit

Authentication

Windows NTLM
154

Web Server

WFE1-8 and APP1

Load balancer type

Windows NLB

Services running locally

WFE 1-8: Basic Federated Services. This


included the following: Timer Service, Admin
Service, and Trace Service. APP1: Word
Automation Services, Servios do 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.
Observao:
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)
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)
155

Database Server Default Instance

DB1-2

Number of network adapters

Network adapter speed

1 Gigabit

Authentication

Windows NTLM

Software version

SQL Server 2008 R2 (pre-release version)

Topology
The following diagram shows the topology in this lab environment:

156

Configuration
157

To allow for the optimal performance, the following configuration changes were made in
this lab environment.

Setting

Value

Notes

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.

Site Collection
Blob Caching

Database
Server Default
Instance
Max degree of 1
parallelism

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

158

Dataset
The dataset for the lab environment described in this document is a subset of the dataset
from a production environment at Microsoft. For more information about the production
environment, see Enterprise intranet collaboration environment technical case study
(SharePoint Server 2010) (em ingls).

Dataset Characteristics

Value

Database size (combined)

130 GB

BLOB size

108.3 GB

Number of content databases

Number of site collections

181

Number of Web applications

1
159

Dataset Characteristics

Value

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

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.

160

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.

161

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
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
Planejamento e configurao de armazenamento e capacidade do SQL Server
(SharePoint Server 2010).
Maximum:

162

Green Zone:

Example of how to read these graphs:

163

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.

Test methodology

Have two content databases on one database server, and then split them to two
servers to effectively double the processor cores and memory available to the
database servers in the environment.

Keep the total IOPs capacity constant even while adding a database server. This
means that the number of reads/sec and writes/sec that the disks could perform for
each content database did not change despite splitting the content onto two
database servers instead of one.

Analysis

The first bottleneck in the 4x1x2 environment was the database server CPU
utilization. There was close to a linear scale when we added more processor and
memory power.

Scaling to four Web servers and 2 database servers did not provide much additional
RPS because the CPU utilization on the Web servers was close to 100%.

When we scaled out database servers (by adding one additional database server)
and added four Web servers, performance scaled almost linearly. The bottleneck at
that point shifted from being the database server CPU utilization to the content
database disk IOPs.

No additional tests were performed in this lab environment to scale out past 8x1x2.
However we expect that additional IOPs capacity would additionally increase
throughput.

A correlation between the IOPs used and the RPS achieved by the tests was
observed

Results graphs and charts


In the following graphs, the x axis is always showing four Web servers together with 1
application server and 1 database server (4x1x1) scaling out to eight Web servers
together with two database servers (8x1x2). Some also show 1x1x1 or 4x1x2.
1. Latency and RPS
The following graph shows how scaling out both Web servers and database servers
affects latency and RPS.

164

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

165

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) (em ingls). Additional content about memory requirements for increased
numbers of site collections is under development. Check back for new and updated
content.
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

166

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

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.

Tests show that the environment can take advantage of a twenty-four core box,
although there is some degradation as twenty-four cores are approached.

Results graphs and charts


In the following graph, the x axis is the number of processors and the amount of RAM on
the Web server. The following graph shows how scaling up (adding processors) affects
RPS on the Web server.

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
168

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.

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
169

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.

Results graphs and charts


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

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

170

171

Departmental collaboration environment


technical case study (SharePoint Server
2010) (em 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:
Prerequisite information

Introduction to this environment

Specifications

Workload

Dataset

Health and Performance Data

Prerequisite information
Before reading this document, make sure that you understand the key concepts behind
SharePoint Server 2010 capacity management. The following documentation will help
you learn about the recommended approach to capacity management and provide
context for helping you understand how to make effective use of the information in this
document, and also define the terms used throughout this document.
For more conceptual information about performance and capacity that you might find
valuable in understanding the context of the data in this technical case study, see the
following documents:
Viso geral do gerenciamento da capacidade e dimensionamento do SharePoint
Server 2010

Gerenciamento de capacidade do SharePoint Server 2010: limites de software

Introduction to this environment


This white paper describes an actual SharePoint Server 2010 environment at Microsoft.
Use this document to compare with your planned workload and usage characteristics. If
172

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) (em ingls) about SharePoint environments at Microsoft.

The
SharePoint Server 2010 environment described in this document is a production
environment at a large, geographically distributed company. Employees use this
environment to track projects, collaborate on documents, and share information within
their department. This environment is also used for internal testing, and is frequently
upgraded to the latest SharePoint Server pre-release versions as they become available.
As many as 9,000 unique users visit the environment on a busy day, generating up to
470 requests per second (RPS) during peak hours. Because this is an intranet site, all
users are authenticated.
The information that is provided in this document reflects the departmental collaboration
environment on a typical day.

Specifications
This section provides detailed information about the hardware, software, topology, and
configuration of the case-study environment.

Hardware
This section provides details about the server computers that were used in this
environment.

173

Observao:
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 Viso geral do gerenciamento da capacidade e
dimensionamento do 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.

Web Server

WFE1-2

WFE3-4

Processor(s)

2 quad core @ 2.33 GHz

2 quad core @
2.33 GHz

RAM

32 GB

16 GB

Operating system

Windows Server 2008, 64 bit

Windows Server
2008, 64 bit

Size of the SharePoint drive

3x146GB 15K SAS (3 RAID 1


Disks) Disk 1: OS Disk 2: Swap
and BLOB Cache Disk 3: Logs and
Temp directory

3x146GB 15K
SAS (3 RAID 1
Disks) Disk 1:
OS Disk 2: Swap
and BLOB Cache
Disk 3: Logs and
Temp directory

Number of network adapters

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 (prerelease version)

SharePoint
Server 2010
(pre-release
version)

Services running locally

Search Query

WFE3 No
services

174

Web Server

WFE1-2

WFE3-4

WFE4 Search
crawl target

Application Server
There are four application servers in the farm.

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 2: Swap
and BLOB Cache Disk 3: Logs and
Temp directory

2x136GB 15K
SAS (RAID 0)
4x60GB SSD,
SATA (RAID 5)
Disk 1: OS Disk
2: Swap and
BLOB Cache
Disk 3: Logs and
Temp directory

Number of network adapters

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 (prerelease version)

SharePoint
Server 2010
(pre-release
version)

Services running locally

APP1 Central Administration and Search Crawler


all applications except for Office
Web Applications
APP2 All applications (including
Office Web Applications)
APP3 Office Web Applications

Database Servers
175

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 GHz

2 quad
core @
3.2 GHz

RAM

32 GB

16 GB

32 GB

Operating system

Windows Server 2008 SP1, 64 Windows


bit
Server 2008
SP1, 64 bit

Storage and geometry

5x146GB 15K SAS + SAN


6x450GB 15K 2x136GB
SAS
15K SAS
Disk 1: OS (2 disk RAID 10)
(RAID 0)
Disk 2: Swap (2 disk RAID 10) Directly
attached
6x60GB
Disk 3: Direct Attached Storage
14x146GB
SSD,
(16 disk RAID 10, Temp DB
15K SAS
SATA
data) SAS 146 GB 15K
Disk 1: Usage (RAID 5)
Disk 4: Direct Attached Storage
logs and OS Disk 1:
(16 disk RAID 10, Temp DB
Disk 2: Usage OS
data) SAS 146 GB 15K
data
Disk 2:
Disk 5-15: SAN using fiber
Swap
connection. When possible, one
and
database per two disks.
BLOB
Separating logs and data
Cache
between LUNs. 15K drives.
Disk 3:
Logs and
Temp
directory.
Solid
state
drives. 660GB
Solid
state
drives
(RAID 5)

Windows
Server
2008
SP1, 64
bit

Number of network adapters 2

Network adapter speed

1 Gigabit

1 Gigabit

1 Gigabit

Authentication

Windows NTLM

Windows
NTLM

Windows
NTLM

176

Database

DB1 Default Instance

DB2

DB3

Software version

SQL Server 2008

SQL Server
2008

SQL
Server
2008 R2

Topology
The following diagram shows the topology for this farm.

177

Configuration
178

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

Setting

Value

Notes

Site collection:
On
Object Caching (On |
Disabled
Off)
Disabled
Anonymous Cache
On 100GB
Profile (select)
60 seconds
Anonymous Cache
Profile (select)
Object Cache (Off | n
MB)
Cross List Query Cache
Changes (Every Time |
Every n seconds)

Enabling the output cache improves server


efficiency by reducing calls to the database for
data that is frequently requested.

Site collection cache


profile (select)

Intranet
(Collaboration
Site)

Allow writers to view cached content is


checked, bypassing the ordinary behavior of not
letting people with edit permissions to have
their pages cached.

Object Cache (Off | n


MB)

On 500 MB

The default is 100 MB. Increasing this setting


enables additional data to be stored in the frontend Web server memory.

Usage Service:
Trace Log days to
store log files (default:
14 days)

5 days

The default is 14 days. Lowering this setting


can save disk space on the server where the
log files are stored.

Query Logging
1 second
Threshold:
Microsoft SharePoint
Foundation Database
configure
QueryLoggingThreshold
to 1 second

The default is 5 seconds. Lowering this setting


can save bandwidth and CPU on the database
server.

Database Server
Default Instance:
Max degree of
parallelism

The default is 0. To ensure optimal


performance, we strongly recommend that you
set max degree of parallelism to 1 for database
servers that host SharePoint Server 2010
databases. For more information about how to
set max degree of parallelism, see max degree
of parallelism Option
(http://go.microsoft.com/fwlink/?LinkId=189030).

179

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

Workload Characteristics

Value

Average Requests per Second (RPS)

165

Average RPS at peak time (11 AM-3 PM)

216

Total number of unique users per day

9186

Average concurrent users

189

Maximum concurrent users

322

Total # of requests per day

7,124,943

This table shows the number of requests for each user agent.

User Agent

Requests

Percentage of
Total

Search (crawl)

4,373,433

67.61%

Outlook

897,183

13.87%

OneNote

456,917

7.06%

DAV

273,391

4.23%

Browser

247,303

3.82%

Word

94,465

1.46%

SharePoint Workspaces

70,651

1.09%

Office Web Applications

45,125

0.70%

Excel

8,826

0.14%

Access

1,698

0.03%

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

Dataset Characteristics

Value

180

Dataset Characteristics

Value

Database size (combined)

1.8 TB

BLOB size

1.68 TB

Number of content databases

18

Total number of databases

36

Number of site collections

7,499

Number of Web applications

Number of sites

42,457

Search index size (number of items)

4.6 million

Health and Performance Data


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

General Counters
Metric

Value

Availability (uptime)

99.9995%

Failure Rate

0.0005%

Average memory used

0.89 GB

Maximum memory used

5.13 GB

Search Crawl % of Traffic (Search client


requests / total requests)

82.5%

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

181

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
182

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

Average Disk queue length

1.42

Disk Queue Length: Reads

1.38

Disk Queue Length: Writes

0.04

Disk Reads/sec

56.51

Disk Writes/sec

17.60

SQL Compilations/second

13.11

SQL Re-compilations/second

0.14

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%

183

Divisional portal environment lab study


(SharePoint Server 2010) (em 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:
Introduction to this environment

Glossary

Overview

Specifications

Results and analysis

Introduction to this environment


This document outlines the test methodology and results to provide guidance for capacity
planning of a typical divisional portal. A divisional portal is a SharePoint Server 2010
deployment where teams mainly do collaborative activities and some content publishing.
This document assumes a "division" to be an organization inside an enterprise with 1,000
to 10,000 employees.
Different scenarios will have different requirements. Therefore, it is important to
supplement this guidance with additional testing on your own hardware and in your own
environment. If your planned design and workload resembles the environment described
in this document, you can use this document to draw conclusions about scaling your
environment up and out.
When you read this document, you will understand how to do the following:
Estimate the hardware that is required to support the scale that you need to support:
number of users, load, and the features enabled.

Design your physical and logical topology for optimal reliability and efficiency. High
Availability/Disaster Recovery are not covered in this document.

Understand the effect of ongoing search crawls on RPS for a divisional portal
deployment.
The SharePoint Server 2010 environment described in this document is a lab
environment that mimics a production environment at a large company. For details about
the production environment, see Departmental collaboration environment technical case
study (SharePoint Server 2010) (em ingls).
184

Before reading this document, make sure that you understand the key concepts behind
capacity management in SharePoint Server 2010. The following documentation will help
you learn about the recommended approach to capacity management and provide
context for helping you understand how to make effective use of the information in this
document, and also define the terms used throughout this document.
Viso geral do gerenciamento da capacidade e dimensionamento do SharePoint
Server 2010
Gerenciamento de capacidade do SharePoint Server 2010: limites de software
Also, we encourage you to read the following:
Planejamento e configurao de armazenamento e capacidade do SQL Server
(SharePoint Server 2010)

Glossary
There are some specialized terms that you will encounter in this document. Here are
some key terms and their definitions.
RPS: Requests per second. The number of requests received by a farm or server in
one second. This is a common measurement of server and farm load.
Note that requests differ from page loads; each page contains several components,
each of which creates one or more requests when the page is loaded. Therefore, one
page load creates several requests. Typically, authentication checks and events
using insignificant resources are not counted in RPS measurements.
Green Zone: This is the state at which the server can maintain the following set of
criteria:

The server-side latency for at least 75% of the requests is less than .5 second.

All servers have a CPU Utilization of less than 50%.


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

185

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.

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

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.

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

Processor(s)

2px4c@2.33GHz

2px4c@2.33GHz 4px4c@
3.19GHz

RAM

8 GB

8 GB

32 GB

Number of network
adapters

Network adapter speed

1 Gigabit

1 gigabit

1 Gigabit

Load balancer type

F5 - Hardware load balancer Not applicable

Not
applicable

ULS Logging level

Medium

Not
applicable

Medium

Database
Server

Software
The table that follows explains software installed and running on the servers that were
used in this testing effort.

Operating System

Web Server

Application
Server

Database
Server

Windows Server 2008 R2 x64

Windows
Server 2003
x64

Windows
Server
2008 x64

187

Web Server

Application
Server

Database
Server

Software version

SharePoint Server 2010 and


Office Web Applications, prerelease versions

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

SQL
Server
2008 R2
CTP3

Authentication

Windows NTLM

Windows
NTLM

Windows
NTLM

Load balancer type

F5 - Hardware load balancer

Not applicable Not


applicable

ULS Logging level

Medium

Medium

Not
applicable

Anti-Virus Settings

Disabled

Disabled

Disabled

Services running locally

Microsoft SharePoint
Foundation Incoming E-Mail
Microsoft SharePoint
Foundation Web Application
Microsoft SharePoint
Foundation Workflow Timer
Service
Search Query and Site Settings
Service
SharePoint Server Search

Central
Not
Administration applicable
Excel
Services
Managed
Metadata
Web Service
Microsoft
SharePoint
Foundation
Incoming EMail
Microsoft
SharePoint
Foundation
Web
Application
Microsoft
SharePoint
Foundation
Workflow
Timer Service
PowerPoint
Services
Search Query
and Site
Settings
Service

188

Web Server

Application
Server

Database
Server

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.

189

Dataset and disk geometry


190

The test farm was populated with about 1.62 Terabytes of content, distributed across five
different sized content databases. The following table explains this distribution:

Content database

Content database size

36 GB

135 GB

175 1.2
75
GB terabytes GB

Number of sites

44

74

Number of webs

1544

2308

2242 2041

1178

RAID configuration

Number of spindles for


MDF

Number of spindles for


LDF

222

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.

Feature or Service

Operation

Read/write

Percentage
of mix

ECM

Get static files

8.93%

View home page

1.52%

Display/Edit upsize list item and r


new forms

0.32%

Download file by using "Save


as"

1.39%

Microsoft InfoPath

Microsoft OneNote 2010

Open Microsoft Office OneNote r


2007 file

13.04%

Search

Search through

4.11%

191

Feature or Service

Operation

Read/write

Percentage
of mix

0.35%

OSSSearch.aspx or
SearchCenter
Workflow

Start autostart workflow


Microsoft Visio

Render Visio file in PNG/XAML r

0.90%

Office Web Applications PowerPoint

Render Microsoft PowerPoint, r


scroll to 6 slides

0.05%

Office Web Applications Word

Render and scroll Microsoft


Word doc in PNG/Silverlight

0.24%

Microsoft SharePoint
Foundation

List Check out and then


check in an item

0.83%

List - Get list

0.83%

List - Outlook sync

1.66%

List - Get list item changes

2.49%

List - Update list items and


adding new items

4.34%

Get view and view collection

0.22%

Get webs

1.21%

Browse to Access denied page r

0.07%

View Browse to list feeds

0.62%

Browse to viewlists

0.03%

Browse to default.aspx (home r


page)

1.70%

Browse to Upload doc to doc lib w

0.05%

Browse to List/Library's default r


view

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 w


using DAV

3.32%

Propfind list by using DAV

4.16%

Propfind site by using DAV

4.16%

List document by using FPSE

0.91%

192

Feature or Service

Operation

Read/write

Percentage
of mix

Upload doc by using FPSE

0.91%

Browse to all site content page r

0.03%

View RSS feeds of lists or wikis r

2.03%

Servios do Excel

Render small/large Excel files

1.56%

Workspaces

WXP - Cobalt internal protocol r

23.00%

Full file upload using WXP

0.57%

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

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

193

125

User Load

50

75

100

125

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

95th Percentile (sec)

0.71

0.77

1.03 1

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

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

194

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.
Performance counters and graphs
The following table presents various performance counters captured during testing a
1x1x1 farm, at different steps in user load.

User Load

25

50

195

75

100

125

150

User Load

25

50

75

100

125

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.

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

196

150

Results from 2x1x1 farm configuration


Summary of results

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

This configuration delivered "green zone" RPS of 191, with 75th percentile latency
being 0.37 sec, and Web server CPU hovering around 47 % utilization. This indicates
that this farm can healthily deliver an RPS of around 191. "Max zone" RPS delivered
by this farm was 291 with latencies of 0.5 sec and Web server CPU hovering around
75%.

Because the Web server CPU was the bottleneck in this iteration, we relived the
bottleneck by adding another Web server for the next iteration.
Performance counters and graphs
The following table presents various performance counters captured during testing a
2x1x1 farm, at different steps in user load.

User Load

40

80

197

115

150

175

200

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

Database server CPU

21.2

36.1

43.7 48.5 52.8 56.2

75th Percentile (sec)

0.205

0.23

0.27 0.3

95th Percentile (sec)

0.535

0.57

0.625 0.745 0.645 0.57

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

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

198

45

45.9

0.305 0.305

Results from 3x1x1 farm configuration


Summary of results

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

This configuration delivered "green zone" RPS of 242, with 75th percentile latency
being 0.41 sec, and database server CPU hovering around 44% utilization. This
indicates that this farm can healthily deliver an RPS of around 242. "Max zone" RPS
delivered by this farm was 318 with latencies of 0.5 sec and database server CPU
hovering around 75%.

This was the last configuration in the series.


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

User Load

66

103

141

RPS

193.8

218.5

269.8 275.5 318.25 310

199

17

202

226

User Load

66

103

141

17

202

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

75th Percentile (sec)

0.22

0.24

0.30 0.65 0.78

0.87

95th Percentile (sec)

0.49

0.57

0.72 1.49 0.51

1.43

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

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

200

226

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.

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.

201

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

202

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:

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.

203

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.
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
No
10%
Incremental Resource Resource
Crawl
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

204

Baseline 3x1x1

Only
No
10%
Incremental Resource Resource
Crawl
Governor Governor

Web server CPU (%)

53.40

0.30

47.00

46.5

Application server CPU


(%)

22.10

28.60

48.00

41.3

16.50

15.00

12.1

(%)

Crawl Web server CPU (%) 0.50

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

205

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

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

207

Social environment technical case study


(SharePoint Server 2010) (em 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:
Prerequisite information

Introduction to this environment

Specifications

Workload

Dataset

Health and Performance Data

Prerequisite information
Before reading this document, make sure that you understand the key concepts behind
SharePoint Server 2010 capacity management. The following documentation will help
you learn about the recommended approach to capacity management and provide
context for helping you understand how to make effective use of the information in this
document, and also define the terms used throughout this document.
For more conceptual information about performance and capacity that you might find
valuable in understanding the context of the data in this technical case study, see the
following documents:
Viso geral do gerenciamento da capacidade e dimensionamento do SharePoint
Server 2010

Gerenciamento de capacidade do SharePoint Server 2010: limites de software

Introduction to this environment


This white paper describes an actual SharePoint Server 2010 environment at Microsoft.
Use this document to compare with your planned workload and usage characteristics. If
your planned design is similar, you can use the deployment described here as a starting
point for your own installation.
208

This document includes the following:


Specifications, which include hardware, topology and configuration

Workload, which is the demand on the farm that includes the number of users, and
the usage characteristics

Dataset that includes database sizes

Health and performance data specific to the environment


This document is part of a series of Performance and capacity technical case studies
(SharePoint Server 2010) (em ingls) about SharePoint environments at Microsoft.

The
SharePoint Server 2010 environment described in this document is a production
environment at a large, geographically distributed company. This environment hosts
SharePoint My Sites that connect employees with one another and the information that
they need. Employees use this environment to present personal information such as
areas of expertise, past projects, and colleagues to the wider organization. The
environment also hosts personal sites and documents for viewing, editing, and
collaboration. My Sites are integrated with Active Directory Domain Services (AD DS) to
provide a central location that can be accessed from the browser and various client
applications.
As many as 72,000 unique users visit the environment on a busy day, generating up to
180 requests per second (RPS) during peak hours. Because this is an intranet site, all
users are authenticated.
The information that is provided in this document reflects the enterprise social
environment on a typical day.

Specifications
This section provides detailed information about the hardware, software, topology, and
configuration of the case-study environment.

Hardware
This section provides details about the server computers that were used in this
environment.
209

Observao:
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 Viso geral do gerenciamento da capacidade e
dimensionamento do 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.

Web Server

WFE1-3

Processor(s)

2 quad core @ 2.33 GHz

RAM

16 GB

Operating system

Windows Server 2008, 64 bit

Size of the SharePoint drive

400 GB

Number of network adapters

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
210

Web Server

WFE1-3

Business Data Connectivity Service


Managed Metadata Web Service

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

Application Server

APP1-4

Processor(s)

2 quad core @ 2.33 GHz

RAM

16 GB

OS

Windows Server 2008, 64 bit

Size of the SharePoint drive

400 GB

Number of network adapters

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

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.

Database Server

DB1-2

Processor(s)

4 quad core @ 2.4 GHz

RAM

64 GB

Operating system

Windows Server 2008, 64 bit

Storage and geometry

(1.25 TB * 6)
211

Database Server

DB1-2

Disk 1-4: SQL Data


Disk 5: Logs
Disk 6: TempDB
Number of network adapters

Network adapter speed

1 @ 100MB, 1 @ 1GB

Authentication

Windows NTLM

Software version

SQL Server 2008

Topology
The following diagram shows the topology for this farm.

212

Configuration
213

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 the server where the log files are
Trace Log days to store
stored.
log files (default: 14 days)
QueryLoggingThreshold 1
The default is 5 seconds. Lowering this setting can
second
save bandwidth and CPU on the database server.
Microsoft SharePoint
Foundation Database
configure
QueryLoggingThreshold
to 1 second
1
Database Server
Default Instance
Max degree of parallelism

The default is 0. To ensure optimal performance, we


strongly recommend that you set max degree of
parallelism to 1 for database servers that host
SharePoint Server 2010 databases. For more
information about how to set max degree of
parallelism, see max degree of parallelism
Option(http://go.microsoft.com/fwlink/?LinkId=189030).

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

Workload Characteristics

Value

Average Requests per Second (RPS)

64

Average RPS at peak time (11 AM-3 PM)

112

Total number of unique users per day

69,814

Average concurrent users

639

Maximum concurrent users

1186

Total # of requests per day

4,045,677

This table shows the number of requests for each user agent.

User Agent

Requests

214

Percentage of
Total

User Agent

Requests

Percentage of
Total

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%

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

Dataset Characteristics

Value

Database size (combined)

1.5 TB

BLOB size

1.05 TB

Number of content databases

64

Number of Web applications

Number of site collections

87,264

Number of sites

119,400

Search index size (number of items)

5.5 million

Health and Performance Data


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

General Counters

215

Metric

Value

Availability (uptime)

99.61%

Failure Rate

0.39%

Average memory used

0.79 GB

Maximum memory used

4.53 GB

Search Crawl % of Traffic (Search client


requests / total requests)

17.42%

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

216

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

217

Metric

Value

Read/Write Ratio (IO Per Database)

99.854 : 0.146

Average Disk queue length

8.702

Disk Queue Length: Reads

30.518

Disk Queue Length: Writes

4.277

Disk Reads/sec

760.886

Disk Writes/sec

180.644

SQL Compilations/second

3.129

SQL Re-compilations/second

0.032

SQL Locks: Average Wait Time

125 ms

SQL Locks: Lock Wait Time

33.322 ms

SQL Locks: Deadlocks Per Second

SQL Latches: Average Wait Time

0 ms

SQL Cache Hit Ratio

20.1%

218

Recomendaes e resultados de testes


de desempenho e capacidade
(SharePoint Server 2010)
Esta seo contm uma srie de white papers e artigos que descrevem o impacto no
desempenho e na capacidade causado por conjuntos de recursos especficos includos
no Microsoft SharePoint Server 2010. Os white papers e artigos incluem informaes
sobre as caractersticas de desempenho e capacidade do recurso e sobre como ele foi
testado pela Microsoft, incluindo:
Caractersticas do teste de farm

Resultados do teste

Recomendaes

Soluo de problemas de desempenho e escalabilidade


Observao:

Os white papers esto sendo atualizados e republicados em forma de artigos. Se voc


baixar um white paper desta pgina, poder haver informaes atualizadas quando ele
for publicado novamente como um artigo.
Antes de ler os white papers e artigos, importante que voc entenda os conceitoschave que fundamentam o gerenciamento de capacidade do SharePoint Server 2010.
Para obter mais informaes, consulte Capacity management and sizing for SharePoint
Server 2010 (em ingls).
A tabela a seguir descreve os white papers e artigos disponveis. Se o contedo estiver
disponvel como um white paper, ele ser disponibilizado como um documento do
Microsoft Word na pgina sobre resultados do teste e recomendaes sobre
desempenho e capacidade do SharePoint Server 2010.

Assunto

Descrio

Servios do Access

Apresenta diretrizes sobre o impacto do uso dos


Servios do Access nas topologias que executam o
SharePoint Server 2010. Visualize o artigo em Estimate
performance and capacity requirements for Access
Services in SharePoint Server 2010 (em ingls).

Servios Corporativos de
Conectividade

Apresenta diretrizes sobre o volume de recursos que o


uso dos Servios Corporativos de Conectividade requer
nas topologias que executam o SharePoint Server
2010. Baixe o white paper
219

Assunto

Descrio

(BCSCapacityPlanningDoc.docx).
Viso geral dos caches

Fornece informaes sobre como os trs caches do


SharePoint Server 2010 ajudam a ajustar a escala e o
crescimento do produto para atender as demandas do
seu aplicativo de negcios. Baixe o white paper
(SharePointServerCachesPerformance.docx).

Servios do Excel no Microsoft


SharePoint Server 2010

Apresenta diretrizes de planejamento para os Servios


do Excel no Microsoft SharePoint Server 2010.
Visualize o artigo em Estimate performance and
capacity requirements for Excel Services in SharePoint
Server 2010 (em ingls).

InfoPath Forms Services

Apresenta diretrizes sobre o volume de recursos que o


uso do InfoPath Forms Services requer nas topologias
que executam o SharePoint Server 2010. Baixe o white
paper (InfoPath2010CapacityPlanningDoc.docx).

Listas grandes

Apresenta diretrizes sobre o desempenho de


bibliotecas e listas de documentos grandes. Este
documento especfico do SharePoint Server 2010,
embora os limites abordados tambm se apliquem ao
Microsoft SharePoint Foundation 2010. Baixe o white
paper
(DesigningLargeListsMaximizingListPerformance.docx).

Repositrios de documentos de Apresenta diretrizes sobre o desempenho de


repositrios de documentos de larga escala em relao
larga escala
ao SharePoint Server 2010. Baixe o white paper
(LargeScaleDocRepositoryCapacityPlanningDoc.docx).
Meus Sites e computao social Apresenta diretrizes sobre o volume de recursos que o
uso de Meus Sites e outros recursos de computao
social requer nas topologias que executam o
SharePoint Server 2010. Baixe o white paper
(MySitesSocialComputingCapacityPlanningDoc.docx).
Office Web Apps

Apresenta diretrizes sobre o volume de recursos que o


uso do Office Web Apps requer nas topologias que
executam o SharePoint Server 2010. Baixe o white
paper (OfficeWebAppsCapacityPlanningDoc.docx).

Servios PerformancePoint

Apresenta diretrizes sobre o volume de recursos que o


uso dos Servios PerformancePoint requer nas
topologias que executam o SharePoint Server 2010.
Visualize o artigo em Estimar os requisitos de
desempenho e capacidade dos Servios
PerformancePoint.

Pesquisa

Fornece informaes sobre planejamento de


220

Assunto

Descrio

capacidade para diferentes implantaes de Pesquisa


no SharePoint Server 2010, incluindo farms pequenos,
mdios e grandes. Baixe o white paper
(SearchforSPServer2010CapacityPlanningDoc.docx).
Se estiver usando o FAST Search Server 2010 para
SharePoint como sua soluo de pesquisa empresarial,
consulte Plan for performance and capacity (FAST
Search Server 2010 for SharePoint).
Servios do Visio

Apresenta diretrizes sobre o volume de recursos que o


uso dos Servios do Visio requer nas topologias que
executam o SharePoint Server 2010. Baixe o white
paper (VisioServicesCapacityPlanningDoc.docx).

Web Analytics

Apresenta diretrizes sobre o volume de recursos que o


uso do servio Web Analytics requer nas topologias
que executam o SharePoint Server 2010. Visualize os
artigos em Capacity requirements for Web Analytics
Shared Service in SharePoint Server 2010 (em ingls).

Gerenciamento de Contedo da Apresenta diretrizes sobre o planejamento de


desempenho e capacidade para uma soluo de
Web
Gerenciamento de Contedo da Web. Visualize o
artigo em Estimar os requisitos de desempenho e
capacidade do Gerenciamento de contedo da Web no
SharePoint Server 2010.
Word Automation Services

Apresenta diretrizes sobre o planejamento de


capacidade para o Word Automation Services no
SharePoint Server 2010. Baixe o white paper
(WASCapacityPlanningDoc.docx).

Fluxo de trabalho

Apresenta diretrizes sobre o volume de recursos que o


uso de Fluxo de Trabalho requer nas topologias que
executam o SharePoint Server 2010. Baixe o white
paper (WorkflowCapacityPlanningDoc.docx).

221

Estimate performance and capacity


requirements for Access Services in
SharePoint Server 2010 (em ingls)
This article provides guidance on the footprint that usage of Servios do Access no
Microsoft SharePoint Server 2010 has on topologies that are running Microsoft
SharePoint Server 2010.
In this article:
Test farm characteristics

Test results

Recommendations

Troubleshooting

Test farm characteristics


This section describes the dataset that was used during the testing; the workloads that
were placed on the product during performance gathering; the hardware that was used
during the testing; and the topology for how that hardware was deployed.

Dataset
Servios do 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, Servios do Access applications were simulated on a
farm dedicated to Servios do Access (no other SharePoint tests were running). The farm
contained the following representative sites:
1,500 Servios do Access applications that have a Small size profile; 100 items
maximum per list.

1,500 Servios do Access applications that have a Medium size profile; 2,000 items
maximum per list.

1,500 Servios do 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. Servios do 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.
222

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

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. Servios do 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.
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
223

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 Servios do 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 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.
224

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 Servios do Access. For each group of tests,
only certain specific variables are changed to show the progressive impact on farm
performance.
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 Servios do 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
225

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

226

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 Servios do Access, and in reality the front-end
Web servers are likely shared with other SharePoint workloads. The following graph
shows the results.

227

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.

228

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

229

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.

230

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.

231

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

Overall

1x1

1x2

1x3

Req/Sec

14.96

28.76 45.22 48.01 14.85 28.77 58.02

Tests/Sec

2.00

3.81

Average Latency

235.80

241.21 247.21 244.87 240.70 242.26 250.94

6.11

1x4

6.42

2x1

1.99

2x2

3.81

2x4

7.80

Average front- 1x1


end Web
server tier

1x2

1x3

1x4

2x1

2x2

2x4

%CPU

24.40

41.02

43.62

6.31

12.48

26.18

13.82

232

Average front- 1x1


end Web
server tier

1x2

Max w3wp
9.46E+08
Private Bytes

2.31E+08 1.49E+09 1.55E+09 8.43E+08 9.84E+08 1.19E+09

Average
1x1
application
server
(Access Data
Services) tier

1x2

1x3

1x4

2x1

2x2

2x4

%CPU

46.30

42.83

43.74

34.51

46.56

43.45

42.13

%CPU w3wp 33.61

31.15

30.71

24.29

33.48

31.64

29.72

%CPU RS

7.94

9.17

6.84

9.03

8.02

8.71

8.62

1x3

1x4

2x1

2x2

2x4

Max total
4.80E+09
Private Bytes

4.89E+09 4.91E+09 4.62E+09 5.32E+09 4.82E+09 5.07E+09

Max w3wp
2.10E+09
Private Bytes

1.97E+09 2.04E+09 1.86E+09 2.00E+09 2.00E+09 2.07E+09

Max RS
1.78E+09
Private Bytes

2.00E+09 1.97E+09 1.86E+09 2.30E+09 1.89E+09 2.02E+09

Database
server (SQL
Server) tier
(single
computer)

1x1

1x2

1x3

1x4

2x1

2x2

2x4

%CPU

12.07

18.64

32.53

36.05

9.89

21.42

47.46

Avg Private
Bytes

2.96E+10

3.22E+10 3.25E+10 3.25E+10 2.89E+10 3.22E+10 3.25E+10

Max Private
Bytes

3.26E+10

3.25E+10 3.25E+10 3.25E+10 3.25E+10 3.25E+10 3.25E+10

Avg Disk
0.74
Queue Length
Total

1.18

1.64

1.77

0.67

1.24

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

233

2.18

Overall

1x1

1x2

1x3

Req/Sec

14.96

28.76 45.22 48.01 14.85 28.77 58.02

Tests/Sec

2.00

3.81

Average Latency

235.80

241.21 247.21 244.87 240.70 242.26 250.94

6.11

1x4

6.42

2x1

1.99

2x2

3.81

2x4

7.80

Average front- 1x1


end Web
server tier

1x2

1x3

1x4

2x1

2x2

2x4

%CPU

24.40

41.02

43.62

6.31

12.48

26.18

13.82

Max w3wp
9.46E+08
Private Bytes

2.31E+08 1.49E+09 1.55E+09 8.43E+08 9.84E+08 1.19E+09

Average
1x1
application
server
(Access Data
Services) tier

1x2

1x3

1x4

2x1

2x2

2x4

%CPU

46.30

42.83

43.74

34.51

46.56

43.45

42.13

%CPU w3wp 33.61

31.15

30.71

24.29

33.48

31.64

29.72

%CPU RS

7.94

9.17

6.84

9.03

8.02

8.71

8.62

Max total
4.80E+09
Private Bytes

4.89E+09 4.91E+09 4.62E+09 5.32E+09 4.82E+09 5.07E+09

Max w3wp
2.10E+09
Private Bytes

1.97E+09 2.04E+09 1.86E+09 2.00E+09 2.00E+09 2.07E+09

Max RS
1.78E+09
Private Bytes

2.00E+09 1.97E+09 1.86E+09 2.30E+09 1.89E+09 2.02E+09

Database
server (SQL
Server) tier
(single
computer)

1x1

1x2

1x3

1x4

2x1

2x2

2x4

%CPU

12.07

18.64

32.53

36.05

9.89

21.42

47.46

Avg Private
Bytes

2.96E+10

3.22E+10 3.25E+10 3.25E+10 2.89E+10 3.22E+10 3.25E+10


234

Database
server (SQL
Server) tier
(single
computer)

1x1

1x2

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
0.74
Queue Length
Total

1.18

1x3

1x4

1.64

1.77

2x1

0.67

2x2

1.24

2x4

2.18

Recommendations
This section provides general performance and capacity recommendations.
Servios do 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 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
Servios do 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 Servios do Access scenario:
To provide for more user load, check the CPU for the existing Servios do Access
application servers. Add additional CPUs or cores, or both, to these servers if it is
possible. Add more Servios do 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.

235

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 Servios do Access is to limit the
size and complexity of queries that can be performed. Servios do 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 Servios do 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:
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 Servios do Access augments to cover a broader
set of application scenarios. For Servios do 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, Servios do 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
236

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.

Performance counter

Apply to object

Notes

% Processor Time

Processor(_Total)

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

Private Bytes

Process(w3wp)

This value should


not approach the
Max Private
Bytes set for
w3wp processes.
Iif it does,
additional
investigation is
needed into what
component is
using the
memory.

Access Data Services


The following table shows performance counters and processes to monitor for application
servers, or Access Data Services (Access Data Services) in this case, within your farm.

Performance counter

Apply to object

Notes

% Processor Time

Processor(_Total)

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

% Processor Time

Process(w3wp)

The Access Data


Services runs
within its own

237

Performance counter

Apply to object

Notes

w2wp process,
and it will be
obvious which
w2wp process
this is as it will be
getting the bulk
of the CPU time.
Avg. Disk Queue Length

PhysicalDisk(_Total)

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

Private Bytes

Process(ReportingSrevicesService) Reports are


handled by SQL
238

Watch for too


much disk writing
because of
logging.

Servios do
Access caches
the results of
queries in
memory, until the
users session
expires (the timeout 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.

Performance counter

Apply to object

Notes

Server Reporting
Services. If too
many reports are
being run, or
reports are very
complex, the
CPU and Private
Bytes for this
process will be
high.

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

Performance counter

Apply to object

Notes

% Processor Time

Processor(_Total)

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

% Processor Time

Process(sqlservr)

Average values
larger than 80
percent indicate
that processor
capacity on the
database server
is insufficient.

Private Bytes

Process(sqlservr)

Shows the
average amount
of memory being
consumed by
SQL Server.

Avg. Disk Queue Length

PhysicalDisk(_Total)

Shows the
average disk
queue length; the
database
requests waiting
to be committed
to disk. This is
often a good
indicator that the

239

Performance counter

Apply to object

Notes

instance 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

Servios do Access Increase the number of CPUs or cores, or


depends on a large both, in the existing Access Data Services
computers. Add additional Access Data
amount of
Services computers if possible.
processing in the
application server
tier. If a 1x1, 1x2, or
1x3 configuration is
used, the first
bottleneck
encountered will
likely be the CPU on
the Access Data
Services servers.

Web server CPU


usage

When a Web server This issue can be resolved in one of two ways.
is overloaded with You can add more Web servers to the farm to
user requests,
distribute user load, or you can scale up the
average CPU usage Web server or servers by adding higher-speed
will approach 100
processors.
percent. This
prevents the Web
server from
responding to
requests quickly and
can cause timeouts
and error messages
on client computers.

Database server
disk I/O

When the number of Distributing data files across multiple physical


I/O requests to a
drives allows for parallel I/O. The blog
240

Bottleneck

Cause

Resolution

hard disk exceeds SharePoint Disk Allocation and Disk I/O


(http://go.microsoft.com/fwlink/?LinkId=129557)
the disks I/O
contains useful information about resolving
capacity, the
disk I/O issues.
requests will be
queued. As a result,
the time to complete
each request
increases.
Reporting Services The Reporting
CPU utilization
Services process is
using a large share
of the CPU
resources.

Dedicate a computer to Reporting Services,


taking load from the application server (Access
Data Services) tier (connected mode) or the
front-end Web server tier (local mode).

241

Estimate performance and capacity


requirements for Excel Services in
SharePoint Server 2010 (em ingls)
This article describes the effects of using Servios do Excel no 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.
Observao:
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 farm characteristics

Test Results

Recommendations
For general information about how to plan and run your capacity planning for SharePoint
Server 2010, see Capacity management and sizing for SharePoint Server 2010 (em
ingls).

Test farm characteristics


This section describes the dataset, workloads, hardware settings, topology, and test
definitions that were used during the performance and capacity testing of Servios do
Excel.

Dataset
Servios do 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:
242

Workbook Characteristics

Small

Large

Very
Large

Sheets

1-3

1-5

1-20

Columns

10-20

10-500

101,000

Rows

10-40

10-10,000

10030,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%

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

This differs from other SharePoint Server 2010 capacity planning documents. Servios
do 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%

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, Servios de Clculo do Excel, 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 Servios de
Clculo do Excel 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 Servios de Clculo
do Excel 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
244

three application servers for Servios do Excel and Servios de Clculo do Excel, 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.

Machine Role

CPU

Memory

Network

Web front-end server

2 proc/4 core 2.33 GHz Intel


Xeon

8 GB

1 gig

Servios de Clculo do Excel

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 Servios de Clculo do Excel 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 Servios de Clculo do Excel and Web front-end
servers for the scale-up tests, and then varied the number of processors and available
memory in the Servios de Clculo do Excel computers.
Servios de Clculo do Excel 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 Servios de Clculo do Excel 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 Servios do Excel no 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 Servios do Excel bottlenecks, see the Common bottlenecks and
their causes section in this article.

Overall Scale
The table here summarizes the effect of adding additional Web Front-End and dedicated
Servios de Clculo do Excel computers to the farm. These throughput numbers are
specifically for the Servios de Clculo do Excel computers, and do not reflect the effect
on the overall farm.
245

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

246

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

247

The previous chart shows that there is overhead associated with adding Web front-end
computers to the farm. However, this is offset as Servios de Clculo do Excel computers
are added. A single Web front-end became the bottleneck after adding two additional
Servios de Clculo do Excel computers. This Web front-end bottleneck reversed any
benefit that was gained from the additional capacity of adding a second and third
Servios de Clculo do Excel computer. Also notice that three Web front-end computers
248

did not add any more throughput, as Servios de Clculo do Excel became the limiting
factor.

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 Servios de Clculo do Excel computers, the CPU load is reaching
the maximum seen for a single Web front-end computer. This implies that adding another
Servios de Clculo do Excel 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.
249

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 Servios de Clculo do Excel computer. Also
notice that exactly as with the recommended results, adding a third Web front-end
computer does not add to throughput as Servios de Clculo do Excel is the limiting
factor after the second Web front-end computer is added.
250

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 Servios de Clculo do Excel 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

251

1x3

2x1

2x2

2x3

3x1

3x2

3x3

Overall

1x1

1x2

1x3

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

1x3

2x1

2x2

2x1

2x3

2x2

2x3

3x1

3x2

3x1 3x2

3x3

Web Front-end Tier

1x1

1x2

3x3

% CPU (average
over all Web Frontend computers

33.73

37.64 33.84 14.61 23.95 36.90 7.54 13.12 21.75

Servios 1x1
de
Clculo
do Excel
Tier

1x2

1x3

2x1

2x2

2x3

3x1

3x2

3x3

% CPU 30.56
(average
over all
Servios
de
Clculo
do Excel
computer
s)

34.55

31.67

26.03

45.94

68.37

20.71

38.82

63.70

Peak
5.94E+0 5.82E+0 5.79E+0 5.87E+0 6.09E+0 5.92E+0 5.79E+0 5.91E+0 5.85E+0
Private 9
9
9
9
9
9
9
9
9
Bytes
(maximu
m over all
Servios
de
Clculo
do Excel
computer
s)

Maximum Results
The following tables show the maximum results of our tests.
252

Overall

1x1

1x2

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

% CPU (average
41.08
over all Web Frontend computers

1x3

1x3

2x1

2x1

2x2

2x2

2x3

2x3

3x1

3x1

3x2

3x2

3x3

3x3

67.78 58.59 19.44 34.11 45.97 10.19 17.79 28.69

Servios 1x1
de
Clculo
do Excel
Tier

1x2

1x3

% CPU 24.99
(average
over all
Servios
de
Clculo
do Excel
computer
s)

1844 10.96

2x1

2x2

2x3

3x1

3x2

3x3

23.57

20.56

17.77

18.97

17.04

18.10

Peak
5.91E+ 5.85E+ 5.91E+ 5.88E+ 5.99E+ 6.502E+ 5.94E+ 5.94E+ 6.04E+
Private 09
09
09
09
09
09
09
09
09
Bytes
(maximu
m over
all
Servios
de
Clculo
do Excel
computer
s)

253

Scale Up Test results


We also measured the effect of adding CPUs and memory to the Servios de Clculo do
Excel tier. For these tests, a 1x1 topology was used.

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

254

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 Servios do 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 Servios de
Clculo do Excel computer can support.

Recommendations
This section provides general performance and capacity recommendations for hardware,
Servios do Excel settings, common bottlenecks and troubleshooting.
Note that Servios do 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.
255

Hardware Recommendations
Servios do 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
Servios de Clculo do Excel tier. Note that one of the first bottlenecks an Servios de
Clculo do Excel 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 Servios do Excel scenario:
To provide for more user load, check the CPU and memory for the existing Servios
do 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 Servios de Clculo do Excel computers may be necessary.
Add additional Servios de Clculo do Excel 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. Servios do 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.

Performance-Related Servios do Excel Settings


One of the ways to control the performance characteristics of Servios do 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 > Aplicativo Servios do Excel > Global Settings:
Maximum Private Bytes By default, Servios de Clculo do Excel 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 Servios de Clculo do Excel, 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 Servios de Clculo do Excel will cache unused


objects (for example, read-only workbooks for which all sessions have timed out) in
memory. By default, Servios de Clculo do Excel 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 Servios de Clculo
do Excel. 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.

256

Maximum Unused Object Age By default, Servios de Clculo do Excel will keep
objects in the memory cache as long as possible. To reduce the Servios de Clculo
do Excel 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 > Aplicativo Servios do 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, Servios de Clculo do Excel 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 Servios de Clculo do Excel tier
computers. However, there may be users in your organization that need these settings to
be increased for Servios de Clculo do Excel 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.

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, Servios de Clculo do Excel 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 Servios de Clculo do Excel can draw on external data
sources. However, the time that is required to draw upon the external source can be
significant, with potentially a large amount of data returned. If external data is
allowed, there are several additional settings that can help throttle the effect of this
feature.

Common bottlenecks and their causes


During performance testing, several different common bottlenecks were revealed.
Bottlenecks are defined as a state in which the capacity of a particular component of a
farm is reached. This causes a plateau or decrease in farm throughput.
The following table lists some common bottlenecks and describes their causes and
possible resolutions.

Troubleshooting performance and scalability


Bottleneck

Cause

Resolution

Servios de Clculo do Excel


Memory

Scale Up with
Servios do Excel holds each
more memory in
workbook in memory throughout
the user's session. A large number the Servios de
257

Bottleneck

Cause

Resolution

of workbooks, or large workbooks,


can cause Servios de Clculo do
Excel to consume all available
memory causing the actually
consumed "Private Bytes" to
exceed "Maximum Private Bytes."

Clculo do Excel
tier computers, or
Scale Out with
the addition of
more Servios de
Clculo do Excel
computers. The
choice will partly
depend on if
CPU is also
reaching a
maximum.

Servios de Clculo do Excel CPU Servios do Excel can depend on a


large amount of processing in the
application tier, depending on the
number and complexity of
workbooks.

Increase the
number of CPUs
and/or cores in
the existing
Servios de
Clculo do Excel
computers, or
add Servios de
Clculo do Excel
computers.

Web server CPU usage

This issue can be


resolved in one
of two ways. You
can add Web
servers to the
farm to distribute
user load, or you
can scale up the
Web server or
servers by
adding faster
processors.

When a Web server is overloaded


with user requests, average CPU
usage will approach 100 percent.
This prevents the Web server from
responding to requests quickly and
can cause timeouts and error
messages on client computers.

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.

258

Performance Counter

Apply to object

Notes

% Processor Time

Processor (w3wp)

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

% Processor Time

Processor (_Total)

Shows the
percentage of
elapsed time that
all threads on the
server computer
that used the
processor to
execute
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.

Servios de Clculo do Excel


The following table shows performance counters and processes to monitor for application
servers, or in this case Servios de Clculo do Excel, within your farm.

Performance Counter

Apply to object

Notes

% Processor Time

Processor (_Total)

Shows the
percentage of
elapsed time that
all threads on the
server that used
the processor to
execute
instructions.

% Processor Time

Processor (w3wp)

The Servios de
Clculo do Excel

259

Performance Counter

Apply to object

Notes

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.
Average Disk Queue Length

PhysicalDisk(_Total)

Watch for too


much disk writing
because of
logging.

Private Bytes

Process(w3wp)

Servios do
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
Servios de
Clculo do Excel,
memory
consumption for
the Servios de
Clculo do Excel
w3wp will
increase.

SQL Server
As we have previously described, Servios do Excel is light on the SQL Server tier, as
workbooks are read once into memory on the Servios de Clculo do Excel tier during
the user's session. Follow general SharePoint Server guidelines for monitoring and
troubleshooting of the SQL Server tier.

260

Estimar os requisitos de desempenho e


capacidade dos Servios
PerformancePoint
Este artigo descreve o efeito que o uso do Servios PerformancePoint tem sobre
topologias que executam o Microsoft SharePoint Server 2010.
Observao:
importante estar ciente de que os nmeros especficos relativos capacidade e ao
desempenho apresentados neste artigo sero diferentes daqueles usados em ambientes
reais. Os nmeros aqui apresentados tm por objetivo fornecer um ponto de partida para
o design de um ambiente dimensionado adequadamente. Depois de concludo o design
inicial do sistema, teste a configurao para determinar se o sistema dar suporte aos
fatores do seu ambiente.
Neste artigo:
Caractersticas do farm de teste

Resultados do teste

Recomendaes
Para obter informaes gerais sobre como planejar e executar o planejamento da
capacidade para o SharePoint Server 2010, consulte Capacity management and sizing
for SharePoint Server 2010 (em ingls).

Caractersticas do farm de teste


Conjunto de dados
O conjunto de dados consistia em um portal corporativo criado com o uso do SharePoint
Server 2010 e do Servios PerformancePoint e que continha um painel de mdio porte
nico. O painel continha dois filtros vinculados a um scorecard, dois grficos e uma
grade. O painel se baseou em uma fonte de dados nica do Microsoft SQL Server 2008
Analysis Services (SSAS) que usou os bancos de dados de amostra do AdventureWorks
para o cubo do SQL Server 2008 Analysis Services.
A tabela a seguir descreve o tipo e o tamanho de cada elemento no painel.

Nome

Descrio

Tamanho

Filtro Um

Filtro de seleo de membros

7 membros da
dimenso

261

Nome

Descrio

Tamanho

Filtro Dois

Filtro de seleo de membros

20 membros da
dimenso

Scorecard

Scorecard

15 linhas de
membros da
dimenso por 4
colunas (2 KPIs)

Grfico Um

Grfico de linhas

3 sries por 12
colunas

Grfico Dois

Grfico de barras empilhadas

37 sries por 3
colunas

Grade

Grade analtica

5 linhas por 3
colunas

O painel mdio usou o modelo de Cabealho e Duas Colunas, e os tamanhos de itens


do painel foram definidos como dimensionamento automtico ou como uma
porcentagem especfica do painel. Cada item do painel foi renderizado com uma altura e
uma largura aleatrias entre 400 e 500 pixels para simular as diferenas nos tamanhos
de janelas de navegadores da Web. importante alterar a altura e a largura de cada
item do painel porque grficos so renderizados com base nos tamanhos de janelas dos
navegadores da Web.

Cenrios e processos de teste


Esta seo define os cenrios de teste e aborda os processos de teste que foram
usados para cada cenrio. Informaes detalhadas, como resultados de teste e
parmetros especficos, so fornecidas nas sees "Resultados de teste", mais adiante
neste artigo.

Nome do teste

Descrio do teste

Renderize um painel e altere aleatoriamente 1. Renderize o painel.


um dos dois filtros cinco vezes, com 15
2. Selecione um dos dois filtros, selecione
segundos de pausa entre as interaes.
aleatoriamente um valor de filtro e
aguarde at que o painel seja
renderizado novamente.
3. Repita mais quatro vezes, selecionando
aleatoriamente um dos dois filtros e um
valor de filtro aleatrio.
Renderize um painel, selecione um grfico e 1. Renderize o painel.
expanda e recolha-o cinco vezes com uma 2. Selecione um membro aleatrio em um
pausa de 15 segundos entre interaes.
262

Nome do teste

Descrio do teste

grfico e expanda-o.
3. Selecione outro membro aleatrio no
grfico e recolha-o.
4. Selecione outro membro aleatrio no
grfico e expanda-o.
5. Selecione outro membro aleatrio no
grfico e recolha-o.
Renderize um painel, selecione uma grade 1. Renderize o painel. Selecione um
e expanda e recolha-a cinco vezes com
membro aleatrio em uma grade e
uma pausa de 15 segundos entre
expanda o membro.
interaes.
2. Selecione outro membro aleatrio na
grade e expanda-o.
3. Selecione outro membro aleatrio na
grade e recolha-o.
4. Selecione outro membro aleatrio na
grade e expanda-o.

Uma nica combinao de testes foi usada com as seguintes porcentagens de testes
iniciados.

Nome do teste

Combinao de testes

Renderize um painel e altere aleatoriamente 80%


um dos dois filtros cinco vezes.
Renderize um painel, selecione um grfico e 10%
expanda e recolha-o cinco vezes.
Renderize um painel, selecione uma grade 10%
e expanda e recolha-a cinco vezes.
As ferramentas de Teste de Carga do Microsoft Visual Studio 2008 foram usadas para
criar um conjunto de testes da Web e testes de carga que simularam os usurios
alterando filtros aleatoriamente e navegando em grades e grficos. Os testes usados
neste artigo continham uma distribuio normal de pausas de 15 segundos entre
interaes, tambm conhecidas como "momentos de reflexo", e um momento de
reflexo entre iteraes de teste de 15 segundos. A carga foi aplicada para produzir um
tempo de resposta mdio de dois segundos para renderizar um scorecard ou um
relatrio. O tempo mdio de resposta foi medido durante um perodo de 15 minutos aps
um tempo de aquecimento inicial de dez minutos.

263

Cada nova iterao de teste seleciona uma conta de usurio diferente de um pool de
cinco mil contas e um endereo IP aleatrio (usando a Troca de IP do Visual Studio) de
um pool de aproximadamente 2.200 endereos.
A combinao de testes foi executada duas vezes para o mesmo painel de porte mdio.
Na primeira execuo, a autenticao da fonte de dados foi configurada para usar a
Conta de Servio sem Superviso, que usa uma conta comum para solicitar os dados.
Os resultados de dados so idnticos para vrios usurios, e o Servios
PerformancePoint pode usar um cache para melhorar o desempenho. Na segunda
execuo, a autenticao da fonte de dados foi configurada para usar a identidade por
usurio, e o cubo do SQL Server Analysis Services foi configurado para usar a
segurana dinmica. Nessa configurao, o Servios PerformancePoint usa a identidade
do usurio para solicitar os dados. Como os resultados de dados podem ser diferentes,
nenhum cache pode ser compartilhado entre os usurios. Em alguns casos, o cache
para a identidade por usurio pode ser compartilhado quando a segurana dinmica do
Analysis Services no est configurada e as funes do Analysis Services, s quais os
usurios e grupos do Microsoft Windows esto atribudos, so idnticas.

Configurao e topologia de hardware


Hardware de laboratrio
Para fornecer um alto nvel de detalhes para o resultado do teste, vrias configuraes
de farm foram usadas para teste. As configuraes do farm abrangeram de um a trs
servidores Web, de um a quatro servidores de aplicativos e um nico servidor de banco
de dados que estava executando o Microsoft SQL Server 2008. Foi feita uma instalao
corporativa padro do SharePoint Server 2010.
A tabela a seguir lista o hardware especfico que foi usado para teste.

Servidor Web

Servidor Computador Computador


de
executando executando
aplicativos o SQL
o Analysis
Server
Services

Processador(es)

2px4c a 2.66 GHz

2px4c a 2px4c a
2.66 GHz 2.66 GHz

4px6c a 2.4
GHz

RAM

16 GB

32 GB

64 GB

Sistema operacional

Windows Server 2008 R2 Windows Windows


Enterprise
Server
Server
2008 R2 2008 R2
Enterprise Enterprise

NIC

1x1 gigabit

1x1
gigabit

Autenticao

NTLM e Kerberos

NTLM e NTLM e
Kerberos Kerberos

16 GB

Windows
Server
2008 R2
Enterprise

1x1 gigabit 1x1 gigabit


NTLM e
Kerberos

Depois que o farm foi dimensionado para vrios servidores Web, um balanceador de
carga de hardware foi usado para balancear a carga de usurios entre vrios servidores
264

Web por meio do uso de afinidade do endereo de origem. A afinidade do endereo de


origem registra o endereo IP de origem de solicitaes recebidas e o host do servio
para o qual elas tiveram a carga balanceada e encaminha todas as futuras transaes
para o mesmo host.
Topologia
A topologia inicial consistia em dois servidores fsicos, com um servidor atuando como
servidor Web e de aplicativos e o segundo atuando como servidor de banco de dados. A
topologia inicial considerada uma topologia de dois computadores (2C) ou uma
topologia "1 por 0 por 1", em que o nmero de servidores Web dedicados listado
primeiro, seguido por servidores de aplicativos dedicados e, em seguida, por servidores
de banco de dados.
Os servidores Web tambm so conhecidos como WFE (front-ends da web) mais
adiante neste documento. A carga foi aplicada at a identificao de fatores limitadores.
Geralmente, a CPU no servidor Web ou no servidor de aplicativos era o fator limitador, e
os recursos foram adicionados para solucionar esse limite. Os fatores limitadores e as
topologias diferiam significativamente com base na configurao da autenticao da
fonte de dados da Conta de Servio sem Superviso ou da Identidade por usurio com
segurana de cubo dinmica.

Resultados do teste
Os resultados do teste contm trs medidas importantes para ajudar a definir a
capacidade do Servios PerformancePoint.

Medida

Descrio

Contagem de usurios

Contagem total de usurios informada pelo Visual Studio.

SPS (solicitaes por


segundo)

SPS total informado pelo Visual Studio, o que inclui todas as


solicitaes e um arquivo esttico de solicitaes, como
imagens e folhas de estilo.

EPS (exibies por


segundo)

Total de exibies que o Servios PerformancePoint pode


renderizar. Uma exibio qualquer filtro, scorecard, grade
ou grfico renderizado pelo Servios PerformancePoint ou
qualquer solicitao da Web para a URL do servio de
renderizao que contm o RenderWebPartContent ou o
CreateReportHtml. Para saber mais sobre o
CreateReportHtml e o RenderWebPartContent, consulte
a especificao do protocolo RenderingService do
PerformancePoint Services
(http://go.microsoft.com/fwlink/?linkid=200609&clcid=0x416).
Os logs do IIS podem ser analisados para essas
solicitaes a fim de ajudar a planejar a capacidade do
Servios PerformancePoint. Alm disso, o uso dessa
medida fornece um nmero que muito menos dependente
da composio do painel. Um painel com duas exibies
pode ser comparado a um painel com dez exibies.
265

Dica:
Quando voc est usando uma fonte de dados configurada para usar a autenticao da
Conta de Servio sem Superviso, a regra para o ndice de servidores dedicados um
servidor Web para cada dois servidores de aplicativos que executam o Servios
PerformancePoint.

Dica:
Quando voc est usando uma fonte de dados configurada para usar a autenticao por
usurio, a regra para o ndice de servidores dedicados um servidor Web para cada
quatro ou mais servidores de aplicativos que executam o Servios PerformancePoint.
Em topologias maiores do que quatro servidores de aplicativos, provvel que o
afunilamento seja o servidor do Analysis Services. Avalie a possibilidade de monitorar a
CPU e o tempo de consulta de seu servidor do Analysis Services para determinar se
voc deve dimensionar o Analysis Services para vrios servidores. Qualquer atraso no
tempo de consulta no servidor do Analysis Services aumentar significativamente o
tempo mdio de resposta do Servios PerformancePoint para alm do limite desejado de
dois segundos.
As tabelas a seguir mostram um resumo dos resultados de teste para a autenticao da
Conta de Servio sem Superviso e para a autenticao por usurio, quando se
expande de dois para sete servidores. Os resultados detalhados que incluem contadores
de desempenho adicionais so includos mais adiante neste documento.
Resumo da autenticao da Conta de Servio sem Superviso

Topologia (WFE x APP x SQL)

Usurios

SPS
EPS
(solicitaes (exibies
por segundo) por seg)

2C (1x0x1)

360

83

50

3C (1x1x1)

540

127

75

4C (1x2x1)

840

196

117

5C (1x3x1)

950

215

129

6C (2x3x1)

1.250

292

175

7C (2x4x1)

1.500

346

205

Resumo da autenticao por usurio

266

Topologia (WFE x APP x SQL)

Usurios

SPS
EPS
(solicitaes (exibies
por segundo) por seg)

2C (1x0x1)

200

47

27

3C (1x1x1)

240

56

33

4C (1x2x1)

300

67

40

5C (1x3x1)

325

74

44

Topologias 2C e 3C
Para ajudar a explicar o custo de hardware por transao e a curva do tempo de
resposta, os testes de carga foram executados com quatro cargas de usurio crescentes
at a carga mxima de usurios para as topologias 2C e 3C.
Autenticao da Conta de Servio sem Superviso

Contagem de usurios

50

150

250

Mdia de CPU WFE/APP

19,20%

57,70%

94,00% 96,70%

SPS

18

53

83

83

Exibies por segundo

10,73

31,72

49,27

49,67

Tempo mdio de resposta


(seg)

0,12

0,15

0,38

267

360

Autenticao por usurio

Contagem de usurios

50

100

150

Mdia de CPU WFE/APP

30,80%

61,30%

86,50% 93,30%

SPS

17

32

43

47

Exibies por segundo

10,3

19,32

26,04

27,75

Tempo mdio de resposta


(seg)

0,28

0,45

0,81

268

200

Resultados do farm 3C (1x1x1)


Autenticao da Conta de Servio sem Superviso

Contagem de usurios

100

250

400 540

SPS

36

87

124 127

Exibies por segundo

21

52

74

Tempo mdio de resposta (seg) 0,12

0,18

0,65 2

11%

28%

43% 46%

1,4 GB

2
2,4
GB GB

62%

94% 95%

10,8 GB

14,1 14,6
GB GB

Mdia de CPU WFE

Mximo de bytes privados WFE 0,7 GB


do processo de trabalho W3WP
do IIS (Servios de Informaes
da Internet) do SharePoint
Server.
Mdia de CPU APP

25%

Mximo de bytes privados APP 5,9 GB


do W3WP do Servios
269

75

100

250

400 540

Contagem de usurios

50

120

180 240

SPS

17

39

52

56

Exibies por segundo

10

23

31

33

0,48

0,91 2

12%

17% 19%

1,3 GB

1,6 1,9
GB GB

57%

81% 81%

Contagem de usurios

PerformancePoint

Autenticao por usurio

Tempo mdio de resposta (seg) 0,28


Mdia de CPU WFE

5%

Mximo de bytes privados WFE 0,78 GB


do W3WP do SharePoint
Server
Mdia de CPU APP

25%
270

Contagem de usurios

50

Mximo de bytes privados APP 19 GB


do W3WP do Servios
PerformancePoint

120

180 240

20,1 GB

20,5 20,9
GB GB

Resultados para mais de 4C com


autenticao da Conta de Servio sem
Superviso
Comeando com a topologia de 4C, a carga foi aplicada para produzir um tempo de
resposta mdio de dois segundos para renderizar um scorecard ou um relatrio. Em
seguida, um servidor extra foi adicionado para solucionar o fator limitador (sempre CPU
no servidor Web ou no servidor de aplicativos) e, em seguida, a combinao de testes foi
executada novamente. Esta lgica foi repetida at alcanar um total de sete servidores.

271

4C (1x2x1)

5C (1x3x1)

6C
7C
(2x3x1) (2x4x1)

Contagem de usurios

840

950

1.250 1.500

SPS

196

216

292

346

Exibies por segundo

117

131

175

206

Mdia de CPU WFE

77%

63%

54%

73%

Mximo de bytes privados


WFE do W3WP do
SharePoint Server

2,1 GB

1,7 GB

2,1
GB

2 GB

Mdia de CPU APP

83%

94%

88%

80%

Mximo de bytes privados


APP do W3WP do Servios
PerformancePoint

16 GB

12 GB

15 GB 15 GB

Resultados para mais de 4C com


autenticao por usurio
Os mesmos testes foram repetidos para uma fonte de dados configurada para
autenticao por usurio. Observe que adicionar um servidor de aplicativos para criar
uma topologia de quatro servidores de aplicativos no aumentou o nmero de usurios
ou solicitaes por segundo para o qual havia suporte do Servios PerformancePoint por
causa dos atrasos de consulta que o Analysis Services produziu.

3C (1x1x1)

4C (1x2x1)

5C
6C
(1x3x1) (1x4x1)

Contagem de usurios

240

300

325

325

RPS

56

67

74

74

Exibies por segundo

33

40

44

45

Mdia de CPU WFE

19%

24%

26%

12%

Mximo de bytes privados


WFE do W3WP do
SharePoint Server

2,1 GB

1,9 GB

1,9
GB

1,5
GB

Mdia de CPU APP

89%

68%

53%

53%

Mximo de bytes privados


APP do W3WP do Servios
PerformancePoint

20 GB

20 GB

20 GB 20 GB

272

CPU do Analysis Services

3C (1x1x1)

4C (1x2x1)

5C
6C
(1x3x1) (1x4x1)

17%

44%

57%

68%

Recomendaes
Recomendaes de hardware
Os contadores de memria e processador das tabelas de teste devem ser usados para
determinar os requisitos de hardware para uma instalao do Servios
PerformancePoint. Para servidores Web, o Servios PerformancePoint usa os requisitos
recomendados de hardware do SharePoint Server 2010. Os requisitos de hardware do
servidor de aplicativos talvez precisem ser alterados quando o Servios
PerformancePoint consome uma grande quantidade de memria. Isso acontece quando
as fontes de dados so configuradas para a autenticao por usurio ou quando o
servidor de aplicativos executa vrios painis com longos tempos limites da fonte de
dados.
O servidor de banco de dados no se tornou um afunilamento nos testes e alcanou o
mximo de uso de CPU de 31% no painel 7C autenticado pela Conta de Servio sem
273

Superviso. As definies de contedo do Servios PerformancePoint, como relatrios,


scorecards e KPIs, so armazenadas em listas do SharePoint e so armazenadas em
cache na memria pelo Servios PerformancePoint, reduzindo a carga no servidor de
banco de dados.
Consumo de memria
O Servios PerformancePoint pode consumir grandes quantidades de memria em
algumas configuraes, e importante monitorar o uso de memria do pool de
aplicativos do Servios PerformancePoint. O Servios PerformancePoint armazena em
cache vrios itens em memria, incluindo o Analysis Services e outros resultados de
consulta da fonte de dados para o tempo de vida do cache da fonte de dados (um
padro de dez minutos). Quando voc est usando uma fonte de dados configurada
para autenticao de Conta de Servio sem Superviso, esses resultados de consulta
so apenas armazenados uma vez e compartilhados entre vrios usurios. No entanto,
quando voc usa uma fonte de dados configurada para autenticao por usurio e a
segurana do cubo dinmico do Analysis Services, os resultados de consulta so
armazenados uma vez por usurio e por exibio (ou seja, uma combinao "por filtro").
A API do cache subjacente que o Servios PerformancePoint usa a API do Cache
ASP.NET. A vantagem significativa de usar essa API que o ASP.NET gerencia o cache
e remove itens (o que tambm conhecido como corte) com base em limites de
memria, para evitar erros de falta de memria. O limite de memria padro 60% da
memria fsica. Depois de alcanar esses limites, o Servios PerformancePoint ainda
renderizou exibies, mas os tempos de resposta aumentaram significativamente
durante o curto perodo em que o ASP.NET removeu as entradas armazenadas em
cache.
O contador de desempenho "Aplicativos ASP.NET \ Cortes de API de Cache" do pool de
aplicativos de host do Servios PerformancePoint pode ser usado para monitorar os
cortes de cache do ASP.NET que ocorrem por presso da memria. Se esse contador
for maior do que zero, examine a tabela a seguir para encontrar possveis solues.

Problema

Soluo

O uso do processador do servidor de


aplicativos baixo e outros servios esto
em execuo no servidor de aplicativos.

Adicione mais memria fsica ou limite a


memria do cache ASP.NET.

O uso do processador do servidor de


aplicativos baixo e apenas o Servios
PerformancePoint est em execuo no
servidor de aplicativos.

Se aceitvel, configure as definies de


cache do ASP.NET para que o cache use
mais memria ou adicione mais memria.

O uso do processador do servidor de


aplicativos alta.

Adicione outro servidor de aplicativos.

Uma fonte de dados configurada para usar a autenticao por usurio pode compartilhar
resultados de consulta e entradas de cache quando os conjuntos de associao de
funes do Analysis Services dos usurios so idnticos e quando a segurana do cubo
dinmico no est configurada. Esse um novo recurso do Servios PerformancePoint
no Microsoft SharePoint Server 2010. Por exemplo, se o usurio A estiver nas funes 1
274

e 2, o usurio B estiver nas funes 1 e 2 e o usurio C estiver nas funes 1, 2 e 3,


somente o usurio A e o usurio B compartilharo entradas de cache. Se houver
segurana de cubo dinmico, os usurios A, B e C no compartilharo as entradas de
cache.

Analysis Services
Quando o Servios PerformancePoint estava sendo testado com autenticao por
usurio, duas propriedades do Analysis Services foram alteradas para melhorar o
desempenho da produtividade para vrios usurios. A tabela a seguir mostra as
propriedades que foram alteradas e um novo valor de cada propriedade.

Propriedade do Analysis Services

Valor

Memria \ HeapTypeForObjects

Memria \ MemoryHeapType

Essas duas definies de memria configuram o Analysis Services para usar o heap do
Windows em vez do heap do Analysis Services. Antes de alterar essas propriedades e
durante a adio de carga de usurio, os tempos de resposta aumentaram
significativamente de 0,2 segundos para mais de 30 segundos, enquanto a CPU nos
servidores Web, de aplicativos e do Analysis Services permaneceu baixa. Para
solucionar o problema, o tempo de consulta foi coletado por meio do uso de DMV
(exibies de gerenciamento dinmico) do Analysis Services, que apresentaram um
aumento de tempos de consulta individuais de 10 milissegundos para 5.000
milissegundos. Esses resultados levaram modificao das configuraes de memria
acima.
importante observar que, embora isso tenha melhorado significativamente a
produtividade, segundo a equipe do Analysis Services, a alterao dessas configuraes
tem um custo pequeno, mas mensurvel em consultas de um nico usurio.
Antes de alterar qualquer propriedade do Analysis Services, consulte o white paper do
SQL Server 2008 sobre o guia de desempenho do Analysis Services
(http://go.microsoft.com/fwlink/?linkid=165486&clcid=0x416) para obter prticas
recomendadas sobre como melhorar o desempenho da produtividade para vrios
usurios.

Afunilamentos comuns e suas causas


Durante o teste de desempenho, vrios afunilamentos comuns foram revelados. Um
afunilamento uma condio em que a capacidade de um elemento especfico de um
farm alcanada. Isso causa uma estabilizao ou uma diminuio na produtividade do
farm. Quando a alta utilizao do processador encontrada como um afunilamento,
servidores adicionais so adicionados para resolver o afunilamento. A tabela a seguir
lista alguns afunilamentos comuns e possveis solues, considerando uma baixa
utilizao do processador e no o afunilamento.

275

Possvel
afunilamento

Causa e o que
monitorar

Desempenho
do heap de
memria do
Analysis
Services

Altere o Analysis Services para usar o heap do


Por padro, o
Windows. Consulte a seo "Analysis Services"
Analysis
Services usa
anteriormente neste artigo e o white paper do SQL
seu prprio heap Server 2008 sobre o guia de desempenho do Analysis
de memria em Services
vez do heap do (http://go.microsoft.com/fwlink/?linkid=165486&clcid=0x4
Windows, o que 16) para obter instrues.
proporciona
baixo
desempenho de
produtividade
para vrios
usurios. Analise
os tempos de
consulta do
Analysis
Services usando
DMV (exibies
de
gerenciamento
dinmico) para
ver se os
tempos de
consulta
aumentam com
a carga dos
usurios e se a
utilizao do
processador do
Analysis
Services
baixa.

Threads de
Por padro, o
processament Analysis
o e consulta Services limita o
do Analysis nmero de
Services
threads de
consulta e
processamento
para consultas.
Consultas de
execuo longa
e altas cargas
de usurio
podem usar
todos os threads

Soluo

Aumente o nmero de threads disponveis para consulta


e processos. Consulte a seo do Analysis Services e o
white paper do SQL Server 2008 sobre o guia de
desempenho do Analysis Services
(http://go.microsoft.com/fwlink/?linkid=165486&clcid=0x4
16) para obter instrues.

276

Possvel
afunilamento

Causa e o que
monitorar

Soluo

disponveis.
Monitore os
threads ociosos
e contadores de
desempenho da
fila de trabalhos
na categoria
MSAS
2008:Threads.
Memria do
servidor de
aplicativos

O Servios
Adicione memria ou aumente os limites padro da
PerformancePoi memria cache do ASP.NET. Consulte a seo
nt armazena em Consumo de memria anteriormente neste documento
cache o Analysis para obter informaes adicionais. Alm disso, consulte
Services e
as configuraes de elementos do cache do ASP.NET
outros
(http://go.microsoft.com/fwlink/?linkid=200610&clcid=0x4
resultados de
16) e a postagem do blog de Thomas Marquardt sobre o
consulta da
histrico dos limites de memria cache do ASP.NET
fonte de dados (http://go.microsoft.com/fwlink/?linkid=200611&clcid=0x4
em memria
16).
pelo tempo de
vida do cache
da fonte de
dados. Esses
itens podem
consumir uma
grande
quantidade de
memria.
Monitore o
contador
Aplicativos
ASP.NET \
Cortes de API
de Cache do
pool de
aplicativos do
Servios
PerformancePoi
nt para
determinar se as
remoes ou
cortes de cache
esto sendo
foradas pelo
ASP.NET por
causa de baixa
memria.
277

Possvel
afunilamento

Causa e o que
monitorar

Soluo

Configuraes O Servios
Se necessrio, altere o comportamento de limitao do
de limitao PerformancePoi WCF (Windows Communication Foundation. Consulte os
nt
comportamentos de limitao do servio WCF
de WCF
implementado (http://go.microsoft.com/fwlink/?linkid=200612&clcid=0x4
como um servio 16) e a postagem do blog de Wenlong Dong sobre
limitao de solicitaes do WCF e escalabilidade do
WCF. O WCF
limita o nmero servidor
(http://go.microsoft.com/fwlink/?linkid=200613&clcid=0x4
mximo de
16).
chamadas
simultneas
como um
comportamento
de limitao do
servio. Embora
consultas de
execuo longa
possam atingir
esse
afunilamento,
esse um
afunilamento
incomum.
Monitore as
chamadas
pendentes do
contador de
desempenho do
WCF / Modelo
de Servio para
o Servios
PerformancePoi
nt e compare-as
com o nmero
mximo atual de
chamadas
simultneas.

Monitoramento de desempenho
Para ajudar voc a determinar quando necessrio aumentar a escala do sistema ou
expandi-lo, use contadores de desempenho para monitorar a integridade do sistema. O
Servios PerformancePoint um servio WCF do ASP.NET e pode ser monitorado com
o uso dos mesmos contadores de desempenho utilizados para monitorar qualquer outro
servio WCF do ASP.NET. Alm disso, use as informaes nas tabelas a seguir para
278

determinar contadores de desempenho suplementares a serem monitorados e para qual


processo os contadores de desempenho devem ser aplicados.

Contador de
desempenho

Instncia do
contador

Observaes

Aplicativos ASP.NET \ Pool de


Se o valor for maior do que zero, leia "Consumo
Cortes de API de Cache aplicativos do de memria".
Servios
PerformanceP
oint
MSAS 2008:Threads / N/A
threads ociosos do pool
de consultas

Se o valor for zero, leia a seo "Analysis


Services" e o white paper do SQL Server 2008
sobre o guia de desempenho do Analysis
Services
(http://go.microsoft.com/fwlink/?linkid=165486&cl
cid=0x416).

MSAS 2008:Threads /
tamanho da fila de
trabalhos do pool de
consultas

N/A

Se o valor for maior do que zero, leia a seo


"Analysis Services" e o white paper do SQL
Server 2008 sobre o guia de desempenho do
Analysis Services
(http://go.microsoft.com/fwlink/?linkid=165486&cl
cid=0x416).

MSAS 2008:Threads / N/A


threads ociosos do pool
de processamento

Se o valor for maior do que zero, leia a seo


"Analysis Services" e o white paper do SQL
Server 2008 sobre o guia de desempenho do
Analysis Services
(http://go.microsoft.com/fwlink/?linkid=165486&cl
cid=0x416).

MSAS 2008:Threads /
tamanho da fila de
trabalhos do pool de
processamento

Se o valor for maior do que zero, leia a seo


"Analysis Services" e o white paper do SQL
Server 2008 sobre o guia de desempenho do
Analysis Services
(http://go.microsoft.com/fwlink/?linkid=165486&cl
cid=0x416).

N/A

WCF
Instncia do Se o valor for maior do que zero, consulte o
CountersServiceModelS PerformanceP artigo sobre limitao de solicitaes de WCF e
ervice
oint Service escalabilidade do servidor
3.0.0.0(*)\Chamadas
(http://go.microsoft.com/fwlink/?linkid=200613&cl
pendentes
cid=0x416).

Consulte tambm
Outros recursos
279

Plan for PerformancePoint Services (SharePoint Server 2010)

280

Capacity requirements for Web Analytics


Shared Service in SharePoint Server
2010 (em 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:
Gerenciamento de desempenho e capacidade (SharePoint Server 2010)
Capacity management and sizing for SharePoint Server 2010 (em ingls)
In this article:
Introduction

Hardware specifications and topology

Capacity requirements

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

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

282

Figure 1. SharePoint Server 2010 Web Analytics architectural overview


The performance of the Logging Web Service primarily depends on the number of
application servers. (Scaling out is available for the application servers.) The
283

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
Observao:
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 Gerenciamento de
desempenho e capacidade (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

RAM

8 GB

Operating system

Windows Server 2008, 64 bit

Size of the SharePoint drive

300 GB

Number of network adapters

Network adapter speed

1 GB

Authentication

NTLM

Load balancer type

SharePoint Load Balancer


284

Application server

Minimum requirement

Software version

SharePoint Server 2010 (prerelease


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

Web Analytics Data Processing Service

Web Analytics Web Service

Database servers
The following table describes the configuration of each database server. Instances of
SQL Server were required for both the staging and reporting databases.

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
Observao:
Although we used this disk size for our
capacity testing, your environment will likely
require a much larger disk size to support
Web Analytics.

Number of network adapters

Network adapter speed

1 GB

Authentication

NTLM

Software version

SQL Server 2008


285

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

286

Figure 2. Web Analytics topology

287

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.

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.

288

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.

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.

289

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


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

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.

Figure 4. Daily site traffic vs. SQL Server topology


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

Configuration

1S+R

1S1R

1S1R

2S1R

2S1R

Staging + Reporting

Staging Reporting Staging Reporting

Total sum of percentage 19


of processor time for 8
processor computer

192

5.78

100

13.4

SQL Server buffer hit


ratio

99

100

100

100

100

% Disk time

7,142

535

5.28

59.3

98.2

Disk queue length

357

28.6

0.26

2.97

4.91

Other factors
Many other factors can affect the performance of various analytics components and can
affect the capacity planning. These factors primarily affect the performance of the Report
Extractor component because they can affect the size of the data aggregated each day.
The total size of the data in the reporting database also affects the performance of the
Reporting Extractor, although this is not significant because the data is partitioned daily.
Some of these other factors are as follows:
Number of unique queries each day.

Number of unique users each day.

Total number of unique assets clicked each day.

Existing data size in the reporting warehouse, based on the data retention in the
warehouse.
The overall effect of these factors is less significant than the total data volume and the
number of site entities. However, it is important to conduct your own capacity
management based on your planned workload and usage characteristics. For more
information about the capacity management process, see Gerenciamento de
desempenho e capacidade (SharePoint Server 2010).

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.

Consulte tambm
Conceitos
Gerenciamento de desempenho e capacidade (SharePoint Server 2010)

Outros recursos
SharePoint 2010 Administration Toolkit (SharePoint Server 2010)
292

Estimar os requisitos de desempenho e


capacidade do Gerenciamento de
contedo da Web no SharePoint Server
2010
Este artigo apresenta as diretrizes sobre o gerenciamento de capacidade relevantes
para os sites do Microsoft SharePoint Server 2010 com a Infraestrutura de Publicao
habilitada. Este documento especfico ao SharePoint Server 2010 e as informaes
abordadas no se aplicam ao SharePoint Foundation.
Este artigo aborda os seguintes cenrios:
Site de publicao na Internet - um site de presena corporativa.
Esse tipo de site publicado na Internet e permite que usurios annimos da
Internet localizem informaes sobre uma corporao. Sites como esse contm uma
marca, e o contedo rigorosamente controlado.
Site de publicao na intranet - site interno de notcias.
Esse tipo de site publicado internamente, dentro de uma organizao. Seu
principal uso compartilhar informaes com usurios autenticados, dentro da
organizao. As informaes do site podem ser gerenciadas com rigor ou, em
algumas reas, elas podem ser menos gerenciadas.
Wiki corporativo - um repositrio de conhecimentos.
Um wiki corporativo um site de farm nico, que cresce organicamente medida
que os colaboradores criam novas pginas e as vinculam a outras pginas, que
podem ou no existir. Os wikis corporativos geralmente so publicados no ambiente
interno de uma organizao. Esse site permite que as pessoas em uma empresa ou
organizao capturem e compartilhem conhecimentos, usando uma soluo
integrada e aprimorada pelo ambiente do SharePoint.
Aps a leitura deste documento, voc compreender os seguintes conceitos:
A principal mtrica (taxa de transferncia) que voc deve maximizar para aceitar
diversas operaes de leitura.

Os vrios afunilamentos possveis relevantes a uma implantao de Gerenciamento


de Contedo da Web do SharePoint Server 2010.

A importncia do cache de sada para a maximizao da taxa de transferncia.

O efeito das operaes de gravao na experincia de leitura do usurio final.


Neste artigo:
Informaes sobre pr-requisitos

Detalhes e abordagem do teste

Implantaes de Gerenciamento de Contedo da Web

O que otimizar
293

Resultados do teste e recomendaes

Sobre os autores

Informaes sobre pr-requisitos


Antes de ler este documento, voc deve entender os principais conceitos subjacentes ao
gerenciamento de capacidade do SharePoint Server 2010. A seguinte documentao o
ajudar a conhecer a abordagem recomendada para o gerenciamento da capacidade e
fornecer contexto que o ajudar a entender como fazer uso eficaz das informaes
deste documento.
Para obter mais informaes conceituais sobre desempenho e capacidade, que podem
ser teis para compreender o contexto dos dados deste artigo, consulte os seguintes
documentos:
Gerenciamento de capacidade e dimensionamento do SharePoint Server 2010

Estudos tcnicos de caso de desempenho e capacidade (SharePoint Server 2010)

Detalhes e abordagem do teste


Em cada teste, as variveis que podem existir no mundo real foram resumidas para
mostrar recomendaes especficas. Dessa forma, muito importante testar e monitorar
seu prprio ambiente, para verificar se voc o dimensionou corretamente para atender
ao volume de solicitaes esperado. Para saber mais sobre os conceitos de
gerenciamento de capacidade, consulte Viso geral do gerenciamento da capacidade e
dimensionamento do SharePoint Server 2010.
Este artigo aborda o desempenho com os Recursos de Conjunto de Sites, a
Infraestrutura de Publicao do SharePoint Server e o Cache de sada. Esses recursos
s esto disponveis quando a Infraestrutura de Publicao do SharePoint Server est
habilitada. Por padro, esse recurso est habilitado nos Portais de Publicao.

Conjunto de dados
Os testes foram conduzidos com o uso de um conjunto de dados que compartilha
caractersticas comuns s implantaes reais de Gerenciamento de Contedo da Web.
Embora o carregamento fosse constante, diferentes pginas foram solicitadas. A tabela
a seguir descreve o conjunto de dados usado para esses testes.

Conjunto de dados
Objeto

Site de publicao

Tamanho dos bancos de dados de


contedo

2.63 GB

Quantidade de bancos de dados de


contedo

Quantidade de conjuntos de sites

Quantidade de aplicativos Web

Quantidade de sites

50
294

Objeto

Site de publicao

Nmero de pginas

20.000 pginas divididas em 20 pastas com


1.000 pginas cada

Composio das pginas

Pginas de artigos em HTML bsico, com


referncias a duas imagens

Tamanho da pgina

42 KB descompactada; 12 KB compactada

Imagens

3.000 a 30 KB at 1.3 MB cada

recomendvel configurar o IIS (Servios de Informaes da Internet) para sempre


compactar arquivos, em vez da configurao padro de compactar arquivos
dinamicamente. Quando a compactao dinmica est habilitada, o IIS compacta
pginas at que a utilizao da CPU exceda um determinado limite e, nesse ponto, o IIS
para de compactar pginas at que a utilizao fique abaixo do limite. Os testes deste
artigo foram realizados com a compactao sempre ativada.
Esse conjunto de dados de teste utilizou apenas os recursos padro do SharePoint
Server 2010, que esto includos no produto. Seu site provavelmente incluir
personalizaes, alm desses recursos bsicos. Portanto, importante testar o
desempenho da sua prpria soluo.

Hardware
O nmero de servidores Web do farm variou em cada teste, mas todos tinham hardware
idntico. A tabela a seguir descreve o hardware de servidor Web e de servidor de
aplicativos que foi usado durante os testes.

Especificaes de hardware para servidores de aplicativos e


servidores Web
Servidor Web

Processadores

2 ncleos qudruplos a 2.33 GHz

RAM

8 GB

Sistema operacional

Windows Server 2008, 64 bits

Tamanho da unidade do SharePoint

300 GB

Quantidade de adaptadores de rede

Velocidade do adaptador de rede

1 gigabit

Autenticao

Bsica do Windows

Tipo de balanceador de carga

Balanceamento de carga do hardware

Verso do software

SharePoint Server 2010 (verso de prlanamento)

Servios em execuo no local

Administrao Central
295

Servidor Web

Email de entrada do Microsoft SharePoint


Foundation
Aplicativo Web do Microsoft SharePoint
Foundation
Servio de Timer do Fluxo de Trabalho do
Microsoft SharePoint Foundation
A tabela a seguir descreve o hardware do servidor de banco de dados usado para esses
testes.

Especificaes de hardware para servidores de banco de dados


Servidor de banco de dados

Processadores

4 ncleos qudruplos a 3.19 GHz

RAM

16 GB

Sistema operacional

Windows Server 2008, 64 bits

Armazenamento

15 discos de 300 GB a 15.000 RPM

Quantidade de adaptadores de rede

Velocidade do adaptador de rede

1 gigabit

Autenticao

NTLM

Verso do software

Microsoft SQL Server 2008

Glossrio
H alguns termos especializados que voc encontrar neste documento. Aqui esto
alguns dos principais termos e suas definies:
RPS Solicitaes por segundo. O nmero de solicitaes recebidas por um farm ou
servidor em um segundo. Esta uma medida comum de carga de servidor e farm.
Observe que as solicitaes diferem dos carregamentos de pgina; cada pgina
contm vrios componentes, cada um deles cria uma ou mais solicitaes quando a
pgina carregada. Portanto, um carregamento de pgina cria vrias solicitaes.
Em geral, as verificaes e os eventos de autenticao que usam recursos
insignificantes no so contados nas medies RPS.
Zona Verde Este o estado em que o servidor pode manter o seguinte conjunto de
critrios:

A latncia no servidor para pelo menos 75% das solicitaes menor que 1
segundo.

Todos os servidores tm uma utilizao de CPU menor que 50%.

A taxa de falha menor que 0,01%.


296

Implantaes de Gerenciamento de Contedo


da Web
H dois modelos que baseiam a autoria de contedo nos sites de publicao do
SharePoint, os quais podem afetar a sua escolha de topologia de farm de servidores.
No modelo autor no local, um nico conjunto de sites compartilhado por autores e
visitantes. Os autores podem criar e atualizar contedo a qualquer momento, o que leva
a distribuies variveis de operaes de leitura e gravao durante todo o dia. Esse
farm de servidores geralmente passa por incontveis leituras e uma quantidade
moderada de gravaes.
O diagrama a seguir mostra como a criao no local funciona de uma perspectiva
topolgica.

No modelo implantao de contedo, vrios conjuntos de sites, separada e


exclusivamente, oferecem suporte criao e publicao de contedo. O contedo
criado e atualizado no ambiente de criao e, em seguida, implantado no ambiente de
publicao de acordo com uma agenda, para ser lido pelos visitantes. O ambiente de
publicao atende primeiramente s solicitaes de leitura, exceto quando o contedo
est sendo implantado a partir do ambiente de criao. Diferentemente do modelo autor
no local, a carga do servidor gerada pela implantao de contedo pode ser ajustada
para intervalos agendados.
O diagrama a seguir mostra como a implantao de contedo funciona de uma
perspectiva topolgica.

Esses modelos de criao de contedo so mutuamente exclusivos.


Embora os sites de publicao na Internet e os sites de publicao na intranet possam
usar o modelo autor no local ou o modelo de implantao de contedo, os wikis
corporativos funcionam melhor com o modelo autor no local. Um wiki corporativo
geralmente apresenta um volume maior de operaes de gravao em relao s
operaes de leitura, porque uma proporo maior de usurios pode editar pginas. As
pginas de wiki corporativo diferem das pginas de artigo de publicao e exibem
caractersticas diferentes de desempenho.

O que otimizar
Esta seo aborda as informaes de otimizao do ambiente de Gerenciamento de
Contedo da Web. A otimizao do ambiente inclui saber como gerenciar taxas de
transferncia, afunilamentos e armazenamentos em cache.
297

Nesta seo:
Taxa de transferncia a mtrica principal

Afunilamentos e correo

Ajuda do armazenamento em cache

Taxa de transferncia a mtrica principal


Taxa de transferncia e tempo de resposta so as mtricas mais importantes a serem
otimizadas quando voc faz o planejamento de capacidade para uma implantao de
Gerenciamento de Contedo da Web do SharePoint Server 2010. A taxa de
transferncia o nmero de operaes que um farm de servidores pode executar por
segundo, medida em RPS (solicitaes por segundo).

Afunilamentos e correo
Afunilamento o recurso do sistema que, quando atingido, impede que o farm de
servidores atenda a solicitaes adicionais. O diagrama a seguir mostra os elementos de
um farm de servidores e os recursos que podem se tornar afunilamentos e que devem
ser monitorados.

298

Utilizao da CPU do servidor Web


A CPU do servidor Web deve ser o afunilamento de uma topologia bem ajustada, pois
o componente mais facilmente escalonvel. O balanceador de carga faz o roteamento de
299

solicitaes entre os servidores Web e garante que nenhum servidor seja muito mais
utilizado do que seus pares.
Embora outros usurios possam visitar o site aps a total utilizao da CPU do servidor
Web, o tempo de resposta do servidor maior para esses usurios. Esse
comportamento til ao gerenciamento de picos no volume de solicitaes. Entretanto,
uma carga constante que exceda a capacidade de um farm de servidores, com o tempo,
resultar em uma lista de pendncias de solicitaes grande o bastante para ultrapassar
o limite de solicitaes em espera. Nesse ponto, os servidores Web aceleram as
solicitaes e respondem com um erro HTTP 503. Na ilustrao a seguir, o tempo de
resposta do servidor diminui aps o limite de solicitaes em espera ter sido atingido
porque somente erros HTTP so exibidos.

As seguintes alteraes so mostradas neste diagrama:


1. O tempo de resposta aumenta medida que a utilizao da CPU do servidor Web se
aproxima dos 100%.
2. Depois que o limite de solicitaes em espera atingido, solicitaes adicionais so
exibidas com erros.

Outros afunilamentos
300

Se a CPU do servidor Web no apresentar afunilamento, os prximos itens a serem


investigados para deteco de afunilamentos so a topologia do farm, a configurao do
farm ou o contedo das pginas em exibio. Alguns possveis afunilamentos desses
elementos incluem o seguinte:
1. Rede Em situaes de alta taxa de transferncia, a rede pode ficar saturada entre o
servidor Web e o servidor de banco de dados ou entre o servidor Web e os usurios
finais. Para que isso no acontea, recomendvel que os servidores Web usem
adaptadores de rede gigabit com 2 portas.
2. CPU do servidor de banco de dados Se a CPU do servidor de banco de dados
apresentar afunilamento, a adio de servidores Web ao farm de servidores no
poder aumentar a taxa de transferncia mxima aceita pelo farm. Um afunilamento
na CPU de banco de dados, mas no nas CPUs de servidores Web, pode refletir
duas situaes:
a) Configuraes inadequadas do cache ou pginas muito lentas,
especialmente aquelas no armazenadas no cache de sada. Isso se
caracteriza por uma alta utilizao da CPU do servidor de banco de dados,
mas uma taxa de transferncia baixa ou mdia e uma utilizao baixa ou
mdia do servidor Web.
b) servidor de banco de dados pode ter atingido a capacidade da taxa de
transferncia necessria ao farm. Isso se caracteriza por uma alta utilizao
da CPU do servidor Web e do servidor de banco de dados, em uma
condio de alta taxa de transferncia.

Ajuda do armazenamento em cache


O SharePoint Server 2010 usa trs tipos de cache. O objetivo mais comum desses
caches melhorar a eficincia, reduzindo as chamadas ao banco de dados para
obteno de dados solicitados com frequncia. As solicitaes subsequentes de uma
pgina podem ser atendidas pelo cache no servidor Web, o que resulta em uma
utilizao consideravelmente reduzida de recursos nos servidores Web e nos servidores
de banco de dados.
Estes so os trs tipos de cache:
Cache de sada Esse cache armazena o contedo de pgina solicitado na
memria do servidor Web. Para obter mais informaes sobre o cache de sada,
consulte o artigo sobre cache de sada e perfis de cache
(http://go.microsoft.com/fwlink/?linkid=121543&clcid=0x416).

Cache de objetos Esse cache armazena objetos do SharePoint, como metadados


de item da Web e de lista, na memria do servidor Web. Para obter mais
informaes sobre o cache de objetos, consulte o artigo sobre cache de objetos
(http://go.microsoft.com/fwlink/?linkid=123948&clcid=0x416).

Cache baseado em disco para BLOBs (objetos binrios grandes) Esse cache
armazena arquivos de imagem, udio e vdeo, e outros arquivos binrios grandes,
no disco. Para obter mais informaes sobre o cache BLOB, consulte o artigo sobre
cache baseado em disco para objetos binrios grandes
(http://go.microsoft.com/fwlink/?linkid=123947&clcid=0x416).
Cada um desses caches importante para sustentar uma taxa de transferncia alta.
Entretanto, o cache de sada tem o maior efeito e abordado em detalhes em todo este
artigo.
301

Resultados do teste e recomendaes


Esta seo aborda as reas especficas que foram testadas e inclui recomendaes
resultantes desses testes.
Nesta seo:
Efeito da habilitao do cache de sada

Usurios annimos e usurios autenticados

Caractersticas de expanso das operaes de leitura e gravao

Advertncias do cache de sada

Efeito do volume de leitura na CPU e no tempo de resposta

Efeito das operaes de gravao na taxa de transferncia

Efeito da implantao de contedo

Efeito do instantneo de banco de dados durante a exportao da implantao de


contedo

Caractersticas de contedo

Efeito da habilitao do cache de sada


O cache de sada um recurso valioso para otimizar uma soluo do SharePoint Server
2010 para muitas operaes de leitura.
Nestes testes, para determinar a RPS mxima, o nmero de usurios ativos fazendo
solicitaes no farm foi aumentado at que a utilizao da CPU do servidor de banco de
dados ou dos servidores Web atingisse 100% e apresentasse afunilamento. O teste foi
conduzido em topologias de farm 1x1 (1 servidor Web e 1 servidor de banco de dados),
2x1, 4x1 e 8x1, para demonstrar o efeito da expanso de servidores Web em diferentes
taxas de acertos do cache de sada.

Taxa de acertos do cache de sada


A taxa de acertos do cache de sada uma medida dos acertos do cache de sada em
relao aos erros.
Um acerto ocorre quando o cache recebe uma solicitao de dados de objeto j
armazenados no cache.

Um erro de cache ocorre quando uma solicitao recebida para dados de objeto
no armazenados no cache. A ocorrncia de um erro faz com que o cache tente
armazenar os dados de objeto solicitados, de modo que as solicitaes posteriores
por esses dados resultem em um acerto de cache.
H vrios motivos que explicam por que uma solicitao de pgina pode resultar em um
erro de cache.
Pginas configuradas para no usar o cache de sada.

Pginas personalizadas; por exemplo, pginas com dados especficos do usurio


atual.

Primeira navegao por chave de variao do cache de sada.

Primeira navegao aps a expirao do contedo armazenado em cache.


O diagrama a seguir mostra o efeito do cache de sada na taxa de transferncia de pico
em farms com um a quatro servidores Web e um servidor de banco de dados.

302

Observao:
O ponto de dados de uma RPS mxima em um farm de servidores 4x1 com uma taxa de
acertos de 100% no cache de sada foi extrapolado e no foi efetivamente observado. O
volume de solicitaes do farm de servidores atingiu o limite de largura de banda da
rede, ou seja, a taxa de transferncia de dados alcanou 1 gigabit por segundo. Em
todos os casos, a utilizao da CPU do servidor Web de 100%.
A tabela a seguir lista os efeitos das taxas de acertos do cache de sada nas topologias
de farm com um a quatro servidores Web e um servidor de banco de dados.

Efeitos da taxa de acertos do cache de sada em diferentes


topologias de farm

303

Taxa Medida
de
acertos
do
cache
de
sada

1x1

2x1

4x1

RPS mxima

3.463

7.331

11.032

Utilizao da CPU
do SQL Server

0%

0%

0%

RPS mxima

2.137

3.945

5.937

Utilizao da CPU
do SQL Server

5,93%

12,00%

21,80%

RPS mxima

1.518

2.864

4.518

Utilizao da CPU
do SQL Server

7,12%

14,40%

28,00%

RPS mxima

459

913

1.596

Utilizao da CPU
do SQL Server

9,86%

19,50%

42,00%

RPS mxima

172

339

638

Utilizao da CPU
do SQL Server

9,53%

19,00%

36,30%

100%

95%

90%

50%

0%

Concluses e recomendaes referentes ao efeito da habilitao do


cache de sada
304

Uma taxa de acertos mais alta do cache de sada produz aumentos significativos da
RPS mxima. Por isso, recomendvel habilitar o cache de sada para otimizar a
soluo de publicao do SharePoint Server 2010. possvel configurar o cache de
sada na pgina Configuraes do Cache de Sada do conjunto de sites. Para obter mais
informaes, consulte o artigo sobre definio da pgina de configuraes do cache de
sada de um conjunto de sites
(http://go.microsoft.com/fwlink/?linkid=205058&clcid=0x416) no site Office.Microsoft.com.
Nos testes em que o cache de sada estava habilitado, a primeira solicitao que
armazenou uma pgina no cache foi excluda, ou seja, uma determinada porcentagem
de pginas j havia sido armazenada no cache. Quando um usurio solicita pela
primeira vez uma pgina no armazenada em cache, essa pgina adicionada ao
cache. Se o cache tiver atingido ou estiver perto de atingir sua capacidade, ele cortar
os dados que foram menos solicitados recentemente.
A taxa de acertos do cache de 0% simula o perodo curto em um ambiente, durante o
qual o cache de sada habilitado preenchido aps sua liberao. Por exemplo, isso
observado diariamente em um ambiente do mundo real, quando o pool de aplicativos faz
a reciclagem. importante dimensionar o hardware adequadamente para acomodar
uma situao em que haja uma taxa de acertos do cache de 0% para o rpido perodo
entre a reciclagem do pool de aplicativos e a prxima solicitao e armazenamento em
cache de pginas. A taxa de acertos do cache de 0% tambm simula um ambiente em
que o cache de sada no est habilitado.

Usurios annimos e usurios autenticados


O teste anterior pressupe que todas as solicitaes ao site so feitas por leitores
annimos. Entretanto, no seu site, alguns ou todos os usurios talvez sejam
autenticados. Exemplos de cenrios de leitura autenticados incluem um site de
publicao de intranet corporativo e contedo destinado somente para membros em um
site da Internet.
Com os perfis de cache de sada, possvel especificar que o comportamento do cache
de sada para usurios autenticados seja diferente do comportamento para usurios
annimos.

Perfis de cache
Os perfis de cache agregam configuraes que podem ser aplicadas a pginas, itens
de pgina, tipos de contedo e nveis de escala em uma implantao de site. Um perfil
de cache define os seguintes tipos de comportamento de cache:
Quanto tempo os itens devem ser mantidos no cache.

A poltica de filtragem de segurana.

A expirao das configuraes; por exemplo, durao e alteraes.

As variaes de contedo armazenado em cache; por exemplo, com base em


permisses do usurio, direitos do usurio e outras variveis personalizadas.
Qualquer alterao feita em um perfil de cache afeta imediatamente todo o contedo
aplicvel no site. Voc pode definir diferentes perfis de cache para usurios annimos e
para usurios autenticados.
O perfil de cache de sada Internet Pblica (Somente Annimo) foi usado para os
usurios annimos e o perfil Extranet (Site Publicado) foi usado para os usurios
autenticados.

305

O grfico a seguir mostra os efeitos da taxa de transferncia autenticada sobre a


utilizao da CPU do servidor de banco de dados.

O modelo de autenticao era Autenticao Bsica do Windows. Embora no seja


recomendvel usar essa autenticao para sites da Internet, esse mtodo de
autenticao foi selecionado para demonstrar o mnimo de sobrecarga que foi imposta
pela autenticao. O tamanho dessa sobrecarga varia de acordo com o seu mecanismo
de autenticao especfico. Ao testar sua implantao, voc deve considerar o efeito do
seu mecanismo de autenticao. Para obter mais informaes sobre mecanismos de
autenticao compatveis com o SharePoint Server 2010, consulte Plan authentication
methods (SharePoint Server 2010).

Concluses e recomendaes para usurios annimos e


autenticados
Os usurios autenticados experimentam menor RPS e potencial de expanso porque o
trabalho adicional de validao de credenciais gera carga no servidor de banco de
dados. Como demonstrado nos resultados do teste, a RPS mxima observada quando
os usurios so autenticados consideravelmente menor do que a observada em um
farm de acesso annimo.

Caractersticas de expanso das operaes de leitura e gravao


Nossos testes foram criados para registrar gravaes por hora. Neste artigo, uma
gravao definida como sendo a criao e o check-in de uma nova Pgina de
Publicao ou a edio e o check-in de uma Pgina de Publicao existente.
Para os testes a seguir, leitores foram adicionados ao sistema at que a utilizao da
CPU do servidor Web atingisse cerca de 80-90% e, em seguida, as operaes de
306

gravao foram executadas no ambiente usando atraso artificial. O total de gravaes


por hora do teste foi de aproximadamente 500. Usamos uma taxa de acertos do cache
de sada de 90% em todos os testes. Executamos o mesmo teste em um farm 1x1, 2x1 e
4x1, e observamos a utilizao da CPU do servidor Web e do SQL Server, alm da taxa
de transferncia geral de leitura de cada configurao. Alm disso, testamos uma
configurao somente leitura annima como uma linha de base e testamos tambm uma
configurao com leitores autenticados, usando a Autenticao Bsica do Windows.
Embora a CPU do servidor Web tenha sido 100% utilizada durante os testes de
expanso somente leitura, mantivemos a CPU do servidor Web entre 80-90% para os
testes de expanso com gravaes. Assim foi feito para deixar espao para alguma
utilizao adicional da CPU durante a execuo da atividade de gravao.
O grfico a seguir mostra a RPS geral de leitura observada durante cada teste. A RPS
de leitura expandida linearmente medida que mais servidores Web so adicionados,
inclusive na atividade de gravao. Entretanto, h uma perda de RPS quando as
gravaes so incorporadas.

A utilizao da CPU do servidor de banco de dados cresceu quando o nmero de


servidores Web aumentou. O grfico a seguir mostra o padro de crescimento da
307

utilizao da CPU do SQL Server nas vrias configuraes. Conforme observado na


seo anterior Usurios annimos e usurios autenticados deste artigo, a autenticao
afeta a utilizao da CPU do servidor de banco de dados, e isso fica mais evidente
quando a atividade de gravao adicionada (o que tambm afeta a utilizao da CPU
do servidor de banco de dados).

A tendncia extrapolada do uso do SQL Server demonstra que o SQL Server


apresentar afunilamento com seis servidores Web que tenham solicitaes de leitura
autenticadas. Entretanto, no caso de leitura annima, a expanso para um nmero maior
de servidores Web mostra-se funcional.
importante saber que fatores adicionais em uma implantao usual afetam a carga no
servidor de banco de dados, e esses fatores so relevantes e devem ser considerados
durante o planejamento da capacidade. Para saber mais sobre como determinar uma
zona verde para uma tpica utilizao da CPU do servidor de banco de dados, consulte
Viso geral do gerenciamento da capacidade e dimensionamento do SharePoint Server
2010.

Concluses e recomendaes para caractersticas de expanso das


operaes de leitura e gravao
308

Nossos dados mostram que a expanso do nmero de servidores Web ser uma
estratgia eficiente para o aumento da taxa de transferncia se o servidor de banco de
dados no apresentar afunilamento. Em mdia, o teste misto de leitura annima e
gravaes autenticadas gerou um aumento de 52% na utilizao da CPU do servidor
Web em comparao com um teste misto de leitura annima e nenhuma gravao. Alm
disso, as leituras autenticadas agregam uma grande carga adicional ao SQL Server,
porque cada solicitao incorre em mais verificaes de autenticao, o que exige uma
viagem de ida e volta ao SQL Server.
O grfico a seguir mostra o efeito da taxa de transferncia sobre a utilizao da CPU do
servidor de banco de dados.

Advertncias do cache de sada


Se a nica preocupao do planejamento de capacidade fosse maximizar a RPS, estes
testes recomendariam uma taxa ideal de acertos do cache de 100%. Entretanto, pode
no ser vivel nem desejvel habilitar o cache de sada de algumas ou de todas as
pginas por causa dos requisitos de atualizao de dados ou das restries de memria.
309

Atualizao de dados
Os dados apresentados no cache de sada talvez no tenham as atualizaes feitas
recentemente no contedo original. Na fonte da implantao de contedo ou (para
autores autenticados) em um cenrio de autor em produo, pode ser conveniente aos
autores ver as alteraes mais recentes logo aps terem atualizado o contedo
existente.
Em geral, isso possibilitado pela definio da propriedade Durao no perfil do cache,
que especifica o tempo de persistncia de uma pgina armazenada no cache de sada
antes que ela expire. Quando uma pgina expira, ela removida do cache e uma
solicitao posterior resulta em um erro de cache que atualiza o contedo da pgina.
A propriedade de perfil de cache Verificar Alteraes tambm pode ser definida,
determinando que o servidor compare o horrio do armazenamento da pgina no cache
com o horrio em que o contedo foi modificado pela ltima vez em um conjunto de
sites. Uma solicitao de pgina com carimbos de data/hora no correspondentes causa
a invalidao do cache para todas as pginas no conjunto de sites. Como a propriedade
Verificar Alteraes afeta todas as pginas em um conjunto de sites, recomendvel
habilitar essa opo apenas quando houver uma soluo de autor no local autenticado
que no seja atualizada com frequncia e que seja basicamente esttica. A combinao
dessa opo com uma longa durao permite que todas as pginas sejam atendidas no
cache at que uma atualizao seja feita no site.
Por padro, a propriedade Verificar Alteraes no est habilitada. Isso significa que o
servidor Web exibe dados do cache de sada em resposta a solicitaes de uma pgina
que ainda no expirou, independentemente de a pgina ASPX subjacente e original ter
sido ou no modificada.
Nesse teste, realizado em um farm de servidores 1x1, todas as variveis so as mesmas
dos testes apresentados na seo Caractersticas de expanso das operaes de leitura
e gravao, com exceo da propriedade Verificar Alteraes. Quando a propriedade
Verificar Alteraes ativada, o cache liberado com mais frequncia, resultando em
uma taxa menor de acertos do cache de sada.
O grfico a seguir mostra o efeito da propriedade Verificar Alteraes na taxa de
transferncia.

310

recomendvel evitar a propriedade Verificar Alteraes do perfil de cache de sada,


exceto em casos especficos. Um site que usa o modelo autor no local e apresenta
alteraes pouco frequentes no contedo pode se beneficiar dessa configurao para
usurios autenticados juntamente com uma longa durao de cache, mas outros tipos de
sites provavelmente tero alguma degradao da RPS.
Dependendo das suas necessidades, convm ativar o contedo com deteco de hora
instantaneamente ou com mais rapidez do que o permitido pelas configuraes padro.
Nesse caso, voc deve diminuir a durao ou no habilitar o cache de sada.

Concluses e recomendaes para advertncias do cache de sada


O cache de sada no resolve todos os problemas relacionados ao gerenciamento da
capacidade. H algumas situaes em que o cache de sada inadequado, e voc deve
consider-las ao habilit-lo e configurar perfis de cache de sada.

Efeito do volume de leitura na CPU e no tempo de resposta


Esse teste foi realizado em um farm 1x1 com acesso annimo e cache de sada
habilitado.
O grfico a seguir mostra o efeito do volume de leitura na CPU e no tempo de resposta.

311

Concluses e recomendaes para o efeito do volume de leitura na


CPU e no tempo de resposta
Como discutido na seo Afunilamentos e correo, o tempo de resposta do servidor
geralmente constante at o servidor Web receber um volume de solicitaes suficiente
para usar completamente sua CPU. medida que a CPU do servidor Web totalmente
utilizada, o tempo de resposta aumenta bastante. Entretanto, o farm de servidores ainda
pode lidar com algum volume adicional de solicitaes.

Efeito das operaes de gravao na taxa de transferncia


A taxa de criao para operaes de edio foi distribuda de maneira uniforme no
decorrer dos testes. Os valores de gravaes por hora foram testados at
aproximadamente 500, pois a criao ou a edio de mais de 500 pginas por hora est
fora do intervalo de operao da maioria das implantaes do SharePoint. O teste no
cobriu os processos automatizados, como a implantao de contedo, que foi abordada
na seo Efeito da implantao de contedo. Essas operaes de criao e edio
podem resultar em vrias operaes do SQL Server. Portanto, importante saber que
as gravaes avaliadas nesses testes no esto no nvel do SQL Server, mas sim,
representam o que um usurio considera como uma operao de gravao. Todos os
testes de RPS versus gravaes por hora foram realizados em um farm 1x1.
Primeiro, adicionamos operaes de leitura ao teste at que a CPU do servidor Web
estivesse entre 60 e 80%, para deixar um buffer para picos de trfego, e mantivemos
esse nvel mdio de utilizao no decorrer de todo o teste. Em seguida, introduzimos
312

gravaes usando um atraso artificial para controlar o nmero de operaes de


gravao. Entretanto, houve picos de crescimento do uso da CPU do servidor Web e do
SQL Server durante a execuo das gravaes. Alguns desses picos de algumas taxas
de acertos do cache excederam o limite da operao comum, conforme mostrado no
grfico a seguir, embora a mdia tenha permanecido dentro do intervalo de operao
regular.

Como mostrado no grfico anterior, h uma pequena reduo na taxa de transferncia


medida que as gravaes so adicionadas ao ambiente. O grfico demonstra a alterao
na taxa de transferncia entre um cenrio somente leitura e as operaes de leitura
durante aproximadamente 500 gravaes por hora. Dois pontos de dados foram
registrados para cada taxa de acertos do cache de sada. Portanto, a relao entre os
pontos de dados no necessariamente linear.
A reduo percentual mais pronunciada nas taxas menores de acertos do cache,
conforme mostrado no grfico a seguir. A RPS geral de leitura continua muito
relacionada taxa de acertos do cache, independentemente das gravaes.

313

O grfico a seguir demonstra que a utilizao da CPU do servidor de banco de dados


no aumentou significativamente quando as gravaes foram adicionadas ao sistema.
Observe que a escala vertical de 0 a 10% da capacidade da CPU.

314

Carga adicional do SQL Server foi observada durante as operaes de gravao, o que
era esperado. Entretanto, o maior aumento foi de 2,06%, o que irrelevante. A utilizao
mdia da CPU do servidor de banco de dados permaneceu menor que 10% em todos os
testes. Esse teste foi executado em um farm 1x1. O uso da CPU do servidor de banco
de dados aumentar medida que o nmero de servidores Web for expandido, tema
abordado com mais detalhes em Caractersticas de expanso das operaes de leitura e
gravao.
A utilizao da CPU do servidor Web tambm foi avaliada durante os testes. O grfico a
seguir demonstra que o uso mdio da CPU do servidor Web permaneceu na faixa de 6080% no decorrer de todos os testes, mesmo quando as gravaes por hora se
aproximaram a 500.

315

Entretanto, a real utilizao da CPU medida atingiu o pico quando as gravaes


ocorreram, conforme mostrado no grfico a seguir. Em geral, esses picos de CPU no
representam um problema. O objetivo da zona verde fornecer espao livre de CPU
para absorver alguns picos de carga de CPU. Alm disso, medida que mais servidores
Web forem adicionados, o efeito dos picos ser distribudo entre esses servidores, para
que o efeito na CPU de um nico servidor Web seja reduzido. Contudo, preciso saber
que esses picos so esperados em uma implantao real; a atividade de gravao no
distribuda de maneira uniforme, embora ela geralmente ocorra de modo intermitente.

316

Uma taxa de acertos do cache de 90% muito baixa para uma implantao tpica. A
maioria das implantaes do SharePoint Server 2010, com inmeras operaes de
leitura, tem uma taxa de acertos do cache de sada de 95% ou mais.

Concluses e recomendaes para o efeito das operaes de


gravao na taxa de transferncia
Os dados apresentados indicam que as operaes de gravao no tero um grande
efeito negativo na taxa geral de transferncia do sistema para os leitores. preciso
reconhecer que a atividade de gravao pode causar picos de uso da CPU, e voc deve
planejar sua configurao tpica para esperar esses picos. Uma estratgia de
redistribuio desses picos expandir para vrios servidores Web. Isso traz duas
vantagens:
Propaga a carga de gravao para vrios servidores Web, o que ameniza os picos
gerais.

Proporciona RPS de leitura maior, especialmente em altas taxas de acertos do


cache de sada.

Efeito da implantao de contedo


317

Uma alternativa ao modelo autor no local, que usa um nico ambiente para edio e
leitura, dividir o ambiente nico em dois ambientes separados um para criao e
outro para produo e usar a implantao de contedo para copiar o contedo do
ambiente de criao para o ambiente de produo.
Nessa configurao, o ambiente de produo abrange desde pouca atividade de
gravao at nenhuma, exceto quando a implantao de contedo est importando
contedo. Para esses testes, foram adicionadas leituras at que a utilizao da CPU do
servidor Web entrasse na faixa de 70-80%. O trabalho de implantao de contedo
exportou 10 sites, com 500 pginas cada um, do conjunto de sites de criao como um
pacote e importou esse pacote para o conjunto de sites de publicao. O tamanho do
pacote implantado era maior do que geralmente se observa em ambientes do mundo
real, visando estender suficientemente a durao do trabalho de implantao de
contedo para ver os resultados do teste. Para obter mais informaes sobre as
caractersticas do contedo implantado, consulte a seo Conjunto de dados.
Quando a exportao foi concluda, importamos o contedo para um conjunto de sites
separado e avaliamos o servidor de aplicativos e a carga do SQL Server, e tambm a
taxa de transferncia, enquanto a importao estava em andamento. O teste de
importao foi executado para vrias taxas de acertos do cache de sada.
A principal observao que a importao teve apenas um pequeno efeito na RPS
global de leitura, conforme mostrado no grfico a seguir. Tambm observamos que a
importao no teve nenhum efeito significativo na utilizao da CPU do servidor Web,
conforme mostrado nas tabelas a seguir, independentemente da taxa de acertos do
cache. Entretanto, houve um efeito mais perceptvel na CPU do SQL Server, mostrado
no grfico a seguir. Isso esperado, porque o servidor de banco de dados apresenta
carga adicional durante a importao de contedo. O uso da CPU do SQL Server,
porm, ficou abaixo dos 12% em todas as taxas de acertos do cache testadas, mesmo
durante a importao.

318

As tabelas a seguir mostram o efeito da importao da implantao de contedo na


utilizao da CPU do servidor Web e do servidor de banco de dados.

Efeito da importao da implantao de contedo na utilizao da


CPU do servidor Web
Acerto do cache

100%

99%

98%

95%

90%

50%

0%

Linha de base

72,32%

73,26% 71,28% 73,53% 71,79% 68,05% 63,97%

Com importao

70,93%

74,45% 69,56% 74,12% 70,95% 67,93% 63,94%

Efeito da importao da implantao de contedo na utilizao da


CPU do servidor de banco de dados
Acerto do cache

100%

99%

319

98%

95%

90%

50%

0%

Acerto do cache

100%

99%

98%

95%

90%

50%

0%

Linha de base

1,19%

1,64% 2,01% 3,00% 3,73% 5,40% 6,82%

Com importao

6,03%

6,82% 6,97% 7,96% 8,52% 10,29% 10,56%

Concluses e recomendaes para o efeito da implantao de


contedo
Os resultados de nossos testes mostram que a execuo de operaes de implantao
de contedo durante as operaes comuns do site no implica em uma preocupao
relevante quanto ao desempenho. Esses resultados mostram que no estritamente
necessrio implantar contedo durante perodos de pouco trfego, visando minimizar o
efeito da operao no desempenho geral, e que os tempos de implantao podem ser
direcionados principalmente pelas necessidades comerciais, e no pelos requisitos de
desempenho.

Efeito do instantneo de banco de dados durante a exportao da


implantao de contedo
No SharePoint Server 2010, a implantao de contedo pode ser configurada para criar
um instantneo do banco de dados de contedo de origem antes da exportao de
contedo. Isso realmente protege o processo de exportao contra atividades de criao
que possam ocorrer durante a exportao. Entretanto, os instantneos podem afetar o
desempenho de gravao do servidor de banco de dados, pois o instantneo atua como
um multiplicador das gravaes. Por exemplo, se voc tiver dois instantneos de um
banco de dados de origem e gravar nesse banco de dados, o servidor de banco de
dados copiar os dados existentes para cada instantneo e gravar os novos dados no
banco de dados de origem. Isso significa que uma nica gravao no banco de dados de
origem, na verdade, implica trs gravaes:
Para determinar o efeito de um instantneo no ambiente de criao, medimos a RPS de
gravao, o tempo de resposta e a utilizao da CPU dos servidores Web, do servidor
de banco de dados e do servidor de aplicativos durante uma operao de exportao
com atividade de gravao em andamento. As tabelas a seguir exibem os resultados.

Efeito dos instantneos de banco de dados durante a implantao de


contedo
Mtrica

4 WPH - Nenhum instantneo

4 WPH - Com
instantneos

RPS de gravao

0,2

0,16

Tempo de resposta

0,13

0,15

% CPU do servidor Web

0,42%

0,27%

% CPU do servidor de aplicativos

8,67%

8,98%

% CPU do servidor de banco de


dados

3,34%

2,41%

320

Efeito dos instantneos de banco de dados durante a implantao de


contedo
Mtrica

8 WPH - Nenhum instantneo

8 WPH - Com
instantneos

RPS de gravao

0,44

0,44

Tempo de resposta

0,13

0,13

% CPU do servidor Web

0,61%

0,73%

% CPU do servidor de aplicativos

14,6%

12%

% CPU do servidor de banco de


dados

7,04%

7,86%

Concluses e recomendaes para o efeito do instantneo de banco


de dados durante a exportao da implantao de contedo
Os resultados de nossos testes mostram que no h nenhum efeito significativo em
qualquer ponto de dados avaliado com instantneos de banco de dados. Toda a
variao registrada estava dentro da margem de erro. Isso confirma que os instantneos
de banco de dados podem ser usados sem grandes consideraes quanto ao
desempenho.

Caractersticas de contedo
Os testes foram realizados em um nico conjunto de dados criado para responder a um
conjunto especfico de questes. Seu conjunto de dados ser diferente e mudar ao
longo do tempo. Esta seo investiga como as caractersticas de contedo; por exemplo,
o nmero de pginas na biblioteca de pginas e os recursos includos nas pginas,
podem comunicar decises referentes ao gerenciamento de capacidade.

Nmero de pginas
A RPS mxima em muitos tamanhos de biblioteca de pginas foi testada. Esse teste foi
realizado em uma topologia 4x4 com cache de sada desabilitado e acesso annimo.
Todas as pginas tinham 42 KB quando descompactadas e 12 KB quando compactadas.
A tabela a seguir mostra os resultados do teste.

Efeito da contagem de pginas da biblioteca na RPS


Nmero de pginas

1.000

20.000

RPS mxima

860

801

790

O aumento do nmero de pginas para 20.000 no apresentou efeito significativo na


RPS mxima.

Campos de pesquisa de mltiplos valores


Um campo de pesquisa de mltiplos valores uma coluna, em uma lista, que faz
referncia a um ou mais itens em outra lista; por exemplo, colunas que usam metadados
321

corporativos gerenciados. Esses campos geralmente so usados como palavras-chave


de pesquisa para uma pgina e no so necessariamente renderizados. Em alguns
casos, como nos wikis corporativos, faz sentido renderizar esses valores de campo no
contedo de pginas. Por exemplo, pginas podem ser arquivadas em categorias
quando so criadas (em um site de notcias, pode haver Notcias do Mundo, Interesses
Humanitrios e Esportes), e a pgina mestra pode incluir um espao reservado que
mostra ao usurio em qual categoria a pgina foi marcada.
Campos de pesquisa de mltiplos valores provocam a busca de mais dados sempre que
uma pgina solicitada. Por isso, a existncia de muitos campos de pesquisa de
mltiplos valores em uma pgina pode afetar o desempenho.
O grfico a seguir mostra o efeito de campos de pesquisa de mltiplos valores na taxa
de transferncia.

O grfico a seguir mostra o efeito de campos de pesquisa de mltiplos valores na


utilizao de recursos do farm.

322

A degradao da RPS mxima ocorre medida que o nmero de campos de pesquisa


de mltiplos valores cresce devido ao efeito na rede, entre o servidor Web e o servidor
de banco de dados.

Efeito do relatrio de uso


O relatrio de uso um servio que ajuda os administradores a monitorar as estatsticas
referentes ao uso de sites. Para obter mais informaes sobre o relatrio de uso,
consulte Configure usage and health data collection (SharePoint Server 2010).
Testamos o efeito dos trabalhos de timer de relatrio de uso sobre a RPS mxima em
um farm 1x1. A tabela a seguir descreve os resultados.

Efeito do log de uso sobre o desempenho (em RPS)


BD de uso ativado

323

BD de uso
desativado

Diferena

BD de uso ativado

BD de uso
desativado

Diferena

Cache de sada ativado

3.459

3.463

Cache de sada desativado

629

638

Os resultados mostram que a habilitao do log de uso no afeta significativamente a


RPS em um cenrio somente leitura.

Sobre os autores
Joshua Stickler gerente de programa do SharePoint Server 2010 na Microsoft.
Tyler Butler gerente de programa do SharePoint Server 2010 na Microsoft.
Zhi Liu engenheiro de desenvolvimento de software em teste do SharePoint Server
2010 na Microsoft.
Cheuk Dong engenheiro de desenvolvimento de software em teste do SharePoint
Server 2010 na Microsoft.
Philippe Flamm engenheiro de desenvolvimento de software em teste do SharePoint
Server 2010 na Microsoft.

324

Estimate performance and capacity


planning for workflow in SharePoint
Server 2010 (em 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
Gerenciamento de desempenho e capacidade (SharePoint Server 2010).
Contents

Test farm characteristics

Test results

Recommendations

Troubleshooting

Test farm characteristics


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

Workload

Hardware, settings, and topology

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

Workload
Testing for this scenario helps develop estimates of how different farm configurations
respond to changes to the following variables:
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.

325

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

Test name

Test description

Throughput for starting workflows manually 1. Associate the included MOSS Approval
workflow with a list that creates one
task.
2. Populate the list with list items.
3. Call the StartWorkflow Web service
method on Workflow.asmx against the
items in the list for five minutes.
4. Calculate throughput by looking at the
number of workflows in progress.
Throughput for starting workflows
automatically when an item is created

1. Associate the included MOSS Approval


workflow with a list that creates one
task, set to automatically start when an
item is created.
2. Create items in the list for five minutes.
3. Calculate throughput by looking at the
number of workflows in progress.

Throughput for completing workflow tasks

1. Associate the included MOSS Approval


workflow with a list that 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
326

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

Storage

680 GB

4.2 terabyte

Number of network adapters

Network adapter speed

1 gigabit

1 gigabit

Authentication

NTLM

NTLM

Software version

4747

SQL Server 2008


R1

Number of SQL Server instances

Load balancer type

No load balancer

No load balancer

ULS logging level

Medium

Medium

Workflow Capacity Planning Topology

327

328

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

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

329

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.

Topology

Approval workflow maximum RPS

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
330

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.

Topology

Approval workflow maximum RPS

1x1

13.5

2x1

23.86

3x1

27.06

4x1

27.14
331

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.
Task completion throughput

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
332

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)

32.18

10

32

1,000

28.67

10,000

27.16

100,000

16.98

1,000,000

9.27

Autostart throughput as number of items and workflows increases

333

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

Throughput with different list


configurations (workflows started
per second)

Million item task list

Empty task list

Million item list

9.27

12

Empty item list

9.3

13

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

Recommendations
This section provides general performance and capacity recommendations. Use these
recommendations to determine the capacity and performance characteristics of the
starting topology that you created to decide whether you have to scale out or scale up the
starting topology.
For specific information about minimum and recommended system requirements, see
Hardware and software requirements (SharePoint Server 2010).

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

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
335

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>)
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.
Observao:
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
336

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.
Observao:
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.
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:
337

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.

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

Troubleshooting
Bottleneck

Cause

Database contention Database locks


(locks)
prevent multiple
users from making
conflicting
modifications to a
set of data. When a
set of data is locked
by a user or
process, no other
user or process can

Resolution

To help reduce the incidence of database


locks, you can do the following:
Distribute workflows to more document
libraries.

Scale up the database server.

Tune the database server hard disk for


read/write.
Methods exist to circumvent the database
338

Bottleneck

Cause

Resolution

change that same


set of data until the
first user or process
is complete,
changing the data
and relinquishing
the lock.

locking system in SQL Server 2005, such as


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

Database server
disk I/O

When the number of Distributing data files across multiple physical


I/O requests to a
drives allows for parallel I/O. The blog
hard disk exceeds SharePoint Disk Allocation and Disk I/O
the disk's I/O
(http://go.microsoft.com/fwlink/?LinkId=129557)
capacity, the
contains useful information about resolving
requests will be
disk I/O issues.
queued. As a result,
the time to complete
each request
increases.

Web server CPU


utilization

When a Web server This issue can be resolved in one of two ways.
is overloaded with You can add Web servers to the farm to
user requests,
distribute user load, or you can scale up the
average CPU
Web server or servers by adding faster
utilization will
processors.
approach 100
percent. This
prevents the Web
server from
responding to
requests quickly and
can cause timeouts
and error messages
on client computers.

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

Performance counter

Apply to object

Notes

Processor time

Total

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

Performance counter

Apply to object

Notes

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.

Performance counter

Apply to object

Notes

Average disk queue length

Hard disk that contains


SharedServices.mdf

Average values
larger than 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
340

Performance counter

Apply to object

Notes

elapsed time that


this thread used
the processor to
execute
instructions.
Memory utilization

Total

Shows the
average
utilization of
system memory.

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

341

Planejamento e configurao de
armazenamento e capacidade do SQL
Server (SharePoint Server 2010)
Este artigo descreve como planejar e configurar o armazenamento e a camada do banco
de dados do Microsoft SQL Server em um ambiente do Microsoft SharePoint Server
2010.
As informaes de planejamento de capacidade neste documento fornece diretrizes a
serem usadas por voc em seu planejamento. Elas se baseiam em testes realizados na
Microsoft em ativos em uso. No entanto, os resultados obtidos por voc podem variar
com base nos equipamentos usados e nos recursos implementados.
Como o SharePoint Server geralmente executado em ambientes em que os bancos de
dados so gerenciados por administradores de bancos de dados do SQL Server
separados, este documento destinado ao uso conjunto por implementadores de farms
do SharePoint Server e administradores de bancos de dados do SQL Server. Ele
pressupe um grande entendimento do SharePoint Server e do SQL Server.
Este artigo pressupe que voc est familiarizado com os conceitos apresentados em
Capacity management and sizing for SharePoint Server 2010 (em ingls).

Processo de design e configurao do


armazenamento e da camada do banco de
dados dos Produtos SharePoint 2010
recomendvel que voc divida o processo de design do armazenamento e da camada
do banco de dados nas etapas a seguir. Cada seo fornece informaes detalhadas
sobre cada etapa de design, incluindo requisitos e prticas recomendadas de
armazenamento:
Coletar requisitos de armazenamento e de espao e E/S do SQL Server

Escolher a verso e a edio do SQL Server

Projetar a arquitetura de armazenamento com base em requisitos de capacidade e


E/S

Estimar requisitos de memria

Entender os requisitos de topologia de rede

Configurar o SQL Server

Validar e monitorar o desempenho do armazenamento e do SQL Server

342

Coletar requisitos de armazenamento e de


espao e E/S do SQL Server
Vrios fatores de arquitetura do SharePoint Server 2010 influenciam o design do
armazenamento. A quantidade usada de contedo, recursos e aplicativos de servio, o
nmero de farms e a necessidade de disponibilidade so fatores-chave.
Antes de comear a planejar o armazenamento, voc deve conhecer os bancos de
dados que o SharePoint Server 2010 pode usar.
Nesta seo:
Bancos de dados usados por Produtos do SharePoint 2010

Conhecer o SQL Server e o IOPS

Estimar as necessidades de IOPS e armazenamento central

Estimar necessidades de armazenamento do aplicativo de servio e IOPS

Determinar as necessidades de disponibilidade

Bancos de dados usados por Produtos do SharePoint 2010


Os bancos de dados instalados com o SharePoint Server 2010 dependem dos recursos
que estejam sendo usados no ambiente. Todos os ambientes do Produtos do SharePoint
2010 dependem dos bancos de dados do sistema do SQL Server. Esta seo fornece
um resumo dos bancos de dados instalados com o SharePoint Server 2010. Para obter
informaes detalhadas, consulte Database types and descriptions (SharePoint Server
2010) e o artigo sobre modelo de banco de dados
(http://go.microsoft.com/fwlink/?linkid=187968&clcid=0x416).

Verso e edio do produto

Bancos de dados

SharePoint Foundation 2010

Configurao
Contedo da Administrao Central
Contedo (um ou mais)
Coleta de Dados de Uso e Integridade
Conectividade de Dados Corporativos
Servio de Registro de Aplicativo (em caso
de atualizao do Catlogo de Dados
Corporativos do Microsoft Office SharePoint
Server 2007)
Servio de Configuraes de Inscrio (se
habilitado por meio do Windows
PowerShell)

Bancos de dados adicionais para o


SharePoint Server 2010 Standard Edition

Aplicativo de servio de pesquisa:

Administrao de pesquisa

Rastreamento (um ou mais)

Propriedades (uma ou mais)


Aplicativo de servio de Perfil de Usurio:
343

Verso e edio do produto

Bancos de dados

Perfil

Sincronizao

Marcao social
Aplicativo de servio do Web Analytics

Preparo

Relatrios
Repositrio seguro
Estado
Metadados Gerenciados
Servios de Automao do Word
Bancos de dados adicionais para o
SharePoint Server 2010 Enterprise Edition

PerformancePoint

Bancos de dados adicionais para o Project Rascunho


Server 2010
Publicado
Arquivo morto
Relatrios
Bancos de dados adicionais para o FAST
Search Server

Administrao de pesquisa

Se voc estiver fazendo uma integrao mais completa com o SQL Server, seu
ambiente tambm poder inclui bancos de dados adicionais, como ocorre nos seguintes
cenrios:
O Microsoft SQL Server 2008 R2 PowerPivot para Microsoft SharePoint 2010 pode
ser usado em um ambiente do SharePoint Server 2010 que inclui o SQL Server 2008
R2 Enterprise Edition e oSQL Server Analysis Services. Voc tambm deve planejar
dar suporte para o banco de dados do aplicativo PowerPivot, caso ele esteja sendo
usado, e para a carga adicional sobre o sistema. Para obter mais informaes,
consulte o artigo sobre como planejar uma implantao do PowerPivot em um farm
do SharePoint (http://go.microsoft.com/fwlink/?linkid=186698&clcid=0x416).

O plug-in do Microsoft SQL Server 2008 Reporting Services (SSRS) pode ser usado
com qualquer ambiente dos Produtos do SharePoint 2010. Se estiver usando o plugin, planeje oferecer suporte para os dois bancos de dados do SQL Server 2008
Reporting Services e para a carga adicional necessria para o SQL Server 2008
Reporting Services.

Conhecer o SQL Server e o IOPS


Em qualquer servidor que hospede o SQL Server, muito importante que o servidor
obtenha a resposta mais rpida possvel do subsistema de E/S.
Uma quantidade maior de discos ou matrizes mais rpidos fornecem IOPS (operaes
de E/S por segundo) suficientes, embora mantendo baixa latncia e enfileiramento em
todos os discos.
344

Uma baixa resposta do subsistema de E/S no pode ser compensada pela incluso de
outros tipos de recursos, como CPU ou memria; no entanto, ela pode influenciar e
causar problemas para todo o farm. Planeje uma latncia mnima antes da implantao e
monitore os sistemas existentes.
Antes de implantar um novo farm, recomendvel que voc avalie o desempenho do
subsistema de E/S usando a ferramenta de parmetro de comparao de subsistema de
disco SQLIO. Para obter detalhes, consulte o artigo sobre a ferramenta de parmetro de
comparao de subsistema de disco SQLIO
(http://go.microsoft.com/fwlink/?linkid=105586&clcid=0x416).
Para obter informaes detalhadas sobre como analisar os requisitos de IOPS do ponto
de vista do SQL Server, consulte o documento sobre como analisar caractersticas de
E/S e dimensionar sistemas de armazenamento para aplicativos de bancos de dados do
SQL Server (http://sqlcat.com/whitepapers/archive/2010/05/10/analyzing-i-ocharacteristics-and-sizing-storage-systems-for-sql-server-database-applications.aspx).

Estimar as necessidades de IOPS e armazenamento central


O armazenamento da configurao e do contedo e as IOPS so a camada bsica que
voc deve planejar em todas as implantaes do SharePoint Server 2010.

Armazenamento de configurao e IOPS


Os requisitos de armazenamento para o banco de dados de Configurao e o banco de
dados de contedo da Administrao Central no so grandes. recomendvel alocar 2
GB para o banco de dados de Configurao e 1 GB para o banco de dados de contedo
da Administrao Central. Com o tempo, o banco de dados de Configurao pode
crescer e passar de 1 GB, mas isso no acontece rapidamente ele cresce
aproximadamente 40 MB para cada 50 mil conjuntos de sites.
Os logs de transao do banco de dados de Configurao podem ser grandes.
recomendvel, portanto, que voc altere o modelo de recuperao do banco de dados
de completo para simples.
Observao:
Se desejar usar o espelhamento do banco de dados do SQL Server para fornecer
disponibilidade para o banco de dados de Configurao, voc dever usar o modelo de
recuperao completo.
Os requisitos de IOPS para o banco de dados de Configurao e o banco de dados de
contedo da Administrao Central so mnimos.

Armazenamento de contedo e IOPS


A estimativa do armazenamento e das IOPS necessrias para bancos de dados de
contedo no uma atividade precisa. Ao testar e explicar as informaes a seguir,
pretendemos ajudar voc a obter estimativas a serem usadas para determinar o
tamanho inicial da sua implantao. No entanto, quando seu ambiente estiver em
execuo, esperamos que voc recalcule suas necessidades de capacidade com base
nos dados do ambiente real.
Para obter mais informaes sobre nossa metodologia geral de planejamento de
capacidade, consulte Capacity management and sizing for SharePoint Server 2010 (em
ingls).
345

Estimar o armazenamento do banco de dados de contedo


O seguinte processo descreve como estimar de modo aproximado o armazenamento
necessrio para bancos de dados de contedo, sem considerar os arquivos de log:
1. Calcule o nmero esperado de documentos. Esse valor expresso na frmula como
D.
A forma de clculo do nmero de documentos ser determinada pelos recursos que
voc estiver usando. Por exemplo, para sites do Meu Site ou sites de colaborao,
recomendvel calcular o nmero esperado de documentos por usurio e multiplicar
esse valor pelo nmero de usurios. Para sites de gerenciamento de registros ou de
publicao de contedo, voc pode calcular o nmero de documentos gerenciados e
gerados por um processo.
Se voc estiver migrando de um sistema atual, talvez seja mais fcil extrapolar o uso
e a taxa de crescimento atual. Se estiver criando um novo sistema, avalie os
compartilhamentos de arquivos existentes ou outros repositrios e faa a estimativa
com base nessa taxa de uso.
2. Estime o tamanho mdio dos documentos que est armazenando. Esse valor
expresso na frmula como S.Talvez valha a pena estimar mdias para diferentes
tipos ou grupos de sites. O tamanho mdio do arquivo para sites do Meu Site,
repositrios de mdia e diferentes portais de departamentos pode variar
significativamente.
3. Estime o nmero de itens da lista no ambiente. Esse valor expresso na frmula
como L.
mais difcil estimar itens da lista do que documentos. Geralmente usamos uma
estimativa equivalente a trs vezes o nmero de documentos (D), mas isso varia
com base em como voc espera usar seus sites.
4. Determine o nmero aproximado de verses. Estime o nmero mdio de verses
que qualquer documento de uma biblioteca ter (esse valor geralmente ser muito
menor do que o nmero mximo permitido de verses). Esse valor expresso na
frmula como V.
O valor de V deve ser maior do que zero.
5. Use a seguinte frmula para estimar o tamanho de seus bancos de dados de
contedo:
Tamanho do banco de dados = ((D V) S) + (10 KB (L + (V D)))
O valor de 10 KB na frmula uma constante que estima aproximadamente a
quantidade de metadados exigidos pelo SharePoint Server 2010. Se o seu sistema
exigir o uso significativo de metadados, convm aumentar essa constante.
Como exemplo, se voc pretendesse usar a frmula para estimar a quantidade de
espao de armazenamento necessrio para os arquivos de dados de um banco de
dados de contedo em um ambiente de colaborao com as caractersticas a seguir,
seriam necessrios aproximadamente 105 GB.

Entrada

Valor

Nmero de documentos (D)

200.000
Calculado como 10.000 usurios vezes 20
346

Entrada

Valor

documentos
Tamanho mdio dos documentos (S)

250 KB

Itens da lista (L)

600.000

Nmero de verses no atuais (V)

2
Presumindo que o mximo permitido de
verses 10

Tamanho do banco de dados = (((200.000 x 2)) 250) + ((10 KB (600.000 + (200.000


x 2))) = 110.000.000 KB ou 105 GB

Recursos que afetam o tamanho dos bancos de dados de contedo


O uso dos seguintes recursos do SharePoint Server 2010 pode afetar significativamente
o tamanho dos bancos de dados de contedo:
Lixeiras Enquanto um documento no for totalmente excludo das lixeiras de
primeiro e segundo estgio, ele ocupar espao em um banco de dados de
contedo. Calcule quantos documentos so excludos a cada ms para determinar o
efeito das lixeiras no tamanho dos bancos de dados de contedo. Para obter mais
informaes, consulte Configure Recycle Bin settings (SharePoint Server 2010).

Auditoria Os dados de auditoria podem compor e usar grandes quantidades de


espao em um banco de dados de contedo, especialmente se a auditoria de
exibio estiver ativada. Em vez de permitir que os dados de auditoria se expandam
sem limite, recomendamos que voc habilite apenas a auditoria dos eventos que
sejam importantes para cumprir requisitos regulatrios ou para controles internos.
Use as seguintes diretrizes para estimar o espao que precisar reservar para dados
de auditoria:

Estime o nmero de novas entradas de auditoria para um site e multiplique esse


nmero por 2 KB (as entradas geralmente esto limitadas a 4 KB, com um
tamanho mdio aproximado de 1 KB).

Com base no espao que voc deseja alocar, determine o nmero de dias de
logs de auditoria que deseja manter.

Office Web Apps. Se o Office Web Apps estiver sendo usado, o cache do Office Web
Apps poder afetar significativamente o tamanho de um banco de dados de
contedo. Por padro, o cache do Office Web Apps configurado como 100 GB.
Para obter mais informaes sobre o tamanho do cache do Office Web Apps,
consulte Manage the Office Web Apps cache.

Estimar os requisitos de IOPS do banco de dados de contedo


Os requisitos de IOPS para bancos de dados de contedo variam muito de acordo com o
modo como o seu ambiente est sendo usado e com a quantidade existente de espao
em disco e servidores. Em geral, recomendvel comparar a carga de trabalho prevista
em seu ambiente com uma das solues testadas. Para obter mais informaes,
consulte Recomendaes e resultados de testes de desempenho e capacidade
(SharePoint Server 2010).
347

Importante:
O teste do contedo desta seo ainda no foi concludo. Verifique a existncia de
informaes adicionais.

Estimar necessidades de armazenamento do aplicativo de servio e


IOPS
Depois de estimar as necessidades de armazenamento de contedo e de IOPS, voc
dever determinar o armazenamento e as IOPS exigidas pelos aplicativos de servio
que esto sendo usados em seu ambiente.

Requisitos de IOPS e armazenamento de aplicativos de servio do


SharePoint Foundation 2010
Para estimar os requisitos de armazenamento dos aplicativos de servio no sistema,
primeiro voc deve conhecer os aplicativos de servio e saber como us-los. Os
aplicativos de servio disponveis no SharePoint Foundation 2010 que tm bancos de
dados so listados na tabela a seguir.

Banco de dados de aplicativos de servio

Recomendao de estimativa de tamanho

Coleta de Dados de Uso e Integridade

O banco de dados de Uso pode crescer


muito rapidamente e exigir um grande
volume de IOPS.
Por exemplo, em ambientes de colaborao
que usam configuraes predefinidas, um
milho de solicitaes HTTP exige 2 GB de
armazenamento.
Use uma das seguintes frmulas para
estimar a quantidade necessria de IOPS:

115 visitas/segundo

5 solicitaes HTTP
Se voc precisar restringir o tamanho do
banco de dados de uso, recomendvel
comear registrando em log apenas as
solicitaes de pginas. Voc tambm pode
restringir o tamanho do banco de dados
definindo o intervalo de dados padro a ser
mantido como inferior a duas semanas.
Se possvel, coloque o banco de dados de
Uso em seu prprio disco ou eixo.
Servio Conectividade de Dados
Corporativos

O tamanho do banco de dados dos servios


Conectividade de Dados Corporativos
afetado principalmente pelo nmero de tipos
de contedo externo a que voc planeja dar
348

Banco de dados de aplicativos de servio

Recomendao de estimativa de tamanho

suporte. Aloque 0,5 MB para cada tipo de


contedo externo. Se voc no sabe de
quantos tipos de contedo externo poder
precisar, recomendvel alocar 50 MB. Os
requisitos de IOPS so mnimos.
Servio de Registro de Aplicativo

Aloque 1 GB apenas se estiver fazendo


uma atualizao do Catlogo de Dados
Corporativos do Microsoft Office SharePoint
Server 2007. Os requisitos de IOPS so
mnimos.

Configuraes de inscrio

Aloque 1 GB. Os requisitos de IOPS so


mnimos.

Requisitos de IOPS e armazenamento de aplicativos de servio do


SharePoint Server 2010
Para estimar os requisitos de armazenamento dos aplicativos de servio no sistema,
primeiro voc deve conhecer os aplicativos de servio e saber como us-los. Os
aplicativos de servio disponveis no SharePoint Server 2010 que tm bancos de dados
so listados na tabela a seguir.

Aplicativo de servio

Recomendao de estimativa de tamanho

Pesquisa

A Pesquisa exige trs bancos de dados.


Seu ambiente pode incluir vrios bancos de
dados de Propriedade e Rastreamento.
O banco de dados de administrao de
Pesquisa geralmente pequeno: aloque
10 GB.
Para estimar o armazenamento necessrio
para seus bancos de dados de Propriedade
e Rastreamento, use os seguintes
multiplicadores:
Rastreamento: 0,046 (soma dos
bancos de dados de contedo)

Propriedade: 0,015 (soma dos bancos


de dados de contedo)
Os requisitos de IOPS para Pesquisa so
significativos.
Para o banco de dados de
Rastreamento, a pesquisa exige de
3.500 a 7.000 IOPS.

349

Para o banco de dados de Propriedade,

Aplicativo de servio

Recomendao de estimativa de tamanho

a pesquisa precisa de 2.000 IOPS.


Para obter informaes detalhadas sobre
como estimar a capacidade necessria para
Pesquisa, consulte Recomendaes e
resultados de testes de desempenho e
capacidade (SharePoint Server 2010).
Perfil do Usurio

O aplicativo de servio do Perfil do Usurio


est associado a trs bancos de dados:
Perfil, Sincronizao e Marcao Social.
Para estimar o armazenamento necessrio
para os bancos de dados, use as seguintes
informaes:

Perfil. Com configuraes predefinidas,


em um ambiente configurado para usar
o Active Directory, o banco de dados de
perfil exigir aproximadamente 1 MB
por perfil de usurio.

Sincronizao. Com configuraes


predefinidas, em um ambiente com
poucos grupos por usurio, o banco de
dados de sincronizao exigir
aproximadamente 630 KB por perfil de
usurio. O arquivo de dados usar 90%
do espao.

Marcao social. Com configuraes


prvias, o banco de dados de marcao
social exigir aproximadamente
0,009 MB por marca, comentrio ou
classificao. Para estimar quantas
marcas ou notas os usurios criaro,
analise as seguintes informaes sobre
o site del.icio.us:

Aproximadamente 10% dos


usurios so considerados ativos.

Os usurios ativos criam 4,5


marcas e 1,8 comentrios por ms.
Em um ambiente de colaborao dinmica
com 160.000 perfis de usurios, cinco
grupos, 79.000 marcas, comentrios e
classificaes (2.500 comentrios, 76.000
marcas e 800 classificaes) e
configuraes predefinidas, temos os
seguintes tamanhos para estes bancos de
dados:
350

Aplicativo de servio

Recomendao de estimativa de tamanho

Nome do banco de
dados

Tamanho do banco de
dados

Perfil

155 GB

Sincronizao

96 GB

Marcao social

0,66 GB

Metadados gerenciados

O aplicativo de servio Metadados


Gerenciados tem um banco de dados. O
tamanho do banco de dados afetado pelo
nmero de tipos de contedo e palavraschave usados no sistema. Muitos ambientes
incluiro vrias instncias do aplicativo de
servio Metadados Gerenciados. Para obter
informaes detalhadas sobre como estimar
o tamanho e os requisitos de IOPS desse
banco de dados, consulte Recomendaes
e resultados de testes de desempenho e
capacidade (SharePoint Server 2010).

Web Analytics

O Web Analytics tem dois bancos de dados:


Preparo e Relatrios. Muitos fatores
influenciam o tamanho dos bancos de
dados. Entre eles, esto o perodo de
reteno, o volume dirio de dados
rastreados e o nmero de conjuntos de
sites, sites e subsites no aplicativo Web que
est sendo analisado. Para obter
informaes detalhadas sobre como estimar
seus requisitos de tamanho e IOPS,
consulte Recomendaes e resultados de
testes de desempenho e capacidade
(SharePoint Server 2010).

Repositrio seguro

O tamanho do banco de dados do aplicativo


de servio de Repositrio Seguro
determinado pelo nmero de credenciais no
repositrio e pelo nmero de entradas na
tabela de auditoria. recomendvel alocar
5 MB para cada 1.000 credenciais para ele.
A necessidade de IOPS mnima.

Estado

O aplicativo de servio de Controle de


Sesso tem um banco de dados.
recomendvel alocar 1 GB para ele. A
351

Aplicativo de servio

Recomendao de estimativa de tamanho

necessidade de IOPS mnima.


Servio Word Automation

O aplicativo de servio Word Automation


tem um banco de dados. recomendvel
alocar 1 GB para ele. A necessidade de
IOPS mnima.

PerformancePoint

O aplicativo de servio PerformancePoint


tem um banco de dados. recomendvel
alocar 1 GB para ele. A necessidade de
IOPS mnima.

Determinar as necessidades de disponibilidade


A disponibilidade um grau pelo qual um ambiente do SharePoint Server 2010
percebido por usurios como disponvel. Um sistema disponvel um sistema flexvel
ou seja, incidentes que afetem o servio ocorrem com pouca frequncia e aes
oportunas e eficientes so tomadas quando eles ocorrem.
Os requisitos de disponibilidade podem aumentar significativamente suas necessidades
de armazenamento. Para obter informaes detalhadas, consulte Plan for availability
(SharePoint Server 2010).

Escolher a verso e a edio do SQL Server


Embora o Produtos do SharePoint 2010 possa ser executado no Microsoft SQL Server
2008 R2, SQL Server 2008 ou no SQL Server 2005, altamente recomendvel que voc
considere a possibilidade de executar seu ambiente na Enterprise Edition do SQL Server
2008 ou do SQL Server 2008 R2 para aproveitar os recursos adicionais de desempenho,
disponibilidade, segurana e gerenciamento por ela fornecidos. Para obter mais
informaes sobre os benefcios de usar o SQL Server 2008 R2 Enterprise Edition,
consulte SQL Server 2008 R2 and SharePoint Products 2010: Better Together (White
paper) (SharePoint Server 2010).
Voc deve avaliar especialmente sua necessidade dos seguintes recursos:
Compactao de backup A compactao de backup pode agilizar qualquer
backup do SharePoint e est disponvel no SQL Server 2008 Enterprise Edition ou
no SQL Server 2008 R2 Standard Edition. Ao configurar a opo de compactao
em seu script de backup ou ao configurar o servidor que est executando o SQL
Server para compactar por padro, voc pode reduzir significativamente o tamanho
do seus backups de bancos de dados e logs remetidos. Para obter mais
informaes, consulte o artigo sobre compactao de backup (SQL Server)
(http://go.microsoft.com/fwlink/?linkid=129381&clcid=0x416).

352

Observao:
No h suporte para a compactao de dados do SQL Server para o Produtos do
SharePoint 2010.

Criptografia de dados transparente Se os seus requisitos de segurana inclurem


a necessidade de criptografia de dados transparente, voc dever usar o SQL
Server Enterprise Edition.

Aplicativo de servio do Web Analytics Se voc planeja usar o aplicativo de


servio do Web Analytics para anlise significativa, avalie o uso do SQL Server
Enterprise Edition para que o sistema se beneficie do particionamento de tabelas.

Implantao de contedo Se voc planeja usar o recurso de implantao de


contedo, avalie o uso do SQL Server Enterprise Edition para que o sistema se
beneficie dos instantneos do banco de dados do SQL Server.

Remote BLOB storage Se voc quiser aproveitar o remote BLOB storage em um


banco de dados ou local fora dos arquivos associados a cada banco de dados de
contedo, use o SQL Server 2008 ou o SQL Server 2008 R2 Enterprise Edition.

Administrador de recursos O Administrador de Recursos uma tecnologia


lanada no SQL Server 2008 para gerenciar cargas de trabalho e recursos do SQL
Server por meio da especificao de limites para o consumo de recursos por
solicitaes de entrada. O Administrador de Recursos permite diferenciar cargas de
trabalho e alocar CPU e memria medida que elas so solicitadas, com base nos
em limites especificados por voc. Ele est disponvel apenas no SQL Server 2008
ou no SQL Server 2008 R2 Enterprise Edition. Para obter mais informaes sobre o
uso do Administrador de Recursos, consulte o artigo sobre como gerenciar cargas
de trabalho do SQL Server com o Administrador de Recursos.
recomendvel usar o Administrador de Recursos com o SharePoint Server 2010
para:
Limitar a quantidade de recursos do SQL Server consumida pelos servidores
Web visados pelo componente de rastreamento de pesquisa. Como prtica
recomendada, limite o componente de rastreamento a dez por cento da CPU
quando o sistema estiver sobrecarregado.

Monitorar quantos recursos cada banco de dados consome no sistema por


exemplo, voc pode usar o Administrador de Recursos para ajudar a determinar
a melhor colocao de bancos de dados entre computadores que esto
executando o SQL Server.

PowerPivot para SharePoint 2010


Permite que os usurios
compartilhem anlises e modelos de dados gerados por usurios e colaborem neles
no Excel e no navegador enquanto atualiza automaticamente essas anlises. Faz
parte do SQL Server 2008 R2 Enterprise Edition Analysis Services.

Projetar a arquitetura de armazenamento com


base em requisitos de capacidade e E/S
A arquitetura de armazenamento e os tipos de disco selecionados para o seu ambiente
podem afetar o desempenho do sistema.
353

Nesta seo:
Escolher uma arquitetura de armazenamento

Escolher tipos de disco

Escolher tipos de RAID

Escolher uma arquitetura de armazenamento


H suporte para as arquiteturas de armazenamento DAS (armazenamento de conexo
direta), SAN (rede de rea de armazenamento) e NAS (armazenamento conectado
rede) com o SharePoint Server 2010, mas o suporte para NAS se restringe apenas ao
uso com bancos de dados de contedo configurados para utilizar remote BLOB storage.
Sua escolha depende de fatores da sua soluo de negcios e da sua infraestrutura
existente.
Qualquer arquitetura de armazenamento deve dar suporte para suas necessidades de
disponibilidade e ter um desempenho adequado em IOPS e latncia. Para ter suporte, o
sistema deve retornar de modo consistente o primeiro byte de dados dentro
20 milissegundos (ms).

DAS (armazenamento de conexo direta)


O DAS um sistema de armazenamento digital diretamente conectado a um servidor ou
a uma estao de trabalho, sem uma rede de armazenamento intermediria. Os tipos de
disco fsico DAS incluem SAS (Serial Attached SCSI) e SATA (Serial Attached ATA).
Em geral, recomendvel que voc escolha uma arquitetura DAS quando uma
plataforma de armazenamento compartilhada no possa assegurar um tempo de
resposta de 20 ms e capacidade suficiente para IOPS mdio e mximo.

SAN (rede de rea de armazenamento)


A SAN uma arquitetura para conectar dispositivos remotos de armazenamento de
computador (como matrizes de discos e bibliotecas de fitas) a servidores de um modo
que os dispositivos sejam exibidos como conectados localmente ao sistema operacional
(por exemplo, armazenamento em bloco).
Em geral, recomendvel escolher uma SAN quando os benefcios do armazenamento
compartilhado sejam importantes para a sua organizao.
Estes so alguns benefcios do armazenamento compartilhado:
Realocao mais fcil de armazenamento em disco entre servidores.

Pode atender a vrios servidores.

Nenhuma limitao de nmero de discos que podem ser acessados.

NAS (armazenamento conectado rede)


Uma unidade de NAS um computador autnomo conectado a uma rede. Seu nico
objetivo fornecer servios de armazenamento de dados baseados em arquivos para
outros dispositivos na rede. O sistema operacional e outros softwares na unidade de
NAS fornecem a funcionalidade do armazenamento de dados, sistemas de arquivos e
acesso a arquivos, bem como o gerenciamento dessas funcionalidades (por exemplo,
armazenamento de arquivos).

354

Observao:
O suporte para NAS se restringe apenas ao uso com bancos de dados de contedo
configurados para utilizar remote BLOB storage. Qualquer arquitetura de
armazenamento de rede deve responder a um ping dentro de 1 ms e deve retornar o
primeiro byte de dados em 20 ms. Essa restrio no se aplica ao provedor
FILESTREAM local do SQL Server porque ele apenas armazena dados localmente no
mesmo servidor.

Escolher tipos de disco


Os tipos de disco usados no sistema podem afetar a confiabilidade e o desempenho.
Com todos os outros fatores inalterados, unidades maiores aumentam o tempo mdio de
busca. O SharePoint Server 2010 d suporte aos seguintes tipos de unidades:
SCSI

SATA

SAS

FC

Interface IDE

Unidade de estado slido ou Disco Flash

Escolher tipos de RAID


O RAID (Redundant Array of Independent Disks) usado geralmente para melhor as
caractersticas de desempenho de discos individuais (por meio da distribuio de dados
por vrios discos) e para fornecer proteo contra falhas de disco individuais.
Todos os tipos de RAID do suporte ao SharePoint Server 2010; no entanto,
recomendvel usar o RAID 10 ou uma soluo de RAID especfica de um fornecedor
com desempenho equivalente.
Ao configurar uma matriz RAID, no se esquea de alinhar o sistema de arquivos ao
deslocamento informado pelo fornecedor. Na ausncia de orientao do fornecedor,
consulte o artigo sobre prticas recomendadas de E/S pr-implantao do SQL Server
(http://go.microsoft.com/fwlink/?linkid=105583&clcid=0x416).
Para obter mais informaes sobre como provisionar RAID e o subsistema de E/S do
SQL Server, consulte o artigo sobre prticas recomendadas do SQL Server
(http://go.microsoft.com/fwlink/?linkid=168612&clcid=0x416).

Estimar requisitos de memria


A memria necessria para o SharePoint Server 2010 est diretamente relacionada ao
tamanho dos bancos de dados de contedo hospedados em um servidor que executa o
SQL Server.
medida que voc adiciona aplicativos de servio e recursos, seus requisitos tendem a
crescer. A tabela a seguir d diretrizes sobre a quantidade de memria recomendvel.

355

Observao:
Nossas definies de implantaes pequenas e mdias so descritas na seo
"Arquiteturas de referncia" do artigo Capacity management and sizing for SharePoint
Server 2010 (em ingls).

Tamanho combinado de bancos de dados de RAM recomendada para computadores que


executam o SQL Server
contedo

Mnimo para pequenas implantaes de


produo

8 GB

Mnimo para mdias implantaes de


produo

16 GB

Recomendao para at 2 terabytes

32 GB

Recomendao para a faixa entre 2


terabytes at o mximo de 5 terabytes

64 GB

Observao:
Esses valores so maiores do que os recomendados como mnimos para o SQL Server
devido distribuio dos dados necessrios para um ambiente do SharePoint Server
2010. Para obter mais informaes sobre requisitos de sistema do SQL Server, consulte
Requisitos de hardware e software para a instalao do SQL Server 2008
(http://go.microsoft.com/fwlink/?linkid=129377&clcid=0x416).
Estes so alguns dos outros fatores que podem influenciar a memria exigida:
O uso de espelhamento do SQL Server.

O uso frequente de arquivos maiores do que 15 megabytes (MB).

Entender os requisitos de topologia de rede


Planeje as conexes de rede dentro dos farms e entre eles. recomendvel usar uma
rede de baixa latncia.
A lista a seguir fornece algumas prticas recomendadas:
Todos os servidores no farm devem ter largura de banda e latncia de LAN (rede
local) para o servidor que est executando o SQL Server. A latncia no deve ser
maior do que 1 ms.

No recomendvel uma topologia de WAN (rede de longa distncia) em que um


servidor que esteja executando o SQL Server seja implantado remotamente de
356

outros componentes do farm atravs de uma rede com latncia maior do que 1 ms.
Essa topologia no foi testada.

Planeje uma rede WAN adequada se estiver planejando usar o espelhamento do


SQL Server ou o envio de logs para manter um site remoto atualizado.

recomendvel que os servidores Web e os servidores de aplicativos tenham dois


adaptadores de rede: um para gerenciar o trfego do usurio final e o outro para
gerenciar a comunicao com os servidores que executam o SQL Server.

Configurar o SQL Server


As sees a seguir descrevem como planejar a configurao do SQL Server para o
SharePoint Server 2010.
Nesta seo:
Determinar quantas instncias ou servidores so necessrios

Configurar o armazenamento e a memria

Definir opes do SQL Server

Configurar bancos de dados

Estimar quantos servidores so necessrios


Em geral, o SharePoint Server 2010 designado para aproveitar o dimensionamento do
SQL Server ou seja, o SharePoint Server 2010 pode ter um desempenho melhor com
um grande nmero de servidores de mdio porte que executam o SQL Server do que
com apenas alguns grandes servidores.
Sempre coloque o SQL Server em um servidor dedicado que no esteja executando
qualquer outra funo de farm ou hospedando bancos de dados de qualquer outro
aplicativo, a menos que voc esteja implantando o sistema em um servidor autnomo.
A seguir, apresentada uma orientao geral sobre quando implantar um servidor
adicional para executar o SQL Server:
Adicione outro servidor de banco de dados quando tiver mais de quatro servidores
Web que estejam sendo executados em plena capacidade.

Adicione outro servidor de banco de dados quando seus bancos de dados de


contedo ultrapassarem 5 terabytes.
Observao:

A Microsoft d suporte a configuraes de servidor que no seguem esta orientao.


Para promover o armazenamento seguro de credenciais quando estiver executando o
aplicativo de servio Repositrio Seguro, recomendvel que o banco de dados de
repositrio seguro esteja hospedado em uma instncia separada de banco de dados em
que o acesso seja limitado a um administrador.

Configurar o armazenamento e a memria


No servidor que est executando o SQL Server 2008, recomendvel que o cache L2
por CPU tenha um mnimo de 2 MB para melhorar a memria.
357

Siga as recomendaes de configurao de armazenamento do


fornecedor
Para obter um desempenho ideal ao configurar uma matriz de armazenamento fsica,
siga as recomendaes de configurao de hardware informadas pelo fornecedor de
armazenamento, em vez de adotar os valores padro do sistema operacional.
Se voc no receber orientaes do fornecedor, recomendamos que use o utilitrio de
configurao de disco DiskPart.exe para configurar o armazenamento para o SQL
Server 2008. Para obter mais informaes, consulte o artigo sobre melhores prticas de
E/S de pr-implantao (http://go.microsoft.com/fwlink/?linkid=105583&clcid=0x416).

Fornea o mximo de recursos possvel


Verifique se os canais de E/S do SQL Server para os discos no so compartilhados por
outros aplicativos, como o arquivo de paginao e os logs do IIS (Servios de
Informaes da Internet).
Fornea o mximo possvel de banda larga. Maior banda larga de barramento ajuda a
melhorar a confiabilidade e o desempenho. Lembre-se de que o disco no o nico
usurio da banda larga de barramento por exemplo, voc tambm deve considerar o
acesso rede.

Definir opes do SQL Server


As seguintes configuraes e opes do SQL Server devem ser definidas antes da
implantao do SharePoint Server.
No habilite estatsticas de criao automtica em um SQL Server que esteja dando
suporte ao SharePoint Server. O SharePoint Server implementa estatsticas
especficas. Nenhuma estatstica adicional necessria. As estatsticas de criao
automtica podem alterar significativamente o plano de execuo de uma consulta
de uma instncia do SQL Server para outra instncia do SQL Server. Portanto, para
dar suporte consistente para todos os clientes, o SharePoint Server fornece dicas
codificadas para consultas, de acordo com a necessidade, para fornecer o melhor
desempenho em todos os cenrios.

Para garantir um desempenho ideal, altamente recomendvel definir o grau


mximo de paralelismo como 1 para servidores de banco de dados que hospedam
bancos de dados do SharePoint Server 2010. Para obter mais informaes sobre
como definir o grau mximo de paralelismo, consulte o artigo sobre a opo de
grau mximo de paralelismo
(http://go.microsoft.com/fwlink/?linkid=189030&clcid=0x416).

Para facilitar a manuteno, configure aliases de conexo do SQL Server para cada
servidor de banco de dados em seu farm. Um alias de conexo um nome
alternativo que pode ser usado para estabelecer uma conexo com uma instncia do
SQL Server. Para obter mais informaes, consulte o artigo sobre como definir um
alias do SQL Server (SQL Server Management Studio)
(http://go.microsoft.com/fwlink/?linkid=132064&clcid=0x416).

Configurar bancos de dados


As orientaes a seguir descrevem prticas recomendadas de planejamento na
configurao de cada banco de dados em seu ambiente.

Separe e priorize seus dados em discos


358

De modo ideal, voc deve colocar o banco de dados tempdb, os bancos de dados de
contedo, o banco de dados de Uso, os bancos de dados de pesquisa e os logs de
transaes do SQL Server 2008 em discos rgidos separados.
A lista a seguir fornece algumas prticas recomendadas de priorizao de dados:
Ao priorizar dados em discos mais rpidos, use a seguinte classificao:
1. Arquivos de dados tempdb e logs de transaes
2. Arquivos de log de transaes do banco de dados
3. Bancos de dados de pesquisa, com exceo do banco de dados de
administrao de Pesquisa

4. Arquivos de dados de banco de dados


Em um site de portal fortemente orientado leitura, priorize dados em relao a
logs.
Testes e dados de clientes mostram que o desempenho de farms do SharePoint
Server 2010 pode ser muito prejudicado por E/S insuficiente de disco para o tempdb.
Para evitar esse problema, aloque discos dedicados para o tempdb. Se uma alta
carga de trabalho estiver projetada ou monitorada ou seja, a operao de leitura
mdia ou a operao de gravao mdia exigir mais do que 20 ms talvez voc
precise reduzir o afunilamento separando os arquivos em discos ou substituindo os
discos por outros mais rpidos.

Para melhorar o desempenho, coloque o tempdb em uma matriz RAID 10. O nmero
de arquivos de dados do tempdb deve ser igual ao nmero de ncleos de CPUs e os
arquivos de dados do tempdb devem ser definidos com o mesmo tamanho. Conte
processadores de ncleo duplo como duas CPUs para essa finalidade. Conte cada
processador que d suporte a hyperthreading como uma CPU. Para obter mais
informaes, consulte o artigo sobre como otimizar o desempenho do tempdb
(http://go.microsoft.com/fwlink/?linkid=148537&clcid=0x416).

Separe dados de banco de dados e arquivos de log de transaes em diferentes


discos. Se os arquivos precisarem compartilhar discos porque os arquivos so muito
pequenos para justificar o uso de um disco inteiro ou de uma faixa inteira, ou se
faltar espao em disco, coloque os arquivos que tm padres de uso diferentes no
mesmo disco para minimizar solicitaes de acesso simultneo.

Consulte o fornecedor do seu hardware de repositrio para obter informaes sobre


como configurar todos os logs e os bancos de dados de pesquisa a fim de otimizar a
gravao em sua soluo de repositrio especfica.

Use vrios arquivos de dados para bancos de dados de contedo


Siga estas recomendaes para melhorar o desempenho:
Crie apenas arquivos no grupo de arquivos primrio do banco de dados.

Distribua os arquivos por discos separados.

O nmero de arquivos de dados deve ser menor ou igual ao nmero de ncleos de


CPUs. Conte processadores de ncleo duplo como duas CPUs para essa finalidade.
Conte cada processador que d suporte a hyperthreading como uma CPU.

Crie arquivos de dados de mesmo tamanho.

359

Importante:
Embora voc possa usar as ferramentas de backup e recuperao internas do
SharePoint Server 2010 para fazer backup e recuperar vrios arquivos de dados, se
voc substitu-los no mesmo local, as ferramentas no podero restaurar vrios arquivos
de dados em um local diferente. Por esse motivo, altamente recomendvel que, ao
usar vrios arquivos de dados para um banco de dados de contedo, voc use as
ferramentas de backup e recuperao do SQL Server. Para obter mais informaes
sobre como fazer backup e recuperar o SharePoint Server 2010, consulte Plan for
backup and recovery (SharePoint Server 2010).
Para obter mais informaes sobre como criar e gerenciar grupos de arquivos, consulte
o artigo sobre arquivos e grupos de arquivos fsicos de banco de dados
(http://go.microsoft.com/fwlink/?linkid=117909&clcid=0x416).

Limite o tamanho do banco de dados de contedo para melhorar a


capacidade de gerenciamento
Planeje o dimensionamento do banco de dados para melhorar a capacidade de
gerenciamento, o desempenho e a facilidade de atualizao do seu ambiente.
Para ajudar a garantir o desempenho do sistema, altamente recomendvel limitar o
tamanho dos bancos de dados de contedo a 200 GB.
Um conjunto de sites no deve ultrapassar 100 GB, a menos que haja apenas um
conjunto de sites no banco de dados. Esse limite existe para que voc possa usar as
ferramentas de backup granular do SharePoint Server 2010 para mover um conjunto de
sites para outro banco de dados, se precisar.
Importante:
H suporte para tamanhos de bancos de dados de contedo de at 1 terabyte somente
para grandes repositrios de um nico site e arquivos nos quais os dados permanecem
razoavelmente estticos, como sistemas de gerenciamento de documentos de referncia
e sites de Central de Registros. H suporte para tamanhos de bancos de dados maiores
nesses cenrios porque seus padres de E/S e formatos tpicos de estrutura de dados
foram projetados e testados em escalas maiores.
Se o seu design exigir um banco de dados maior do que o padro recomendado, siga
esta orientao:
Para bancos de dados que contenham muitos arquivos grandes armazenados como
BLOBs (objetos binrios grandes), avalie a possibilidade de usar RBS (remote BLOB
storage). O RBS adequado nas seguintes circunstncias:
1. Quando voc estiver executando sites que contenham arquivos grandes pouco
acessados, como repositrios de conhecimento.
2. Quando voc tiver terabytes de dados.
3. Para arquivos de vdeo ou mdia.
360

Para obter mais informaes, consulte Plan for remote BLOB storage (RBS)
(SharePoint Server 2010).
Siga prticas recomendadas de exibio de dados de grandes bancos de dados.
Para obter mais informaes, consulte Gerenciamento de capacidade do SharePoint
Server 2010: limites de software.
Para obter mais informaes sobre repositrios de documentos em grande escala,
consulte a seo sobre estimativa de requisitos de desempenho e capacidade para
repositrios de documentos em grande escala, disponvel em Recomendaes e
resultados de testes de desempenho e capacidade (SharePoint Server 2010).

Gerencie de modo proativo o crescimento dos arquivos de dados e


log
recomendvel gerenciar de maneira proativa o crescimento dos arquivos de dados e
log, considerando as seguintes recomendaes:
Sempre que possvel, expanda previamente todos os arquivos de dados e log para
seu tamanho final previsto.

recomendvel habilitar o aumento automtico por razes de segurana. No


confie nas configuraes padro de aumento automtico. Leve em conta as
seguintes diretrizes ao configurar o aumento automtico:

Quando planejar bancos de dados de contedo que ultrapassem o tamanho


recomendado (200 GB), defina o valor de aumento automtico do banco de
dados para um nmero fixo de megabytes, e no para uma porcentagem. Isso
reduz a frequncia com que o SQL Server aumenta o tamanho de um arquivo.
Aumentar o tamanho do arquivo uma operao de bloqueio que envolve o
preenchimento do novo espao com pginas vazias.

Defina o valor de aumento automtico para o banco de dados de Repositrio de


Propriedades do aplicativo de servio de Pesquisa como 10 por cento.

Se no houver previso de que o tamanho calculado do banco de dados de


contedo alcance o tamanho mximo recomendado de 200 GB dentro de um
ano, defina-o como o tamanho mximo que o banco de dados deve alcanar em
um ano (com 20% de margem adicional de erro) usando a propriedade ALTER
DATABASE MAXSIZE. Revise periodicamente essa configurao para verificar
se ela ainda tem um valor adequado com base nas taxas de crescimento
anteriores.

Mantenha um nvel de pelo menos 25 por cento de espao disponvel nos discos
para estabelecer padres de crescimento e uso mximo. Se voc estiver
gerenciando o crescimento por meio da incluso de discos em uma matriz RAID ou
da alocao de mais armazenamento, monitore o tamanho do disco cuidadosamente
para evitar ficar sem espao.

Validar e monitorar o desempenho do


armazenamento e do SQL Server
Teste se a soluo de desempenho e backup do seu hardware permite que voc cumpra
seus SLAs (contratos de nvel de servio). Teste especificamente o subsistema de E/S

361

do computador que est executando o SQL Server para garantir que o desempenho seja
satisfatrio.
Teste a soluo de backup que voc est usando para garantir que ela possa fazer
backup do sistema dentro da janela de manuteno disponvel. Se a soluo de backup
no puder atender aos SLAs exigidos por seu negcio, avalie a possibilidade de usar
uma soluo de backup incremental, como o System Center Data Protection Manager
(DPM) 2010.
importante controlar os seguintes componentes de recursos de um servidor que
executa o SQL Server: CPU, memria, taxa de acertos do cache e subsistema de E/S.
Quando um ou mais dos componentes parecerem lentos ou sobrecarregados, analise a
estratgia apropriada com base na carga de trabalho atual e projetada. Para obter mais
informaes, consulte o artigo sobre como solucionar problemas de desempenho no
SQL Server 2008 (http://go.microsoft.com/fwlink/?linkid=168448&clcid=0x416).
A seo a seguir relaciona os contadores de desempenho de uso recomendado para
monitorar o desempenho dos bancos de dados do SQL Server que esto sendo
executados em seu ambiente do SharePoint Server 2010. Tambm esto descritos
valores aproximados de integridade para cada contador.
Para obter detalhes sobre como monitorar o desempenho e usar contadores de
desempenho, consulte o artigo sobre como monitorar desempenho
(http://go.microsoft.com/fwlink/?linkid=189032&clcid=0x416).

Contadores do SQL Server a serem monitorados


Monitore os seguintes contadores do SQL Server para garantir a integridade de seus
servidores:
Estatsticas gerais Este objeto fornece contadores para monitorar a atividade
geral em todo o servidor, como o nmero de conexes atuais e o nmero de
usurios que se conectam e desconectam por segundo de computadores que
executam uma instncia do SQL Server. Avalie a possibilidade de monitorar o
seguinte contador:

Bancos de dados Este objeto fornece contadores para monitorar operaes de


cpia em massa, produtividade de backup e restaurao e atividades de log de
transaes. Monitore as transaes e o log de transaes para determinar o volume
de atividades dos usurios no banco de dados e o quanto o log de transaes est
ficando cheio. O volume de atividades dos usurios pode determinar o desempenho
do banco de dados e afetar o tamanho do log, o bloqueio e a replicao. Monitorar a
atividade de log de baixo nvel para medir a atividade dos usurios e o uso de
recursos pode ajudar voc a identificar afunilamentos de desempenho. Avalie a
possibilidade de monitorar o seguinte contador:

Conexes de usurio Este contador mostra a quantidade de conexes de


usurio no seu computador que executa o SQL Server. Se voc vir esse nmero
crescer 500 por cento em relao linha de base, talvez experimente uma
reduo do desempenho.

Transaes/s Este contador mostra a quantidade de transaes por segundo


em um determinado banco de dados ou no servidor inteiro. Esse nmero mais
para a sua linha de base e para ajudar voc a solucionar problemas.

Bloqueios Este objeto fornece informaes sobre bloqueios do SQL Server em


tipos de recursos individuais. Avalie a possibilidade de monitorar os seguintes
contadores:
362

Tempo de Espera Mdio (ms) Este contador mostra a quantidade mdia de


tempo de espera para cada solicitao de bloqueio que resultou em uma espera.

Tempo de Espera de Bloqueio (ms) Este contador mostra o tempo de espera


para bloqueios no ltimo segundo.

Esperas de Bloqueio/s Este contador mostra o nmero de bloqueios por


segundo que no puderam ser atendidos imediatamente e precisaram esperar
recursos.

Nmero de deadlocks Este contador mostra o nmero de deadlocks por


segundo no computador que executa o SQL Server. O valor no deve ser maior
do que 0.

Travas Este objeto fornece contadores para monitorar bloqueios internos de


recursos do SQL Server chamados travas. A monitorao de travas para determinar
a atividade dos usurios e o uso de recursos pode ajudar voc a identificar os
afunilamentos de desempenho. Avalie a possibilidade de monitorar os seguintes
contadores:

Tempo Mdio de Espera de Trava (ms) Este contador mostra o tempo mdio
de espera de trava para solicitaes de trava que precisaram esperar.

Esperas de Trava/s Este contador mostra o nmero de solicitaes de trava


que no puderam ser atendidas imediatamente.

Estatsticas SQL Este objeto fornece contadores para monitorar a compilao e o


tipo de solicitaes enviadas para uma instncia do SQL Server. A monitorao do
nmero de compilaes e recompilaes de consultas e do nmero de lotes
recebidos por uma instncia do SQL Server indica a rapidez com que o SQL Server
est processando as consultas de usurios e a eficincia com que o otimizador de
consulta est processando as consultas. Avalie a possibilidade de monitorar os
seguintes contadores:

Compilaes de SQL/s Este contador indica o nmero de vezes que o


caminho de cdigo de compilao inserido por segundo.

Recompilaes de SQL/s Este contador indica o nmero de recompilaes da


instruo por segundo.

Gerenciador de Buffer Este objeto fornece contadores para monitorar como o


SQL Server usa a memria para armazenar pginas de dados, estruturas de dados
internas e o cache de procedimento, bem como contadores para monitorar o E/S
fsico enquanto o SQL Server l e grava pginas de banco de dados. Avalie a
possibilidade de monitorar o seguinte contador:

Taxa de Acertos do Cache do Buffer

Este contador mostra a porcentagem de pginas encontradas no cache do buffer


sem a necessidade de ler do disco. A taxa o nmero total de acertos de cache
dividido pelo nmero total de pesquisas de cache nos ltimos mil acessos a
pginas. Como ler do cache muito mais caro do que ler do disco, convm que
essa taxa seja alta. Geralmente, voc pode aumentar a taxa de acertos do
cache do buffer aumentando a quantidade de memria disponvel para o SQL
Server.

Cache de Planos Este objeto fornece contadores para monitorar como o SQL
Server usa a memria para armazenar objetos como procedimentos armazenados,
363

instrues Transact-SQL ad-hoc e preparadas e gatilhos. Avalie a possibilidade de


monitorar o seguinte contador:

Taxa de Acertos do Cache

Este contador indica a taxa entre acertos e pesquisas de cache para planos.

Contadores do servidor fsico a serem monitorados


Monitore os seguintes contadores para assegurar a integridade dos computadores que
executam o SQL Server:
Processador: % Tempo do Processador: _Total Este contador mostra a
porcentagem de tempo que o processador est executando processos do aplicativo
ou do sistema operacional diferentes de Ocioso. No computador que estiver
executando o SQL Server, esse contador dever ficar entre 50 por cento e 75 por
cento. No caso de sobrecarga constante, investigue se existe uma atividade anormal
de processos ou se o servidor precisa de CPUs adicionais.

Sistema: Comprimento da Fila de Processador Este contador mostra o nmero


de threads na fila do processador. Monitore este contador para assegurar que ele
permanea inferior ao dobro do nmero de ncleos de CPU.

Memria: Mbytes Disponveis Este contador mostra a quantidade de memria


fsica, em megabytes, disponvel para processos executados no computador.
Monitore este contador para assegurar a manuteno de um nvel de pelo menos
20 por cento do total de RAM fsica disponvel.

Memria: Pginas/s Este contador mostra a taxa em que as pginas so lidas do


disco ou nele gravadas para resolver falhas de pgina de hardware. Monitore este
contador para assegurar que ele permanea abaixo de 100.
Para obter mais informaes e mtodos de soluo de problemas de memria, consulte
o artigo sobre o monitoramento do uso da memria pelo SQL Server 2005
(http://go.microsoft.com/fwlink/?linkid=105585&clcid=0x416).

Contadores de disco a serem monitorados


Monitore os seguintes contadores para assegurar a integridade dos discos. Observe que
os seguintes valores so medidos ao longo do tempo no so valores que ocorrem
durante um pico repentino e no se baseiam em uma nica medio.
Disco Fsico: % Tempo de Disco: DataDrive Este contador mostra a
porcentagem do tempo decorrido em que a unidade de disco selecionada est
ocupada atendendo a solicitaes de leitura ou gravao um indicador geral de
como o disco est ocupado. Se o contador PhysicalDisk: % Tempo de Disco for
alto (mais do que 90 por cento), verifique o contador PhysicalDisk: Comprimento
da Fila de Disco Atual para ver quantas solicitaes do sistema esto aguardando
o acesso ao disco. O nmero de solicitaes de E/S em espera deve ser mantido em
no mais de 1,5 a 2 vezes o nmero de eixos que constituem o disco fsico.

Disco Lgico: Transferncias de Disco/s Este contador mostra a taxa em que


so executadas as operaes de leitura e gravao no disco. Use este contador
para monitorar as tendncias de crescimento e fazer previses adequadamente.

Disco Lgico: Bytes de Leitura de Disco/s e Disco Lgico: Bytes de Gravao


de Disco/s Estes contadores mostram a taxa em que os bytes so transferidos do
disco durantes as operaes de leitura e gravao.
364

Disco Lgico: Mdia de Bytes de Disco/Leitura Este contador mostra o nmero


mdio de bytes transferidos do disco durante as operaes de leitura. Esse valor
pode refletir a latncia do disco operaes de leitura maiores podem resultar em
latncia ligeiramente maior.

Disco Lgico: Mdia de Bytes de Disco/Gravao Este contador mostra o


nmero mdio de bytes transferidos para o disco durante as operaes de gravao.
Esse valor pode refletir a latncia do disco operaes de gravao maiores
podem resultar em latncia ligeiramente maior.

Disco Lgico: Comprimento da Fila de Disco Atual Este contador mostra o


nmero de solicitaes pendentes no disco no momento em que os dados de
desempenho so coletados. Para este contador, valores menores so melhores.
Valores maiores do que 2 por disco podem indicar um afunilamento e devem ser
investigados. Isso significa que um valor at 8 aceitvel para uma LUN (unidade
lgica) constituda de quatro discos. Os afunilamentos podem criar uma lista de
pendncias capaz de se difundir para alm do servidor atual que est acessando o
disco e provocar longos tempos de espera para os usurios. As possveis solues
para um afunilamento so adicionar mais discos matriz de RAID, substituir os
discos existentes por discos mais rpidos ou mover alguns dados para outros discos.

Disco Lgico: Comprimento Mdio da Fila de Disco Este contador mostra o


nmero mdio de solicitaes de leitura e gravao que foram enfileiradas para o
disco selecionado durante o intervalo da amostra. A regra que deve haver no
mximo duas solicitaes pendentes de leitura e gravao por eixo, mas isso pode
ser difcil de medir por causa da virtualizao do armazenamento e de diferenas em
nveis de RAID entre configuraes. Procure comprimentos de fila de disco maiores
do que a mdia em combinao com latncias de disco maiores do que a mdia.
Essa combinao pode indicar que o cache da matriz de armazenamento est
sendo superutilizado ou que o compartilhamento do eixo com outros aplicativos est
afetando o desempenho.

Disco Lgico: Mdia de Disco s/Leitura e Disco Lgico: Mdia de Disco


s/Gravao Estes contadores mostram o tempo mdio, em segundos, de uma
operao de leitura ou gravao no disco. Monitore estes contadores para assegurar
que eles permaneam abaixo de 85 por cento da capacidade do disco. O tempo de
acesso a disco aumenta exponencialmente se operaes de leitura ou gravao
representarem mais de 85 por cento da capacidade do disco. Para determinar a
capacidade especfica do seu hardware, consulte a documentao do fornecedor ou
use a Ferramenta de Parmetro de Comparao de Subsistema de Disco SQLIO
para calcul-la. Para obter mais informaes, consulte o artigo sobre a Ferramenta
de Parmetro de Comparao de Subsistema de Disco SQLIO
(http://go.microsoft.com/fwlink/?linkid=105586&clcid=0x416).

Disco Lgico: Mdia de Disco s/Leitura Este contador mostra o tempo


mdio, em segundos, de uma operao de leitura do disco. Em um sistema bem
ajustado, os valores ideais vo de 1 a 5 ms para logs (idealmente 1 ms em uma
matriz em cache) e de 4 a 20 ms para dados (idealmente menos do que 10 ms).
Latncias maiores podem ocorrer durante momentos de pico, mas se forem
registrados valores maiores regularmente, voc dever investigar a causa.

Disco Lgico: Mdia de Disco s/Gravao Este contador mostra o tempo


mdio, em segundos, de uma operao de gravao no disco. Em um sistema
365

bem ajustado, os valores ideais vo de 1 a 5 ms para logs (idealmente 1 ms em


uma matriz em cache) e de 4 a 20 ms para dados (idealmente menos do que
10 ms). Latncias maiores podem ocorrer durante momentos de pico, mas se
forem registrados valores maiores regularmente, voc dever investigar a causa.
Quando voc usar configuraes de RAID com os contadores Mdia de Disco
s/Leitura ou Mdia de Disco s/Gravao, use as frmulas relacionadas na
tabela a seguir para determinar a taxa de entrada e sada no disco.
Nvel de RAID

Frmula

RAID 0

E/Ss por disco = (leituras + gravaes) /


nmero de discos

RAID 1

E/Ss por disco = [leituras + (2 gravaes)]


/2

RAID 5

E/Ss por disco = [leituras + (4 gravaes)]


/ nmero de discos

RAID 10

E/Ss por disco = [leituras + (2 gravaes)]


/ nmero de discos

Por exemplo, se voc tiver um sistema RAID 1 com dois discos fsicos
e seus contadores tiverem os valores mostrados na tabela a seguir:
Contador

Valor

Mdia de Disco s/Leitura

80

Disco Lgico: Mdia de Disco s/Gravao 70


Comprimento Mdio da Fila de Disco

O valor de E/S por disco pode ser calculado da seguinte forma: (80 +
(2 70))/2 = 110
O comprimento da fila de disco pode ser calculado da seguinte forma: 5/2 = 2,5
Nessa situao, voc tem um afunilamento de E/S limtrofe.

Outras ferramentas de monitorao


Voc tambm pode monitorar a latncia de disco e analisar tendncias usando a
exibio de gerenciamento dinmico sys.dm_io_virtual_file_stats no SQL Server 2008.
Para obter mais informaes, consulte o artigo sobre sys.dm_io_virtual_file_stats
(Transact-SQL) (http://go.microsoft.com/fwlink/?linkid=105587&clcid=0x416).

366