Capacity Planning Sharepoint 2010-Libre PDF

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
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
Glossary ....................................................................................................................... 152
Overview ...................................................................................................................... 153
Specifications ............................................................................................................... 154
Results and Analysis ................................................................................................... 160
Departmental collaboration environment technical case study (SharePoint Server 2010)
(em ingls) ................................................................................................................... 172
Specifications ............................................................................................................... 173
Workload ...................................................................................................................... 180
Dataset......................................................................................................................... 180
Divisional portal environment lab study (SharePoint Server 2010) (em ingls) ............. 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
Specifications ............................................................................................................... 209
Workload ...................................................................................................................... 214
Dataset......................................................................................................................... 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 Results ................................................................................................................. 245
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 results .................................................................................................................. 329
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

7
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

8

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.
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.
(SharePoint Server 2010)
9
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).

10

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

11

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
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
12
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:
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
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:
13
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:
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:
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:
Server 2010)
Para obter informaes sobre dimensionamento e desempenho, consulte o seguinte
artigo:
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)
14
Para obter informaes adicionais sobre gerenciamento de capacidade, consulte os
seguintes artigos complementares a este artigo de viso geral:
Agora, voc deve ter boas noes bsicas sobre os conceitos. Para obter informaes
sobre os limites do SharePoint Server 2010, consulte o seguinte artigo:
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)
Server 2010)
Para obter informaes sobre dimensionamento e desempenho, consulte o seguinte
artigo:
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:
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
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:
15
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.
16
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.
17
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:
18
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.
19
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
20

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.
21
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.
22
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.
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.
23
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
24
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
25
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
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
servidor
Web
CPU do
servidor
de
aplicativos
RAM do
servidor de
aplicativos:
CPU
do
SQL
Server
IOPS
do
SQL
Server
Armazenamento
do SQL Server
Servio do
SharePoint
XXX XXX XX XXX XXX
26
Aplicativo de
Servio
CPU do
servidor
Web
RAM do
servidor
Web
CPU do
servidor
de
aplicativos
RAM do
servidor de
aplicativos:
CPU
do
SQL
Server
IOPS
do
SQL
Server
Armazenamento
do SQL Server
Foundation
Servio da
Administrao
Central
XX XX X X X
Servio de Log * XX XX XX XXX XXX
Servio de
Pesquisa do
SharePoint
XXX XXX XXX XXX XXX XXX XXX
Aplicativo de
servio de
Exibio do Word
*
X X XXX XX
Servio
PowerPoint *
XX XX XXX XX
Servio de
Clculo do Excel
XX X XX XXX
Servio do Visio * X X XXX XXX X X X
Servio do
Access *
X X XXX XX X X X
Servio de Perfil
de Usurio
X XX XX XX XXX XXX XX
Servio de
Metadados
Gerenciados *
X XX XX XX X X XX
Servio do Web
Analytics *
X X XXX XXX XXX
Servio de
Conectividade de
Dados
Corporativos *
XX XX XXX XXX
Servio do
InfoPath Forms
XX XX XX XX X X X
Servio de
Converso do
Word
X X XXX XX X X X
27
Aplicativo de
Servio
CPU do
servidor
Web
RAM do
servidor
Web
CPU do
servidor
de
aplicativos
RAM do
servidor de
aplicativos:
CPU
do
SQL
Server
IOPS
do
SQL
Server
Armazenamento
do SQL Server
Aplicativo de
Servio do
PerformancePoint
*
XX XX XXX XXX X X X
Servio do
Project *
X X X X XXX XXX XX
Solues de rea
Restrita *
X X XXX XXX
Recursos de fluxo
de trabalho *
XXX XXX
Servio de Timer XX XX XX XX
PowerPivot * X X XXX XXX 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,
28
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 e
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).
29
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
30
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 co-
localizado 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.
31
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 X
Aplicativo cliente do Word e do
PowerPoint 2010
XX X
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
32
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
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
33
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).
34
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.
35
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.
36
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
37
contedo e dos bancos de dados de servios de aplicativo habilitados no farm. Espera-
se 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.
38

Consulte tambm
Conceitos
39
Server 2010)
Performance and capacity technical case studies (SharePoint Server 2010) (em ingls)
Outros recursos
Hardware and software requirements (SharePoint Server 2010)

40

Planejamento de capacidade para
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.
41
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
Media do RPS dirio
Media do RPS no horrio de pico
Numero total de usurios
exclusivos por dia

Media diria de usurios
simultneos

Usurios simultneos no horrio de
pico

Numero total de solicitaes por dia
Distribuio da carga de trabalho
esperada
Numero de solicitaes por dia %
Navegador da Web -
Rastreamento de Pesquisa

Navegador da Web - Interao
Geral de Colaborao

Social

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)

42

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 numero total de usurios dirios pode indicar o crescimento potencial da carga no
farm. Por exemplo, se o numero de usurios potenciais for de 100 mil funcionrios, 15 mil
usurios dirios indicam que a carga pode crescer significativamente com o tempo, a
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).
43

44

Estimando sua carga de trabalho de produo
45
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 pr-
produo.
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
46
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-a3f7-
2e0be6d5532e&displaylang=en).
possvel baixar o Analisador de Logs 2.2 pelo site
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=890CD06B-ABF8-4C25-
91B2-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.

47
Objeto Valor
Tamanho do BD (em GB)
Numero de BDs de Conteudo
Numero de conjuntos de sites
Numero de aplicativos web
Numero de sites
Tamanho do lndice de pesquisa (numero de
itens)

Numero de documentos
Numero de listas
Tamanho medio dos sites
Tamanho do maior site
Numero 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
48
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
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.
49
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
(Padro
ou virtual)
Nmero de
computadores
Processamentos RAM IOPS
necessrio
Tamanho
do disco
SO+Log
Unidade
de
dados
Servidores
Web
Virtual 4 4 nucleos 8 N/A 400 GB N/A
Servidor de
banco de
dados de
conteudo
Padro 1 cluster 4 nucleos
qudruplos 2.33
(GHz)
48 2 mil 400 GB 20
discos
de 300
GB
A 15
mil
RPM
50
Funo Tipo
(Padro
ou virtual)
Nmero de
computadores
Processamentos RAM IOPS
necessrio
Tamanho
do disco
SO+Log
Unidade
de
dados
Servidores de
aplicativos
Servidor Web
de Destino de
Rastreamento
de Pesquisa
Servidor de
Consulta de
Pesquisa
Padro 2 2 nucleos
qudruplos 2.33
(GHz)
32 N/A 400 GB 500 GB
Servidor do
Rastreador
de Pesquisa
Padro 2 2 nucleos
qudruplos 2.33
(GHz)
16 400 400 GB N/A
Servidor de
banco de
dados de
Rastreamento
de Pesquisa
qudruplos 2.33
(GHz)
48 4 mil
(ajustado
para
leitura)
100 GB 16
discos
de 150
GB a
15 mil
RPM
Banco de
dados de
Repositrio
de
Propriedades
de Pesquisa
+ Servidor de
banco de
dados de
administrao
qudruplos 2.33
(GHz)
48 2 mil
(ajustado
para
gravao)
100 GB 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
51
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/pt-
br/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/71c203cd-
7534-47b0-9122-657d72ff0080(Office.14).aspx).
Diretrizes de seleo de hardware
Escolhendo processadores
52
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
Escolhendo redes
53
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
54
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.
55
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 in-
loco, 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.
56
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 indicadores-
chave 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:
Soluo de problemas (http://blogs.msdn.com/b/ecm/archive/2010/06/22/variations-
propagate-pages-on-your-terms.aspx)
Consulte tambm
Conceitos
2010
Outros recursos

57

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
Neste artigo:
Crie testes e ferramentas
58
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.
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.
59
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
60
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-427a-
81c3-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
61
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
62
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 check-
in dele e public-lo. Tambm necessrio o estado de reserva entre as etapas por
63
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
64
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
2010
65
Outros recursos

66

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:
Antes de ler este artigo, voc deve ler Viso geral do gerenciamento da capacidade e
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
de Eventos
Desabilitado O valor padro e
Habilitado. Ele
pode ser
desabilitado para
coletar a
quantidade
67
mxima posslvel
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 e
de 30 minutos.
Se essa
configurao for
reduzida, os
dados sero
importados para
o banco de
dados de uso
com mais
frequncia. Isso e
particularmente
util na soluo de
problemas. Para
operaes
normais, o valor
deve ser de 30
minutos.
Provedores de Diagnstico
Habilitar todos os provedores de
diagnstico
Habilitado O valor padro e
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, convem
reverter ao
68
padro.
Definir intervalos de agendamento
de "job-diagnostics-performance-
counter-wfe-provider" e "job-
diagnostics-performance-counter-
sql-provider"
1 minuto O valor padro e
de cinco
minutos. Se
essa
configurao for
reduzida, o
polling dos dados
poder ser
realizado com
mais frequncia.
Isso e
particularmente
util na soluo de
problemas. Para
operaes
normais, o valor
deve ser de
cinco minutos.
Diversos
Habilitar rastreamento de pilha
para solicitaes de conteudo
Desabilitado. Se
essa
configurao for
habilitada,
permitir o
diagnstico de
falhas de
solicitaes de
conteudo usando
o rastreamento
de pilha de
processos. Para
operaes
normais, ela
deve ser
desabilitada.
Habilitar o Painel do
Desenvolvedor
Desabilitado. Se
essa
configurao for
habilitada,
permitir o
diagnstico de
pginas lentas ou
69
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 Conteudo
Uso de Exportao de Conteudo
Solicitaes de Pgina
Uso de Recursos
Uso de Consultas de Pesquisa
Uso de Inventrio de Site
Trabalhos de Timer
Uso de Classificao
Habilitado 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 Add-
SPDiagnosticsPerformanceCounter 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

70
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. Alem 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 media 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 a qual os dados so
enviados e recebidos atraves 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 disponlvel e essencial em
qualquer estudo de capacidade, mas voc
tambem 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 numero de falhas de cache.
Arquivo de Memria e Paginao

Monitore a quantidade de memria flsica
disponlvel para alocao. Se houver
memria insuficiente, isso levar ao uso
excessivo do arquivo de paginao e a um
aumento no numero de falhas de pgina por
segundo.

71
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 perlodo 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 tambem pode medir a utilizao em
cada processador, para garantir um
desempenho equilibrado entre os nucleos.
Disco
- Comprimento Medio da Fila de Disco Mostra o numero medio 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 Medio da Fila de Leitura de
Disco
O numero medio de solicitaes de leitura
que esto na fila.
Comprimento Medio da Fila de Gravao de
Disco
O numero medio de solicitaes de
gravao que esto na fila.
Leituras de Disco/s O numero de leituras de disco por segundo.
Gravaes de Disco/s O numero de gravaes em disco por
segundo.
Memria
- Mbytes Disponlveis Mostra a quantidade de memria flsica
disponlvel para alocao. Se houver
memria insuficiente, isso levar ao uso
excessivo do arquivo de paginao e a um
aumento no numero de falhas de pgina por
segundo.
72
- Falhas de Cache/s Este contador mostra a taxa a qual ocorrem
falhas quando uma pgina e procurada no
cache do sistema de arquivos e no e
encontrada. Pode se tratar de uma falha
leve, quando a pgina e 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 e indicado por uma reduo
em Leituras Rpidas Assncronas/s ou
Leituras Antecipadas/s.
- Pginas/s Esse contador mostra a taxa a 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, as
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 flsica
for inadequada.
NIC
- Total de Bytes/s Essa e a taxa a qual os dados so enviados
e recebidos atraves 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 e
reservada para o processo, mesmo que no
73
esteja em uso.
- % Tempo de Processador Esse contador indica a porcentagem de
tempo de processador que e usada por
determinado processo.
Contagem de Threads (_Total) O numero atual de threads.
ASP.NET
Total de Solicitaes O numero 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 atraves de HTTP. Esse contador
mostra o numero de solicitaes
aguardando para serem processadas.
Tempo de Espera da Solicitao O numero de milissegundos que a
solicitao mais recente aguardou na fila
para processamento. A medida que
aumenta o numero de eventos de espera,
os usurios experimentam desempenho de
renderizao de pginas degradado.
Solicitaes Rejeitadas O numero total de solicitaes no
executadas devido a recursos insuficientes
do servidor para process-las. Esse
contador representa o numero de
solicitaes que retornam um cdigo de
status 503 HTTP, indicando que o servidor
est muito ocupado.
Solicitaes em Execuo (_Total) O numero de solicitaes em execuo no
momento.
Solicitaes/s (_Total) O numero de solicitaes executadas por
segundo. Isso representa a produtividade
atual do aplicativo. Sob carga constante,
esse numero 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 numero de vezes que os objetos da
74
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 numero e util
como uma razo de Gerao 0: Gerao 1:
Gerao 2 para garantir que o numero de
conjuntos da Gerao 2 no exceda em
muito os conjuntos da Gerao 0,
otimamente por um fator de 2.
gerao 1 foram submetidos a coleta de lixo
desde que o aplicativo foi iniciado.
gerao 2 foram submetidos a coleta de lixo
desde que o aplicativo foi iniciado. O
contador e incrementado ao final de uma
coleta de lixo da gerao 2 (tambem
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 ultimo 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 e uma media; seu
valor reflete o ultimo 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.

Estatlsticas Gerais Esse objeto fornece contadores para
monitorar a atividade em todo o servidor
geral, como o numero de conexes atuais e
o numero 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
75
conexes de usurio em sua instncia do
SQL Server. Se esse numero crescer
500 por cento em relao a 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 nlvel 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 numero serve para ajud-
lo a criar uma linha de base e solucionar
problemas.
Bloqueios Esse objeto fornece informaes sobre
bloqueios do SQL Server em tipos de
recursos individuais.
Numero de Deadlock/s Esse contador mostra o numero de
deadlocks no SQL Server por segundo.
Esse valor normalmente deve ser 0.
Tempo de Espera Medio (ms) Este contador mostra a quantidade media
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 ultimo segundo.
Esperas de Bloqueio/s Este contador mostra o numero 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
76
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 Medio de Espera de Trava (ms) Esse contador mostra o tempo medio de
espera de trava para solicitaes de trava
que precisaram esperar.
Esperas de Trava/s Esse contador mostra o numero de
solicitaes de trava por segundo que no
puderam ser atendidas imediatamente.
Estatlsticas SQL Esse objeto fornece contadores para
monitorar a compilao e o tipo de
solicitaes enviadas a uma instncia do
SQL Server. O monitoramento do numero
de compilaes e recompilaes de
consultas e do numero 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 numero de vezes
que o caminho de cdigo de compilao e
inserido por segundo.
Recompilaes de SQL/s Esse contador indica o numero 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 flsica enquanto o SQL
77
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 e o numero total de acertos de cache
dividido pelo numero 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.
78

Objetos e contadores Problema Opes de resoluo
Processador
Processador - % Tempo de
Processador
Mais de 75-85% Atualizar o processador
Aumentar o numero de
processadores
Adicionar servidor(es)
Disco
Comprimento Medio da Fila
de Disco
Aumentando gradualmente;
o sistema no est em um
estado de equillbrio e a fila
est aumentando
Aumentar o numero ou a
velocidade dos discos
Alterar configurao de matriz
para distribuio
Mover alguns dados para um
servidor alternativo
% Tempo Ocioso Mais de 90% Aumentar o numero de discos
Mover dados para um disco ou
% de Espao Livre Menos de 30% Aumentar o numero de discos
Memria
Mbytes Disponlveis Menos de 2 GB em um
servidor Web.
Adicionar memria.

Observao:
A memria disponlvel 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 posslvel
Pginas/s Mais de 10 Adicionar memria
Arquivo de Paginao
79
% Usado e % Pico de Uso O arquivo de paginao do
servidor, as 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
flsica for inadequada.
Adicionar memria
NIC
Total de Bytes/s Mais de 40-50% da
capacidade da rede. Essa e
a taxa a qual os dados so
enviados e recebidos
atraves da placa de
interface de rede.
Continuar a investigar
monitorando Bytes recebidos/s
e Bytes Enviados/s
Reavaliar a velocidade da placa
de rede de interface
Verificar o numero, tamanho e
uso de buffers de memria
Processo
Conjunto de Trabalho Mais de 80% da memria
total
Adicionar memria
% Tempo de Processador Mais de 75-85%. Aumentar o numero 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 e 5.000, e voc pode
alterar essa configurao no
80
arquivo Machine.config
Tempo de Espera da
Solicitao
A medida que aumenta o
numero 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
2010
Outros recursos

81

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
82
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.
83
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
84
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.
85
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
conteudo
300 por aplicativo Web Com
suporte
Com 300 bancos de
dados de conteudo por
aplicativo Web, no so
afetadas as operaes de
usurios finais, como
abertura de sites ou de
conjuntos de sites.
Porem, operaes
administrativas, como a
criao de um novo
conjunto de sites, tero
seu desempenho
reduzido. L recomendvel
usar o Windows
PowerShell para
gerenciar o aplicativo
Web quando houver um
grande numero de
bancos de dados de
conteudo, pois a interface
de gerenciamento torna-
se lenta e diflcil de
navegar.
Zona 5 por aplicativo Web Delimitador O numero de zonas
definidas para um farm e
embutido em cdigo
como cinco. As zonas
so Padro, Intranet,
Extranet, Internet e
Personalizada.
Caminho gerenciado

20 por aplicativo Web Com
suporte
Os caminhos
gerenciados so
armazenados em cache
86
limite
Observaes
no servidor Web, e os
recursos da CPU so
usados para processar
solicitaes recebidas em
relao a 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, e
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 Set-
SPInfoPathFormsService
do Windows PowerShell.
Para obter mais
informaes, consulte
Set-
SPInfoPathFormsService.

Servidor Web e limites de servidor de aplicativos
A tabela a seguir lista as diretrizes recomendadas para servidores Web no farm.
87

limite
Observaes
Pools de aplicativos 10 por servidor Web Com
suporte
O numero mximo e
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
Observaes
Tamanho do banco de
dados de conteudo
200 GB por banco de
dados de conteudo
Com
suporte
L altamente
recomendvel limitar
o tamanho dos
bancos de dados de
conteudo a 200 GB
para ajudar a
garantir o
desempenho do
sistema.
H suporte para
tamanhos de bancos
de dados de
conteudo de ate
1 terabyte somente
para grandes
repositrios de um
unico site e
88
limite
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
tlpicos 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,
disponlvel em
Recomendaes e
resultados de testes
de desempenho e
capacidade
(SharePoint Server
2010), e a seo
Cenrios comuns de
gerenciamento de
conteudo em grande
escala, disponlvel
em Enterprise
content storage
planning (SharePoint
Server 2010).
Um conjunto de sites
no deve ultrapassar
100 GB, a menos
89
limite
Observaes
que haja apenas um
conjunto de sites no
banco de dados.
Conjuntos de sites por
banco de dados de
conteudo
2.000 recomendados
Mximo de 5.000
Com
suporte
L altamente
recomendvel limitar
o numero de
conjuntos de sites
em um banco de
dados de conteudo
para 2000. No
entanto, h suporte
para ate 5000
conjuntos de sites
em um banco de
dados.
Esses limites
referem-se a
velocidade de
atualizao. Quanto
maior for o numero
de conjuntos de sites
em um banco de
dados, mais lenta
ser a atualizao.
O limite quanto ao
numero de conjuntos
de sites em um
banco de dados est
subordinado ao
limite de tamanho de
um banco de dados
de conteudo que
tenha mais de um
conjunto de sites
(200 GB). Portanto,
a medida que o
numero de conjuntos
de sites em um
banco de dados
aumentar, o
tamanho medio dos
conjuntos de sites
nele contidos dever
diminuir.
Se voc exceder o
limite de 2000
90
limite
Observaes
conjuntos de sites, o
tempo de inatividade
durante as
atualizaes poder
ser mais longo. Se
voc planeja exceder
2000 conjuntos de
sites, e
recomendvel ter
uma estrategia 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 nlvel
de alerta para o
numero de sites em
um banco de dados
de conteudo, use o
cmdlet Set-
SPContentDatabase
do Windows
PowerShell com o
parmetro -
WarningSiteCount.
Para obter mais
informaes,
consulte Set-
SPContentDatabase.
Subsistema de
armazenamento RBS
(Remote BLOB Storage) no
Armazenamento NAS
(Network Attached Storage)
O tempo ate o primeiro
byte de qualquer resposta
do NAS no pode exceder
20 milissegundos

Delimitador Quando o
SharePoint Server
2010 estiver
configurado para
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 ate o
91
limite
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
Observaes
Site 250.000 por conjunto de
sites
Com
suporte
O numero mximo
recomendado de
sites e subsites e
de 250.000 sites.
Voc pode criar um
numero 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 nlveis de
subsites, tambem
conteria um total
de 100.000 sites.
Observao: a
excluso ou a
criao de um site
ou subsite pode
afetar de maneira
significativa a
92
limite
Observaes
disponibilidade de
um site. O acesso
ao site e aos
subsites ser
limitado enquanto
o site est sendo
excluldo. A
tentativa de criar
vrios subsites ao
mesmo tempo
tambem poder
falhar.
Tamanho de conjunto de
sites
100 GB por conjunto de
sites
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 Move-
SPSite.

Limites de listas e bibliotecas
93
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
Observaes
Tamanho de
linha de lista
8.000 bytes por
linha
Limite 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.
Tamanho do
arquivo
2 GB Delimitador O tamanho de arquivo padro mximo e de
50 MB. Ele pode ser aumentado para ate 2
GB; no entanto, um alto volume de arquivos
muito grandes pode afetar o desempenho
do farm.
Documentos 30.000.000 por
biblioteca
Com
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 Com
suporte
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
lista
Com
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 numero de
colunas na lista e da utilizao da lista.
Limite de
tamanho de
linhas
6 linhas de
tabela internas
ao banco de
dados usadas
para uma lista
ou um item da
biblioteca
Com
suporte
Especifica o numero 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, ate seis linhas por padro. Isso e
94
limite
Observaes
configurvel por administradores de farm
somente por meio do modelo de objeto. O
metodo de modelo de objeto e
SPWebApplication.MaxListItemRowStorage.
Operaes em
massa
100 itens por
operao em
massa
Delimitador A interface do usurio permite que no
mximo 100 itens sejam selecionados para
operaes em massa.
Limite de
pesquisa no
modo de
exibio de lista
8 operaes de
juno por
consulta
Limite Especifica o numero 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 unico. Quando voc
usa o modo de exibio mximo por meio do
modelo de objeto (sem especificar campos
de modo de exibio), o SharePoint retorna
ate as primeiras oito pesquisas.
Limite do modo
de exibio de
lista
5.000 Limite Especifica o numero mximo de itens na
lista ou biblioteca que uma operao de
banco de dados, como uma consulta, pode
processar de uma unica vez, fora da janela
de tempo diria definida pelo administrador
durante a qual as consultas so irrestritas.
Limite do modo
de exibio de
lista para
auditores e
administradores
20.000 Limite Especifica o numero mximo de itens na
lista ou biblioteca que uma operao de
banco de dados, como uma consulta, pode
processar de uma unica vez quando e 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
de exibio de
site
Limite A interface para enumerar os subsites de
um determinado site no funciona
adequadamente quando o numero de
subsites ultrapassa 2.000. Da mesma
forma, a pgina Todo o Conteudo do Site e
o desempenho do controle de exibio de
rvore diminuiro significativamente a
medida que o numero de subsites
aumentar.
Coautoria no 10 editores Limite O numero mximo recomendado de
95
limite
Observaes
Microsoft Word
e no Microsoft
PowerPoint
para arquivos
.docx, .pptx e
.ppsx
simultneos por
documento
editores simultneos e 10. O limite e 99.
Se houver 99 coautores com um unico
documento aberto para edio simultnea,
qualquer usurio aps o centesimo 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 numero mximo de escopos de
segurana exclusivos definidos para uma
lista no deve exceder 1.000.
Um escopo e o limite de segurana para um
objeto proteglvel e quaisquer de seus filhos
que no tenham um limite de segurana
separado definido. Um escopo contem uma
ACL (Lista de Controle de Acesso), mas,
diferentemente de outras ACLs de NTFS,
um escopo pode incluir entidades de
segurana especlficas 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.
96
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
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
de
limite
Tamanho por
coluna
Observaes
Linha unica 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
unica por lista do SharePoint (6
* 64 = 384). No entanto, como
o limite por item de lista do
SharePoint e de 8000 bytes,
dos quais 256 bytes so
reservados para colunas
internas do SharePoint, o limite
real e de 276 colunas de linha
de texto unica.
Vrias linhas de
texto
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
384 colunas de Opo por lista
97
de
limite
Tamanho por
coluna
Observaes
do SharePoint (6 * 64 = 384);
porem, como o limite por item
de lista do SharePoint e de
8000 bytes, dos quais 256
bytes so reservados para
colunas internas do
SharePoint, o limite real deve
ser de 276 colunas de opes.
Numero 72 Limite 12 bytes A disposio de linhas do SQL
72 colunas de Numero por lista
do SharePoint (6 * 12 = 72).
Moeda 72 Limite 12 bytes A disposio de linhas do SQL
72 colunas de Moeda por lista
Data e Hora 48 Limite 12 bytes A disposio de linhas do SQL
Server ocorre aps cada oito
48 colunas de Data e Hora por
lista do SharePoint (6 * 12 =
48).
Pesquisa 96 Limite 4 bytes A disposio de linhas do SQL
96 colunas de Pesquisa de
valor unico por lista do
SharePoint (6 * 16 = 96).
98
de
limite
Tamanho por
coluna
Observaes
Sim/No 96 Limite 5 bytes A disposio de linhas do SQL
96 colunas de Sim/No por lista
Pessoa ou grupo 96 Limite 4 bytes A disposio de linhas do SQL
96 colunas de Pessoa ou
Grupo por lista do SharePoint
(6 * 16 = 96).
Hiperlink ou
imagem
192 colunas de Hiperlink ou
Imagem por lista do SharePoint
(6 * 32 = 192); porem, como o
limite por item de lista do
SharePoint e 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
48 colunas de Calculada por
lista do SharePoint (6 * 8 = 48).
GUID 6 Limite 20 bytes A disposio de linhas do SQL
Server ocorre aps cada
99
de
limite
Tamanho por
coluna
Observaes
coluna em uma lista do
seis colunas de GUID por lista
Inteiros 96 Limite 4 bytes A disposio de linhas do SQL
96 colunas de Inteiros por lista
Metadados
gerenciados
94 Limite 40 bytes
para a
primeira e
32 bytes
para cada
uma
subsequente
So alocadas quatro colunas
para o primeiro campo de
Metadados Gerenciados
adicionado a uma lista:
Um campo de pesquisa
para a marca real
Um campo de texto oculto
para o valor da cadeia de
caracteres
para o mecanismo de
coleta
para transmisso do
mecanismo de coleta
Cada campo de Metadados
Gerenciados subsequente
adicionado a uma lista adiciona
duas colunas:
para a marca real
Um campo de texto oculto
para o valor da cadeia de
caracteres
O numero mximo de colunas
de Metadados Gerenciados e
calculado como (14 (16 * (n-
1))), em que n e o valor de
100
de
limite
Tamanho por
coluna
Observaes
mapeamento de linha (o
padro e 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
Observaes
Web parts 25 por wiki ou pgina de Web
parts
Limite Esse valor e
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.

101
Limites de segurana

limite
Observaes
Numero de grupos do
SharePoint aos quais um
usurio pode pertencer
5.000 Com
suporte
Esse no e um imite rlgido,
mas e consistente com as
diretrizes do Active Directory.
H vrios itens que afetam
esse numero:
O tamanho do token de
usurio
O cache de grupos: o
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.

Usurios em um conjunto
de sites
2 milhes por conjunto
de sites
Com
suporte
Voc pode adicionar milhes
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
102
limite
Observaes
usar o Windows PowerShell
para gerenciar os usurios,
em vez da interface do
usurio. Isso proporcionar
uma melhor experincia de
gerenciamento.
Princlpios/Usurios do
Active Directory em um
grupo do SharePoint
5.000 por grupo do
SharePoint
Com
suporte
O SharePoint Server 2010
permite adicionar usurios ou
grupos do Active Directory a
um grupo do SharePoint.
A existncia de ate 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.

Grupo do SharePoint 10.000 por conjunto de
sites
Com
suporte
Acima de 10.000 grupos, o
tempo necessrio para
executar operaes aumenta
significativamente. Isso se
aplica particularmente a
adio de um usurio a um
grupo existente, a criao de
um novo grupo e a
renderizao de modos de
exibio de grupos.
Entidade de segurana:
tamanho do Escopo de
Segurana
5.000 por ACL (Lista de
Controle de Acesso)
Com
suporte
O tamanho do escopo afeta
os dados que so usados
para um clculo de
103
limite
Observaes
verificao de segurana.
Esse clculo ocorre sempre
que o escopo e alterado. No
h um limite rlgido, 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
Observaes
Aplicativos de
servio de pesquisa
do SharePoint
20 por farm 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 e
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
10 bancos de dados de
rastreamento por aplicativo
de servio de pesquisa
25 milhes de itens por
banco de dados de
rastreamento
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 e de 10 bancos de
por aplicativo de servio
de Pesquisa do
SharePoint.
O limite recomendado e
de 25 milhes de itens por
banco de dados de
rastreamento (ou um total
104
limite
Observaes
de quatro bancos de
por aplicativo de servio
de pesquisa).
Componentes de
rastreamento
16 por aplicativo de servio
de pesquisa
Limite O limite recomendado por
aplicativo e 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 (nucleos).
O numero 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 disponlveis no
servidor de rastreamento,
banco de dados e host de
conteudo.
Parties de
indexao
de pesquisa; total de 128
Limite A partio de lndice
contem um subconjunto
do lndice de aplicativo de
servio de pesquisa. O
limite recomendado e de
20. Se for aumentado o
numero de parties de
lndice, cada partio
conter um subconjunto
menor do lndice,
reduzindo a memria
105
limite
Observaes
RAM e o espao em disco
necessrios no servidor
de consulta que hospeda
o componente de consulta
atribuldo a partio de
lndice. O limite para o
numero total de parties
de lndice e de 128.
Itens indexados 100 milhes por aplicativo de
servio de pesquisa; 10
milhes por partio de lndice
Com
suporte
A Pesquisa do SharePoint
d suporte a parties de
lndice, cada uma das
quais contendo um
subconjunto do lndice de
pesquisa. O mximo
recomendado e de 10
milhes de itens em
qualquer partio. O
numero mximo total de
itens recomendado (por
exemplo, pessoas, itens
de lista, documentos,
pginas da Web) e de 100
milhes.
Entradas do log de
rastreamento
100 milhes por aplicativo de
pesquisa
Com
suporte
Esse e o numero de
entradas de log
individuais no log de
rastreamento. Ele seguir
o limite de "itens
indexados".
Bancos de dados
de propriedade
de pesquisa; total de 128
Limite O banco de dados de
propriedade armazena os
metadados de itens em
cada partio de lndice
associada a ele. Uma
partio de lndice s pode
ser associada a um
repositrio de
propriedades. O limite
recomendado e de 10
bancos de dados de
propriedade por aplicativo
de servio de pesquisa. O
limite para parties de
lndice e de 128.
106
limite
Observaes
Componentes de
consulta
128 por aplicativo de
pesquisa; 64/(total de
componentes de
rastreamento) por servidor
Limite O numero total de
componentes de consulta
e limitado pela capacidade
dos componentes de
rastreamento de copiar
arquivos. O numero
mximo de componentes
de consulta por servidor e
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 e 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. Alem disso,
a exibio dos escopos na
interface de administrao
de pesquisa e prejudicada
a medida que o numero
de escopos passa do
limite recomendado.
Grupos de exibio 25 por site 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
107
limite
Observaes
de escopo na interface de
administrao de
pesquisa.
Alertas 1.000.000 por aplicativo de
pesquisa
Com
suporte
Esse e o limite testado.
Fontes de conteudo 50 por aplicativo de servio
de pesquisa
Limite O limite recomendado de
50 pode ser excedido ate
o limite de 500 por
pesquisa. No entanto,
devem ser usados menos
endereos iniciais, e o
limite de rastreamento
simultneo deve ser
seguido.
Endereos iniciais 100 por fonte de conteudo Limite O limite recomendado
pode ser excedido ate o
limite de 500 por origem
de conteudo. No entanto,
quanto mais endereos
iniciais houver, menos
fontes de conteudo
devero ser usadas.
Quando h muitos
endereos iniciais, e
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 e o numero de
rastreamentos em
andamento ao mesmo
tempo. Se esse numero
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
108
limite
Observaes
de rastreamento 100 por farm. A
recomendao pode ser
excedida, porem, a
exibio das regras de
visitas do site na interface
de administrao de
pesquisa e prejudicada.
Em cerca de 2000 regras
de visitas do site, a pgina
Gerenciar Regras de
Visitas do Site torna-se
ileglvel.
Regras de
rastreamento
de pesquisa
Limite Esse valor pode ser
excedido; no entanto, a
exibio das regras de
rastreamento na interface
de administrao de
pesquisa e 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.
Remoes de URL 100 remoes por operao Com
suporte
Esse e o numero mximo
recomendado de URLs
que devem ser removidas
do sistema em uma
operao.
Pginas
autoritativas
1 pgina de nlvel superior e o
mlnimo de pginas de
segundo e terceiro nlvel por
pesquisa
Limite O limite recomendado e
de uma pgina autoritativa
de nlvel superior e o
menor numero posslvel de
pginas de segundo e
terceiro nlvel para obter a
relevncia desejada.
O limite e de 200 por nlvel
109
limite
Observaes
de relevncia por
aplicativo de pesquisa,
mas a adio de pginas
pode no proporcionar a
relevncia desejada.
Adicione o site principal
ao primeiro nlvel de
relevncia. Adicione mais
sites principais no
segundo ou terceiro nlvel
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
O limite recomendado
pode ser excedido ate 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 palavras-
chave 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).
Propriedades de
metadados
reconhecidas
10.000 por item rastreado Delimitador Esse e o numero de
propriedades de
metadados que podem
ser determinadas e
potencialmente mapeadas
ou usadas para consultas
quando um item e
rastreado.

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

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
ate dois
milhes de
perfis de
usurio com
funcionalidade
completa de
recursos
sociais. Esse
numero
representa o
numero de
perfis que
podem ser
importados
para o
repositrio de
perfis de
pessoas de
um servio de
diretrio e
tambem o
numero de
perfis aos
quais um
aplicativo de
servio de
perfil de
usurio pode
dar suporte
sem
prejudicar o
desempenho
dos recursos
sociais.
Etiquetas de conteudo social,
observaes e classificaes
500.000.000 por banco de
dados social
Com
suporte
H suporte
para um total
de ate 500
milhes de
111
limite
Observaes
etiquetas de
conteudo
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
Observaes
Trabalhos de
implantao de
conteudo executados
em caminhos diferentes
20 Com
suporte
Para trabalhos de execuo
simultnea em caminhos que
esto conectados a conjuntos
de sites no mesmo banco de
dados de conteudo de origem,
h maior risco de deadlocks no
banco de dados. Para trabalhos
que devem ser executados
simultaneamente, e
recomendvel mover os
conjuntos de sites para bancos
de dados de conteudos de
origem diferentes.
112
limite
Observaes

Observao:
No e posslvel haver trabalhos
em execuo simultnea no
mesmo caminho.

Se voc estiver usando
instantneos do SQL Server
para implantao de conteudo,
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 numero
mximo de
posts de
blog e de
5000 por
site.
Comentrios 1000 por post Com suporte O numero
mximo de
comentrios
e de 1000
por post.

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

limite
Observaes
113
limite
Observaes
ECTs (Tipos de Conteudo
Externo) (na memria)
5000 por servidor Web (por
locatrio)
Limite Numero total de
definies de ECT
(tipo de conteudo
externo)
carregadas na
memria em um
determinado ponto
no tempo em um
servidor Web.
Conexes externas do
sistema
500 por servidor Web Delimitador Numero de
conexes do
sistema externas
ativas/abertas em
um determinado
ponto no tempo. O
valor mximo
padro e de 200; o
limite e de 500.
Esse limite e
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 e usado
para restringir o
numero de
conexes. Um
aplicativo pode
especificar um
limite maior por
meio do contexto
de execuo; o
limite impe o
mximo ate 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 Numero de itens
por solicitao que
o conector de
114
limite
Observaes
banco de dados
pode retornar.
O padro mximo
de 2.000 e usado
pelo conector de
banco de dados
para restringir o
numero 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 e de
1.000.000.

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

limite
Observaes
Limite de adiamento de fluxo
de trabalho
15 Limite O numero
mximo de
fluxos de
trabalho que
podem ser
executados em
relao a um
banco de
dados de
conteudo ao
mesmo tempo
e 15, excluindo
as instncias
em execuo
115
limite
Observaes
no servio de
timer. Quando
esse limite e
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 e
conclulda, as
novas
solicitaes
so contadas
em relao a
esse limite. O
limite pode ser
configurado
por meio do
cmdlet Set-
SPFarmConfig
do Windows
PowerShell.
Para obter
mais
informaes,
consulte Set-
SPFarmConfig.
Observao:
esse limite no
se refere ao
numero total
de instncias
de fluxos de
trabalho que
esto em
andamento.
Em vez disso,
116
limite
Observaes
ele e o numero
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 tambem
aumentar a
carga em
relao ao
banco de
dados de
conteudo e aos
recursos do
sistema.
Tamanho de lote de timer de
fluxo de trabalho
100 Limite O numero de
eventos que
cada execuo
do trabalho de
timer de fluxo
de trabalho
selecionar e
entregar aos
fluxos de
trabalho. Esse
numero pode
ser
configurado
por meio do
Windows
PowerShell.
Para permitir
eventos
adicionais,
voc pode
executar
instncias
adicionais do
117
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
Observaes
Numero mximo de
nlveis de termos
aninhados em um
repositrio de termos
7 Com
suporte
Os termos em um conjunto de
termos podem ser
representados de forma
hierrquica. Um conjunto de
termos pode ter ate sete nlveis
de termos (um termo pai e seis
nlveis de aninhamento abaixo
dele).
Numero mximo de
conjuntos de termos em
um repositrio de
termos
1000 Com
suporte
Pode haver ate 1000 conjuntos
de termos em um repositrio de
termos.
Numero mximo de
termos em um conjunto
de termos
30.000 Com
suporte
O numero mximo de termos
em um conjunto de termos e
30.000.

Observao:
Rtulos adicionais para o
mesmo termo, como sinnimos
e tradues, no contam como
termos separados.

Numero total de itens
em um repositrio de
termos
1.000.000 Com
suporte
Um item e um termo ou um
conjunto de termos. A soma do
numero de termos e conjuntos
118
limite
Observaes
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 numero
mximo de conjuntos de termos
e o numero 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.

de
limite
Observaes
Tamanho de arquivo de
desenhos da Web do
Visio
50 MB 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.
Aumento do uso da CPU.
Reduo das solicitaes
de servidor de aplicativos
por segundo.
Aumento da latncia total.
119
de
limite
Observaes
Aumento da carga de rede
de farm do SharePoint.

Tempo limite de
reclculo de desenhos
da Web do Visio
120 segundos 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 mlnima do cache
do Servios do Visio
(diagramas conectados
a dados)
Idade mlnima do cache:
0 a 24 horas
Limite A idade mlnima do cache se
aplica a diagramas conectados
a dados. Ela determina o
primeiro momento em que o
diagrama atual pode ser
removido do cache.
A definio da Idade Mlnima 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
120
de
limite
Observaes
a recalcular com frequncia e
reduz a disponibilidade da CPU
e da memria.

Idade mxima do cache
do Servios do Visio
(diagramas no
conectados a dados)
Idade mxima do cache:
0 a 24 horas
Limite 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 disponlvel.

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

limite
Observaes
Celulas 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 celulas
por consulta.
Colunas e linhas 15 colunas por 60.000 linhas Limite O numero
121
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
numero de linhas
pode ser alterado
em funo do
numero de
colunas.
Consulta em uma lista do
SharePoint
15 colunas por 5000 linhas Com
suporte
O numero
mximo de
colunas e linhas
ao renderizar
qualquer objeto
de painel do
PerformancePoint
que use uma lista
do SharePoint
como fonte de
dados. O numero
de linhas pode
ser alterado em
funo do numero
de colunas.
Consulta em uma fonte de
dados do SQL Server
15 colunas por 20000 linhas Com
suporte
O numero
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 numero
de linhas pode
ser alterado em
funo do numero
de colunas.
122

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

limite
Observaes
Tamanho do
arquivo de entrada
512 MB Delimitador Tamanho mximo de arquivo que
pode ser processado pelo Word
Automation Services.
Frequncia para
iniciar as
converses
(minutos)
1 minuto
(recomendado)
15
minutos (padro)
59 minutos (limite)
Limite Essa configurao determina a
frequncia com que o trabalho de
timer do Word Automation Services e
executado. Um numero mais baixo
torna mais rpida a execuo do
trabalho de timer. Nossos testes
mostram que e mais util executar o
trabalho de timer uma vez por minuto.
Numero de
converses a
iniciar por
processo de
converso
Para formatos de
salda PDF/XPS:
30 x M. Para todos
os outros formatos
de salda: 72 x
M, em que M e o
valor da
Frequncia para
iniciar converses
(minutos)
Limite O numero de converses a iniciar
afeta a taxa de transferncia do Word
Automation Services.
Se estes valores forem definidos
como mais elevados do que os nlveis
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 e
iniciado.
Tamanho do
trabalho de
converso
100.000 itens de
converso
Com
suporte
Um trabalho de converso inclui um
ou mais itens de converso, cada um
dos quais representa uma unica
converso a ser realizada em um
unico arquivo de entrada no
SharePoint. Quando um trabalho de
converso e iniciado (usando o
metodo 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 numero de itens de
converso aumentar o tempo de
123
limite
Observaes
execuo do metodo Start e o numero
de bytes transmitidos ao servidor de
aplicativos.
Total de processos
de converso
ativos
N-1, em que N e o
numero de nucleos
em cada servidor
de aplicativos

Limite Um processo de converso ativo pode
consumir um unico nucleo de
processamento. Portanto, os clientes
no devem executar mais processos
de converso do que o numero de
nucleos de processamento existentes
em seus servidores de aplicativos. O
trabalho de timer de converso e
outras atividades do SharePoint
tambem exigem o uso ocasional de
um nucleo de processamento.
L recomendvel deixar sempre um
nucleo 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
de converso
Com
suporte
O Word Automation Services mantem
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 Remove-
SPWordConversionServiceJobHistory
do Windows PowerShell. Para obter
mais informaes, consulte Remove-
SPWordConversionServiceJobHistory.

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

Sincronizao do SharePoint
Workspace
30.000 itens por lista Delimitador O
SharePoint
124
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
e muito
longo, e a
utilizao de
recursos e
elevada.
Sincronizao do SharePoint
Workspace
Limite de 1800 documentos no
SharePoint Workspace
Delimitador Os usurios
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
Observaes
Numero de Sees e
Grupos de Sees em
um Bloco de Anotaes
Consulte o limite para
"Documentos" em
Limites de lista e
Cada seo conta como uma
pasta e um documento na
lista. Cada grupo de sees
125
limite
Observaes
do OneNote (no
SharePoint)
biblioteca conta como uma pasta e um
documento na lista.
Tamanho mximo de
uma seo
"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.
"Tamanho de arquivo"
em Limites de lista e
biblioteca
Cada item e 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 unica pgina do
OneNote.
O limite padro e o
dobro do limite de
"Tamanho de arquivo".
Limite Isso se aplica ao conteudo
inserido em uma unica
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 conteudo inserido
em pginas diferentes e
excluindo as verses
anteriores da pgina. Se os
usurios precisarem ajustar
esse valor ("Tamanho
126
limite
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
conteudo inserido em uma
pgina ser limitado a 200
MB).
Operaes de
mesclagem
Uma por nucleo de
CPU por servidor Web
Delimitador O OneNote mescla
alteraes combinadas de
vrios usurios que esto
realizando a coautoria de um
bloco de anotaes. Se
nenhum nucleo de CPU
estiver disponlvel 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 e 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
Observaes
Tamanho do cache 100 GB Limite Espao
disponlvel
para
renderizar
documentos,
criados como
127
limite
Observaes
parte de um
banco de
dados de
conteudo. Por
padro, o
cache
disponlvel
para
renderizar
documentos
e de 100 GB.
No e
recomendvel
aumentar o
cache
disponlvel.
Renderizaes Uma por documento por
segundo por nucleo de CPU
por servidor de aplicativos
(mximo de oito nucleos)
Delimitador Esse e o
numero
medio
medido de
renderizaes
de
documentos
"tlpicos" que
podem ser
executadas
no servidor
de aplicativos
em um
perlodo 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.

Horrio do final do projeto Data: 31/12/2049 Delimitador Planos do
Project no
podem
ultrapassar
a data de
128
31/12/2049.
Produtos por plano de projeto 1500 produtos Delimitador Planos do
Project no
podem
conter mais
de 1500
produtos.
Numero de campos em um
modo de exibio
256 Delimitador Um usurio
no pode
ter mais de
256 campos
adicionados
a um modo
de exibio
que tenha
sido
definido no
Project Web
App.
Numero de clusulas em um
filtro para um modo de exibio
50 Delimitador Um usurio
no pode
adicionar
um filtro a
um modo
de exibio
que
contenha
mais de 50
clusulas.

129

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

131

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
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:
Server 2010
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
132
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
133
Esta seo traz detalhes sobre os computadores servidores usados nesse ambiente.

Observao:
O ambiente e dimensionado para acomodar compilaes de pre-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 e descrito para dar mais contexto ao ambiente e
serve como ponto de partida para ambientes semelhantes.
L importante direcionar seu gerenciamento de capacidade de acordo com a carga de
trabalho planejada e as caracterlsticas 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 nucleos 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 2
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 pre-
lanamento)
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
Servio de Consulta de Pesquisa e
Configuraes do Site
Pesquisa do SharePoint Server
134
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 nucleos qudruplos a 2.4 GHz
RAM 32 GB
Armazenamento e geometria (1,25 TB * 6) + 3 TB
Discos 1-4: Dados SQL
Disco 5: Logs
Disco 6: TempDB
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.
135

Configurao
136
A tabela abaixo enumera configuraes que foram alteradas e que afetam o
desempenho ou a capacidade do ambiente.

Administrao de
Conjunto de
Sites:
Cache de salda do
conjunto de sites
Ativado Habilitar o cache de salda aumenta a eficincia do
servidor, reduzindo chamadas no banco de dados em
busca de dados frequentemente solicitados.
Perfil do cache do
conjunto de sites
(selecionar)
Intranet
(Site de
Colabora
o)
A opo Permitir que os autores exibam o conteudo
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
(Desativado | n
MB)
Ativado
500 MB
O padro e 100 MB. O aumento dessa configurao
permite o armazenamento de mais dados na memria do
servidor Web front-end.
Servio de Uso:
Log de
Rastreamento
dias para
armazenar
arquivos de log
(padro: 14 dias)
5 dias O padro e 14 dias. Baixar essa configurao pode liberar
espao em disco no servidor onde os arquivos de log
esto armazenados.
Limite de Registro
de Consulta em
Log:
Microsoft
SharePoint
Foundation Banco
de dados
configurar
QueryLoggingThre
shold para 1
segundo
1 segundo O padro e 5 segundos. Baixar essa configurao pode
economizar largura de banda e CPU no servidor do
banco de dados.
Servidor de
Banco de Dados
Instncia Padro:
Grau mximo de
paralelismo
1 O padro e 0. Para garantir um desempenho ideal, e
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).
137

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
Media de Solicitaes por Segundo (RPS) 100
Media de RPS no horrio de pico (11h -
15h)
226
Quantidade total de usurios diferentes por
dia
33.580
Media 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
138
Caractersticas do Conjunto de Dados Valor
Tamanho do BLOB 22,2 GB
Quantidade de bancos de dados de
conteudo
3
Numero de aplicativos Web 3
Numero de conjuntos de sites 4
Numero de sites 797
Tamanho do lndice de pesquisa (numero de
itens)
275.000

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%
Media de memria usada 1,08 GB
Mximo de memria usada 2,60 GB
% de Rastreamento de Pesquisa de Trfego
(solicitaes de clientes de pesquisa/total de
solicitaes)
6%
Solicitaes ASP.NET na Fila 0,00

Os grficos abaixo mostram a utilizao mdia de CPU e a latncia desse ambiente.
139
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.
140
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
de Dados)
99,999:0,001
Comprimento Medio 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 Medio de Espera 0 ms
Bloqueios SQL: Tempo de Espera de
Bloqueio
0 ms
Bloqueios SQL: Deadlocks por Segundo 0
Travas SQL: Tempo Medio de Espera 0,25 ms
Taxa de Acertos do Cache SQL >99%

141

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

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 2
Network adapter speed 1 Gigabit
Authentication Windows NTLM
Load balancer type Hardware load balancing
Software version SharePoint Server 2010 (pre-release
version)
Services running locally Central Administration
Microsoft SharePoint Foundation Incoming
E-Mail
Microsoft SharePoint Foundation Web
Application
Microsoft SharePoint Foundation Workflow
Timer Service
Search Query and Site Settings Service
SharePoint Server Search
Services consumed from a federated
Services farm
User Profile Service
Web Analytics Web Service
144
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
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
RAM 32 GB
OS Windows Server 2008, 64-bit
Storage and geometry (1.25 TB * 7) + 3 TB
145
Disk 1-4: SQL Data
Disk 5: Logs
Disk 6: TempDB
Software version SQL Server 2008

Topology
The following diagram shows the topology for this farm.
146

Configuration
147
The following table enumerates settings that were changed that affect performance or
capacity in the environment.

Setting Value Notes
Usage Service
Trace Log days to store
log files (default: 14 days)
5 days The default is 14 days. Lowering this setting can save
disk space on the server where the log files are
stored.
QueryLoggingThreshold
SharePoint Foundation
Database change
to 1 second
1
second
The default is 5 seconds. Lowering this setting can
save bandwidth and CPU on the database server.
Database Server
Default Instance
Max degree of parallelism
1 The default is 0. To ensure optimal performance, we
strongly recommend that you set max degree of
parallelism to 1 for database servers that host
SharePoint Server 2010 databases. For more
information about how to set max degree of
parallelism, see max degree of parallelism
Option(http://go.microsoft.com/fwlink/?LinkId=189030).

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

Workload Characteristics Value
Average Requests per Second (RPS) 157
Average RPS at peak time (11 AM-3 PM) 350
Total number of unique users per day 69,702
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%
148
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 2
Number of site collections 34,423
Number of sites 101,598
Search index size (number of items) 23 million

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

Metric Value
Availability (uptime) 99.1%
Failure Rate 0.9%
Average memory used 3.4 GB
Maximum memory used 16.1 GB
Search Crawl % of Traffic (Search client
requests / total requests)
47%
149
Metric Value
ASP.NET Requests Queued 0.00

The following charts show the average CPU utilization and latency for this environment:
150
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 2
Disk Queue Length: Writes 0.3
Disk Reads/sec 131.33
Disk Writes/sec 278.33
SQL Compilations/second 9.9
SQL Re-compilations/second 0.07
SQL Locks: Average Wait Time 225 ms
SQL Locks: Lock Wait Time 507 ms
SQL Locks: Deadlocks Per Second 3.8
SQL Latches: Average Wait Time 14.3 ms
SQL Server: Buffer Cache Hit Ratio 74.3%

151

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
Lab environment specifications, such as hardware, farm topology and configuration
Test farm dataset
Test results analysis which should help you determine the hardware, topology and
configuration that you must have to deploy a similar environment, and optimize your
environment for appropriate capacity and performance characteristics
In this article:
Glossary
Overview
Specifications
Results and Analysis
This document provides guidance about scaling out and scaling up servers in a
SharePoint Server 2010 enterprise intranet collaboration solution, based on a testing
environment at Microsoft. Capacity planning informs decisions on purchasing hardware
and making system configurations to optimize your solution.
Different scenarios have different requirements. Therefore, it is important to supplement
this guidance with additional testing on your own hardware and in your own environment.
If your planned design and workload resembles the environment described in this
document, you can use this document to draw conclusions about scaling your
environment up and out.
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
152
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).
capacity management in SharePoint Server 2010. The following documentation will help
Server 2010
Also, we encourage you to read the following:
Glossary
There are some specialized terms that you will encounter in this document. Here are
some key terms and their definitions.
RPS: Requests per second. The number of requests received by a farm or server in
one second. This is a common measurement of server and farm load.
Note that requests differ from page loads; each page contains several components,
each of which creates one or more requests when the page is loaded. Therefore, one
page load creates several requests. Typically, authentication checks and events
using insignificant resources are not counted in RPS measurements.
Green Zone: This is the state at which the server can maintain the following set of
criteria:
The server-side latency for at least 75% of the requests is less than 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:
153
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,
154
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
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
155
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)
156
Database Server Default Instance DB1-2
Software version SQL Server 2008 R2 (pre-release version)

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

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

Setting Value Notes
Site Collection
Blob Caching On The default is Off. Enabling Blob Caching improves
server efficiency by reducing calls to the database
server for static page resources that may be frequently
requested.
Database
Server Default
Instance

Max degree of
parallelism
SharePoint Server databases. For more information
about how to set max degree of parallelism, see max
degree of parallelism

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

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

Database size (combined) 130 GB
BLOB size 108.3 GB
Number of site collections 181
160
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.
161
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.
162
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
Maximum:
163
Green Zone:
Example of how to read these graphs:
164
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
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.
165
2. Processor utilization
The following graphs show how scaling out affects processor utilization.
166
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
167
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.
168
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.
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
169
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
170
Office SharePoint Server 2007. This reflects the improvements that were made in
SharePoint Server 2010 to sustain larger deployments.
When the web servers were scaled out to maximize the database server usage,
SharePoint Server 2010 was SQL Server CPU Utilization bound, whereas Office
SharePoint Server 2007 was Lock bound on the database tier. This means that
increasing the processing power available to the database servers enables
SharePoint Server 2010 to achieve better throughput than would be possible with the
same hardware using Office SharePoint Server 2007. This is caused by the locking
mechanisms in the database in Office SharePoint Server 2007 which are unaffected
by improved hardware so that we were unable to push the database servers CPU
Utilization past 80%.
As a result of these findings outlined earlier in this section, on Office SharePoint
Server 2007 the maximum throughput possible was achieved in a 5x0x1 topology
whereas in SharePoint Server 2010 the maximum throughput possible with the same
workload was achieved in a 7x0x1 topology, and yielded a 25% increased total RPS.
The following graph shows the throughput without scaling out Web servers.
The following graph shows the throughput when Web servers were at maximum scale
out.
171

172

Departmental collaboration environment
technical case study (SharePoint Server
2010) (em ingls)
This document describes a specific deployment of Microsoft SharePoint Server 2010. It
and configuration
The workload that includes the number, and types, of users or clients, and
environment usage characteristics
Technical case study farm dataset that includes database contents and Search
indexes
Health and performance data that is specific to the environment
In this article:
Specifications
Workload
Dataset
Server 2010
Use this document to compare with your planned workload and usage characteristics. If
173
Specifications, which include hardware, topology and configuration
Dataset that includes database sizes
The
SharePoint Server 2010 environment described in this document is a production
environment at a large, geographically distributed company. Employees use this
environment to track projects, collaborate on documents, and share information within
their department. This environment is also used for internal testing, and is frequently
upgraded to the latest SharePoint Server pre-release versions as they become available.
The information that is provided in this document reflects the departmental collaboration
environment on a typical day.
Specifications
configuration of the case-study environment.
Hardware
environment.
174

Observao:
management process, see Viso geral do gerenciamento da capacidade e

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 2 2
Network adapter speed 1 Gigabit 1 Gigabit
Authentication Windows NTLM Windows NTLM
Load balancer type Hardware load balancing Hardware load
balancing
Software version SharePoint Server 2010 (pre-
release version)
SharePoint
Server 2010
(pre-release
version)
Services running locally Search Query WFE3 No
services
175
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
Network adapter speed 1 Gigabit 1 Gigabit
Authentication Windows NTLM Windows NTLM
Load balancer type Hardware load balancing Hardware load
balancing
Software version SharePoint Server 2010 (pre-
release version)
SharePoint
Server 2010
(pre-release
version)
Services running locally APP1 Central Administration and
all applications except for Office
Web Applications
APP2 All applications (including
Office Web Applications)
APP3 Office Web Applications
Search Crawler

Database Servers
176
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
bit
Windows
Server 2008
SP1, 64 bit
Windows
Server
2008
SP1, 64
bit
Storage and geometry 5x146GB 15K SAS + SAN
Disk 1: OS (2 disk RAID 10)
Disk 2: Swap (2 disk RAID 10)
Disk 3: Direct Attached Storage
(16 disk RAID 10, Temp DB
data) SAS 146 GB 15K
Disk 4: Direct Attached Storage
(16 disk RAID 10, Temp DB
data) SAS 146 GB 15K
Disk 5-15: SAN using fiber
connection. When possible, one
database per two disks.
Separating logs and data
between LUNs. 15K drives.
6x450GB 15K
SAS
Directly
attached
14x146GB
15K SAS
Disk 1: Usage
logs and OS
Disk 2: Usage
data
2x136GB
15K SAS
(RAID 0)
6x60GB
SSD,
SATA
(RAID 5)
Disk 1:
OS
Disk 2:
Swap
and
BLOB
Cache
Disk 3:
Logs and
Temp
directory.
Solid
state
drives. 6-
60GB
Solid
state
drives
(RAID 5)
Number of network adapters 2 2 2
Network adapter speed 1 Gigabit 1 Gigabit 1 Gigabit
Authentication Windows NTLM Windows
NTLM
Windows
NTLM
177
Database DB1 Default Instance DB2 DB3
Software version SQL Server 2008 SQL Server
2008
SQL
Server
2008 R2

Topology
178

Configuration
179
The following table enumerates settings that were made that affect performance or

Setting Value Notes
Site collection:
Object Caching (On |
Off)
Anonymous Cache
Profile (select)
Anonymous Cache
Profile (select)
Object Cache (Off | n
MB)
Cross List Query Cache
Changes (Every Time |
Every n seconds)
On
Disabled
Disabled
On 100GB
60 seconds
Enabling the output cache improves server
efficiency by reducing calls to the database for
data that is frequently requested.
Site collection cache
profile (select)
Intranet
(Collaboration
Site)
Allow writers to view cached content" is
checked, bypassing the ordinary behavior of not
letting people with edit permissions to have
their pages cached.
Object Cache (Off | n
MB)
On 500 MB The default is 100 MB. Increasing this setting
enables additional data to be stored in the front-
end Web server memory.
Usage Service:
Trace Log days to
store log files (default:
14 days)
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
Threshold:
Microsoft SharePoint
Foundation Database
configure
to 1 second
1 second The default is 5 seconds. Lowering this setting
can save bandwidth and CPU on the database
server.
Database Server
Default Instance:
Max degree of
parallelism
1 The default is 0. To ensure optimal
performance, we strongly recommend that you
set max degree of parallelism to 1 for database
servers that host SharePoint Server 2010
databases. For more information about how to
set max degree of parallelism, see max degree
of parallelism Option
(http://go.microsoft.com/fwlink/?LinkId=189030).

180
Workload

Total number of unique users per day 9186
Maximum concurrent users 322


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

181
BLOB size 1.68 TB
Total number of databases 36
Search index size (number of items) 4.6 million

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

Metric Value
Failure Rate 0.0005%
82.5%

The following charts show the average CPU utilization and latency for this environment:
182
183
within that response time, and therefore, 5% of the requests experience slower response
times.
Database Counters

Metric Value
Disk Queue Length: Reads 1.38
SQL Locks: Average Wait Time 294.56 ms
SQL Locks: Lock Wait Time 867.53 ms
SQL Locks: Deadlocks Per Second 1.87
SQL Latches: Average Wait Time 5.10 ms
SQL Cache Hit Ratio 99.77%

184

Divisional portal environment lab study
This document provides guidance on performance and capacity planning for a divisional
portal based on Microsoft SharePoint Server 2010. It includes the following:
Test environment specifications, such as hardware, farm topology and configuration
Test farm dataset
Test data and recommendations for how to determine the hardware, topology and
configuration that you must have to deploy a similar environment, and how to
optimize your environment for appropriate capacity and performance characteristics
In this article:
Glossary
Overview
Specifications
Results and analysis
This document outlines the test methodology and results to provide guidance for capacity
planning of a typical divisional portal. A divisional portal is a SharePoint Server 2010
deployment where teams mainly do collaborative activities and some content publishing.
This document assumes a "division" to be an organization inside an enterprise with 1,000
to 10,000 employees.
Different scenarios will have different requirements. Therefore, it is important to
supplement this guidance with additional testing on your own hardware and in your own
environment. If your planned design and workload resembles the environment described
in this document, you can use this document to draw conclusions about scaling your
environment up and out.
When you read this document, you will understand how to do the following:
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).
185
capacity management in SharePoint Server 2010. The following documentation will help
Server 2010
Also, we encourage you to read the following:
Glossary
There are some specialized terms that you will encounter in this document. Here are
some key terms and their definitions.
RPS: Requests per second. The number of requests received by a farm or server in
one second. This is a common measurement of server and farm load.
Note that requests differ from page loads; each page contains several components,
each of which creates one or more requests when the page is loaded. Therefore, one
page load creates several requests. Typically, authentication checks and events
using insignificant resources are not counted in RPS measurements.
Green Zone: This is the state at which the server can maintain the following set of
criteria:
The server-side latency for at least 75% of the requests is less than .5 second.
All servers have a CPU Utilization of less than 50%.
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%.
186
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.
187
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
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
Database
Server
Processor(s) 2px4c@2.33GHz 2px4c@2.33GHz 4px4c@
3.19GHz
RAM 8 GB 8 GB 32 GB
Number of network
adapters
2 2 1
Network adapter speed 1 Gigabit 1 gigabit 1 Gigabit
Load balancer type F5 - Hardware load balancer Not applicable Not
applicable
ULS Logging level Medium Medium Not
applicable

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

Web Server Application
Server
Database
Server
Operating System Windows Server 2008 R2 x64 Windows
Server 2003
x64
Windows
Server
2008 x64
188
Server
Database
Server
Software version SharePoint Server 2010 and
Office Web Applications, pre-
release versions
SharePoint
Server 2010
and Office
Web
Applications,
pre-release
versions
SQL
Server
2008 R2
CTP3
Authentication Windows NTLM Windows
NTLM
Windows
NTLM
Load balancer type F5 - Hardware load balancer Not applicable Not
applicable
ULS Logging level Medium Medium Not
applicable
Anti-Virus Settings Disabled Disabled Disabled
Services running locally Microsoft SharePoint
Foundation Incoming E-Mail
Foundation Web Application
Foundation Workflow Timer
Service
Search Query and Site Settings
Service
Central
Administration
Excel
Services
Managed
Metadata
Web Service
Microsoft
SharePoint
Foundation
Incoming E-
Mail
Microsoft
SharePoint
Foundation
Web
Application
Microsoft
SharePoint
Foundation
Workflow
Timer Service
PowerPoint
Services
Search Query
and Site
Settings
Service
Not
applicable
189
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.
190

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

Content database 1 2 3 4 5
Content database size 36 GB 135 GB 175
GB
1.2
terabytes
75
GB
Number of sites 44 74 9 9 222
Number of webs 1544 2308 2242 2041 1178
RAID configuration 0 0 0 0 0
Number of spindles for
MDF
1 1 5 3 1
Number of spindles for
LDF
1 1 1 1 1

Transactional mix
The following are important notes about the transactional mix:
There are no My Sites provisioned on the divisional portal. Also, the User Profile
service, which supports My Sites, is not running on the farm. The transactional mix
does not include any My Site page/web service hits or traffic related to Outlook Social
Connector.
The test mix does not include any traffic generated by co-authoring on documents.
The test mix does not include traffic from Search Crawl. However this was factored
into our tests by modifying the Green-zone definition to be 40 percent SQL Server
CPU usage instead of the standard 50 percent to allow for 10 percent for the search
crawl. Similarly, we used 80 percent SQL Server CPU as the criteria for max RPS.
The following table describes the overall transaction mix. The percentages total 100.

Feature or Service Operation Read/write Percentage
of mix
ECM Get static files r 8.93%
View home page r 1.52%
Microsoft InfoPath Display/Edit upsize list item and
new forms
r 0.32%
Download file by using "Save
as"
r 1.39%
Microsoft OneNote 2010 Open Microsoft Office OneNote
2007 file
r 13.04%
Search Search through r 4.11%
192
of mix
OSSSearch.aspx or
SearchCenter
Workflow Start autostart workflow w 0.35%
Microsoft Visio Render Visio file in PNG/XAML r 0.90%
Office Web Applications -
PowerPoint
Render Microsoft PowerPoint,
scroll to 6 slides
r 0.05%
Office Web Applications -
Word
Render and scroll Microsoft
Word doc in PNG/Silverlight
r 0.24%
Foundation
List Check out and then
check in an item
w 0.83%
List - Get list r 0.83%
List - Outlook sync r 1.66%
List - Get list item changes r 2.49%
List - Update list items and
adding new items
w 4.34%
Get view and view collection r 0.22%
Get webs r 1.21%
Browse to Access denied page r 0.07%
View Browse to list feeds r 0.62%
Browse to viewlists r 0.03%
Browse to default.aspx (home
page)
r 1.70%
Browse to Upload doc to doc lib w 0.05%
Browse to List/Library's default
view
r 7.16%
Delete doc in doclib using DAV w 0.83%
Get doc from doclib using DAV r 6.44%
Lock and Unlock a doc in doclib
using DAV
w 3.32%
Propfind list by using DAV r 4.16%
Propfind site by using DAV r 4.16%
List document by using FPSE r 0.91%
193
of mix
Upload doc by using FPSE w 0.91%
Browse to all site content page r 0.03%
View RSS feeds of lists or wikis r 2.03%
Servios do Excel Render small/large Excel files r 1.56%
Workspaces WXP - Cobalt internal protocol r 23.00%
Full file upload using WXP w 0.57%

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

User Load 50 75 100 125
RPS 74.958 89.001 95.79 101.37
Latency 0.42 0.66 0.81 0.81
Web server CPU 79.6 80.1 89.9 86
194
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.
195

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

User Load 25 50 75 100 125 150
196
User Load 25 50 75 100 125 150
RPS 53.38 91.8 112.2 123.25 123.25 124.1
Latency 34.2 56 71.7 81.5 84.5 84.9
Web server CPU 23.2 33.8 34.4 32 30.9 35.8
Application server CPU 12.9 19.7 24.1 25.2 23.8 40.9
Database server CPU 0.22 0.23 0.27 0.32 0.35 0.42
75th Percentile (sec) 0.54 0.52 0.68 0.71 0.74 0.88

The following chart shows RPS and latency results for a 1x1x1 configuration.
The following chart shows performance counter data in a 1x1x1 configuration.
197

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.
being 0.37 sec, and Web server CPU hovering around 47 % utilization. This indicates
that this farm can healthily deliver an RPS of around 191. "Max zone" RPS delivered
by this farm was 291 with latencies of 0.5 sec and Web server CPU hovering around
75%.
Because the Web server CPU was the bottleneck in this iteration, we relived the
bottleneck by adding another Web server for the next iteration.

User Load 40 80 115 150 175 200
198
User Load 40 80 115 150 175 200
RPS 109 190 251 287 304 318
Latency 0.32 0.37 0.42 0.49 0.54 0.59
Web server CPU 27.5 47.3 61.5 66.9 73.8 76.2
Application server CPU 17.6 29.7 34.7 38 45 45.9
Database server CPU 21.2 36.1 43.7 48.5 52.8 56.2

The following chart shows RPS and latency results for a 2x1x1 configuration.
The following chart shows performance counter data in a 2x1x1 configuration.
199

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.
being 0.41 sec, and database server CPU hovering around 44% utilization. This
indicates that this farm can healthily deliver an RPS of around 242. "Max zone" RPS
delivered by this farm was 318 with latencies of 0.5 sec and database server CPU
hovering around 75%.
This was the last configuration in the series.

User Load 66 103 141 17 202 226
RPS 193.8 218.5 269.8 275.5 318.25 310
200
User Load 66 103 141 17 202 226
Latency 0.3 0.41 0.47 0.58 0.54 0.78
Web server CPU 33 38.3 45.8 43.3 51 42.5
Application server CPU 28 32.6 46.5 40 45.1 43.7
Database server CPU 41.6 44.2 52.6 48 61.8 75

The following chart shows RPS and latency results in a 3x1x1 configuration.
The following chart shows performance counter data for a 3x1x1 configuration.
201

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.
202
The following chart shows a summary of latency at different configurations.
203

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

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
Incremental
Crawl
No
Resource
Governor
10%
Resource
Governor
RPS 318 N/A 276 294.5
Percent RPS difference
from baseline
0% N/A 83% 88%
Database server CPU (%) 83.40 8.00 86.60 87.3
SA Database server CPU 3.16 2.13 3.88 4.2
205
Baseline 3x1x1 Only
Incremental
Crawl
No
Resource
Governor
10%
Resource
Governor
(%)
Web server CPU (%) 53.40 0.30 47.00 46.5
Application server CPU
(%)
22.10 28.60 48.00 41.3
Crawl Web server CPU (%) 0.50 16.50 15.00 12.1

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

206

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

208

Social environment technical case study
This document describes a specific deployment of Microsoft SharePoint Server 2010. It
and configuration
The workload that includes the number, and types, of users or clients, and
environment usage characteristics
Technical case study farm dataset that includes database contents and Search
indexes
In this article:
Specifications
Workload
Dataset
Server 2010
Use this document to compare with your planned workload and usage characteristics. If
209
Specifications, which include hardware, topology and configuration
Dataset that includes database sizes
Health and performance data specific to the environment
The
SharePoint Server 2010 environment described in this document is a production
environment at a large, geographically distributed company. This environment hosts
SharePoint My Sites that connect employees with one another and the information that
they need. Employees use this environment to present personal information such as
areas of expertise, past projects, and colleagues to the wider organization. The
environment also hosts personal sites and documents for viewing, editing, and
collaboration. My Sites are integrated with Active Directory Domain Services (AD DS) to
provide a central location that can be accessed from the browser and various client
applications.
The information that is provided in this document reflects the enterprise social
environment on a typical day.
Specifications
configuration of the case-study environment.
Hardware
environment.
210

Observao:
management process, see Viso geral do gerenciamento da capacidade e

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
RAM 16 GB
Operating system Windows Server 2008, 64 bit
version)
Microsoft SharePoint Foundation Incoming
E-Mail
Application
Microsoft SharePoint Foundation Workflow
Timer Service
Services consumed from a federated
services farm
User Profile Service
211
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
RAM 16 GB
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.

RAM 64 GB
Storage and geometry (1.25 TB * 6)
212
Disk 1-4: SQL Data
Disk 5: Logs
Disk 6: TempDB
Network adapter speed 1 @ 100MB, 1 @ 1GB

Topology
213

Configuration
214
The following table enumerates settings that were changed that affect performance or

Setting Value Notes
Usage Service:
Trace Log days to store
log files (default: 14 days)
5 days The default is 14 days. Lowering this setting can save
disk space on the server where the log files are
stored.
Foundation Database
configure
to 1 second
1
second
The default is 5 seconds. Lowering this setting can
save bandwidth and CPU on the database server.
Database Server
Default Instance
Max degree of parallelism
SharePoint Server 2010 databases. For more
information about how to set max degree of
parallelism, see max degree of parallelism

Workload

Total number of unique users per day 69,814
Maximum concurrent users 1186


Total
215
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
Search indexes.

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

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

216
Metric Value
Failure Rate 0.39%
17.42%

The following charts show average CPU utilization and latency for this environment.
217
within that response time, and therefore, 5% of the requests experience slower response
times.
Database Counters

218
Metric Value
Read/Write Ratio (IO Per Database) 99.854 : 0.146
Disk Queue Length: Reads 30.518
SQL Locks: Average Wait Time 125 ms
SQL Locks: Lock Wait Time 33.322 ms
SQL Locks: Deadlocks Per Second 0
SQL Latches: Average Wait Time 0 ms
SQL Cache Hit Ratio 20.1%

219

Recomendaes e resultados de testes
de desempenho e capacidade
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 conceitos-
chave 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
220
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
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
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 e especlfico do SharePoint Server 2010,
embora os limites abordados tambem se apliquem ao
Microsoft SharePoint Foundation 2010. Baixe o white
paper
(DesigningLargeListsMaximizingListPerformance.docx).
Repositrios de documentos de
larga escala
Apresenta diretrizes sobre o desempenho de
repositrios de documentos de larga escala em relao
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
221
Assunto Descrio
capacidade para diferentes implantaes de Pesquisa
no SharePoint Server 2010, incluindo farms pequenos,
medios 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
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 Conteudo da
Web
Apresenta diretrizes sobre o planejamento de
desempenho e capacidade para uma soluo de
Gerenciamento de Conteudo da Web. Visualize o
artigo em Estimar os requisitos de desempenho e
capacidade do Gerenciamento de conteudo da Web no
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
paper (WorkflowCapacityPlanningDoc.docx).

222

Estimate performance and capacity
requirements for Access Services in
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
In this article:
Test farm characteristics
Test results
Recommendations
Troubleshooting
This section describes the dataset that was used during the testing; the workloads that
were placed on the product during performance gathering; the hardware that was used
during the testing; and the topology for how that hardware was deployed.
Dataset
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.
223
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
224
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.
225
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

226

Recommended results
The following graph shows the results for recommended sustainable throughput.
227
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.
228
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.
229
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.
230
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.
231
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.
232

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

Overall 1x1 1x2 1x3 1x4 2x1 2x2 2x4
Req/Sec 14.96 28.76 45.22 48.01 14.85 28.77 58.02
Tests/Sec 2.00 3.81 6.11 6.42 1.99 3.81 7.80
Average Latency 235.80 241.21 247.21 244.87 240.70 242.26 250.94

Average front-
end Web
server tier
1x1 1x2 1x3 1x4 2x1 2x2 2x4
%CPU 13.82 24.40 41.02 43.62 6.31 12.48 26.18
233
Average front-
end Web
server tier
1x1 1x2 1x3 1x4 2x1 2x2 2x4
Max w3wp
Private Bytes
9.46E+08 2.31E+08 1.49E+09 1.55E+09 8.43E+08 9.84E+08 1.19E+09

Average
application
server
(Access Data
Services) tier
1x1 1x2 1x3 1x4 2x1 2x2 2x4
%CPU 46.30 42.83 43.74 34.51 46.56 43.45 42.13
%CPU w3wp 33.61 31.15 30.71 24.29 33.48 31.64 29.72
%CPU RS 8.62 7.94 9.17 6.84 9.03 8.02 8.71
Max total
Private Bytes
4.80E+09 4.89E+09 4.91E+09 4.62E+09 5.32E+09 4.82E+09 5.07E+09
Max w3wp
Private Bytes
2.10E+09 1.97E+09 2.04E+09 1.86E+09 2.00E+09 2.00E+09 2.07E+09
Max RS
Private Bytes
1.78E+09 2.00E+09 1.97E+09 1.86E+09 2.30E+09 1.89E+09 2.02E+09

Database
server (SQL
Server) tier
(single
computer)
1x1 1x2 1x3 1x4 2x1 2x2 2x4
%CPU 12.07 18.64 32.53 36.05 9.89 21.42 47.46
Avg Private
Bytes
2.96E+10 3.22E+10 3.25E+10 3.25E+10 2.89E+10 3.22E+10 3.25E+10
Max Private
Bytes
3.26E+10 3.25E+10 3.25E+10 3.25E+10 3.25E+10 3.25E+10 3.25E+10
Avg Disk
Queue Length
Total
0.74 1.18 1.64 1.77 0.67 1.24 2.18

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

234
Overall 1x1 1x2 1x3 1x4 2x1 2x2 2x4
Req/Sec 14.96 28.76 45.22 48.01 14.85 28.77 58.02
Tests/Sec 2.00 3.81 6.11 6.42 1.99 3.81 7.80
Average Latency 235.80 241.21 247.21 244.87 240.70 242.26 250.94

Average front-
end Web
server tier
1x1 1x2 1x3 1x4 2x1 2x2 2x4
%CPU 13.82 24.40 41.02 43.62 6.31 12.48 26.18
Max w3wp
Private Bytes
9.46E+08 2.31E+08 1.49E+09 1.55E+09 8.43E+08 9.84E+08 1.19E+09

Average
application
server
(Access Data
Services) tier
1x1 1x2 1x3 1x4 2x1 2x2 2x4
%CPU 46.30 42.83 43.74 34.51 46.56 43.45 42.13
%CPU w3wp 33.61 31.15 30.71 24.29 33.48 31.64 29.72
%CPU RS 8.62 7.94 9.17 6.84 9.03 8.02 8.71
Max total
Private Bytes
4.80E+09 4.89E+09 4.91E+09 4.62E+09 5.32E+09 4.82E+09 5.07E+09
Max w3wp
Private Bytes
2.10E+09 1.97E+09 2.04E+09 1.86E+09 2.00E+09 2.00E+09 2.07E+09
Max RS
Private Bytes
1.78E+09 2.00E+09 1.97E+09 1.86E+09 2.30E+09 1.89E+09 2.02E+09

Database
server (SQL
Server) tier
(single
computer)
1x1 1x2 1x3 1x4 2x1 2x2 2x4
%CPU 12.07 18.64 32.53 36.05 9.89 21.42 47.46
Avg Private
Bytes
2.96E+10 3.22E+10 3.25E+10 3.25E+10 2.89E+10 3.22E+10 3.25E+10
235
Database
server (SQL
Server) tier
(single
computer)
1x1 1x2 1x3 1x4 2x1 2x2 2x4
Max Private
Bytes
3.26E+10 3.25E+10 3.25E+10 3.25E+10 3.25E+10 3.25E+10 3.25E+10
Avg Disk
Queue Length
Total
0.74 1.18 1.64 1.77 0.67 1.24 2.18

Recommendations
This section provides general performance and capacity recommendations.
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.
236
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
237
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.

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
238
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) Watch for too
much disk writing
because of
logging.
% Processor Time Process(ReportingServicesService) Reports are
handled by SQL
Server Reporting
Services. If too
many reports are
being run, or if
the reports are
very complex,
then the CPU
and Private
Bytes for this
process will be
high.
Private Bytes Process(w3wp) Servios do
Access caches
the results of
queries in
memory, until the
users session
expires (the time-
out for which is
configurable). If
a large amount
of data is being
processed
through the
Access Data
Services,
memory
consumption for
the Access Data
Services w3wp
will increase.
Private Bytes Process(ReportingSrevicesService) Reports are
handled by SQL
239
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

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
240
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
depends on a large
amount of
processing in the
application server
tier. If a 1x1, 1x2, or
1x3 configuration is
used, the first
bottleneck
encountered will
likely be the CPU on
the Access Data
Services servers.
Increase the number of CPUs or cores, or
both, in the existing Access Data Services
computers. Add additional Access Data
Services computers if possible.
Web server CPU
usage
When a Web server
is overloaded with
user requests,
average CPU usage
will approach 100
percent. This
prevents the Web
server from
responding to
requests quickly and
can cause timeouts
and error messages
on client computers.
This issue can be resolved in one of two ways.
You can add more Web servers to the farm to
distribute user load, or you can scale up the
Web server or servers by adding higher-speed
processors.
Database server
disk I/O
When the number of
I/O requests to a
Distributing data files across multiple physical
drives allows for parallel I/O. The blog
241
hard disk exceeds
the disks I/O
capacity, the
requests will be
queued. As a result,
the time to complete
each request
increases.
SharePoint Disk Allocation and Disk I/O
(http://go.microsoft.com/fwlink/?LinkId=129557)
contains useful information about resolving
disk I/O issues.
Reporting Services
CPU utilization
The Reporting
Services process is
using a large share
of the CPU
resources.
Dedicate a computer to Reporting Services,
taking load from the application server (Access
Data Services) tier (connected mode) or the
front-end Web server tier (local mode).

242

requirements for Excel Services in
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 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).
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:
243

Workbook Characteristics Small Large Very
Large
Sheets 1-3 1-5 1-20
Columns 10-20 10-500 10-
1,000
Rows 10-40 10-10,000 100-
30,000
Calculated Cells 0-20% 0-70% 0-70%
Number of Formats 1-10 1-15 1-20
Tables 0-1 0-2 0-5
Charts 0-1 0-4 0-4
Workbook Uses External Data 0% 20% 50%
Workbook Uses a Pivot Table 0% 3% 3%
Workbook Uses Conditional
Formats
0% 10% 20%

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.
244
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
245
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.
246

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

247

Recommended Results
The following chart shows our results for recommended sustainable throughput.
248
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
249
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.
250
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.
251
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 1x3 2x1 2x2 2x3 3x1 3x2 3x3
252
Client Successful
RPS
30.56 34.55 31.67 26.03 45.94 68.37 20.71 38.82 63.70
Client Response
Time (sec.)
0.22 0.18 0.19 0.16 0.19 0.20 0.15 0.15 0.17
TPS 1.58 1.77 1.61 1.40 2.38 3.54 1.08 2.03 3.25

Web Front-end Tier 1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3
% CPU (average
over all Web Front-
end computers
33.73 37.64 33.84 14.61 23.95 36.90 7.54 13.12 21.75

Servios
de
Clculo
do Excel
Tier
1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3
% CPU
(average
over all
Servios
de
Clculo
do Excel
computer
s)
30.56 34.55 31.67 26.03 45.94 68.37 20.71 38.82 63.70
Peak
Private
Bytes
(maximu
m over all
Servios
de
Clculo
do Excel
computer
s)
5.94E+0
9
5.82E+0
9
5.79E+0
9
5.87E+0
9
6.09E+0
9
5.92E+0
9
5.79E+0
9
5.91E+0
9
5.85E+0
9

Maximum Results
The following tables show the maximum results of our tests.
253

Client Successful
RPS
37.85 56.70 51.17 35.19 62.04 81.31 27.79 51.62 82.58
Client Response
Time (sec.)
0.19 0.28 0.23 0.16 0.20 0.25 0.16 0.16 0.22
TPS 1.92 2.96 2.59 1.81 3.21 4.60 1.41 2.72 4.30

Web Front-end Tier 1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3
% CPU (average
over all Web Front-
end computers
41.08 67.78 58.59 19.44 34.11 45.97 10.19 17.79 28.69

Servios
de
Clculo
do Excel
Tier
1x1 1x2 1x3 2x1 2x2 2x3 3x1 3x2 3x3
% CPU
(average
over all
Servios
de
Clculo
do Excel
computer
s)
24.99 1844 10.96 23.57 20.56 17.77 18.97 17.04 18.10
Peak
Private
Bytes
(maximu
m over
all
Servios
de
Clculo
do Excel
computer
s)
5.91E+
09
5.85E+
09
5.91E+
09
5.88E+
09
5.99E+
09
6.502E+
09
5.94E+
09
5.94E+
09
6.04E+
09

254
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.
255
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.
256
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.
257
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

Servios de Clculo do Excel
Memory
Servios do Excel holds each
workbook in memory throughout
the user's session. A large number
Scale Up with
more memory in
the Servios de
258
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 When a Web server is overloaded
with user requests, average CPU
usage will approach 100 percent.
This prevents the Web server from
responding to requests quickly and
can cause timeouts and error
messages on client computers.
This issue can be
resolved in one
of two ways. You
can add Web
servers to the
farm to distribute
user load, or you
can scale up the
Web server or
servers by
adding faster
processors.

Performance monitoring
To help you determine when you have to scale up or scale out the system, use
performance counters to monitor the health of the system. Use the information in the
following tables to determine which performance counters to monitor, and to which
process the performance counters should be applied.
Front-end Web server
The following table shows performance counters and processes to monitor for front-end
Web servers in your farm.

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

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

261

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:
L importante estar ciente de que os numeros especlficos relativos a capacidade e ao
desempenho apresentados neste artigo sero diferentes daqueles usados em ambientes
reais. Os numeros aqui apresentados tm por objetivo fornecer um ponto de partida para
o design de um ambiente dimensionado adequadamente. Depois de concluldo 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
262
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 series por 12
colunas
Grfico Dois Grfico de barras empilhadas 37 series por 3
colunas
Grade Grade analltica 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
um dos dois filtros cinco vezes, com 15
segundos de pausa entre as interaes.
1. Renderize o painel.
2. Selecione um dos dois filtros, selecione
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
expanda e recolha-o cinco vezes com uma
pausa de 15 segundos entre interaes.
1. Renderize o painel.
2. Selecione um membro aleatrio em um
263
Nome do teste Descrio do teste
grfico e expanda-o.
3. Selecione outro membro aleatrio no
grfico e recolha-o.
grfico e expanda-o.
grfico e recolha-o.

Renderize um painel, selecione uma grade
e expanda e recolha-a cinco vezes com
uma pausa de 15 segundos entre
interaes.
1. Renderize o painel. Selecione um
membro aleatrio em uma grade e
expanda o membro.
2. Selecione outro membro aleatrio na
grade e expanda-o.
grade e recolha-o.
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
um dos dois filtros cinco vezes.
80%
Renderize um painel, selecione um grfico e
expanda e recolha-o cinco vezes.
10%
Renderize um painel, selecione uma grade
e expanda e recolha-a cinco vezes.
10%

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.
264
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
de
aplicativos
Computador
executando
o SQL
Server
Computador
executando
o Analysis
Services
Processador(es) 2px4c a 2.66 GHz 2px4c a
2.66 GHz
2px4c a
2.66 GHz
4px6c a 2.4
GHz
RAM 16 GB 32 GB 16 GB 64 GB
Sistema operacional Windows Server 2008 R2
Enterprise
Windows
Server
2008 R2
Enterprise
Windows
Server
2008 R2
Enterprise
Windows
Server
2008 R2
Enterprise
NIC 1x1 gigabit 1x1
gigabit
1x1 gigabit 1x1 gigabit
Autenticao NTLM e Kerberos NTLM e
Kerberos
NTLM e
Kerberos
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
265
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 e qualquer filtro, scorecard, grade
ou grfico renderizado pelo Servios PerformancePoint ou
qualquer solicitao da Web para a URL do servio de
renderizao que contem o RenderWebPartContent ou o
CreateReportHtml. Para saber mais sobre o
CreateReportHtml e o RenderWebPartContent, consulte
a especificao do protocolo RenderingService do
PerformancePoint Services
Os logs do IIS podem ser analisados para essas
solicitaes a fim de ajudar a planejar a capacidade do
Servios PerformancePoint. Alem disso, o uso dessa
medida fornece um numero que e muito menos dependente
da composio do painel. Um painel com duas exibies
pode ser comparado a um painel com dez exibies.
266

Dica:
Quando voc est usando uma fonte de dados configurada para usar a autenticao da
Conta de Servio sem Superviso, a regra para o lndice de servidores dedicados e 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 lndice de servidores dedicados e 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
(solicitaes
por segundo)
EPS
(exibies
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

267
Topologia (WFE x APP x SQL) Usurios SPS
(solicitaes
por segundo)
EPS
(exibies
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 360
Media 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 medio de resposta
(seg)
0,12 0,15 0,38 2

268
Autenticao por usurio

Media 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 medio de resposta
(seg)
0,28 0,45 0,81 2

269
Resultados do farm 3C (1x1x1)
Autenticao da Conta de Servio sem Superviso

SPS 36 87 124 127
Exibies por segundo 21 52 74 75
Tempo medio de resposta (seg) 0,12 0,18 0,65 2
Media de CPU WFE 11% 28% 43% 46%
Mximo de bytes privados WFE
do processo de trabalho W3WP
do IIS (Servios de Informaes
da Internet) do SharePoint
Server.
0,7 GB 1,4 GB 2
GB
2,4
GB
Media de CPU APP 25% 62% 94% 95%
Mximo de bytes privados APP
do W3WP do Servios
5,9 GB 10,8 GB 14,1
GB
14,6
GB
270
PerformancePoint

Autenticao por usurio

SPS 17 39 52 56
Tempo medio de resposta (seg) 0,28 0,48 0,91 2
Mximo de bytes privados WFE
do W3WP do SharePoint
Server
0,78 GB 1,3 GB 1,6
GB
1,9
GB
271
Mximo de bytes privados APP
do W3WP do Servios
PerformancePoint
19 GB 20,1 GB 20,5
GB
20,9
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.

272
4C (1x2x1) 5C (1x3x1) 6C
(2x3x1)
7C
(2x4x1)
Contagem de usurios 840 950 1.250 1.500
SPS 196 216 292 346
Mximo de bytes privados
WFE do W3WP do
SharePoint Server
2,1 GB 1,7 GB 2,1
GB
2 GB
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
(1x3x1)
6C
(1x4x1)
RPS 56 67 74 74
WFE do W3WP do
SharePoint Server
2,1 GB 1,9 GB 1,9
GB
1,5
GB
APP do W3WP do Servios
PerformancePoint
20 GB 20 GB 20 GB 20 GB
273
3C (1x1x1) 4C (1x2x1) 5C
(1x3x1)
6C
(1x4x1)
CPU do Analysis Services 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
274
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 e baixo e outros servios esto
em execuo no servidor de aplicativos.
Adicione mais memria flsica ou limite a
memria do cache ASP.NET.
aplicativos e 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.
aplicativos e 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
275
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 0
Memria \ MemoryHeapType 2

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.

276
Possvel
afunilamento
Causa e o que
monitorar
Soluo
Desempenho
do heap de
memria do
Analysis
Services
Por padro, o
Analysis
Services usa
seu prprio heap
de memria em
vez do heap do
Windows, o que
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 e
baixa.
Altere o Analysis Services para usar o heap do
Windows. Consulte a seo "Analysis Services"
anteriormente neste artigo 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.
Threads de
processament
o e consulta
do Analysis
Services
Por padro, o
Analysis
Services limita o
numero de
threads de
consulta e
processamento
para consultas.
Consultas de
execuo longa
e altas cargas
de usurio
podem usar
todos os threads
Aumente o numero de threads disponlveis 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
16) para obter instrues.
277
Possvel
afunilamento
Causa e o que
monitorar
Soluo
disponlveis.
Monitore os
threads ociosos
e contadores de
desempenho da
fila de trabalhos
na categoria
MSAS
2008:Threads.
Memria do
servidor de
aplicativos
O Servios
PerformancePoi
nt armazena em
cache o Analysis
Services e
outros
resultados de
consulta da
fonte de dados
em memria
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.
Adicione memria ou aumente os limites padro da
memria cache do ASP.NET. Consulte a seo
Consumo de memria anteriormente neste documento
para obter informaes adicionais. Alem disso, consulte
as configuraes de elementos do cache do ASP.NET
16) e a postagem do blog de Thomas Marquardt sobre o
histrico dos limites de memria cache do ASP.NET
16).
278
Possvel
afunilamento
Causa e o que
monitorar
Soluo
Configuraes
de limitao
de WCF
O Servios
PerformancePoi
nt e
implementado
como um servio
WCF. O WCF
limita o numero
mximo de
chamadas
simultneas
como um
comportamento
de limitao do
servio. Embora
consultas de
execuo longa
possam atingir
esse
afunilamento,
esse e 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 numero
mximo atual de
chamadas
simultneas.
Se necessrio, altere o comportamento de limitao do
WCF (Windows Communication Foundation. Consulte os
comportamentos de limitao do servio WCF
16) e a postagem do blog de Wenlong Dong sobre
limitao de solicitaes do WCF e escalabilidade do
servidor
16).

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
279
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 \
Cortes de API de Cache
Pool de
aplicativos do
Servios
PerformanceP
oint
Se o valor for maior do que zero, leia "Consumo
de memria".
MSAS 2008:Threads /
threads ociosos do pool
de consultas
N/A 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
cid=0x416).
MSAS 2008:Threads /
threads ociosos do pool
de processamento
Analysis Services
cid=0x416).
MSAS 2008:Threads /
tamanho da fila de
trabalhos do pool de
processamento
Analysis Services
cid=0x416).
WCF
CountersServiceModelS
ervice
3.0.0.0(*)\Chamadas
pendentes
Instncia do
PerformanceP
oint Service
Se o valor for maior do que zero, consulte o
artigo sobre limitao de solicitaes de WCF e
escalabilidade do servidor
cid=0x416).

Consulte tambm
Outros recursos
280
Plan for PerformancePoint Services (SharePoint Server 2010)

281

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:
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:
282
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).
283
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
284
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
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
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
Network adapter speed 1 GB
Authentication NTLM
Load balancer type SharePoint Load Balancer
285
Application server Minimum requirement
Software version SharePoint Server 2010 (prerelease
version)
Incoming E-mail
Application
Workflow Timer Service
Web Analytics Data Processing Service

Database servers
The following table describes the configuration of each database server. Instances of
SQL Server were required for both the staging and reporting databases.

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.

Network adapter speed 1 GB
Authentication NTLM
286

Topology
The following diagram (Figure 2) shows the Web Analytics topology.
287
Figure 2. Web Analytics topology
288
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.

289
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.
290
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).
291
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.
292

Configuration 1S+R 1S1R 1S1R 2S1R 2S1R
Staging + Reporting Staging Reporting Staging Reporting
Total sum of percentage
of processor time for 8
processor computer
19 192 5.78 100 13.4
SQL Server buffer hit
ratio
99 100 100 100 100
% Disk time 7,142 535 5.28 59.3 98.2
Disk queue length 357 28.6 0.26 2.97 4.91

Other factors
Many other factors can affect the performance of various analytics components and can
affect the capacity planning. These factors primarily affect the performance of the Report
Extractor component because they can affect the size of the data aggregated each day.
The total size of the data in the reporting database also affects the performance of the
Reporting Extractor, although this is not significant because the data is partitioned daily.
Some of these other factors are as follows:
Number of unique queries each day.
Number of unique users each day.
Total number of unique assets clicked each day.
Existing data size in the reporting warehouse, based on the data retention in the
warehouse.
The overall effect of these factors is less significant than the total data volume and the
number of site entities. However, it is important to conduct your own capacity
management based on your planned workload and usage characteristics. For more
information about the capacity management process, see 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
Outros recursos
SharePoint 2010 Administration Toolkit (SharePoint Server 2010)
293

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:
Detalhes e abordagem do teste
Implantaes de Gerenciamento de Contedo da Web
O que otimizar
294
Resultados do teste e recomendaes
Sobre os autores
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
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
conteudo
2.63 GB
Quantidade de bancos de dados de
conteudo
1
Quantidade de conjuntos de sites 1
Quantidade de aplicativos Web 1
Quantidade de sites 50
295
Objeto Site de publicao
Numero 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 ate 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 nucleos qudruplos a 2.33 GHz
RAM 8 GB
Tamanho da unidade do SharePoint 300 GB
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 pre-
lanamento)
Servios em execuo no local Administrao Central
296
Servidor Web
Email de entrada do Microsoft SharePoint
Foundation
Aplicativo Web do Microsoft SharePoint
Foundation
Servio de Timer do Fluxo de Trabalho do

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 nucleos qudruplos a 3.19 GHz
RAM 16 GB
Armazenamento 15 discos de 300 GB a 15.000 RPM
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%.
297
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.
298
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.
299

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
300
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
301
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
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
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
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.
302
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.
303

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

304
Taxa
de
acertos
do
cache
de
sada
Medida 1x1 2x1 4x1
100%

RPS mxima
Utilizao da CPU
do SQL Server

3.463
0%

7.331
0%

11.032
0%

95%

RPS mxima
Utilizao da CPU
do SQL Server

2.137
5,93%

3.945
12,00%

5.937
21,80%

90%

RPS mxima
Utilizao da CPU
do SQL Server

1.518
7,12%

2.864
14,40%

4.518
28,00%

50%

RPS mxima
Utilizao da CPU
do SQL Server

459
9,86%

913
19,50%

1.596
42,00%

0%

RPS mxima
Utilizao da CPU
do SQL Server

172
9,53%

339
19,00%

638
36,30%

Concluses e recomendaes referentes ao efeito da habilitao do
cache de sada
305
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.
306
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
307
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
308
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
2010.
Concluses e recomendaes para caractersticas de expanso das
operaes de leitura e gravao
309
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.
310
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.
311
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.
312

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
313
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.
314
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.
315
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 60-
80% no decorrer de todos os testes, mesmo quando as gravaes por hora se
aproximaram a 500.
316
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.
317
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
318
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.
319
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% 98% 95% 90% 50% 0%
320
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%

321
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 3 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
322
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.
323
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 BD de uso
desativado
Diferena
324
BD de uso ativado BD de uso
desativado
Diferena
Cache de salda ativado 3.459 3.463 4
Cache de salda desativado 629 638 9

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.

325

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 results
Recommendations
Troubleshooting
The following sections describe the characteristics of the test farm:
Dataset
Workload
Hardware, settings, and topology
Dataset
To get benchmarks, most tests ran on a default Team Site on a single site collection in
the farm. The manual start tests started workflows by using a list that has 8,000 items.
Workload
Testing for this scenario helps develop estimates of how different farm configurations
respond to changes to the following variables:
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.
326
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
task, set to automatically start when an
item is created.
2. Create items in the list for five minutes.
number of workflows in progress.

Throughput for completing workflow tasks 1. Associate the included MOSS Approval
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.
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
327
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
Network adapter speed 1 gigabit 1 gigabit
Authentication NTLM NTLM
Software version 4747 SQL Server 2008
R1
Number of SQL Server instances 1 1
Load balancer type No load balancer No load balancer
ULS logging level Medium Medium

Workflow Capacity Planning Topology
328

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

Automatically starting workflows when items are created throughput
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.

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
331

Task completion throughput
throughput of completing workflow tasks. The task list that was used by autostart
workflows in the previous test was the list that was used to complete tasks. This test was
run with a user load of 25 concurrent users continuously calling the AlterToDo method on
Workflow.asmx and no other operations on the server. The list started as an empty list.

1x1 13.5
2x1 23.86
3x1 27.06
4x1 27.14
332

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
333
database, the operation will be unable to run. See Recommendations for more
information about workflow queuing.

Number of items or workflows Baseline solution maximum (RPS)
0 32.18
10 32
1,000 28.67
10,000 27.16
100,000 16.98
1,000,000 9.27

Autostart throughput as number of items and workflows increases
334
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.

335
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
336
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
337
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:
338
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

Database contention
(locks)
Database locks
prevent multiple
users from making
conflicting
modifications to a
set of data. When a
set of data is locked
by a user or
process, no other
user or process can
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
339
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
I/O requests to a
hard disk exceeds
the disk's I/O
capacity, the
requests will be
queued. As a result,
the time to complete
each request
increases.
Distributing data files across multiple physical
drives allows for parallel I/O. The blog
SharePoint Disk Allocation and Disk I/O
contains useful information about resolving
disk I/O issues.
Web server CPU
utilization
When a Web server
is overloaded with
user requests,
average CPU
utilization will
approach 100
percent. This
prevents the Web
server from
responding to
requests quickly and
can cause timeouts
and error messages
on client computers.
This issue can be resolved in one of two ways.
You can add Web servers to the farm to
distribute user load, or you can scale up the
Web server or servers by adding faster
processors.

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

Processor time Total Shows the
percentage of
elapsed time that
this thread used
the processor to
execute
instructions.
340
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

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

342

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

Verso e edio do produto Bancos de dados
SharePoint Foundation 2010 Configurao
Conteudo da Administrao Central
Conteudo (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:
344
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
Server 2010
Rascunho
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 plug-
in, 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.
345
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
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-o-
characteristics-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).
346
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
Numero de documentos (D) 200.000
Calculado como 10.000 usurios vezes 20
347
Entrada Valor
documentos
Tamanho medio dos documentos (S) 250 KB
Itens da lista (L) 600.000
Numero de verses no atuais (V) 2
Presumindo que o mximo permitido de
verses e 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
348

Importante:
O teste do conteudo desta seo ainda no foi concluldo. 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, e recomendvel
comear registrando em log apenas as
solicitaes de pginas. Voc tambem pode
restringir o tamanho do banco de dados
definindo o intervalo de dados padro a ser
mantido como inferior a duas semanas.
Se posslvel, 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 e
afetado principalmente pelo numero de tipos
de conteudo externo a que voc planeja dar
349
Banco de dados de aplicativos de servio Recomendao de estimativa de tamanho
suporte. Aloque 0,5 MB para cada tipo de
conteudo externo. Se voc no sabe de
quantos tipos de conteudo externo poder
precisar, e recomendvel alocar 50 MB. Os
requisitos de IOPS so mlnimos.
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
mlnimos.
Configuraes de inscrio Aloque 1 GB. Os requisitos de IOPS so
mlnimos.

Requisitos de IOPS e armazenamento de aplicativos de servio do
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 e 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.
Para o banco de dados de Propriedade,
350
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:
351

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 e afetado pelo
numero de tipos de conteudo e palavras-
chave 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 perlodo de
reteno, o volume dirio de dados
rastreados e o numero 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
Repositrio seguro O tamanho do banco de dados do aplicativo
de servio de Repositrio Seguro e
determinado pelo numero de credenciais no
repositrio e pelo numero de entradas na
tabela de auditoria. L recomendvel alocar
5 MB para cada 1.000 credenciais para ele.
A necessidade de IOPS e mlnima.
Estado O aplicativo de servio de Controle de
Sesso tem um banco de dados. L
recomendvel alocar 1 GB para ele. A
352
necessidade de IOPS e mlnima.
Servio Word Automation O aplicativo de servio Word Automation
tem um banco de dados. L recomendvel
alocar 1 GB para ele. A necessidade de
IOPS e mlnima.
PerformancePoint O aplicativo de servio PerformancePoint
tem um banco de dados. L recomendvel
alocar 1 GB para ele. A necessidade de
IOPS e mlnima.

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
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)
353
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.
354
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).
355

Observao:
O suporte para NAS se restringe apenas ao uso com bancos de dados de conteudo
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
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
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.
356

Observao:
Nossas definies de implantaes pequenas e medias so descritas na seo
"Arquiteturas de referncia" do artigo Capacity management and sizing for SharePoint

Tamanho combinado de bancos de dados de
contedo
RAM recomendada para computadores que
executam o SQL Server
Mlnimo para pequenas implantaes de
produo
8 GB
Mlnimo para medias implantaes de
produo
16 GB
Recomendao para ate 2 terabytes 32 GB
Recomendao para a faixa entre 2
terabytes ate o mximo de 5 terabytes
64 GB

Observao:
Esses valores so maiores do que os recomendados como mlnimos para o SQL Server
devido a 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

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
357
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
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.
358
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
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)
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
359
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
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.
360

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 substitul-los no mesmo local, as ferramentas no podero restaurar vrios arquivos
de dados em um local diferente. Por esse motivo, e altamente recomendvel que, ao
usar vrios arquivos de dados para um banco de dados de conteudo, 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
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 conteudo de ate 1 terabyte somente
para grandes repositrios de um unico 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 tlpicos 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.
361
Para obter mais informaes, consulte Plan for remote BLOB storage (RBS)
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
362
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
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:
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.
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:
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:
363
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,
364
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
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.
365
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
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
366
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) /
numero de discos
RAID 1 E/Ss por disco = [leituras + (2 gravaes)]
/ 2
/ numero de discos
/ numero 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 5
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).

Capacity Planning Sharepoint 2010-Libre PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Capacity Planning Sharepoint 2010-Libre PDF

Caricato da

Copyright:

Formati disponibili

Planejamento de capacidade para SharePoint

Potrebbero piacerti anche