Testes de desempenho para SharePoint Server

Planejamento de capacidade para SharePoint
Server 2010
Microsoft Corporation
Publicado em: janeiro de 2011
Autor: equipe de servidores e do Microsoft Office System ([email protected])
Resumo
Este manual fornece informações sobre o planejamento de requisitos de capacidade e
desempenho para a implantação do Microsoft SharePoint Server 2010. Os tópicos
incluem dimensionamento, teste de desempenho, limites de software e análises de
capacidade. As audiências deste guia são especialistas em aplicativos de negócios,
especialistas em linha de negócios, arquitetos da informação, generalistas em TI,
gerentes de programa e especialistas em infraestrutura que planejam uma solução
baseada no SharePoint Server 2010. Este manual faz parte de um conjunto de quatro
guias de planejamento que fornecem abrangentes informações de planejamento de TI
para o SharePoint Server.
Para obter mais informações sobre o planejamento da arquitetura de uma implantação
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 informações sobre o planejamento de sites e soluções criados com o uso do
SharePoint Server, consulte Planning guide for sites and solutions for Microsoft
SharePoint Server 2010, Part 1
(http://go.microsoft.com/fwlink/?linkid=196150&clcid=0x416) e Planning guide for sites
and solutions for Microsoft SharePoint Server 2010, Part 2
(http://go.microsoft.com/fwlink/?linkid=208024&clcid=0x416).
O conteúdo deste guia é uma cópia do conteúdo selecionado na biblioteca técnica do
SharePoint Server 2010 (http://go.microsoft.com/fwlink/?linkid=181463&clcid=0x416) a
partir da data de publicação. Para obter o conteúdo mais atual, consulte a biblioteca
técnica na Web.
Este documento é fornecido "no estado em que se encontra". As informações e as
exibições expressas neste documento, incluindo URLs e outras referências a sites da
Internet, podem ser alteradas sem aviso prévio. Você assume o risco inerente à sua
utilização.
Alguns exemplos citados neste documento são fornecidos somente como ilustração e
são fictícios. Não há nenhuma intenção, nem por dedução, de qualquer associação ou
conexão real.
Este documento não 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 referência.
© 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 são marcas registradas ou marcas comerciais da Microsoft Corporation
nos Estados Unidos e/ou em outros países.
Conteúdo
Capacity planning for Microsoft SharePoint Server 2010 Error! Bookmark not defined.
Obtendo ajuda ..................................................................................................................... 9
Gerenciamento de desempenho e capacidade (SharePoint Server 2010) ...................... 10
Capacity management and sizing for SharePoint Server 2010 (em inglês) ..................... 12
Visão geral do gerenciamento da capacidade e dimensionamento do SharePoint Server
2010 ............................................................................................................................... 13
Glossário ........................................................................................................................ 13
Quem deve ler os artigos sobre gerenciamento de capacidade? ................................. 14
Quatro fundamentos de desempenho ........................................................................... 16
Gerenciamento de capacidade versus planejamento de capacidade ........................... 21
Superdimensionamento versus subdimensionamento .................................................. 23
Limites e delimitadores de software .............................................................................. 24
Principais diferenças: SharePoint Server 2010 versus Office SharePoint Server 200726
Diferenciadores de chave de implantação do SharePoint Server 2010 ........................ 34
Arquiteturas de referência ............................................................................................. 36
Consulte também ........................................................................................................... 40
Planejamento de capacidade para SharePoint Server 2010 ............................................ 42
Etapa 1: Modelo ............................................................................................................. 42
Etapa 2: Design ............................................................................................................. 51
Etapa 3: Piloto, Teste e Otimização .............................................................................. 55
Etapa 4: Implantação ..................................................................................................... 57
Etapa 5: Monitoração e Manutenção ............................................................................. 58
Consulte também ........................................................................................................... 58
Testes de desempenho para SharePoint Server 2010 ..................................................... 59
Criar um plano de teste ................................................................................................. 60
Criar o ambiente de teste .............................................................................................. 60
Crie testes e ferramentas .............................................................................................. 62
Consulte também ........................................................................................................... 66
Monitorando e mantendo o SharePoint Server 2010 ....................................................... 68
Configurando o monitoramento ..................................................................................... 68
Removendo afunilamentos ............................................................................................ 79
Consulte também ........................................................................................................... 82
Gerenciamento de capacidade do SharePoint Server 2010: limites de software ............ 83
Visão geral de delimitadores e limites ........................................................................... 84
Limites e delimitadores .................................................................................................. 86
Performance and capacity technical case studies (SharePoint Server 2010) (em inglês)
..................................................................................................................................... 131
Ambiente de publicação na intranet da empresa do Microsoft SharePoint Server 2010:
análise técnica ............................................................................................................. 133
Informações sobre pré-requisitos ................................................................................ 133
Introdução a este ambiente ......................................................................................... 133
Especificações ............................................................................................................. 134
Carga de trabalho ........................................................................................................ 139
Conjunto de dados ....................................................................................................... 139
Dados de integridade e desempenho .......................................................................... 140
Enterprise intranet collaboration environment technical case study (SharePoint Server
2010) (em inglês) ......................................................................................................... 143
Prerequisite information ............................................................................................... 143
Introduction to this environment .................................................................................. 143
Specifications ............................................................................................................... 144
Health and Performance Data ..................................................................................... 150
Enterprise intranet collaboration environment lab study (SharePoint Server 2010) (em
inglês) .......................................................................................................................... 153
Introduction to this environment .................................................................................. 153
Glossary ....................................................................................................................... 154
Overview ...................................................................................................................... 155
Specifications ............................................................................................................... 156
Results and Analysis ................................................................................................... 162
Departmental collaboration environment technical case study (SharePoint Server 2010)
(em inglês) ................................................................................................................... 174
Prerequisite information ............................................................................................... 174
Introduction to this environment .................................................................................. 174
Specifications ............................................................................................................... 175
Workload ...................................................................................................................... 182
Dataset......................................................................................................................... 182
Health and Performance Data ..................................................................................... 183
Divisional portal environment lab study (SharePoint Server 2010) (em inglês) ............. 186
Introduction to this environment .................................................................................. 186
Glossary ....................................................................................................................... 187
Overview ...................................................................................................................... 188
Specifications ............................................................................................................... 189
Results and analysis .................................................................................................... 195
About the authors ........................................................................................................ 209
Social environment technical case study (SharePoint Server 2010) (em inglês) ........... 210
Prerequisite information ............................................................................................... 210
Introduction to this environment .................................................................................. 210
Specifications ............................................................................................................... 211
Workload ...................................................................................................................... 216
Dataset......................................................................................................................... 217
Health and Performance Data ..................................................................................... 217
Recomendações e resultados de testes de desempenho e capacidade (SharePoint
Server 2010) ................................................................................................................ 221
Estimate performance and capacity requirements for Access Services in SharePoint
Server 2010 (em inglês) .............................................................................................. 224
Test farm characteristics.............................................................................................. 224
Test results .................................................................................................................. 227
Recommendations ....................................................................................................... 237
Troubleshooting ........................................................................................................... 242
Estimate performance and capacity requirements for Excel Services in SharePoint Server
2010 (em inglês) .......................................................................................................... 244
Test farm characteristics.............................................................................................. 244
Test Results ................................................................................................................. 247
Recommendations ....................................................................................................... 257
Estimar os requisitos de desempenho e capacidade dos Serviços PerformancePoint . 263
Características do farm de teste .................................................................................. 263
Cenários e processos de teste .................................................................................... 264
Configuração e topologia de hardware ........................................................................ 266
Resultados do teste ..................................................................................................... 267
Topologias 2C e 3C ..................................................................................................... 269
Resultados para mais de 4C com autenticação da Conta de Serviço sem Supervisão
.................................................................................................................................. 273
Resultados para mais de 4C com autenticação por usuário ....................................... 274
Recomendações .......................................................................................................... 275
Analysis Services ......................................................................................................... 277
Afunilamentos comuns e suas causas ........................................................................ 277
Monitoramento de desempenho .................................................................................. 280
Consulte também ......................................................................................................... 281
Capacity requirements for Web Analytics Shared Service in SharePoint Server 2010 (em
inglês) .......................................................................................................................... 283
Introduction .................................................................................................................. 283
Hardware specifications and topology ......................................................................... 286
Capacity requirements ................................................................................................. 290
Consulte também ......................................................................................................... 294
Estimar os requisitos de desempenho e capacidade do Gerenciamento de conteúdo da
Web no SharePoint Server 2010 ................................................................................. 295
Informações sobre pré-requisitos ................................................................................ 296
Detalhes e abordagem do teste .................................................................................. 296
Implantações de Gerenciamento de Conteúdo da Web ............................................. 299
O que otimizar ............................................................................................................. 299
Resultados do teste e recomendações ....................................................................... 304
Sobre os autores ......................................................................................................... 326
Estimate performance and capacity planning for workflow in SharePoint Server 2010 (em
inglês) .......................................................................................................................... 327
Test farm characteristics.............................................................................................. 327
Test results .................................................................................................................. 331
Recommendations ....................................................................................................... 337
Troubleshooting ........................................................................................................... 340
Consulte também ......................................................................................................... 343
Planejamento e configuração de armazenamento e capacidade do SQL Server
(SharePoint Server 2010) ............................................................................................ 344
Processo de design e configuração do armazenamento e da camada do banco de
dados dos Produtos SharePoint 2010 ..................................................................... 344
Coletar requisitos de armazenamento e de espaço e E/S do SQL Server ................. 345
Escolher a versão e a edição do SQL Server ............................................................. 354
Projetar a arquitetura de armazenamento com base em requisitos de capacidade e E/S
.................................................................................................................................. 355
Estimar requisitos de memória .................................................................................... 357
Entender os requisitos de topologia de rede ............................................................... 358
Configurar o SQL Server ............................................................................................. 359
Validar e monitorar o desempenho do armazenamento e do SQL Server ................. 363
Obtendo ajuda
Todo esforço foi dedicado para garantir a precisão deste guia. Este conteúdo também
está disponível online na TechNet Library do Office System, portanto, se encontrar
algum problema, veja se há atualizações em:
http://technet.microsoft.com/pt-br/office/bb267342
Se não encontrar a sua resposta no conteúdo online, envie um email para a equipe de
conteúdo de servidores e do Microsoft Office System:
[email protected]
Se a sua dúvida for relacionada aos produtos do Microsoft Office, e não ao conteúdo
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
9
Gerenciamento de desempenho e
capacidade (SharePoint Server 2010)
Planejamento de desempenho e capacidade é o processo de mapeamento do design da
solução do Microsoft SharePoint Server 2010 para um tamanho de farm e conjunto de
hardware que ofereça suporte às suas metas de negócios.
Artigos relevantes sobre planejamento de capacidade e desempenho do Project
Server 2010 estão disponíveis na biblioteca de documentos do Project Server, em Plan
for performance and capacity (Project Server 2010).
Os artigos nesta seção incluem:
 Visão 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 visão 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 informações 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, além de diretrizes para um desempenho aceitável.
 Performance and capacity technical case studies (SharePoint Server 2010) (em
inglês)
Este artigo inclui links para os principais artigos técnicos de estudo de caso que
apresentam os detalhes de desempenho e capacidade para ambientes específicos
que executam o SharePoint Server 2010.
 Recomendações e resultados de testes de desempenho e capacidade (SharePoint
Server 2010)
Este artigo inclui links para artigos que apresentam os resultados de testes e as
recomendações para conjuntos de recursos específicos no SharePoint Server 2010.
 Planejamento e configuração de armazenamento e capacidade do SQL Server
(SharePoint Server 2010)
10
Este artigo descreve um processo para planejar o armazenamento e a capacidade
do SQL Server para uma implantação do SharePoint Server 2010.
Os recursos a seguir também podem ser úteis no planejamento da capacidade:
 Determine hardware and software requirements (SharePoint Server 2010)

Diagramas técnicos:

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).
11
Capacity management and sizing for
SharePoint Server 2010 (em inglês)
The articles in this section help you to make the following decisions regarding the
appropriate capacity for your Microsoft SharePoint Server 2010 environment:
 Understand the concepts behind effective capacity management.

Define performance and capacity targets for your environment.

Select the appropriate data architecture.

Choose hardware to support the number of users and the features you intend to
deploy.

Test, validate, and adjust your environment to achieve your performance and
capacity targets.
 Monitor and adjust your environment to match demand.
In this section:
 Visão geral do gerenciamento da capacidade e dimensionamento do SharePoint
Server 2010

Planejamento de capacidade para SharePoint Server 2010

Testes de desempenho para SharePoint Server 2010

Monitorando e mantendo o SharePoint Server 2010
12
Visão geral do gerenciamento da
capacidade e dimensionamento do
SharePoint Server 2010
Este artigo oferece uma visão geral de como planejar e gerenciar com eficiência a
capacidade de ambientes do Microsoft SharePoint Server 2010. Ele também descreve
como manter um bom entendimento das necessidades de capacidade e dos recursos da
sua implantação, pela análise do desempenho e dos dados de volume. Também analisa
os principais impactos de aplicativos que afetam a capacidade, incluindo as
características e o uso de conteúdo.
O Gerenciamento de capacidade é um processo contínuo porque nenhuma
implementação permanece estática em relação ao conteúdo e ao uso. Você precisa se
planejar para o crescimento e a alteração, de forma que o seu ambiente baseado no
SharePoint Server 2010 possa continuar a oferecer uma solução de negócios 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 opinião do arquiteto, servirá melhor à
implantação do SharePoint Server 2010. O modelo de gerenciamento de capacidade
inclui etapas adicionais para ajudar você a validar e ajustar a arquitetura inicial, além de
oferecer um loop de comentários para replanejamento e otimização do ambiente de
produção até que ele possa oferecer suporte aos objetivos de design com opções ideais
de hardware, topologia e configuração
Neste artigo:
 Glossário

Quem deve ler os artigos sobre gerenciamento de capacidade?

Quatro fundamentos de desempenho

Gerenciamento de capacidade versus planejamento de capacidade

Superdimensionamento versus subdimensionamento

Limites e delimitadores de software

Principais diferenças: SharePoint Server 2010 versus Office SharePoint Server 2007

Diferenciadores de chave de implantação do SharePoint Server 2010

Arquiteturas de referência
Glossário
Os termos especializados a seguir são usados na documentação de gerenciamento de
capacidade do SharePoint Server 2010.
 RPS Solicitações por segundo. O número de solicitações recebidas por um farm ou
servidor em um segundo. É uma medida comum de carga de servidor e de farm. O
número de solicitações processadas por um farm é maior do que o número de
13
carregamentos de página e de interações de usuário final. Isso acontece porque
cada página contém vários componentes, cada um criando uma ou mais solicitações
quando a página é carregada. Algumas solicitações são mais leves do que outras no
que diz respeito a custos de transação. Em nossos testes de laboratório e
documentos de estudo de caso, removemos 401 solicitações e respostas
(handshakes de autenticação) das solicitações que foram usadas para calcular o
RPS porque elas tiveram um impacto insignificante nos recursos do farm.

Horários de pico A hora ou horas durante o dia quando a carga do farm está em
seu máximo.

Carga de pico A carga diária máxima média no farm, medida em RPS.

Picos de Carga Picos de carga transitórios que acontecem fora do horário de pico.
Podem ser causados por aumentos não planejados em tráfego de usuários, taxas de
transferência menores no farm por causa de operações administrativas ou
combinações desses fatores.

Aumentar a escala Aumentar a escala significa adicionar recursos como
processadores ou memórias 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 conteúdo.
Avaliando o SharePoint Server 2010
Eu sou um profissional de TI ou tomador de decisões de negócios e procuro uma
solução para problemas de negócios específicos. O SharePoint Server 2010 é uma
opção para a minha implantação. Ele pode oferecer recursos e escalabilidade que
atendam aos meus requisitos específicos?
Para obter informações sobre como o SharePoint Server 2010 se dimensiona para
atender às demandas de soluções específicas e como determinar o hardware que será
necessário para oferecer suporte aos seus requisitos, consulte as seções a seguir neste
artigo:
 Principais diferenças: SharePoint Server 2010 versus Office SharePoint Server 2007
 Limites e delimitadores de software
Para obter informações sobre como avaliar o SharePoint Server 2010 seus requisitos de
negócios específicos, consulte os seguintes artigos:
 Product evaluation for SharePoint Server 2010

Gerenciamento de capacidade do SharePoint Server 2010: limites de software
Atualizando do Office SharePoint Server 2007
No momento, estou usando o Office SharePoint Server 2007. O que mudou no
SharePoint Server 2010 e o que devo considerar se resolver atualizar? Que efeito a
atualização tem no desempenho e no dimensionamento da minha topologia?
Para obter informações sobre como os fatores de desempenho e capacidade são
diferentes para o Office SharePoint Server 2007 e o SharePoint Server 2010, consulte a
seção a seguir, mais adiante neste artigo:
14
 Principais diferenças: SharePoint Server 2010 versus Office SharePoint Server 2007
Para obter informações sobre considerações de atualização mais gerais e como planejar
e executar uma atualização do Office SharePoint Server 2007, consulte o artigo a seguir:
 Upgrading to SharePoint Server 2010
Ajustando e otimizando um ambiente de produção 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 manutenção?
Para obter informações sobre contadores de monitoramento e desempenho para farms
do Microsoft SharePoint Server 2010, consulte o seguinte artigo:
 Monitorando e mantendo o SharePoint Server 2010
Para obter informações sobre como usar as ferramentas de monitoramento de
integridade internas da interface da Administração 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 informações sobre contadores de monitoramento e desempenho para farms
do Microsoft SharePoint Server 2010, consulte o seguinte artigo:
 Monitorando e mantendo o SharePoint Server 2010
Para obter informações sobre como solucionar problemas usando as ferramentas de
monitoramento de integridade internas da interface da Administração Central, consulte o
seguinte artigo:
 Solving Problems and Troubleshooting (SharePoint Server 2010)
Para obter uma lista de artigos de gerenciamento de capacidade disponíveis para vários
serviços e recursos específicos do SharePoint Server 2010 (mais artigos serão
adicionados quando forem disponibilizados), consulte o seguinte artigo:
 Recomendações e resultados de testes de desempenho e capacidade (SharePoint
Server 2010)
Para obter informações sobre dimensionamento e desempenho, consulte o seguinte
artigo:
 Planejamento e configuração de armazenamento e capacidade do SQL Server
(SharePoint Server 2010)
Para obter informações sobre o RBS (Remote BLOB Storage), consulte o seguinte
artigo:
 Plan for remote BLOB storage (RBS) (SharePoint Server 2010)
O começo do fim
Quero saber tudo sobre o gerenciamento de capacidade do SharePoint Server 2010. Por
onde começar?
Para obter informações sobre os conceitos gerais por detrás do gerenciamento de
capacidade e links para a documentação e recursos adicionais, consulte o seguinte
artigo:
 Gerenciamento de desempenho e capacidade (SharePoint Server 2010)
15
Para obter informações adicionais sobre gerenciamento de capacidade, consulte os
seguintes artigos complementares a este artigo de visão geral:
 Planejamento de capacidade para SharePoint Server 2010

Testes de desempenho para SharePoint Server 2010
 Monitorando e mantendo o SharePoint Server 2010
Agora, você deve ter boas noções básicas sobre os conceitos. Para obter informações
sobre os limites do SharePoint Server 2010, consulte o seguinte artigo:
 Gerenciamento de capacidade do SharePoint Server 2010: limites de software
Quando estiver pronto para identificar uma topologia inicial para o seu ambiente baseado
no SharePoint Server 2010, você poderá consultar a biblioteca de estudos de casos
técnicos para encontrar aquele que mais corresponde aos seus requisitos. Para obter
uma lista de estudos de caso (mais estudos de caso serão adicionados quando forem
disponibilizados), consulte o seguinte artigo:
 Performance and capacity technical case studies (SharePoint Server 2010) (em
inglês)
Para obter uma lista de artigos de gerenciamento de capacidade disponíveis para vários
serviços e recursos específicos do SharePoint Server 2010 (mais artigos serão
adicionados quando forem disponibilizados), consulte o seguinte artigo:
 Recomendações e resultados de testes de desempenho e capacidade (SharePoint
Server 2010)
Para obter informações sobre dimensionamento e desempenho, consulte o seguinte
artigo:
 Planejamento e configuração de armazenamento e capacidade do SQL Server
(SharePoint Server 2010)
Para obter informações sobre o RBS (Remote BLOB Storage), consulte o seguinte
artigo:
 Plan for remote BLOB storage (RBS) (SharePoint Server 2010)
Para obter informações sobre o monitoramento da integridade e como solucionar
problemas usando as ferramentas de monitoramento de integridade internas da interface
da Administração Central, consulte o seguinte artigo:
 Health Monitoring (SharePoint Server 2010)
 Solving Problems and Troubleshooting (SharePoint Server 2010)
Para obter informações sobre as diretrizes de ajuste fino do desempenho geral e uma
variedade de assuntos de desempenho e capacidade específicos (mais artigos serão
adicionados quando forem disponibilizados), consulte o seguinte artigo:
 Use search administration reports (SharePoint Server 2010)
Para obter mais informações 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 solução:
16

Latência Para fins de gerenciamento de capacidade, a latência é definida como a
duração entre o momento em que um usuário inicia uma ação, como clicar em um
hiperlink, e o momento até que o último byte é transmitido ao aplicativo cliente ou
navegador da Web.

Taxa de transferência A taxa de transferência é definida como o número de
solicitações simultâneas 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 conteúdo que o sistema pode hospedar. A estrutura e a distribuição de bancos de
dados de conteúdo tem um efeito significativo no tempo que o sistema leva para
processar solicitações (latência) e o número de solicitações simultâneas que ele
pode servir (taxa de transferência).

Legibilidade A legibilidade é uma medida da capacidade do sistema de cumprir os
objetivos definidos para a latência e a taxa de transferência ao longo do tempo.
O principal objetivo do gerenciamento da capacidade do seu ambiente é estabelecer e
manter um sistema que atenda aos objetivos de latência, taxa de transferência, Escala
de dados e confiabilidade da sua organização.
Latência
A Latência, também conhecida como latência percebida pelo usuário final, é composta
por três componentes principais:
 O tempo que leva para o servidor receber e processar a solicitação.

O tempo que leva para a solicitação e a resposta do servidor serem transferidas pela
rede.
 O tempo que leva para a resposta ser renderizada no aplicativo cliente.
Organizações diferentes definem objetivos de latência diferentes com base em requisitos
de negócios e expectativas do usuário. Algumas organizações aceitam latência de vários
segundos, enquanto outras exigem transações muito rápidas. A otimização de
transações muito rápidas normalmente é muito cara e requer clientes e servidores mais
poderosos, versões mais recentes de navegadores e de aplicativos clientes, soluções de
rede com grande largura de banda e, possivelmente, investimentos em desenvolvimento
e ajuste fino de páginas.
Alguns fatores principais que contribuem para latências mais longas percebidas pelo
usuário final, bem como exemplos de alguns problemas comuns, estão descritos na lista
a seguir. Esses fatores são especialmente relevantes em cenários nos quais os clientes
estão geograficamente distantes do farm de servidores ou estão acessando o farm por
uma conexão de rede com pouca largura de banda.
 Recursos, serviços ou parâmetros de configuração que não estejam otimizados
podem atrasar o processamento de solicitações e a latência de impacto para clientes
remotos e locais. Para obter mais informações, consulte Taxa de
transferênciaConfiabilidade, mais adiante neste documento.

Páginas da Web que geram solicitações desnecessárias ao servidor para o
download de dados e recursos necessários. A otimização incluiria baixar o número
mínimo de recursos para desenhar uma página, reduzindo o tamanho das imagens,
armazenando os recursos estáticos em pastas que permitam o acesso anônimo,
clusterizando solicitações e permitindo a interatividade de página enquanto recursos
são baixados assincronamente do servidor. Essas otimizações são importantes para
a obtenção de uma experiência de navegador de primeira visita aceitável.
17

O volume excessivo de dados transmitidos pela rede contribui para a degradação da
latência e da taxa de transferência. Por exemplo, quando possível, as imagens e
outros objetos em uma página devem usar um formato compactado, como .png ou
.jpg, em vez de bitmaps.

Páginas de Web que não são otimizadas para cargas de página de segundo acesso.
O PLT (tempo de carregamento da página) aprimora os carregamentos de página no
segundo acesso porque alguns recursos de página são armazenados em cache no
cliente, e o navegador só precisa baixar o conteúdo dinâmico que não está
armazenado em cache. Latências de carregamento de página em segundo acesso
inaceitáveis quase sempre são causadas por configuração incorreta do cache BLOB
(Binary Large Object) ou porque o cache do navegador está desabilitado em
computadores clientes. As otimizações incluiriam o armazenamento em cache
correto dos recursos no cliente.

Páginas da Web com código JavaScript personalizado não otimizado. Isso pode
tornar a renderização da página no cliente mais lenta. A otimização poderia atrasar o
processamento de JavaScript no cliente até que o resto da página fosse carregado
e, preferencialmente, chamando scripts em vez da adição de JavaScript embutido.
Taxa de transferência
Taxa de transferência é descrita pelo número de solicitações que um farm de servidores
pode processar em uma unidade de tempo e também costuma ser usada para medir a
escala de operações que se espera que o sistema mantenha com base no tamanho da
organização e de suas características de uso. Todas as operações têm um custo
específico 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
latência não estará abaixo do esperado quando a simultaneidade for alta e o sistema
estiver sob stress.
Alguns exemplos comuns de condições de baixa taxa de transferência incluem:
 Recursos de hardware inadequados Quando o farm recebe mais solicitações do
que pode processar simultaneamente, algumas solicitações são enfileiradas, o que
atrasa cumulativamente o processamento de cada solicitação subsequente até que
a demanda seja reduzida o suficiente para que a fila seja limpa. Alguns exemplos de
otimização de um farm para sustentar a taxa de transferência mais alta incluem:

Garantir que os processadores em servidores do farm não sejam
sobrecarregados. Por exemplo, se o uso de CPU durante os horários de pico ou
de picos de carga exceder consistentemente 80%, adicione mais servidores ou
redistribua os serviços para outros servidores do farm.

Verifique se há memória suficiente em servidores e aplicativos e servidores Web
para conter o cache completo. Isso ajudará a evitar chamadas ao banco de
dados para servir solicitações de conteúdo não armazenado em cache.

Verifique se os servidores de banco de dados estão livres de afunilamentos. Se
o total de IOPS de disco disponível for insuficiente para oferecer suporte à
demanda de pico, adicione mais discos ou redistribua os bancos de dados para
discos subutilizados. Consulte a seção Removendo afunilamentos, do artigo de
monitoramento e manutenção dos Produtos e Tecnologias do SharePoint Server
2010, para obter mais informações.
18



Se a adição de recursos a computadores existentes for insuficiente para resolver
problemas de taxa de transferência, adicione servidores e redistribua os
recursos e serviços afetados aos novos servidores.
Páginas da Web personalizadas não otimizadas A adição de código
personalizado a páginas usadas com frequência em um ambiente de produção é
uma causa comum de problemas de taxa de transferência. A adição de código
personalizado pode gerar viagens de ida e volta adicionais aos servidores de banco
de dados ou serviços Web para servir solicitações de dados. A personalização de
páginas usadas com pouca frequência pode não causar um impacto significativo na
taxa de transferência, mas o código bem otimizado pode diminuir a taxa de
transferência do farm se for solicitado milhares de vezes ao dia. Os administradores
do SharePoint Server podem habilitar o Painel de Desenvolvimento para identificar
código personalizado que requer otimização. Alguns exemplos de otimização de
código personalizado incluem:

Minimizar o número de solicitações ao serviço Web e consultas SQL.

Busque o mínimo necessário dos dados em cada viagem ao servidor de banco
de dados, minimizando o número de viagens de ida e volta necessárias.

Evite a adição de código personalizado a páginas usadas com frequência.

Use índices quando estiver recuperando uma quantidade de dados filtrada.
Soluções não confiáveis A implantação de código personalizado em pastas bin
pode fazer com que o desempenho do servidor fique lento. Sempre que uma página
com código não confiável for solicitada, o SharePoint Server 2010 deverá executar
verificações de segurança antes que ela possa ser carregada. A menos que haja um
motivo específico para a implantação de código não confiável, instale assemblies
personalizados no GAC para evitar a verificação de segurança desnecessária.
Escala de dados
Escala de dados é o volume de dados que o servidor ou o farm de servidores pode
armazenar atendendo aos objetivos de latência e taxa de transferência. Geralmente,
quanto maior o volume de dados do farm, maior o impacto na taxa de transferência e na
experiência do usuário gerais. O método usado para distribuir dados nos discos e
servidores de banco de dados também pode afetar a latência e a taxa de transferência
do farm.
Dimensionamento de banco de dados, arquitetura de dados e hardware de servidor de
banco de dados suficiente são muito importantes para uma solução de banco de dados
ideal. Em uma implantação ideal, os bancos de dados de conteúdo são dimensionados
de acordo com orientação de limites e são distribuídos por discos físicos para que as
solicitações não sejam enfileiradas por causa do sobrecarregamento de disco, e os
servidores de banco de dados são capazes de oferecer suporte a cargas de pico e picos
inesperados sem excederem os limites de utilização de recursos.
Além disso, determinadas operações podem bloquear determinadas tabelas durante a
operação. Um exemplo disso é uma grande exclusão de site, que pode fazer com que
tabelas relacionadas no banco de dados de conteúdo onde reside o site sejam
bloqueadas até que a operação de exclusão seja concluída.
Alguns exemplos de otimização de um farm para obtenção de melhor desempenho de
dados e de armazenamento incluem:
19

Verificar se os bancos de dados estão distribuídos adequadamente pelos servidores
de banco de dados e se os recursos de servidor de banco de dados são suficientes
para oferecer suporte ao volume e à distribuição de dados.

Volumes de banco de dados separados em LUNs (unidades lógicas exclusivas),
consistindo em eixos de disco físico exclusivos. Use vários discos com baixo tempo
de busca e configurações 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 vários
BLOBS (Binary Large Objects). O RBS pode oferecer os seguintes benefícios:

Dados BLOB podem ser armazenados em dispositivos de armazenamento mais
baratos, que são configurados para administrar o armazenamento simples.

A administração do repositório BLOB é controlada por um sistema projetado
especificamente para trabalhar com dados BLOB.

Os recursos do servidor de banco de dados são liberados para operações de
banco de dados.
Esses benefícios não são gratuitos. Antes de implementar o RBS com o
SharePoint Server 2010, você deve avaliar se esses benefícios potenciais
superam os custos e as limitações da implementação e manutenção do RBS.
Para obter mais informações, consulte Plan for remote BLOB storage (RBS)
(SharePoint Server 2010).
Para obter informações sobre como planejar a escala de dados, consulte Planejamento
e configuração 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 latência, taxa de transferência e capacidade de dados estabelecidos
com o passar do tempo. Um farm confiável é aquele para o qual o tempo de ativação, a
capacidade de resposta, a taxa de falha e a frequência e amplitude de picos de latência
estão dentro dos objetivos e requisitos operacionais estabelecidos. Um farm confiável
também pode manter consistentemente os objetivos de latência e taxa de transferência
durante a carga de pico e o horário de pico, ou quando ocorrem operações do sistema,
como rastreamento ou backups diários.
Um fator fundamental na sustentação da confiabilidade é o efeito de operações
administrativas comuns sobre os objetivos de desempenho. Durante determinadas
operações, como a recriação de índices de banco de dados, a manutenção de trabalhos
de timer ou a exclusão de vários sites com um grande volume de conteúdo, o sistema
pode ser incapaz de processar solicitações do usuário com rapidez. Nesse caso, a
latência e a taxa de transferência de solicitações do usuário final podem ser afetadas. O
impacto no farm depende da frequência e do custo de transação dessas operações
menos comuns e se elas são executadas durante o horário normal de operação.
Alguns exemplos de como manter o sistema confiável incluem:
 Agendar trabalhos de timer de uso intenso de recursos e tarefas administrativas para
os horários que não 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.
20

Distribuir os serviços e recursos de uso intenso para servidores dedicados. Você
também pode usar um balanceador de carga de hardware para direcionar o tráfego
específico de recurso para um servidor Web dedicado a recursos ou serviços
específicos.
Gerenciamento de capacidade versus
planejamento de capacidade
O gerenciamento de capacidade amplia o conceito de planejamento de capacidade para
expressar a abordagem cíclica em que a capacidade de uma implantação do SharePoint
Server 2010 é continuamente monitorada e otimizada para acomodar as condições e os
requisitos em constante transformação.
O SharePoint Server 2010 oferece maior flexibilidade e pode ser configurado para
manter cenários de uso em uma ampla variedade de pontos de escala diferentes. Não
há uma única arquitetura de implantação. Dessa forma, os designers de sistema e
administradores devem compreender os requisitos de seus ambientes específicos.
Modelo de gerenciamento de capacidade do SharePoint Server 2010
21

Etapa 1: Modelo Modelagem é o processo pelo qual você decide as soluções
fundamentais para as quais deseja que seu ambiente ofereça suporte e estabelece
todas as métricas e parâmetros importantes. A saída do exercício 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.
22



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 saídas são a arquitetura de dados e as topologias físicas e lógicas.

Determine sua arquitetura de ponto de partida.

Selecione seu hardware.
Etapa 3: Piloto, teste e otimização Se você projetou uma nova implantação,
precisa implantar um ambiente piloto para testar suas características de carga de
trabalho e uso esperado. Para um farm existente, os testes são aconselháveis
quando grandes alterações estiverem sendo feitas na infraestrutura, mas a
otimização regular baseada em resultados de monitoramento pode ser necessária
para manter os objetivos de desempenho. A saída desta fase é a análise dos
resultados de teste em relação aos objetivos e uma arquitetura otimizada capaz de
manter os objetivos de desempenho e capacidade estabelecidos.

Piloto Implante um ambiente piloto.

Teste Teste em relação aos objetivos de latência e taxa de transferência.

Otimização Obtenha os resultados do teste e faça qualquer alteração
necessária nos recursos e na topologia do farm.

Etapa 4: Implantação Esta etapa descreve a implementação do farm, ou a
implantação de alterações em um farm existente. A saída para um novo design é
uma implantação concluída em produção, incluindo todas as migrações de conteúdo
e de usuários. A saída para um farm existente são mapas do farm revisados e
atualizações feitas nos planos de manutenção.

Etapa 5: Monitoramento e manutenção Esta etapa descreve como configurar o
monitoramento e como prever e identificar afunilamentos e executar atividades
regulares de manutenção e redução de afunilamentos.
Superdimensionamento versus
subdimensionamento
Superdimensionamento descreve uma abordagem ao design do farm na qual os
objetivos são atingidos sem a utilização total de hardware, e os recursos do farm do
SharePoint Server são significativa e consistentemente subutilizados. Em uma
implantação superdimensionada, memória, CPU e outros indicadores dos recursos do
farm mostram que ele pode servir bem à demanda com menos recursos. A desvantagem
do superdimensionamento são os maiores gastos em hardware e manutenção e o fato
de ela poder impor grandes demandas de energia e de espaço.
Subdimensionamento descreve uma abordagem ao design do farm na qual os objetivos
de desempenho e capacidade não podem ser atingidos porque os recursos de hardware
no farm do SharePoint Server são utilizados em excesso. O subdimensionamento de um
farm é feito algumas vezes para reduzir custos de hardware, mas geralmente resulta em
alta latência, o que resulta em uma experiência de usuário insuficiente, baixa satisfação,
escalonamentos frequentes, altos custos de suporte e gastos desnecessários com
solução de problemas e ajustes finos do ambiente.
23
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 otimização ajudarão você a garantir que o seu farm
tenha o hardware correto.
Para manter os objetivos de desempenho e acomodar o crescimento, sempre é mais
desejável ter mais recursos do que o necessário para atingir seus objetivos. O custo do
investimento em excesso em hardware geralmente é menor do que as despesas
acumuladas em relação à solução de problemas causados pelo subdimensionamento.
Sempre dimensione um sistema para responder adequadamente durante a demanda de
pico, que pode ser diferente para serviços específicos em ocasiões específicas. Para
estimar com eficiência os requisitos de capacidade, você precisa identificar o pior caso
de período de demanda para todos os recursos.
O farm também deve ser capaz de oferecer suporte a picos inesperados, como quando
anúncios são feitos em toda a organização e um número inesperadamente grande de
usuários acessa um site ao mesmo tempo. Durante esses períodos de alta demanda, os
usuários experimentarão alta latência e não obterão a resposta do farm, a menos que
haja recursos de farm suficientes para satisfazer a carga maior no farm.
A capacidade do farm também deve ser revisitada quando usuários adicionais forem
provisionados na empresa. Situações como uma fusão ou aquisição, caracterizadas por
novos funcionários ou membros acessando o farm, podem ter efeitos negativos sobre o
desempenho se não forem planejadas ou estimadas com antecedência.
Zonas operacionais: Zona Verde e Zona Vermelha
Quando descrevemos a carga de um sistema de produção, 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 transitórias de recursos, que só
podem ser mantidas por períodos 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 condições de
carga normais, até as cargas de pico diárias esperadas. Um farm operando nesse
intervalo deve ser capaz de manter tempos de resposta e latência nos parâmetros
aceitáveis.
Zona Vermelha O intervalo de operação no qual a carga é maior do que a carga de
pico normal, mas ainda é possível servir solicitações por um período limitado. Esse
estado é caracterizado por latência maior do que o normal e possíveis falhas causadas
pela saturação 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 serviço e dentro
dos objetivos de latência e taxa de transferência.
Limites e delimitadores de software
No SharePoint Server 2010, há determinados limites que, por design, não podem ser
excedidos e outros limites definidos como valores padrão que podem ser alterados pelo
administrador do farm. Há também certos limites que não são representados por um
valor configurável, como o número de conjuntos de sites por aplicativo Web.
24
Delimitadores são limites absolutos que não podem ser excedidos por padrão. É
importante entendê-los para garantir que você não faça pressuposições incorretas ao
projetar seu farm.
Um exemplo de delimitador é o limite de tamanho do documento de 2 GB. Não é
possível configurar o SharePoint Server 2010 para armazenar documentos com mais de
2 GB. Esse é um valor absoluto interno que não pode ser excedido por padrão.
Limites são aqueles que possuem um valor padrão que não pode ser excedido, a menos
que o valor seja modificado. Em determinadas circunstâncias, limites podem ser
excedidos para acomodar variações no design do farm. Entretanto, é importante
entender que isso pode afetar o desempenho do farm, além do valor efetivo de outros
limites.
O valor padrão de certos limites só pode ser excedido até um valor máximo absoluto.
Um bom exemplo disso novamente é o limite de tamanho de documento. Por padrão, o
limite de tamanho de documento é definido como 50 MB, mas pode ser alterado para dar
suporte ao valor máximo de 2 GB.
Limites com suporte definem o valor testado para um determinado parâmetro. Os valores
padrão para esses limites foram definidos por meio de testes e representam as
limitações 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 são os parâmetros configuráveis definidos por padrão como
o valor recomendado, enquanto outros limites estão relacionados a parâmetros que não
são representados por um valor configurável.
Um exemplo de limite com suporte é o número de conjuntos de sites por aplicativo Web.
O limite com suporte é de 500.000, que é o maior número de conjuntos de sites por
aplicativo Web que atenderam aos parâmetros de comparação 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 degradação no desempenho à medida que o valor aumenta. Portanto, se
forem excedidos determinados limites, como o número de conjuntos de sites por
aplicativo Web, isso poderá resultar apenas em uma redução fracionária no desempenho
do farm. No entanto, na maioria dos casos, operar em um limite estabelecido ou próximo
a ele não é uma prática recomendada, pois as metas de desempenho e confiabilidade
aceitáveis são alcançadas mais facilmente quando o design de um farm possibilita um
equilíbrio razoável dos valores limites.
Limites e diretrizes de limites com suporte são determinados pelo desempenho. Em
outras palavras, você pode exceder os valores padrão dos limites, mas, à medida que
aumentar o valor limite, o desempenho do farm e o valor efetivo de outros limites
poderão ser afetados. Muitos limites no SharePoint Server 2010 podem ser alterados.
No entanto, é importante entender como a alteração de um determinado limite afeta
outras partes do farm.
Se você contatar o Serviço de Atendimento ao Cliente Microsoft sobre um sistema de
produção que não atende às especificações mínimas 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 mínimos.
Como limites são estabelecidos
No SharePoint Server 2010, limites e limites com suporte são estabelecidos por meio de
testes e da observação do comportamento do farm sob cargas crescentes, até o ponto
25
em que os serviços e as operações do farm atingirem seus limites operacionais efetivos.
Alguns serviços 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
média de vários fatores.
Por exemplo, as observações sobre o comportamento do farm sob carga quando
conjuntos de sites são adicionados indicam que certos recursos apresentam latência
inaceitavelmente alta, enquanto outros recursos ainda estão operando dentro dos
parâmetros aceitáveis. Portanto, o valor máximo atribuído ao número de conjuntos de
sites não é absoluto, sendo calculado com base em um conjunto esperado de
características de uso em que o desempenho geral do farm seria aceitável dentro do
limite específico na maioria das circunstâncias.
Se outros serviços estiverem operando de acordo com parâmetros que sejam mais
elevados do que aqueles usados para testar os limites, os limites máximos efetivos de
outros serviços serão reduzidos. Assim, é importante executar um gerenciamento
rigoroso da capacidade e dimensionar os exercícios de testes para implantações
específicas, de forma a estabelecer limites efetivos para esse ambiente.
Para obter mais informações 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 diferenças: 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 flexível do que as versões anteriores. Antes de usar essa arquitetura
mais complexa para oferecer recursos e funcionalidade mais poderosos aos seus
usuários, considere com cuidado seus efeitos na capacidade e no desempenho do farm.
No Office SharePoint Server 2007, existem quatro serviços principais que podem ser
habilitados em SSPs (Provedores de Serviços Compartilhados): Serviço de Pesquisa,
Serviço de Cálculo do Excel, Serviço de Perfil de Usuário e Serviço de Catálogo 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 serviços disponíveis, conhecidos como SSAs
(Aplicativos de Serviço do SharePoint), e o SharePoint Server 2010 oferece uma
variedade muito maior de aplicativos clientes que podem interagir com o farm, incluindo
vários aplicativos novos do Office, dispositivos móveis, ferramentas de designer e
navegadores. Alguns exemplos de como interações de clientes expandidas causam um
impacto nas considerações 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 informações sobre destinatários
de email que são extraídas do farm do SharePoint Server quando mensagens de
email são visualizadas no cliente do Outlook. Isso introduz um novo conjunto de
padrões de tráfego e de carga de servidor que deve ser levado em consideração.

Alguns novos recursos de clientes do Microsoft Office 2010 atualizam dados
automaticamente em relação ao farm do SharePoint Server, mesmo quando os
aplicativos clientes estão abertos, mas não estão sendo ativamente usados. Esses
clientes, como o SharePoint Workspace e o OneNote, também introduzirão alguns
26
novos padrões de tráfego e de carga de servidor que devem ser levados em
consideração.

Os novos recursos de interatividade da Web do SharePoint Server 2010, como o
Office Web Apps, que permite a edição de arquivos do Office diretamente do
navegador, usam chamadas AJAX que introduzem alguns novos padrões de tráfego
e de carga de servidor que devem ser levados em consideração.
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 solicitações gerais por segundo (RPS). Além
disso, espera-se que o percentual de solicitações vindas do navegador seja menor do
que no Office SharePoint Server 2007, o que abre espaço para o percentual crescente
de novo tráfego vindo de outros clientes, uma vez que eles estão sendo amplamente
adotados na organização.
Adicionalmente, o SharePoint Server 2010 apresenta nova funcionalidade, como o
suporte a vídeo inserido nativo, que pode adicionar stress ao farm. Algumas
funcionalidades também foram expandidas para oferecer suporte a uma escala maior do
que versões anteriores.
A seção a seguir descreve essas interações de cliente, serviços e recursos e suas
implicações de desempenho e capacidade gerais no sistema que você deve considerar
ao projetar sua solução.
Para obter mais informações sobre como atualizar para o SharePoint Server 2010,
consulte Upgrading to SharePoint Server 2010.
Serviços e recursos
A tabela a seguir oferece uma descrição geral simplificada dos requisitos de recursos
para os diferentes serviços em cada camada. As células em branco indicam que o
serviço não é executado naquela camada ou não causa impacto sobre ela.
X – indica custo mínimo ou insignificante no recurso. O serviço pode compartilhar esse
recurso com outros serviços.
XX – indica custo médio no recurso. O serviço poderia compartilhar esse recurso com
outros serviços com impacto mínimo.
XXX – indica alto custo no recurso. Geralmente, o serviço não deve compartilhar esse
recurso com outros serviços.
Para obter mais informações sobre como planejar bancos de dados do SQL Server,
consulte Planejamento e configuração de armazenamento e capacidade do SQL Server
(SharePoint Server 2010).
Para obter uma lista de artigos de gerenciamento de capacidade disponíveis para vários
serviços e recursos específicos do SharePoint Server 2010 (mais artigos serão
adicionados quando forem disponibilizados), consulte Recomendações e resultados de
testes de desempenho e capacidade (SharePoint Server 2010).
Aplicativo de
Serviço
CPU do
servidor
Web
RAM do CPU do
RAM do
CPU IOPS Armazenamento
servidor servidor
servidor de do
do
do SQL Server
Web
de
aplicativos: SQL SQL
aplicativos
Server Server
Serviço do
SharePoint
XXX
XXX
XX
27
XXX XXX
Aplicativo de
Serviço
CPU do
servidor
Web
RAM do CPU do
RAM do
CPU IOPS Armazenamento
servidor servidor
servidor de do
do
do SQL Server
Web
de
aplicativos: SQL SQL
aplicativos
Server Server
Foundation
XX
Serviço da
Administração
Central
Serviço de Log * XX
XX
X
X
X
XX
XXX XXX
XXX
XXX
XXX
X
XXX
XX
XX
XXX
XX
XX
Serviço de
Cálculo do Excel
X
XX
XXX
Serviço do Visio * X
X
XXX
XXX
X
X
X
X
X
XXX
XX
X
X
X
Serviço de Perfil X
de Usuário
XX
XX
XX
XXX XXX XX
Serviço de
Metadados
Gerenciados *
X
XX
XX
XX
X
Serviço do Web
Analytics *
X
X
Serviço de
Pesquisa do
SharePoint
XXX
XX
Aplicativo de
X
serviço de
Exibição do Word
*
Serviço
PowerPoint *
Serviço do
Access *
XX
XXX XXX XXX
X
XX
XXX XXX XXX
XX
Serviço de
Conectividade de
Dados
Corporativos *
XX
XXX
XXX
Serviço do
InfoPath Forms
XX
XX
XX
XX
X
X
X
Serviço de
Conversão do
Word
X
X
XXX
XX
X
X
X
28
Aplicativo de
Serviço
CPU do
servidor
Web
Aplicativo de
XX
Serviço do
PerformancePoint
*
RAM do CPU do
RAM do
CPU IOPS Armazenamento
servidor servidor
servidor de do
do
do SQL Server
Web
de
aplicativos: SQL SQL
aplicativos
Server Server
XX
XXX
XXX
X
X
X
X
X
XXX XXX XX
Soluções de Área X
Restrita *
X
XXX
XXX
Recursos de fluxo XXX
de trabalho *
XXX
Serviço de Timer XX
XX
XX
XX
PowerPivot *
X
XXX
XXX
Serviço do
Project *
X
XX
X
XX
X
XXX
Observação:
Um asterisco indica um novo serviço no SharePoint Server 2010.

Serviço do SharePoint Foundation O principal serviço do SharePoint para
colaboração de conteúdo. Em grandes implantações do SharePoint Server,
recomendamos que você aloque servidores Web redundantes com base na carga de
tráfego esperada, dimensione adequadamente os computadores baseados no SQL
Server que servirão os bancos de dados de conteúdo e aloque adequadamente o
armazenamento com base no tamanho do farm.

Serviço da Administração Central O serviço de administração. Esse serviço tem
requisitos de capacidade relativamente pequenos. Recomendamos que você o
habilite em vários servidores do farm para garantir a redundância.

Serviço de Log O serviço que registra os indicadores de uso e integridade para
fins de monitoramento. É um serviço de gravação intensa e pode exigir um espaço
em disco relativamente grande, dependendo do número de indicadores e da
frequência com que são registrados em log. Em grandes implantações do
SharePoint Server 2010, recomendamos que você isole o banco de dados de uso
dos bancos de dados de conteúdo em computadores baseados no SQL Server
diferentes.

Aplicativo de Serviço de Pesquisa do SharePoint O aplicativo de serviço
compartilhado que oferece recursos de indexação e consulta. Geralmente, é um
serviço de uso relativamente intenso de recursos que pode ser dimensionado para
servir implantações de conteúdo muito grandes. Em grandes implantações do
SharePoint Server, em que a pesquisa empresarial é muito importante,
29
recomendamos que você use um "farm de serviços" separado para hospedar
aplicativos de serviço de pesquisa, com recursos de banco de dados dedicados, use
vários servidores de aplicativos para servir funções de pesquisa específicas
(rastreamento ou consulta) e servidores Web de destino dedicados nos farms de
conteúdo para garantir uma taxa de transferência aceitável para rastreamento e
consulta. Você também pode habilitar Aplicativos de Serviço FAST como Aplicativo
de Serviço de Pesquisa. Opte por criar um ou mais Conectores de Pesquisa FAST
para a indexação de conteúdo com o FAST Search Server 2010 for SharePoint e
crie outra SSA (Consulta de Pesquisa FAST) para consultar conteúdo rastreado
pelos Conectores de Pesquisa FAST.

Aplicativo de Serviço de Exibição do Word A habilitação desse serviço permite
que você exiba documentos do Word diretamente do navegador. O serviço é
adicionando quando você instala o Office Web Apps junto com o SharePoint Server
2010. Esse serviço exige que um servidor de aplicativos prepare os arquivos
originais para a exibição em navegador. Em grandes implantações do SharePoint
Server, recomendamos que você expanda o serviço em vários servidores de
aplicativos para obter redundância e taxa de transferência.
Observação:
A edição em navegador para o Word e o OneNote estará habilitada quando você instalar
o Office Web Apps no farm do SharePoint Server 2010. No entanto, esse recurso é
executado nos servidores Web do farm e não usa qualquer aplicativo de serviço.

Aplicativo de Serviço do PowerPoint Esse serviço exibe e permite que os
usuários editem arquivos do PowerPoint diretamente no navegador, além de permitir
que você transmita e compartilhe apresentações do PowerPoint ao vivo. Esse
serviço é 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
exibição em navegador. Em grandes implantações do SharePoint Server, nas quais
ele se tornar um recurso de uso frequente, recomendamos que você implante vários
servidores de aplicativos para garantir redundância e taxa de transferência
aceitáveis e adicione mais servidores Web quando a Transmissão do PowerPoint
também for usada com frequência.

Aplicativo de Serviço de Cálculo do Excel Esse serviço exibe planilhas do Excel
diretamente no navegador e executa cálculos do Excel no servidor. Também habilita
a edição de planilhas diretamente do navegador quando você instala o Office Web
Apps no SharePoint Server 2010. Em grandes implantações do SharePoint Server,
nas quais ele se tornar um recurso de uso frequente, recomendamos que você
aloque um número suficiente de servidores de aplicativos com RAM suficiente para
garantir desempenho e taxa de transferência aceitáveis.

PowerPivot para SharePoint O serviço para exibir planilhas habilitadas para
PowerPivot do Excel diretamente no navegador. Em grandes implantações do
SharePoint Server, nas quais ele se tornar um recurso de uso frequente,
recomendamos que você aloque um número suficiente de servidores de aplicativos
com RAM e CPU suficientes para garantir desempenho e taxa de transferência
aceitáveis. Para obter mais informações, consulte o artigo sobre requisitos de
hardware e software (PowerPivot para SharePoint).
30

Aplicativo de Serviço do Visio O serviço para exibir diagramas dinâmicos do
Visio diretamente no navegador. Esse serviço tem uma dependência do Aplicativo
de Serviço de Controle de Sessão, que exige um banco de dados do SQL Server
relativamente pequeno. O serviço do Visio exige que um servidor de aplicativos
prepare os arquivos originais do Visio para a exibição em navegador. Em grandes
implantações do SharePoint Server, nas quais ele se tornar um recurso de uso
frequente, recomendamos que você expanda o serviço para vários servidores de
aplicativos com CPU e RAM suficientes para garantir desempenho e taxa de
transferência aceitáveis.

Aplicativo de Serviço do Access O serviço para hospedar soluções do Access no
SharePoint Server 2010. Em grandes implantações do SharePoint Server, nas quais
ele se tornar um recurso de uso frequente, recomendamos que você expanda o
serviço para vários servidores de aplicativos com RAM suficiente para desempenho
e taxa de transferência aceitáveis. O serviço 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 Serviço de Perfil de Usuário O serviço que impulsiona os cenários
sociais no SharePoint Server 2010 e que habilita Meus Sites, Marcação, Notas e
sincronização de Perfis com diretórios e outros recursos sociais. O serviço de perfil
exige três bancos de dados de uso relativamente intensivo: os bancos de dados de
sincronização, de Perfil e de Marcação Social. Esse serviço é dependente do
Serviço de Metadados Gerenciados. Em grandes implantações do SharePoint
Server, considere a distribuição desse serviço por um farm de serviços
compartilhados e dimensione corretamente a camada de servidor de banco de
dados para garantir desempenho aceitável das transações comuns e de trabalhos
de sincronização de diretórios.

Aplicativo de Serviço de Metadados Gerenciados O serviço que impulsiona o
repositório central de metadados e que permite a sindicalização de tipos de
conteúdo na empresa. O serviço pode ser federado para um farm de serviços
dedicados. Requer um banco de dados que pode ser co-localizado com outros
bancos de dados.

Aplicativo de Serviço do Web Analytics O serviço que agrega e armazena
estatísticas sobre características de uso do farm. Esse serviço tem demandas
relativamente altas de recursos e armazenamento do SQL Server. O serviço pode
ser federado para um farm de serviços dedicados. Em grandes implantações 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 Serviço de Conexão de Dados Corporativos O serviço que
permite a integração de vários aplicativos de linha de negócios organizacionais ao
SharePoint Server 2010. Esse serviço exige que um aplicativo de serviço mantenha
conexões de dados a recursos externos. Em grandes implantações do SharePoint
Server, nas quais ele é um recurso de uso frequente, recomendamos que você
aloque um número suficiente de servidores de aplicativos que tenham RAM
suficiente para desempenho aceitável.

Aplicativo de Serviço do InfoPath Forms O serviço que habilita formulários
baseados em navegador no SharePoint Server 2010 e a integração com o aplicativo
31
cliente do InfoPath para a criação de formulários. Esse serviço exige um servidor de
aplicativos e tem uma dependência do Aplicativo de Serviço de Controle de Sessão,
que exige um banco de dados relativamente pequeno. Esse serviço pode ser colocalizado com outros serviços e tem requisitos de capacidade relativamente
pequenos que podem crescer, dependendo da frequência de uso desse recurso.

Aplicativo de Serviço do Word Automation O serviço que permite a conversão
de arquivos do Word de um formato, como .doc, para outro formato, como .docx ou
.pdf. Esse serviço exige um servidor de aplicativos. Em grandes implantações do
SharePoint Server, nas quais ele se tornar um recurso de uso frequente,
recomendamos que você expanda o serviço para vários servidores de aplicativos
com recursos de CPU suficientes para atingir a taxa de transferência aceitável. Esse
serviço também exige um banco de dados relativamente pequeno para manter a fila
de trabalhos de conversão.

Aplicativo de Serviço do PerformancePoint O serviço que habilita os recursos de
BI do PerformancePoint no SharePoint Server 2010 e permite que você crie
visualizações analíticas. Esse serviço exige um servidor de aplicativos e um banco
de dados. Em grandes implantações 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 transferência
aceitáveis.

Aplicativo de Serviço do Project O serviço que habilita todos os recursos de
planejamento e controle do Microsoft Project Server 2010, além do SharePoint
Server 2010. Esse serviço exige um servidor de aplicativos e um banco de dados de
uso relativamente intenso. Em grandes implantações 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 soluções gerenciadas do Project
Server.

Serviço de Timer O processo responsável pela execução de várias tarefas
agendadas nos diferentes servidores do farm. Existem vários trabalhos de timer
executados pelo sistema, alguns executados em todos os servidores, e alguns
executados somente em servidores específicos, dependendo da função 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 conteúdo eles operam. Em grandes implantações do
SharePoint Server, nas quais os trabalhos de timer causam potencialmente impacto
na latência do usuário final, recomendamos que você dedique um servidor para
isolar a execução 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 utilização
de recursos depende da complexidade dos fluxos de trabalho e do número total de
eventos com os quais eles lidam. Em grandes implantações do SharePoint Server,
nas quais ele se tornar um recurso de uso frequente, você deverá considerar a
adição de servidores Web ou o isolamento de um servidor para manipular somente o
serviço de timer do fluxo de trabalho de forma a garantir que o tráfego de usuário
final não seja afetado e que as operações de fluxo de trabalho não sejam atrasadas.
32

Soluções de Área Restrita O serviço que permite o isolamento de código
personalizado para recursos dedicados do farm. Em grandes implantações do
SharePoint Server, nas quais ele se tornar um recurso de uso frequente, você
deverá considerar a dedicação de servidores Web adicionais se o código
personalizado começar a causar impacto no desempenho do servidor.
Novas interações de aplicativos clientes com o SharePoint Server
2010
Esta seção descreve algumas das novas interações entre cliente e servidor que têm
suporte no SharePoint Server 2010 e suas implicações de planejamento e capacidade.
A tabela a seguir oferece uma descrição geral simplificada da carga típica que esses
novos recursos introduzem no sistema:
X – indica carga mínima ou insignificante nos recursos do sistema
XX – indica carga média nos recursos do sistema
XXX – indica carga alta nos recursos do sistema
Cliente
Tráfego
Carga
Office Web Apps
XXX
XX
Transmissão 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 exibição e edição na Web de arquivos do Word, PowerPoint,
Excel e OneNote é um subconjunto de solicitações de navegador, com
características de tráfego ligeiramente diferentes, esse tipo de interação introduz
uma carga relativamente alta de tráfego necessário para habilitar recursos como a
coautoria. Em grandes implantações do SharePoint Server, nas quais esses
recursos forem habilitados, você deverá esperar carga adicional nos servidores Web.

Transmissão do PowerPoint O conjunto de solicitações associado à exibição ao
vivo de apresentações do PowerPoint em um navegador da Web é outro
subconjunto de solicitações de navegador. Durante sessões de transmissão ao vivo
do PowerPoint, os clientes participantes solicitam alterações do serviço. Em grandes
implantações 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 sessão de coautoria carregam e baixam
atualizações com frequência para e do servidor. Em grandes implantações do
33
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 à versão anterior do OneNote
e usa o SharePoint Server 2010 para compartilhar e habilitar a coautoria de blocos
de notas do OneNote. Esse cenário introduz carga no SharePoint Server 2010,
mesmo quando o cliente está aberto, mas não está sendo ativamente usado. Em
grandes implantações 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 também pode ser adicionado a versões anteriores do
Outlook). Esse recurso permite que você exiba atividade social solicitada do farm
SharePoint Server diretamente em emails. Em grandes implantações 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
execução, independentemente de estar sendo usado ativamente. Em grandes
implantações do SharePoint Server, nas quais ele for um recurso de uso frequente,
você deverá esperar carga adicional nos servidores Web.
Diferenciadores de chave de implantação do
SharePoint Server 2010
Cada implantação do SharePoint Server 2010 tem um conjunto fundamental de
características que o tornarão exclusivo e diferente de outros farms. Esses
diferenciadores fundamentais podem ser descritos por estas quatro categorias principais:
 Especificação Descreve o hardware do farm, além de sua topologia e
configuração.

Carga de trabalho Descreve a demanda no farm, incluindo o número e as
características de uso.

Conjunto de dados Descreve os tamanhos e a distribuição de conteúdo.

Integridade e desempenho Descreve o desempenho do farm em relação a
objetivos de latência e taxa de transferência.
Especificações
Hardware
Hardware são os recursos físicos do computador, como processadores, memória e
discos rígidos. O hardware também inclui componentes físicos 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
34
aplicação de recurso de hardware, como memória insuficiente em um servidor, pode
afetar o desempenho de todo o farm.
Topologia
A topologia é a distribuição e os interrelacionamentos de hardware e componentes do
farm. Existem dois tipos de topologias:
 Topologia lógica O mapa de componentes de software, como serviços e recursos
de um farm.
 Topologia física O mapa de servidores e recursos físicos.
Normalmente, o número de usuários e de características de uso determinam a topologia
física de um farm, e requisitos de negócios, como a necessidade de suporte a recursos
específicos para cargas esperadas, orientam a topologia lógica
Configuração
Usamos o termo configuração para descrever configurações de software e como os
parâmetros são definidos. Além disso, a configuração refere-se a cache, RBS, como os
limites configuráveis são definidos e qualquer parte do ambiente de software que possa
ser definido ou modificado para atender a requisitos específicos.
Carga de trabalho
Carga de trabalho define as características operacionais fundamentais do farm, incluindo
a base de usuários, simultaneidade, recursos em uso e os agentes de usuário ou
aplicativos clientes usados para a conexão 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 características de uso permitirá que você dimensione sua
implementação corretamente e reduza o risco de executar o sistema constantemente em
uma condição não íntegra.
Base de Usuários
A base de usuários de um aplicativo baseado no SharePoint Server é uma combinação
de número total de usuários e como eles estão distribuídos geograficamente. Além
disso, na base de usuários total, existem subgrupos de usuários que podem usar
determinados recursos ou serviços de forma mais intensa do que outros grupos. A
simultaneidade de usuários é definida como o percentual total de usuários usando
ativamente o sistema em um determinado momento. Os indicadores que definem a base
de usuários incluem o número total de usuários exclusivos e o número de usuários
simultâneos.
Características de Uso
O desempenho de um farm pode ser afetado não só pelo número de usuários
interagindo com o sistema, como também por suas características de uso. Duas
organizações com o mesmo número de usuários podem ter requisitos significativamente
diferentes com base na frequência em que os usuários acessam os recursos do farm e
se recursos e serviços de uso intensivo estão habilitados no farm. Os indicadores que
descrevem as características de uso incluem a frequência de operações exclusivas, a
mistura operacional geral (a proporção entre operações de leitura e gravação e de
operações administrativas) e os padrões de uso e carga em relação a novos recursos
habilitados no farm (como os sites Meu Site, Pesquisa Fluxos de Trabalho e o Office
Web Apps).
35
Conjunto de Dados
O volume de conteúdo armazenado no sistema e as características 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 frequência de acesso e a
distribuição dos dados permitirá que você dimensione corretamente o armazenamento
no sistema e evite que ele se torne o afunilamento que atrasa interações de usuários
com serviços do farm, além de afetar a experiência do usuário final.
Para estimar corretamente e projetar a arquitetura de armazenamento de uma solução
baseada no SharePoint Server, você precisa conhecer o volume de dados que
armazenará no sistema e quantos usuários estão solicitando dados de diferentes fontes
de dados. O volume do conteúdo é um elemento importante da capacidade de
dimensionamento de disco, porque pode influenciar o desempenho de outros recursos,
além de afetar potencialmente a latência e a largura de banda disponível da rede. Os
indicadores que definem o conjunto de dados incluem o tamanho total do conteúdo, o
número total de documentos, o número total de conjuntos de sites e os tamanhos médio
e máximo do conjunto de sites.
Integridade e desempenho
A integridade do farm do SharePoint Server é, basicamente, uma medida simplificada ou
pontuação que reflete a confiabilidade, a estabilidade e o desempenho do sistema. A
qualidade do desempenho do farm em relação aos objetivos depende basicamente dos
três primeiros diferenciadores. A pontuação de integridade e desempenho pode ser
controlada e descrita por uma destilação de um conjunto de indicadores. Para obter mais
informações, consulte Monitorando e mantendo o SharePoint Server 2010. Esses
indicadores incluem o tempo de ativação do sistema, a latência percebida pelo usuário,
taxas de falha de página e os indicadores de utilização de recursos (CPU, RAM).
Qualquer alteração significativa de hardware, topologia, configuração, carga de trabalho
ou conjunto de dados pode variar significativamente a confiabilidade e a capacidade de
resposta do sistema. A pontuação de integridade pode ser usada para controlar o
desempenho com o passar do tempo e para avaliar como as condições de operação em
alteração ou as modificações do sistema afetam a confiabilidade do farm.
Arquiteturas de referência
O SharePoint Server 2010 é um produto complexo e poderoso, e não há uma solução de
arquitetura de tamanho único. Cada implantação do SharePoint Server é exclusiva e
definida por suas características de uso e de dados. Todas as organizações 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 personalização de uma solução dimensionada de forma correta que
atenda melhor às necessidades organizacionais.
O conceito de arquitetura de referência destina-se a descrever e ilustrar as principais
categorias diferentes de implantações do SharePoint Server e não para fornecer uma
receita para arquitetos usarem para projetar suas soluções. Esta seção se concentra na
descrição dos vetores nos quais as implantações do SharePoint Server são geralmente
dimensionadas.
As arquiteturas relacionadas aqui são oferecidas como uma maneira útil de compreender
os diferenciadores gerais entre essas categorias genéricas e para distingui-las por
fatores de custo geral e por escala de esforço.
36
Implantação de servidor único
A arquitetura de implantação de servidor único consiste em um servidor que executa o
SharePoint Server 2010 e uma versão com suporte do SQL Server. Essa arquitetura
pode ser apropriada para fins de avaliação, desenvolvedores ou para uma implantação
departamental isolada que não seja de missão crítica com apenas alguns usuários. No
entanto, não recomendamos seu uso em um ambiente de produção.
Implantação de farm pequeno
Uma implantação 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
características de arquitetura incluem redundância e failover limitados e um conjunto
mínimo de recursos do SharePoint Server habilitados.
Um farm pequeno é útil para servir somente a implantações limitadas, com um conjunto
mínimo de aplicativos de serviço habilitados, uma base de usuários relativamente
pequena e uma carga de uso relativamente baixa (poucas solicitações por minuto até
muito poucas solicitações por segundo) e um volume relativamente pequeno de dados
(10 ou mais gigabytes).
Implantação de farm médio
Essa arquitetura introduz a divisão da topologia em três camadas: servidores Web
dedicados, servidores de aplicativos dedicados e um ou mais servidores de banco de
dados ou clusters. A separação da camada de servidor de front-end da camada de
servidor de aplicativos permite maior flexibilidade em isolamento de serviços e auxilia o
balanceamento de carga no sistema.
37
Essa não é a arquitetura mais comum e inclui um amplo espectro de topologias de
serviço e de tamanhos de farm. Uma implantação de farm médio é útil para servir
ambientes com:
 Vários aplicativos de serviço distribuídos em vários servidores. Um conjunto típico de
recursos poderia incluir o Serviço do Office Web Apps, o Serviço de Perfil de
Usuário, o Serviço de Metadados Gerenciados e o Serviço de Cálculo do Excel.

Uma base de usuários de dezenas de milhares de usuários e uma carga de 10 a 50
solicitações por segundo.

Um repositório de dados de um ou dois terabytes.
Implantação de farm grande
Implantações de farm grande introduzem a divisão de serviços e soluções entre vários
farms e uma expansão adicional das camadas em um único farm. Vários serviços do
SharePoint Server podem ser implantados em um farm de serviços dedicados que serve
solicitações de vários farms de consumo. Nessas arquiteturas grandes, tipicamente
existem servidores Web, vários servidores de aplicativos, dependendo da característica
de uso de cada um dos serviços locais (não compartilhados) e vários servidores
baseados no SQL Server ou clusters do SQL Server, dependendo do tamanho do
38
conteúdo e dos bancos de dados de serviços de aplicativo habilitados no farm. Esperase que as arquiteturas de farm grande sirvam implantações com:
 Vários aplicativos de serviço federados e consumidos do farm de serviços
dedicados, normalmente o Serviço de Perfil de Usuário, Pesquisa, serviço de
Metadados Gerenciados e Web Analytics.

A maioria dos outros aplicativos de serviço é habilitada localmente.

Uma base de usuários no intervalo de centenas de milhares de usuários.

Uma carga de uso no intervalo de centenas de solicitações por segundo.

Um conjunto de dados no intervalo de dezenas ou mais de terabytes.
39
Consulte também
Conceitos
Planejamento de capacidade para SharePoint Server 2010
Testes de desempenho para SharePoint Server 2010
Monitorando e mantendo o SharePoint Server 2010
Gerenciamento de capacidade do SharePoint Server 2010: limites de software
40
Recomendações e resultados de testes de desempenho e capacidade (SharePoint
Server 2010)
Performance and capacity technical case studies (SharePoint Server 2010) (em inglês)
Outros recursos
Hardware and software requirements (SharePoint Server 2010)
41
Planejamento de capacidade para
SharePoint Server 2010
Este artigo descreve como planejar a capacidade de um farm do Microsoft SharePoint
Server 2010. Com uma boa estimativa e um bom entendimento do planejamento e
gerenciamento da capacidade, você pode aplicar seu conhecimento para dimensionar o
sistema. Dimensionamento é o termo usado para descrever a seleção e configuração da
arquitetura de dados apropriada, topologia lógica e física e hardware para uma
plataforma de solução. Há diversas considerações de uso e gerenciamento da
capacidade que afetam o modo como você deve determinar as opções mais adequadas
de hardware e configuração.
Antes de ler este artigo, leia Visão 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
informações para que sua execução 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 estão descritos em tabelas.
Neste artigo:
 Etapa 1: Modelo

Etapa 2: Design

Etapa 3: Piloto, Teste e Otimização

Etapa 4: Implantação

Etapa 5: Monitoração e Manutenção
Etapa 1: Modelo
A modelagem do seu ambiente baseado no SharePoint Server 2010 começa com a
análise das soluções existentes e a estimativa da demanda e das metas esperadas para
a implantação que pretende configurar. Comece coletando informações sobre a base de
usuários, os requisitos de dados, as metas de latência e produtividade e documente os
recursos do SharePoint Server que deseja implantar. Use esta seção 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 implementação do SharePoint Server 2010
requer estudo e compreensão das características da demanda esperada pela sua
solução. A compreensão da demanda requer a capacidade de descrever tanto as
características da carga de trabalho, como número de usuários e operações utilizadas
mais frequentemente, quanto as características do conjunto de dados, como
dimensionamento e distribuição de conteúdo.
Esta seção pode ajudar a compreender algumas métricas e parâmetros específicos que
devem ser coletados e os mecanismos que podem ser usados para a coleta.
42
Carga de trabalho
A carga de trabalho descreve a demanda à qual o sistema deverá atender, a base de
usuários e as características de uso. A tabela a seguir apresenta algumas métricas
fundamentais úteis na determinação da carga de trabalho. É possível usar esta tabela
para registrar essas métricas à medida que são coletadas.
Características da Carga de
Trabalho
Valor
Média do RPS diário
Média do RPS no horário de pico
Número total de usuários
exclusivos por dia
Média diária de usuários
simultâneos
Usuários simultâneos no horário de
pico
Número total de solicitações por dia
Distribuição da carga de trabalho
esperada
Número de solicitações por dia
Navegador da Web Rastreamento de Pesquisa
Navegador da Web - Interação
Geral de Colaboração
Navegador da Web - Interação
Social
Navegador da Web - Interação
Geral
Navegador da Web - Office Web
Apps
Clientes do Office
Cliente do OneNote
SharePoint Workspace
Sincronização de RSS do Outlook
Outlook Social Connector
Outras interações (Aplicativos
Personalizados/serviços Web)
43
%

Usuários simultâneos – É mais comum medir a simultaneidade das operações
executadas no farm de servidores como o número de usuários distintos que geram
solicitações em determinado intervalo de tempo. As métricas principais são a média
diária e os usuários simultâneos na carga de pico.

Solicitações por segundo (RPS) – RPS é um indicador normalmente usado para
descrever a demanda do farm de servidores expressada no número de solicitações
processadas pelo farm por segundo, mas sem diferenciar entre o tipo ou o tamanho
das solicitações. A base de usuários de cada organização gera uma carga no
sistema a uma taxa que depende das características de uso exclusivas da
organização. Consulte a seção Glossário em Visão geral do gerenciamento da
capacidade e dimensionamento do SharePoint Server 2010 para obter mais
informações sobre este termo.

Total de solicitações diárias – Total de solicitações diárias é um bom indicador da
carga geral à qual o sistema deve atender. É mais comum medir todas as
solicitações, exceto as solicitações de handshake de autenticação (status HTTP 401)
em um período de 24 horas.

Total de usuários diários – Total de usuários é outro indicador fundamental da
carga geral à qual o sistema deve atender. Essa medida é o número real de usuários
exclusivos em um período de 24 horas, e não o número total de funcionários da
organização.
Observação:
O número total de usuários diários pode indicar o crescimento potencial da carga no
farm. Por exemplo, se o número de usuários potenciais for de 100 mil funcionários, 15 mil
usuários diários indicam que a carga pode crescer significativamente com o tempo, à
medida que cresce a adoção dos usuários.

Distribuição da Carga de Trabalho – Compreender a distribuição das solicitações
com base nos aplicativos clientes que interagem com o farm pode ajudar a prever a
tendência esperada e as alterações de carga após a migração para o SharePoint
Server 2010. Conforme os usuários fazem a transição para as versões mais
recentes do cliente, como o Office 2010, e começam a usar os novos recursos, é
esperado o crescimento de novos padrões de carga, RPS e solicitações totais. Para
cada cliente, podemos descrever o número de usuários distintos que o utilizam em
determinado intervalo de tempo do dia e a quantidade de solicitações totais que o
cliente ou o recurso gera no servidor.
Por exemplo, o gráfico a seguir mostra um instantâneo de um ambiente interno real
da Microsoft que trabalha com uma solução social típica. Neste exemplo, é possível
ver que a maior parte da carga é gerada pelo rastreador de pesquisa e pela
navegação na Web comum do usuário final. É possível também observar que existe
uma carga significativa que foi introduzida pelo novo recurso Outlook Social
Connector (6,2% das solicitações).
44
45
Estimando sua carga de trabalho de produção
46
Na estimativa da produtividade necessária que seu farm precisa manter, comece
estimando a combinação de transações que será usada no farm. Concentre-se na
análise das transações utilizadas mais frequentemente às quais o sistema atenderá,
conhecendo a frequência com que elas serão usadas e por quantos usuários. Isso o
ajudará a validar no futuro se o farm será capaz de manter essa carga no teste de préprodução.
O diagrama a seguir descreve a relação entre a carga de trabalho e a carga no sistema:
Para estimar sua carga de trabalho esperada, colete as seguintes informações:
 Identifique as interações do usuário, como navegações comuns de páginas da Web,
downloads e carregamentos de arquivos, modos de exibição e edições do Office
Web Application no navegador, interações de coautoria, sincronizações de sites do
SharePoint Workspace, Conexões Sociais do Outlook, sincronização de RSS (no
Outlook ou outros visualizadores), Transmissões do PowerPoint, blocos de
anotações compartilhados do OneNote, pastas de trabalho compartilhadas do
47
Serviço do Excel, aplicativos compartilhados do Serviço do Access e outros.
Consulte a seção Serviços e recursos do artigo Visão geral do gerenciamento da
capacidade e dimensionamento do SharePoint Server 2010 para obter mais
informações. Mantenha o foco na identificação das interações que podem ser
exclusivas à sua implantação e reconheça o impacto esperado desse tipo de carga.
Alguns exemplos podem ser o uso significativo de Formulários do InfoPath, Cálculos
do Serviço do Excel e soluções semelhantes dedicadas.

Identifique as operações de sistema, como rastreamentos incrementais de Pesquisa,
backups diários, trabalhos de timer de sincronização de perfis, processamento do
Web Analytics, registro dos trabalhos de timer e outros.

Calcule o número total de usuários esperados por dia que utilizarão cada recurso,
obtenha os usuários simultâneos esperados e as Solicitações de alto nível por
segundo. Há algumas suposições a fazer, como a simultaneidade presente e o fator
de RPS por usuários simultâneos que é diferente entre os recursos. Convém usar a
tabela de carga de trabalho apresentada anteriormente nesta seção para suas
estimativas. É importante focar os horários de pico, em vez da produtividade média.
Planejando a atividade de pico, você é capaz de dimensionar adequadamente a sua
solução baseada no SharePoint Server 2010.
Caso tenha uma solução 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 solução existente, ou
consulte as instruções na seção a seguir para obter mais detalhes. Se não estiver
migrando de uma solução existente, preencha a tabela usando estimativas aproximadas.
Nas etapas subsequentes, será preciso validar suas suposições e ajustar o sistema.
Analisando os logs do IIS do SharePoint Server 2010
Para descobrir as métricas principais relacionadas a uma implantação do SharePoint
Server 2010 existente, como a quantidade de usuários ativos, como eles utilizam o
sistema, que tipo de solicitações estão chegando e de que tipo de cliente elas são
originadas, é necessário extrair os dados dos logs ULS e do IIS. Uma das maneiras mais
fáceis de adquirir esses dados é usar o Analisador de Logs, uma ferramenta avançada
da Microsoft disponível gratuitamente para download. O Analisador de Logs é capaz de
ler e gravar em uma variedade de formatos de texto e binários, incluindo todos os
formatos do IIS.
Para obter informações detalhadas sobre como analisar o uso do SharePoint Server
2010 por meio do Analisador de Logs, leia o artigo sobre como analisar o uso dos
Produtos e Tecnologias do Microsoft SharePoint
(http://www.microsoft.com/downloads/en/details.aspx?familyid=f159af68-c3a3-413c-a3f72e0be6d5532e&displaylang=en).
É possível baixar o Analisador de Logs 2.2 pelo site
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=890CD06B-ABF8-4C2591B2-F8D975CF8C07&displayLang=en.
Conjunto de dados
O conjunto de dados descreve o volume de conteúdo armazenado no sistema e como
ele pode ser distribuído no repositório de dados. A tabela a seguir apresenta algumas
métricas fundamentais úteis na determinação do conjunto de dados. É possível usar esta
tabela para registrar essas métricas à medida que são coletadas.
48
Objeto
Valor
Tamanho do BD (em GB)
Número de BDs de Conteúdo
Número de conjuntos de sites
Número de aplicativos web
Número de sites
Tamanho do índice de pesquisa (número de
itens)
Número de documentos
Número de listas
Tamanho médio dos sites
Tamanho do maior site
Número de perfis de usuário

Tamanho do conteúdo – Saber o tamanho do conteúdo que você espera
armazenar no sistema do SharePoint Server 2010 é importante para o planejamento
e a arquitetura do armazenamento do sistema, e também para o dimensionamento
adequado da solução de Pesquisa que vai rastrear e indexar esse conteúdo. O
tamanho do conteúdo está descrito no espaço total em disco. Se estiver migrando
conteúdo de uma implantação existente, você pode achar simples identificar o
tamanho total que vai mover; enquanto no planejamento, você deve deixar espaço
para o crescimento com o passar do tempo, baseado na tendência prevista.

Número total de documentos – Além do tamanho dos dados, é importante
acompanhar o número geral de itens. O sistema reage de forma diferente quando
100 GB dos dados são constituídos de 50 arquivos de 2 GB cada ou de 100.000
arquivos de 1 KB cada. Em implantações maiores, quanto menor o estresse em um
único item, melhor o desempenho. Um conteúdo amplamente distribuído, como
vários arquivos menores entre diversos sites e conjuntos de sites, é mais fácil de ser
atendido do que somente uma biblioteca grande de documentos com arquivos muito
grandes.

Tamanho máximo do conjunto de sites – É importante identificar qual é a maior
unidade de conteúdo que você vai armazenar no SharePoint Server 2010.
Geralmente, isso é uma necessidade organizacional que o impede de dividir essa
unidade de conteúdo. O tamanho médio de todos os conjuntos de sites e o número
total estimado de conjuntos de sites são indicadores adicionais que o ajudam a
identificar a arquitetura de dados de sua preferência.

Características de dados dos aplicativos de serviço – Além de analisar as
necessidades de armazenamento do repositório de conteúdo, analise e calcule os
tamanhos de outros repositórios do SharePoint Server 2010, incluindo:

Tamanho total do índice de Pesquisa
49

O tamanho total do banco de dados de perfil com base no número de usuários no
repositório de perfil

O tamanho total do banco de dados social com base no número esperado de
marcas, colegas e atividades

O tamanho do repositório de metadados

O tamanho do banco de dados de uso
 O tamanho do banco de dados do Web Analytics
Para obter mais informações sobre como estimar os tamanhos de banco de dados,
consulte Planejamento e configuração de armazenamento e capacidade do SQL Server
(SharePoint Server 2010).
Definindo as metas de desempenho e confiabilidade do farm
Um dos resultados finais da Etapa 1: Modelo é o bom entendimento das metas de
desempenho e confiabilidade mais adequadas às necessidades da sua organização.
Uma solução do SharePoint Server projetada adequadamente deve ser capaz de atingir
os "quatro noves" (99,99%) de duração da operação com capacidade de resposta do
servidor em milésimos de segundo.
Os indicadores usados para descrever o desempenho e a confiabilidade do farm podem
incluir:
 Disponibilidade do servidor – Geralmente, descrita pela porcentagem de duração
da operação geral do sistema. Convém acompanhar qualquer tempo de inatividade
inesperado e comparar a disponibilidade geral com a meta definida para a
organização. As metas são 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
solicitações é um bom indicador para acompanhar a integridade do farm. Esse
indicador é normalmente chamado de latência do servidor, e é comum usar a
latência média ou mediana (50 percentil) das solicitações diárias que são atendidas.
As metas são normalmente descritas em milésimos de segundo ou em segundos.
Observe que se a sua organização tem uma meta para atender páginas do
SharePoint Server 2010 em menos de dois segundos, o objetivo do servidor precisa
estar em milésimos de segundo para dar tempo para a página atingir o cliente pela
rede e tempo para a renderização no navegador. Em geral, tempos mais longos de
resposta do servidor são uma indicação 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 solicitações no
servidor.

Capacidade de pico do servidor – Outro bom indicador de latência no servidor que
vale a pena acompanhar é o comportamento dos 5% das solicitações mais lentas de
todas. As solicitações mais lentas em geral são aquelas que chegam ao sistema
quando ele está sob uma carga maior ou, mais comumente, são as solicitações
impactadas por atividades menos frequentes que ocorrem durante a interação dos
usuários com o sistema. Um sistema íntegro é aquele que também tem as
solicitações mais lentas sob controle. A meta aqui é semelhante à Capacidade de
Resposta do Servidor exceto que, para atingir a resposta em milésimos de segundo
na capacidade de pico do servidor, você precisará construir o sistema com muitos
recursos sobressalentes para lidar com os picos de carga.
50

Utilização de recursos do sistema – Outros indicadores comuns usados para
acompanhar a integridade do sistema são uma coleção de contadores de sistema
que indicam a integridade de cada servidor na topologia do farm. Os indicadores
utilizados mais frequentemente são % de utilização da CPU e Memória Disponível;
porém, há vários contadores adicionais que podem ajudar a identificar um sistema
com problemas. Você encontra mais detalhes na Etapa 5: Monitoração e
Manutenção.
Etapa 2: Design
Agora que já concluiu a coleta de alguns fatos ou estimativas sobre a solução que
precisa entregar, você está pronto para começar a próxima etapa de criação de uma
arquitetura proposta prevista para atender à demanda esperada.
No fim desta etapa, você deverá ter sua topologia física criada e um layout para a
topologia lógica, de forma que seja capaz de realizar todas as ordens de compra
necessárias.
As especificações de hardware e o número de computadores esquematizados estão
totalmente relacionados. Para tratar de uma carga específica, há várias soluções que
você pode escolher para implantação. É comum usar um pequeno conjunto de
computadores fortes (dimensionamento vertical) ou um conjunto maior de computadores
menores (dimensionamento horizontal). Cada solução tem suas vantagens e
desvantagens quando se trata de capacidade, redundância, potência, custo, espaço e
outras considerações.
É recomendável começar esta etapa determinando a arquitetura e topologia. Defina
como pretende esquematizar os diferentes farms e serviços em cada farm e, em
seguida, escolha as especificações de hardware para cada servidor individual em seu
design. É possível também executar este processo identificando as especificações de
hardware esperadas para implantação (muitas organizações estão restritas a
determinados padrões da empresa) e, na sequência, definir a arquitetura e topologia.
Use a tabela a seguir para registrar seus parâmetros de design. Os dados incluídos são
apenas exemplos e não devem ser utilizados para dimensionar seu farm. Sua intenção é
demonstrar como usar esta tabela com seus próprios dados.
Função
Tipo
Processamentos RAM IOPS
Tamanho Unidade
Número de
(Padrão
necessário do disco de
computadores
SO+Log dados
ou virtual)
Servidores
Web
Virtual
4
4 núcleos
Servidor de
banco de
dados de
conteúdo
Padrão
1 cluster
48
4 núcleos
quádruplos 2.33
(GHz)
51
8
N/A
400 GB N/A
2 mil
400 GB 20
discos
de 300
GB
A 15
mil
RPM
Função
Tipo
Processamentos RAM IOPS
Tamanho Unidade
Número de
(Padrão
necessário do disco de
computadores
SO+Log dados
ou virtual)
Servidores de Virtual
aplicativos
4
4 núcleos
16
N/A
400 GB N/A
Servidor Web Virtual
de Destino de
Rastreamento
de Pesquisa
1
4 núcleos
8
N/A
400 GB N/A
Servidor de
Consulta de
Pesquisa
Padrão
2
32
2 núcleos
quádruplos 2.33
(GHz)
N/A
400 GB 500 GB
Servidor do Padrão
Rastreador
de Pesquisa
2
16
2 núcleos
quádruplos 2.33
(GHz)
400
400 GB N/A
Servidor de Padrão
banco de
dados de
Rastreamento
de Pesquisa
1 cluster
48
4 núcleos
quádruplos 2.33
(GHz)
4 mil
100 GB
(ajustado
para
leitura)
16
discos
de 150
GB a
15 mil
RPM
Banco de
Padrão
dados de
Repositório
de
Propriedades
de Pesquisa
+ Servidor de
banco de
dados de
administração
1 cluster
48
4 núcleos
quádruplos 2.33
(GHz)
2 mil
100 GB
(ajustado
para
gravação)
16
discos
de 150
GB a
15 mil
RPM
Determinar a arquitetura de ponto de partida
Esta seção descreve como selecionar uma arquitetura de ponto de partida.
Ao implantar o SharePoint Server 2010, você pode escolher dentre várias topologias
para implementar a solução. É possível implantar um servidor único ou dimensionar
vários servidores em um farm do SharePoint Server com servidores de banco de dados
clusterizados ou espelhados e servidores de aplicativos discretos para diversos serviços.
Posteriormente, você selecionará as configurações de hardware baseadas nos requisitos
de cada uma das funções, com base nas necessidades de capacidade, disponibilidade e
redundância.
Comece analisando as diferentes arquiteturas de referência e descubra a estrutura do
seu farm, decida se vai dividir a solução em vários farms ou federar alguns serviços,
como pesquisa, em um farm dedicado. Consulte a seção Arquiteturas de referência
52
em Visão geral do gerenciamento da capacidade e dimensionamento do SharePoint
Server 2010 para obter mais informações.
Estudos de caso técnicos do SharePoint Server 2010
As diretrizes de gerenciamento de capacidade para o SharePoint Server 2010 incluem
um número de estudos de caso técnicos de ambientes de produção existentes que
apresentam uma descrição detalhada dos ambientes de produção baseados no
SharePoint Server. Outros estudos de caso técnicos serão publicados com o tempo; eles
servirão como referência para criar um ambiente baseado no SharePoint Server para
fins específicos.
É possível usar estes estudos de caso como referência ao criar a arquitetura das
soluções do SharePoint Server, principalmente se achar a descrição desses
diferenciadores-chave específicos da implantação parecidos com as demandas e metas
da solução que está arquitetando.
Estes documentos descrevem as seguintes informações para cada estudo de caso
registrado:
 Especificações, como hardware, topologia e configuração do farm;

Carga de trabalho, incluindo a base de usuários e as características de uso;

Conjunto de dados, incluindo tamanhos de conteúdos, características e distribuição
do conteúdo;

Integridade e desempenho, incluindo um conjunto de indicadores registrados
descrevendo as características de confiabilidade e desempenho do farm.
Para obter mais informações, baixe os documentos relevantes da página de estudos de
caso técnicos sobre desempenho e capacidade (http://technet.microsoft.com/ptbr/library/cc261716.aspx).
Selecionar o hardware
A seleção das especificações corretas para os computadores do farm é uma etapa
crucial para garantir confiabilidade e desempenho adequados à sua implantação. Um
conceito fundamental que você deve ter em mente é o planejamento para a carga de
pico e os horários de pico; em outras palavras, quando o farm está operando em
condições de carga média, deve haver recursos suficientes disponíveis para atender à
maior demanda esperada e ainda atingir as metas de latência e produtividade.
Os recursos básicos de hardware de capacidade e desempenho dos servidores refletem
as quatro principais categorias: potência de processamento, desempenho do disco,
capacidade da rede e recursos de memória do sistema.
Outra consideração é utilizar computadores virtualizados. Um farm do SharePoint Server
pode ser implantado usando computadores virtuais. Embora não se tenha notado
nenhum benefício de desempenho com isso, existem alguns benefícios de
gerenciamento. A virtualização de computadores baseados no SQL Server em geral não
é recomendada, mas podem haver alguns benefícios ao se virtualizar as camadas do
servidor Web e do servidor de aplicativos. Para obter mais informações, consulte o artigo
sobre planejamento da virtualização (http://technet.microsoft.com/pt-br/library/71c203cd7534-47b0-9122-657d72ff0080(Office.14).aspx).
Diretrizes de seleção de hardware
Escolhendo processadores
53
O SharePoint Server 2010 só está disponível para processadores de 64 bits. Em geral,
mais processadores lhe permitirão atender a uma demanda maior.
No SharePoint Server 2010, servidores Web individuais serão dimensionados à medida
que você adicionar mais núcleos (testamos até 24 núcleos); quanto mais núcleos o
servidor tiver, mais carga ele poderá sustentar, em condições normais. Em grandes
implantações do SharePoint Server, é recomendado alocar vários servidores Web de 4
núcleos (que podem ser virtualizados) ou menos servidores Web mais fortes (8, 16, 24
núcleos).
Os requisitos de capacidade do processador dos servidores de aplicativos são diferentes
dependendo da função do servidor e dos serviços que estão sendo executados. Alguns
recursos do SharePoint Server exigem maior potência de processamento que outros.
Por exemplo, o Serviço de Pesquisa do SharePoint é altamente dependente da potência
de processamento do servidor de aplicativos. Para obter mais informações sobre os
requisitos de recursos e serviços do SharePoint Server, consulte Serviços e recursos
anteriormente neste documento.
Os requisitos de capacidade do processador para o SQL Server também dependem dos
bancos de dados de serviço que está hospedado em um computador baseado no SQL
Server. Para obter mais informações sobre o comportamento comum e os requisitos de
cada banco de dados, consulte Planejamento e configuração de armazenamento e
capacidade do SQL Server (SharePoint Server 2010).
Escolhendo a memória
Os servidores exigem quantidades variadas de memória, de acordo com a função do
servidor. Por exemplo, os servidores que executam os componentes de rastreamento de
Pesquisa processarão os dados mais rapidamente se tiverem uma grande quantidade de
memória, pois os documentos são lidos na memória para o processamento. Servidores
Web que utilizam vários dos recursos de cache do SharePoint Server 2010 também
podem exigir mais memória.
Em geral, os requisitos de memória do servidor Web são altamente dependentes do
número de pools de aplicativos habilitados no farm e do número de solicitações
simultâneas que estão sendo atendidas. Na maioria das implantações de produção do
SharePoint Server, é recomendável alocar no mínimo 8 GB de RAM em cada servidor
Web, com uma recomendação de 16 GB para servidores com maior tráfego ou
implantações com vários pools de aplicativos configurados para isolamento.
Os requisitos de memória dos servidores de aplicativos também são diferentes: alguns
recursos do SharePoint Server apresentam maior requisito de memória na camada do
aplicativo do que outros. Na maioria das implantações de produção do SharePoint
Server, é recomendável alocar no mínimo 8 GB de RAM em cada servidor de aplicativos;
servidores de aplicativos de 16 GB, 32 GB e 64 GB são comuns quando muitos serviços
de aplicativo estão habilitados no mesmo servidor, ou quando serviços altamente
dependentes da memória, como o Serviço de Cálculo do Excel e o Serviço de Pesquisa
do SharePoint Server, estão habilitados.
Os requisitos de memória dos servidores de banco de dados são totalmente
dependentes dos tamanhos dos bancos de dados. Para obter mais informações sobre
como escolher a memória para seus computadores baseados no SQL Server, consulte
Planejamento e configuração de armazenamento e capacidade do SQL Server
(SharePoint Server 2010).
Escolhendo redes
54
Além do benefício oferecido aos usuários quando os clientes têm acesso rápido aos
dados pela rede, um farm distribuído deve ter acesso rápido para comunicação entre
servidores. Isso é verdade principalmente quando você distribui os serviços por vários
servidores ou faz a federação de alguns dos serviços para outros farms. Existe um
tráfego 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 condições, 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 tráfego do
usuário final e outra para tratar da comunicação entre servidores. A latência de rede
entre os servidores pode ter um impacto significativo no desempenho, por isso, é
importante manter menos de 1 milissegundo de latência de rede entre o servidor Web e
os computadores baseados no SQL Server que hospedam os bancos de dados de
conteúdo. Os computadores baseados no SQL Server que hospedam cada banco de
dados de aplicativo de serviço devem estar o mais próximo possível também do servidor
de aplicativos de consumo. A rede entre os servidores do farm deve ter no mínimo 1
Gbps de largura de banda.
Escolhendo discos e armazenamento
O gerenciamento de disco não é simplesmente uma função para fornecer espaço
adequado aos seus dados. Avalie a demanda e o crescimento constante e verifique se a
arquitetura de armazenamento não está deixando o sistema mais lento. Verifique
sempre se você tem no mínimo 30% de capacidade adicional em cada disco, acima da
sua maior estimativa de requisitos de dados, para deixar espaço para um crescimento
futuro. Além disso, na maioria dos ambientes de produção, a velocidade do disco (IOps)
é fundamental para fornecer produtividade suficiente para atender às demandas de
armazenamento dos servidores. Você deve estimar a quantidade de tráfego (IOps) que
os bancos de dados principais vão precisar na sua implantação e alocar discos
suficientes para satisfazer o tráfego.
Para obter mais informações sobre como escolher discos para servidores de banco de
dados, consulte Planejamento e configuração de armazenamento e capacidade do SQL
Server (SharePoint Server 2010).
Os servidores Web e de aplicativos também têm requisitos de armazenamento. Na
maioria dos ambientes de produção, é recomendável alocar no mínimo 200 GB de
espaço em disco para o SO e os arquivos temporários e 150 GB de espaço em disco
para os logs.
Etapa 3: Piloto, Teste e Otimização
O estágio de teste e otimização é um componente crítico do gerenciamento de
capacidade eficaz. Teste as novas arquiteturas antes de implantá-las na produção e
conduza um teste de aceitação em conjunto com as seguintes práticas recomendadas
de monitoramento para garantir que as arquiteturas criadas atinjam as metas de
desempenho e capacidade. Dessa forma, você identifica e otimiza possíveis
afunilamentos antes que eles afetem os usuários em uma implantação dinâmica. Se
você está atualizando de um ambiente do Office SharePoint Server 2007 e pretende
fazer alterações na arquitetura, ou está estimando a carga do usuário dos novos
recursos do SharePoint Server, o teste é importante principalmente para verificar se o
55
seu novo ambiente baseado no SharePoint Server vai atender às metas de desempenho
e capacidade.
Após testar o seu ambiente, você pode analisar os resultados do teste para determinar
quais alterações são necessárias para atingir as metas de desempenho e capacidade
estabelecidas na Etapa 1: Modelo.
Estas são as subetapas recomendadas que você deve seguir para pré-produção:
 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 sintética 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 usuários.

Analise os resultados do piloto, identifique possíveis afunilamentos e otimize a
arquitetura. Refaça o teste, se necessário.

Implante no ambiente de produção.
Teste
O teste é um fator crítico para estabelecer a capacidade do seu design de sistema em
oferecer suporte às características de carga de trabalho e uso. Consulte Testes de
desempenho para SharePoint Server 2010 para obter informações detalhadas sobre
como testar sua implantação 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 produção, é
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. É recomendável testar primeiro o ambiente piloto com carga sintética,
principalmente para grandes implantações, e depois submetê-lo a um pequeno grupo de
usuários ativos e conteúdo dinâmico. A vantagem de analisar um ambiente piloto com
um pequeno grupo de usuários ativos é a oportunidade de validar algumas suposições
feitas sobre as características de uso e o crescimento do conteúdo antes de entrar
totalmente em produção.
Otimizar
Se você não conseguir atender às metas de capacidade e desempenho dimensionando
o hardware do seu farm ou fazendo alterações na topologia, considere revisar a sua
solução. Por exemplo, se os requisitos iniciais eram referentes a um único farm para
colaboração (de Pesquisa e Social), convém federar alguns dos serviços, como a
pesquisa em um farm de serviços dedicado, ou dividir a carga de trabalho entre mais
farms. Uma alternativa é implantar um farm dedicado para colaboração social e outro
para colaboração de equipe.
56
Etapa 4: Implantação
Após 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 produção.
A estratégia de distribuição apropriada varia de acordo com o ambiente e a situação.
Embora a implantação do SharePoint Server no geral está fora do escopo deste
documento, há algumas atividades sugeridas que podem se revelar por meio do
exercício de planejamento da capacidade. Veja a seguir alguns exemplos:
 Implantando um novo farm do SharePoint Server: o exercício de planejamento da
capacidade deve ter planos orientados e verificados para o design e a implantação
do SharePoint Server 2010. Neste caso, a distribuição será a primeira implantação
ampla do SharePoint Server 2010. Ela exige mover ou reconstruir os servidores e
serviços usados durante os exercícios de planejamento da capacidade para
produção. Este é o cenário mais direto, pois não existe nenhuma atualização ou
modificação necessária para um farm existente.

Atualizando um farm do Office SharePoint Server 2007 para o SharePoint
Server 2010: o exercício 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 exercício de planejamento da capacidade deve incluir migrações de teste para
validar quanto tempo levará o processo de atualização, se algum código
personalizado precisa ser modificado ou substituído, se alguma ferramenta de
terceiros precisa de atualização, etc. Na conclusão 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
atualização, por exemplo, uma atualização in-loco ou uma migração de bancos de
dados de conteúdo para um novo farm. Se estiver realizando uma atualização inloco, durante o planejamento da capacidade você deve ter percebido que há a
necessidade de hardware adicional ou atualizado, além de considerações em
relação ao tempo de inatividade. Parte do resultado do exercício de planejamento
deve ser uma lista das alterações de hardware necessárias e um plano detalhado
para implantação das alterações 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 atualização para o SharePoint
Server 2010.

Melhorando o desempenho de um farm existente do SharePoint Server 2010: o
exercício de planejamento da capacidade deve ajudá-lo a identificar os
afunilamentos em sua implementação atual, apresentar maneiras de reduzir ou
eliminar esses afunilamentos e validar uma implementação aperfeiçoada que atenda
aos requisitos de negócios dos serviços do SharePoint Server. Há diversas maneiras
de se resolver os problemas de desempenho, desde algo simples como realocar
serviços para o hardware existente, atualizar o hardware existente ou adicionar outro
hardware até adicionar outros serviços a ele. As diferentes abordagens devem ser
testadas e validadas durante o exercício de planejamento da capacidade e, em
seguida, um plano de implantação deve ser formulado de acordo com os resultados
do teste.
57
Etapa 5: Monitoração e Manutenção
Para manter o desempenho do sistema, monitore seu servidor para identificar possíveis
afunilamentos. Para um monitoramento eficaz, você deve conhecer os indicadoreschave que lhe mostrarão se determinada parte do seu farm requer atenção 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 são armazenados.
Consulte Monitorando e mantendo o SharePoint Server 2010 para ver uma lista de
configurações que você pode modificar para monitorar o ambiente em seus primeiros
estágios, o que o ajudará a determinar se alguma alteração será necessária. Lembre-se
de que ampliar seus recursos de monitoramento afetará o espaço em disco requerido
pelo banco de dados de uso. Depois que o ambiente estiver estável e o monitoramento
detalhado não for mais necessário, convém reverter as configurações a seguir aos seus
padrões.
Para obter mais informações sobre monitoramento da integridade e solução de
problemas por meio das ferramentas de monitoramento da integridade internas da
interface da Administração Central do SharePoint Server, leia o seguinte artigo sobre:
Health Monitoring (SharePoint Server 2010)
Solução de problemas (http://blogs.msdn.com/b/ecm/archive/2010/06/22/variationspropagate-pages-on-your-terms.aspx)
Consulte também
Conceitos
Visão geral do gerenciamento da capacidade e dimensionamento do SharePoint Server
2010
Testes de desempenho para SharePoint Server 2010
Monitorando e mantendo o SharePoint Server 2010
Planejamento e configuração de armazenamento e capacidade do SQL Server
(SharePoint Server 2010)
Outros recursos
Health Monitoring (SharePoint Server 2010)
58
Testes de desempenho para SharePoint
Server 2010
Este artigo descreve como testar o desempenho do Microsoft SharePoint Server 2010. A
fase de testes e otimização é um componente crucial do gerenciamento de capacidade
efetivo. Você deve testar novas arquiteturas antes de implantá-las em produção e deve
realizar testes de aceitação em conjunto com as práticas 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 usuários em uma implantação dinâmica. Se você
estiver atualizando de um ambiente do Microsoft Office SharePoint Server 2007 e
planejar alterações na arquitetura ou se estiver estimando a carga do usuário dos novos
recursos do SharePoint Server 2010, os testes serão particularmente importantes para
garantir que o novo ambiente baseado no SharePoint Server 2010 cumpra as metas de
desempenho e capacidade.
Após testar o ambiente, você pode analisar os resultados do teste para determinar as
alterações 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 são as subetapas recomendadas para a pré-produção:
 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 sintética 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 usuários menor.

Analisar os resultados do piloto, identificar possíveis afunilamentos e otimizar a
arquitetura. Testar novamente, se necessário.
 Implantar no ambiente de produção.
Antes de ler este artigo, você deve ler Visão geral do gerenciamento da capacidade e
dimensionamento do SharePoint Server 2010.
Neste artigo:
 Criar um plano de teste

Criar o ambiente de teste

Crie testes e ferramentas
59
Criar um plano de teste
Verifique se o plano inclui:
 Hardware projetado para operar de acordo com as metas de desempenho de
produção esperadas. Sempre meça o desempenho dos sistemas de teste de forma
cautelosa.

Se você tem um componente ou código personalizado, é importante testar primeiro o
desempenho desses componentes em isolamento para validar seu desempenho e
estabilidade. Depois que eles estiverem estáveis, você deverá testar o sistema com
os componentes instalados e comparar o desempenho com o farm sem esses itens
instalados. Componentes personalizados frequentemente são uma das principais
causas de problemas de desempenho e confiabilidade em sistemas de produção.

Conheça o objetivo dos testes. Entenda antecipadamente quais são 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 conteúdo? É necessário
determinar a quantas solicitações 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 são seus objetivos.

Entenda como medir sua meta de teste. Se você estiver interessado em medir a
capacidade de produtividade do farm, por exemplo, convém medir o RPS e a
latência de página. Se estiver medindo o desempenho de pesquisa, convém medir o
tempo de rastreamento e as taxas de indexação de documentos. Se o seu objetivo
de testes for bem entendido, isso o ajudará a definir claramente os principais
indicadores de desempenho que você precisará validar para concluir os testes.
Criar o ambiente de teste
Depois que os objetivos de teste tiverem sido decididos, as medidas tiverem sido
definidas e você tiver determinado os requisitos de capacidade do farm (nas etapas 1 e 2
deste processo), o próximo objetivo será projetar e criar o ambiente de teste. O esforço
para criar um ambiente de teste é muitas vezes subestimado. Ele deve duplicar o
ambiente de produção, tanto quanto possível. Alguns dos recursos e funcionalidade que
você deve considerar ao projetar o ambiente de teste são:
 Autenticação – Decida se o farm usará o AD DS (Serviços de Domínio Active
Directory), autenticação baseada em formulários (e, em caso afirmativo, com qual
diretório), autenticação baseada em declarações etc. Independentemente do
diretório que você estiver usando, quantos usuários serão necessários no ambiente
de teste e como você os criará e populará? Quantos grupos ou funções serão
necessários e como você os criará e populará? Também é preciso garantir que haja
recursos suficientes alocados para os serviços de autenticação, para que eles não
se tornem um afunilamento durante o teste.

DNS – Saiba quais são os namespaces de que você necessitará durante os testes.
Identifique os servidores que responderão às solicitações. Verifique se incluiu um
plano com os endereços IP que serão usados por cada servidor e quais entradas
DNS você terá de criar.
60

Balanceamento de carga – Pressupondo que você esteja usando mais de um
servidor (o que normalmente seria o caso, ou você provavelmente não teria carga
suficiente para justificar os testes de carga), será necessário algum tipo de solução
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 opção que você utilizará e anote todas as informações
de configuração de que precisará para configurá-la de forma rápida e eficiente.
Outro item a ser lembrado é que, geralmente, os agentes de teste de carga tentam
resolver o endereço para uma URL apenas uma vez a cada 30 minutos. Isso
significa que você não deve usar um arquivo de hosts local ou o DNS round robin
para balanceamento de carga, pois os agentes de teste provavelmente acabarão
indo para o mesmo servidor para cada solicitação, em vez de equilibrar a carga entre
todos os servidores disponíveis.

Servidores de teste – Ao planejar o ambiente de teste, além de precisar planejar os
servidores para o farm do SharePoint Server 2010, você também precisa planejar os
computadores necessários para executar os testes. Tipicamente, isso incluirá três
servidores, no mínimo, pode ser necessário um número 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 são utilizados como agentes de teste de carga. Os
agentes são os computadores que obtêm as instruções do controlador de teste
sobre o que deve ser testado e emitem as solicitações para o farm do SharePoint
Server 2010. Os resultados do teste são armazenados em um computador baseado
no SQL Server. Você não deve usar o mesmo computador baseado no SQL Server
que é usado para o farm do SharePoint Server 2010, pois a gravação dos dados de
teste distorcerá os recursos disponíveis do SQL Server para o farm do SharePoint
Server 2010. Também é 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 domínio etc., para garantir que os resultados do
teste sejam representativos do farm que você está configurando. Às vezes, os
próprios agentes de carga ou o o próprio controlador podem se tornar o
afunilamento. Se isso ocorrer, a produtividade indicada no teste normalmente não
será o máximo ao qual o farm pode dar suporte.

SQL Server – No ambiente de teste, siga as diretrizes das seções "Configurar o
SQL Server" e "Validar e monitorar o armazenamento e o desempenho do SQL
Server" no artigo Planejamento e configuração de armazenamento e capacidade do
SQL Server (SharePoint Server 2010).

Validação do conjunto de dados – Ao decidir o conteúdo em relação ao qual você
executará os testes, lembre-se de que, na melhor das hipóteses, você usará dados
de um sistema de produção existente. Por exemplo, é possível fazer backup dos
bancos de dados de conteúdo de um farm de produção, restaurá-los no ambiente de
teste e, em seguida, anexar os bancos de dados para levar o conteúdo para o farm.
Sempre que executa testes com dados de amostra ou fictícios, você corre o risco de
obter resultados distorcidos, devido às diferenças no corpus de conteúdo.
Se for necessário criar dados de exemplo, você deverá ter em mente algumas
considerações ao criar o conteúdo:
 Todas as páginas devem ser publicadas; não deve ser feito check-out de nada
61

A navegação deve ser realista; não crie um volume superior ao que seria razoável
esperar para o uso na produção.

Você deve ter uma ideia das personalizações que o site de produção usará. Por
exemplo, páginas mestras, folhas de estilo, JavaScript etc. devem ser
implementados no ambiente de teste da maneira mais semelhante possível ao
ambiente de produção.

Determine de quantos grupos do SharePoint e/ou níveis de permissão você
precisará e como associará usuários a eles.

Determine se precisará realizar importações de perfil e quanto tempo isso levará.

Determinar se precisará de Audiências e como as criará e populará.

Determine se precisará de fontes de conteúdo de pesquisa adicionais e o que será
necessário para criá-las. Se não 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 não tiver, crie um plano para a maneira como você criará esse conteúdo.

Tenha um plano para garantir que haja conteúdo 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 detecção de duplicatas,
o que não ocorreria em um ambiente de produção com o conteúdo real.
Crie testes e ferramentas
Depois que o ambiente de teste estiver funcional, será o momento de criar e ajustar os
testes que serão utilizados para medir a capacidade de desempenho do farm. Esta
seção fará algumas referências especificamente ao Visual Studio Team System (Team
Test Load Agent), mas muitos dos conceitos são aplicáveis independentemente da
ferramenta de teste de carga que você usar. Para obter mais informações sobre o Visual
Studio Team System, consulte Visual Studio Team System at MSDN
(http://msdn.microsoft.com/pt-br/library/fda2bad5.aspx" ).
Você também 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 sintética em relação ao SharePoint
Foundation 2010 ou SharePoint Server 2010, como parte de um exercício de
planejamento de capacidade ou um teste de estresse pré-atualização.
O Kit de Teste de Carga está incluído no Microsoft SharePoint 2010 Administration
Toolkit v1.0, disponível no Centro de Download da Microsoft
(http://www.microsoft.com/downloads/en/details.aspx?FamilyId=718447d8-0814-427a81c3-c9c3d84c456e&displaylang=en).
Um critério fundamental para o sucesso dos testes consiste em poder simular
efetivamente uma carga de trabalho realista, mediante a geração de solicitações em
uma ampla gama dos dados de site de teste, assim como os usuários acessariam uma
ampla gama de conteúdo em um farm de produção do SharePoint Server 2010. Para
fazer isso, normalmente você precisará criar os testes de tal forma que eles sejam
62
controlados por dados. Em vez de criar centenas de testes individuais embutidos em
código para o acesso a uma página específica, você deve usar apenas alguns testes
que utilizem fontes de dados contendo as URLs dos itens para acessar dinamicamente o
conjunto de páginas.
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 fácil de gerenciar
e transportar entre ambientes de desenvolvimento e de teste. Lembre-se de que a
criação de arquivos CSV com esse conteúdo pode exigir a criação de ferramentas
personalizadas para enumerar o ambiente baseado em SharePoint Server 2010 e
registrar as várias URLs que estão sendo usadas.
Talvez você precise usar ferramentas para tarefas como:
 Criar usuários e grupos no Active Directory ou outro repositório de autenticação, se
você estiver usando autenticação baseada em formulários

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 usuário e senhas para usuários de teste; essas
são as contas de usuário com as quais os testes de carga serão executados. Deve
haver vários arquivos, de modo que, por exemplo, alguns contenham apenas
usuários administradores, outros contenham outros usuários com privilégios
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 níveis de permissão com usuários e grupos do
Active Directory (ou funções, se você estiver usando a autenticação baseada em
formulários)
Ao criar os testes da Web, há outras práticas recomendadas que você deve observar e
implementar. São elas:
 Grave testes da Web simples como ponto de partida. Esses testes conterão valores
embutidos em código para parâmetros como URL, IDs etc. Substitua os valores
embutidos em código por links dos arquivos CSV. A vinculação de dados desses
valores no Visual Studio Team System (Team Test Load Agent) é extremamente
fácil.

Sempre tenha regras de validação para o teste. Por exemplo, ao ser solicitada uma
página, se ocorrer um erro, muitas vezes você obterá a página error.aspx como
resposta. De uma perspectiva de teste da Web, essa parece ser apenas outra
resposta positiva, pois você obtém um código 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 criação de uma ou mais regras de
validação permite que você intercepte quando determinado texto é enviado como
resposta, para que a validação falhe e a solicitação seja marcada como tendo
sofrido uma falha. Por exemplo, no Visual Studio Team System (Team Test Load
Agent), uma regra de validação simples poderia ser uma validação responseURL –
ela gravará uma falha se a página que é renderizada após redirecionamentos não
63
for a mesma página de resposta que foi gravada no teste. Você também pode
adicionar uma regra FindText que gravará uma falha se encontrar as palavras
"acesso negado ", por exemplo, na resposta.

Use vários usuários em diferentes funções para os testes. Certos comportamentos,
como o cache de saída, funcionam de forma diferente dependendo dos direitos do
usuário atual. Por exemplo, um administrador de conjunto de sites ou um usuário
autenticado com direitos de aprovação ou criação não obterão resultados
armazenados em cache, pois sempre queremos que eles vejam a versão mais atual
do conteúdo. Usuários anônimos, no entanto, obterão o conteúdo armazenado em
cache. Você precisa garantir que os usuários de teste constituam uma mistura
dessas funções, correspondendo aproximadamente à mistura de usuários no
ambiente de produção. Por exemplo, na produção, provavelmente há apenas dois
ou três administradores de conjuntos de sites; portanto, você não deve criar testes
em que 10% das solicitações de página sejam feitos por contas de usuários de
administradores de conjuntos de sites para o conteúdo de teste.

A análise de solicitações 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 página ou a página e todas as solicitações associadas que
fazem parte dela, como imagens, folhas de estilo, scripts etc. Nos testes de carga,
geralmente esses itens são ignorados por algumas razões:

Depois que um usuário acessa um site pela primeira vez, esses itens geralmente
são armazenados em cache pelo navegador local

Esses itens normalmente não vêm do SQL Server em um ambiente baseado no
SharePoint Server 2010. Com o cache BLOB ativado, eles são atendidos pelos
servidores Web, em vez disso, para que não gerem carga do SQL Server.
Se você tem regularmente uma alta porcentagem de usuários de primeira vez em seu
site, se desabilitou o cache do navegador ou se, por algum motivo, não pretende usar o
cache BLOB, talvez faça sentido habilitar a análise de solicitações dependentes nos
testes. No entanto, essa é realmente uma exceção, não a regra para a maioria das
implementações. Lembre-se de que se, você ativar esse recurso, isso poderá aumentar
significativamente os números de RPS relatados pelo controlador de teste. Essas
solicitações são atendidas tão rapidamente que podem levá-lo a pensar,
enganadamente, que há mais capacidade disponível no farm do que a capacidade real.
 Lembre-se de modelar também a atividade de aplicativos cliente. Aplicativos cliente,
como Microsoft Word, PowerPoint, Excel e Outlook, também geram solicitações para
farms do SharePoint Server 2010. Eles adicionam carga ao ambiente enviando ao
servidor solicitações como recuperação de RSS feeds, aquisição de informações
sociais, solicitação de detalhes sobre estrutura de sites e listas, sincronização de
dados etc. Esses tipos de solicitações deverão ser incluídos e modelados se você
tiver esses clientes em sua implementação.

Na maioria dos casos, um teste da Web deve conter uma única solicitação. É mais
fácil ajustar e solucionar problemas do agente de teste e solicitações individuais se o
teste contém uma única solicitação. Os testes da Web normalmente precisam conter
várias solicitações quando a operação que estão simulando é composta por várias
solicitações. Por exemplo, para testar esse conjunto de ações, você precisará de um
teste com diversas etapas: fazer check-out de um documento, editá-lo, fazer checkin dele e publicá-lo. Também é necessário o estado de reserva entre as etapas – por
64
exemplo, a mesma conta de usuário deve ser usada para fazer o check-out, realizar
as edições e fazer o check-in do documento. Para operações com várias etapas que
exigem que o estado seja mantido entre cada etapa, a melhor opção é utilizar várias
solicitações em um único teste da Web.

Teste cada teste da Web individualmente. Verifique se cada teste pode ser
concluído com êxito antes de executá-lo em um teste com carga maior. Confirme se
todos os nomes de aplicativos Web são resolvidos e se as contas de usuário usadas
no teste têm direitos suficientes para executar o teste.
Testes da Web incluem as solicitações de páginas individuais, o carregamento de
documentos, a exibição de itens de lista etc. Todos esses itens são reunidos em testes
de carga. Um teste de carga é aquele em que você reúne todos os diferentes testes da
Web que serão executados. Pode ser atribuída uma porcentagem de tempo para a
execução de cada teste da Web – por exemplo, se verificasse que 10% das solicitações
em um farm de produção são 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 também são usados para
configurar itens como combinação de navegadores, combinação de redes, padrões de
carga e configurações de execução.
Existem algumas práticas recomendadas adicionais que devem ser observadas e
implementadas nos testes de carga:
 Use uma taxa razoável de leitura/gravação nos testes. A sobrecarga do número de
gravações em um teste pode afetar significativamente a produtividade global do
teste. Mesmo em farms de colaboração, as taxas de leitura/gravação costumam ter
muito mais leituras do que gravações. Para obter mais informações, consulte a
página sobre estudos de caso técnicos de desempenho e capacidade
(http://technet.microsoft.com/pt-br/library/cc261716.aspx).

Considere o impacto de outras operações com uso intensivo de recursos e decida se
elas devem ocorrer durante o teste de carga. Por exemplo, operações como backup
e restauração geralmente não são realizadas durante um teste de carga.
Normalmente, um rastreamento de pesquisa completo pode não ser executado
durante um teste de carga, enquanto um rastreamento incremental pode ser normal.
Você precisa considerar como essas tarefas serão agendadas na produção: elas
serão executadas em horários de pico? Se não forem, então provavelmente deverão
ser excluídas durante os testes de carga, quando você tentará determinar a carga de
estado estável máxima à qual pode dar suporte para o tráfego de pico.

Não use tempos de raciocínio. Tempos de raciocínio são um recurso do Visual
Studio Team System (Team Test Load Agent) que permite simular o tempo de pausa
dos usuários entre os cliques em uma página. Por exemplo, um usuário típico pode
carregar uma página, lê-la por três minutos e, em seguida, clicar em um link nela
para visitar outro site. É quase impossível tentar modelar isso corretamente em um
ambiente de teste e, de fato, não é agregado valor ao resultado do teste. É algo
difícil de modelar porque a maioria das organizações não tem uma maneira de
monitorar usuários diferentes e o tempo que eles gastam entre cliques em diferentes
tipos de sites do SharePoint (como publicação versus pesquisa versus colaboração
etc.) Isso também não agrega valor porque, embora um usuário possa fazer uma
pausa entre solicitações de página, os servidores baseados no SharePoint Server
2010 não o fazem. Simplesmente recebem um fluxo constante de solicitações que
podem ter altos e baixos ao longo do tempo, mas eles não permanecem ociosos
65
aguardando enquanto cada usuário faz uma pausa entre os cliques em links em uma
página.

Entenda a diferença entre usuários e solicitações. O Visual Studio Team System
(Team Test Load Agent) tem um padrão de carga em que pede que você digite o
número de usuários para a simulação. Isso não tem relação alguma com os usuários
do aplicativo; trata-se apenas do número de threads que serão usados nos agentes
de teste de carga para gerar solicitações. Um erro comum é pensar que, se a
implantação terá 5.000 usuários, por exemplo, então 5000 é o número que deverá
ser usado no Visual Studio Team System (Team Test Load Agent) – não é! Essa é
uma das muitas razões pelas quais, ao serem estimados os requisitos de
planejamento de capacidade, os requisitos de uso devem ser baseados no número
de solicitações por segundo, não no número de usuários. Em um teste de carga do
Visual Studio Team System (Team Test Load Agent), você verá que, muitas vezes, é
possível gerar centenas de solicitações por segundo usando apenas 50 a 75
"usuários" do teste de carga.

Use um padrão de carga constante para obter os resultados de testes mais
confiáveis e reproduzíveis. No Visual Studio Team System (Team Test Load Agent),
você tem a opção de basear a carga em um número constante de usuários (threads,
conforme explicado no ponto anterior), um padrão de carga de nível de usuários ou
um teste de uso baseado em metas. Um padrão de carga de nível é aquele em que
você começa com um número menor de usuários e, em seguida, "sobe um nível"
adicionando usuários a cada poucos minutos. Um teste de uso com base em metas
é aquele em que você estabelece um limite para um contador de diagnóstico, como
utilização de CPU, e testa as tentativas para direcionar a carga de modo a manter
esse contador entre os limites mínimo e máximo que você define para ele. No
entanto, se você estiver apenas tentando determinar a produtividade máxima que o
farm do SharePoint Server 2010 pode sustentar durante a carga de pico, será mais
eficaz e preciso selecionar apenas um padrão de carga constante. Isso permite
identificar mais facilmente a quantidade de carga que o sistema pode aceitar antes
de começar 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,
edição de itens de lista ou apenas registro de atividade no banco de dados de uso,
dados serão gravados no SQL Server. Para garantir um conjunto consistente e legítimo
de resultados de teste em cada teste de carga, você deve ter um backup disponível
antes de executar o primeiro teste de carga. Após a conclusão de cada teste de carga, o
backup deverá ser usado para restaurar o conteúdo de volta à maneira como era antes
de ser iniciado o teste.
Consulte também
Conceitos
Visão geral do gerenciamento da capacidade e dimensionamento do SharePoint Server
2010
Planejamento de capacidade para SharePoint Server 2010
Monitorando e mantendo o SharePoint Server 2010
66
Planejamento e configuração de armazenamento e capacidade do SQL Server
(SharePoint Server 2010)
Outros recursos
Health Monitoring (SharePoint Server 2010)
67
Monitorando e mantendo o SharePoint
Server 2010
Este artigo fornece informações 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 possíveis
afunilamentos. Para que você possa monitorar de forma eficaz, é necessário
compreender os indicadores-chave que o informarão se uma parte específica do farm
exigem atenção 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 são
armazenados.
As informações contidas nesta seção se destinam a ajudar os administradores a
configurar manualmente os contadores de desempenho e outras configurações. Para
obter mais informações sobre monitoramento de integridade e solução de problemas
usando as ferramentas de monitoramento de integridade internas à interface da
Administração Central do SharePoint, leia os seguintes artigos:
 Health Monitoring (SharePoint Server 2010)
 Solving Problems and Troubleshooting (SharePoint Server 2010)
Antes de ler este artigo, você deve ler Visão geral do gerenciamento da capacidade e
dimensionamento do SharePoint Server 2010.
Neste artigo:
 Configurando o monitoramento

Removendo afunilamentos
Configurando o monitoramento
A seguir, há uma lista das configurações que você pode modificar para monitorar o
ambiente nos estágios iniciais, o que ajudará a determinar se são necessárias
alterações. Tenha em mente que o aumento dos recursos de monitoramento afetará a
quantidade de espaço em disco de que o banco de dados de uso necessitará. Uma vez
que o ambiente esteja estável e o monitoramento detalhado não seja mais necessário,
convém reverter as configurações a seguir aos padrões.
Configuração
Valor
Observações
Proteção contra Saturação do Log Desabilitado
de Eventos
68
O valor padrão é
Habilitado. Ele
pode ser
desabilitado para
coletar a
quantidade
Configuração
Valor
Observações
máxima possível
de dados de
monitoramento.
Para operações
normais, deve
ser habilitado.
Agenda do Trabalho de Timer
Importação de Dados de Uso de
Microsoft SharePoint Foundation
5 minutos
O valor padrão é
de 30 minutos.
Se essa
configuração for
reduzida, os
dados serão
importados para
o banco de
dados de uso
com mais
frequência. Isso é
particularmente
útil na solução de
problemas. Para
operações
normais, o valor
deve ser de 30
minutos.
Habilitado
O valor padrão é
Desabilitado,
exceto para o
provedor
"Monitoramento
da Integridade da
Pesquisa Eventos de
Rastreamento".
Esses
provedores
coletam de
dados de
integridade para
vários recursos e
componentes.
Para operações
normais, convém
reverter ao
Provedores de Diagnóstico
Habilitar todos os provedores de
diagnóstico
69
Configuração
Valor
Observações
padrão.
Definir intervalos de agendamento 1 minuto
de "job-diagnostics-performancecounter-wfe-provider" e "jobdiagnostics-performance-countersql-provider"
O valor padrão é
de cinco
minutos. Se
essa
configuração for
reduzida, o
polling dos dados
poderá ser
realizado com
mais frequência.
Isso é
particularmente
útil na solução de
problemas. Para
operações
normais, o valor
deve ser de
cinco minutos.
Diversos
Habilitar rastreamento de pilha
para solicitações de conteúdo
Habilitado
O valor padrão é
Desabilitado. Se
essa
configuração for
habilitada,
permitirá o
diagnóstico de
falhas de
solicitações de
conteúdo usando
o rastreamento
de pilha de
processos. Para
operações
normais, ela
deve ser
desabilitada.
Habilitar o Painel do
Desenvolvedor
Habilitado
O valor padrão é
Desabilitado. Se
essa
configuração for
habilitada,
permitirá o
diagnóstico de
páginas lentas ou
70
Configuração
Valor
Observações
outros problemas
usando o Painel
do
Desenvolvedor.
Para operações
normais e uma
vez que a
solução de
problemas não
seja mais
necessária, ela
deve ser
desabilitada.
Coleta de Dados de Uso
Uso de Importação de Conteúdo
Habilitado
Uso de Exportação de Conteúdo
Solicitações de Página
Uso de Recursos
Uso de Consultas de Pesquisa
Uso de Inventário de Site
Trabalhos de Timer
Uso de Classificação
A habilitação dos
logs desse
conjunto de
contadores
permite coletar
mais dados de
uso em todo o
ambiente e
compreender
melhor os
padrões de
tráfego 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
específico (30 minutos, por padrão). Dessa forma, você pode consultar o banco de
dados de uso para recuperar esses contadores e criar um gráfico dos resultados ao
longo do tempo. A seguir há um exemplo do uso do cmdlet AddSPDiagnosticsPerformanceCounter do PowerShell para adicionar o contador %
Tempo de Processador ao banco de dados de uso. Isso só precisa ser executado em um
dos servidores Web:
Código
da
cópia
Add-SPDiagnosticsPerformanceCounter -Category "Processor" -Counter "%
Processor Time" -Instance "_Total" -WebFrontEnd
71
Há diversos contadores de desempenho genéricos que você deve monitorar para
qualquer sistema de servidor. A tabela a seguir os descreve.
Contador de Desempenho
Descrição
Processador
Você deve monitorar o desempenho do
processador para garantir que a totalidade
de seu uso não permaneça
consistentemente elevada (acima de 80 por
cento), pois isso indica que o sistema não
seria capaz de lidar com picos de atividade
repentinos. Além disso, no estado comum,
você não verá um efeito dominó em que, um
componente falhar, causará problemas nos
demais componentes. Por exemplo, se tiver
três servidores Web, você deverá garantir
que a CPU média em todos os servidores
esteja abaixo de 60%, de modo que, se um
deles falhar, os outros dois ainda possam
assumir a carga adicional.
Interface de rede
Monitore a taxa à qual os dados são
enviados e recebidos através da placa de
interface de rede. A taxa deve permanecer
abaixo de 50% da capacidade da rede.
Discos e Cache
Há diversas opções de disco lógico que
você deve monitorar regularmente. O
espaço em disco disponível é essencial em
qualquer estudo de capacidade, mas você
também deve analisar o tempo pelo qual o
disco está ocioso. Dependendo dos tipos de
aplicativos ou serviços em execução no
servidor, você pode examinar os tempos de
leitura e gravação de disco. Filas estendidas
para as funções de gravação ou leitura
afetarão o desempenho. O cache tem
grande impacto sobre as operações de
leitura e gravação. Você deve monitorar se
há maior número de falhas de cache.
Arquivo de Memória e Paginação
Monitore a quantidade de memória física
disponível para alocação. Se houver
memória insuficiente, isso levará ao uso
excessivo do arquivo de paginação e a um
aumento no número de falhas de página por
segundo.
72
Contadores do Sistema
A tabela a seguir fornece informações 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
Descrição
Processador
% Tempo de Processador
Mostra o uso do processador ao longo de
um período 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ê também pode medir a utilização em
cada processador, para garantir um
desempenho equilibrado entre os núcleos.
Disco
- Comprimento Médio da Fila de Disco
Mostra o número médio de solicitações de
leitura e gravação que foram enfileiradas
para o disco selecionado durante o intervalo
de amostragem. Um comprimento de fila de
disco maior pode não ser um problema,
desde que as leitura/gravações de disco não
sejam prejudicadas e o sistema esteja
funcionando em um estado estável, sem
aumentar as filas.
Comprimento Médio da Fila de Leitura de
Disco
O número médio de solicitações de leitura
que estão na fila.
Comprimento Médio da Fila de Gravação de O número médio de solicitações de
Disco
gravação que estão na fila.
Leituras de Disco/s
O número de leituras de disco por segundo.
Gravações de Disco/s
O número de gravações em disco por
segundo.
Memória
- Mbytes Disponíveis
Mostra a quantidade de memória física
disponível para alocação. Se houver
memória insuficiente, isso levará ao uso
excessivo do arquivo de paginação e a um
aumento no número de falhas de página por
segundo.
73
Objetos e contadores
Descrição
- Falhas de Cache/s
Este contador mostra a taxa à qual ocorrem
falhas quando uma página é procurada no
cache do sistema de arquivos e não é
encontrada. Pode se tratar de uma falha
leve, quando a página é encontrada na
memória, ou de uma falha grave, quando a
página está em disco.
O uso efetivo do cache para operações de
leitura e gravação pode ter um efeito
significativo no desempenho do servidor.
Você deve monitorar se há maios falhas de
cache, o que é indicado por uma redução
em Leituras Rápidas Assíncronas/s ou
Leituras Antecipadas/s.
- Páginas/s
Esse contador mostra a taxa à qual as
páginas são lidas ou gravadas em disco,
para resolver falhas de página graves. Se o
valor aumentar, isso indicará problemas de
desempenho em todo o sistema.
Arquivo de Paginação
- % Usado e % Pico de Uso
O arquivo de paginação do servidor, às
vezes chamado de arquivo de troca, tem
endereços de memória "virtuais" em disco.
Falhas de página ocorrem quando um
processo precisa parar e esperar enquanto
recursos "virtuais" necessários são
recuperados do disco para a memória. Elas
serão mais frequentes se a memória física
for inadequada.
NIC
- Total de Bytes/s
Essa é a taxa à qual os dados são enviados
e recebidos através da placa de interface de
rede. Talvez seja necessário continuar a
investigar, caso essa taxa seja superior a
40-50% da capacidade da rede. Para
ajustar a investigação, 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 memória é
reservada para o processo, mesmo que não
74
Objetos e contadores
Descrição
esteja em uso.
- % Tempo de Processador
Esse contador indica a porcentagem de
tempo de processador que é usada por
determinado processo.
Contagem de Threads (_Total)
O número atual de threads.
ASP.NET
Total de Solicitações
O número total de solicitações desde que o
serviço foi iniciado.
Solicitações Enfileiradas
O Microsoft SharePoint Foundation 2010
fornece os blocos de construção de páginas
HTML que são renderizadas no navegador
do usuário através de HTTP. Esse contador
mostra o número de solicitações
aguardando para serem processadas.
Tempo de Espera da Solicitação
O número de milissegundos que a
solicitação mais recente aguardou na fila
para processamento. À medida que
aumenta o número de eventos de espera,
os usuários experimentam desempenho de
renderização de páginas degradado.
Solicitações Rejeitadas
O número total de solicitações não
executadas devido a recursos insuficientes
do servidor para processá-las. Esse
contador representa o número de
solicitações que retornam um código de
status 503 HTTP, indicando que o servidor
está muito ocupado.
Solicitações em Execução (_Total)
O número de solicitações em execução no
momento.
Solicitações/s (_Total)
O número de solicitações executadas por
segundo. Isso representa a produtividade
atual do aplicativo. Sob carga constante,
esse número deve permanecer dentro de
determinado intervalo, com exceção de
outro trabalho do servidor (como coleta de
lixo, threads de limpeza de cache,
ferramentas de servidor externas e assim
por diante).
Memória .NET CLR
Nº de Coletas da Ger. 0
Exibe o número de vezes que os objetos da
75
Objetos e contadores
Descrição
geração 0 (ou seja, os objetos mais novos e
alocados mais recentemente) foram
submetidos a coleta de lixo desde que o
aplicativo foi iniciado. Esse número é útil
como uma razão de Geração 0: Geração 1:
Geração 2 para garantir que o número de
conjuntos da Geração 2 não exceda em
muito os conjuntos da Geração 0,
otimamente por um fator de 2.
Nº de Coletas da Ger. 1
Exibe o número de vezes que os objetos da
geração 1 foram submetidos a coleta de lixo
desde que o aplicativo foi iniciado.
Nº de Coletas da Ger. 2
Exibe o número de vezes que os objetos da
geração 2 foram submetidos a coleta de lixo
desde que o aplicativo foi iniciado. O
contador é incrementado ao final de uma
coleta de lixo da geração 2 (também
chamada de coleta de lixo completa).
% Tempo na Coleta de Lixo
Exibe a porcentagem de tempo que foi
gasto na execução de uma coleta de lixo
desde o último ciclo de coleta de lixo. Esse
contador geralmente indica o trabalho feito
pelo coletor de lixo para recolher e
comprimir memória em nome do aplicativo,
sendo atualizado apenas ao final de cada
coleta de lixo. Ele não é uma média; seu
valor reflete o último valor observado. Esse
contador deve ser inferior a 5% em
operação normal.
Contadores do SQL Server
A tabela a seguir fornece informações sobre objetos e contadores do SQL Server.
Objetos e contadores
Descrição
Estatísticas Gerais
Esse objeto fornece contadores para
monitorar a atividade em todo o servidor
geral, como o número de conexões atuais e
o número de usuários que se conectam e
desconectam por segundo de
computadores que executam uma instância
do SQL Server.
Conexões de Usuário
Esse contador mostra a quantidade de
76
Objetos e contadores
Descrição
conexões de usuário em sua instância do
SQL Server. Se esse número crescer
500 por cento em relação à linha de base,
talvez haja uma redução do desempenho.
Bancos de Dados
Esse objeto fornece contadores para
monitorar operações de cópia em massa,
produtividade de backup e restauração e
atividades de log de transações. Monitore
as transações e o log de transações para
determinar o volume de atividades dos
usuários no banco de dados e o quanto o
log de transações está ficando cheio. O
volume de atividades dos usuários pode
determinar o desempenho do banco de
dados e afetar o tamanho do log, o bloqueio
e a replicação. Monitorar a atividade de log
de baixo nível para medir a atividade dos
usuários e o uso de recursos pode ajudá-lo
a identificar afunilamentos de desempenho.
Transações/s
Esse contador mostra a quantidade de
transações por segundo em determinado
banco de dados ou em toda a instância do
SQL Server. Esse número serve para ajudálo a criar uma linha de base e solucionar
problemas.
Bloqueios
Esse objeto fornece informações sobre
bloqueios do SQL Server em tipos de
recursos individuais.
Número de Deadlock/s
Esse contador mostra o número de
deadlocks no SQL Server por segundo.
Esse valor normalmente deve ser 0.
Tempo de Espera Médio (ms)
Este contador mostra a quantidade média
de tempo de espera para cada solicitação
de bloqueio que resultou em uma espera.
Tempo de Espera de Bloqueio (ms)
Esse contador mostra o tempo total de
espera para bloqueios no último segundo.
Esperas de Bloqueio/s
Este contador mostra o número de
bloqueios por segundo que não puderam
ser atendidos imediatamente e precisaram
esperar recursos
Travas
Esse objeto fornece contadores para
monitorar bloqueios internos de recursos do
77
Objetos e contadores
Descrição
SQL Server chamados travas. O
monitoramento de travas para determinar a
atividade dos usuários e o uso de recursos
pode ajudá-lo a identificar afunilamentos de
desempenho.
Tempo Médio de Espera de Trava (ms)
Esse contador mostra o tempo médio de
espera de trava para solicitações de trava
que precisaram esperar.
Esperas de Trava/s
Esse contador mostra o número de
solicitações de trava por segundo que não
puderam ser atendidas imediatamente.
Estatísticas SQL
Esse objeto fornece contadores para
monitorar a compilação e o tipo de
solicitações enviadas a uma instância do
SQL Server. O monitoramento do número
de compilações e recompilações de
consultas e do número de lotes recebidos
por uma instância do SQL Server indica a
rapidez com que o SQL Server está
processando as consultas de usuários e a
eficiência com que o otimizador de consulta
está processando as consultas.
Compilações de SQL/s
Esse contador indica o número de vezes
que o caminho de código de compilação é
inserido por segundo.
Recompilações de SQL/s
Esse contador indica o número de vezes
que recompilações de declaração são
disparadas por segundo.
Cache de Planos
Esse objeto fornece contadores para
monitorar como o SQL Server usa a
memória para armazenar objetos como
procedimentos armazenados, instruções
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
memória para armazenar páginas de dados,
estruturas de dados internas e o cache de
procedimento, bem como contadores para
monitorar a E/S física enquanto o SQL
78
Objetos e contadores
Descrição
Server lê e grava páginas de banco de
dados.
Taxa de Acertos do Cache do Buffer
Esse contador mostra a porcentagem de
páginas encontradas no cache do buffer
sem a necessidade de leitura do disco. A
taxa é o número total de acertos de cache
dividido pelo número total de pesquisas de
cache desde que uma instância do SQL
Server foi iniciada.
Removendo afunilamentos
Os afunilamentos do sistema representam um ponto de contenção em que não há
recursos suficientes para atender às solicitações de transações do usuário. Elas podem
ser de hardware físico, ambiente operacional ou baseadas em aplicativos. Muitas vezes,
a razão para o afunilamentos consiste em um código personalizado ineficiente ou em
soluções de terceiros, e um exame desses itens poderia render melhores resultados do
que a adição de hardware. Outra causa comum de afunilamentos é a configuração
incorreta do farm ou uma implementação de solução ineficiente que estrutura os dados
de uma maneira que requer mais recursos do que o necessário. Para um administrador
de sistema, é essencial gerenciar os afunilamentos monitorando constantemente o
desempenho. Ao identificar um problema de desempenho, você deve avaliar a melhor
resolução para remover o afunilamento. Os contadores de desempenho e outros
aplicativos de monitoramento de desempenho, como o SCOM (System Center
Operations Manager), são as principais ferramentas de monitoramento e análise de
problemas, para que você possa desenvolver uma solução.
Resolução de afunilamentos físicos
Os afunilamentos físicos são baseados em contenção de processador, disco, memória e
rede: muitas solicitações estão disputando muito poucos recursos físicos. Os objetos e
contadores descritos no tópico Monitorando o desempenho indicam que o problema de
desempenho está localizado, por exemplo, no processador de hardware ou ASP.NET.
Para a resolução de afunilamentos, você deve identificar o problema e fazer uma ou
mais alterações que atenuam o problema de desempenho.
Os problemas raramente acontecem de forma instantânea; em geral, há uma gradual
degradação 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 opções, em diferentes graus, é possível
inserir soluções em um alerta, em forma de texto de aconselhamento ou comandos com
script.
Talvez você tenha que resolver problemas de afunilamento fazendo alterações em
configurações de hardware ou do sistema, após determinar que os problemas não são
causados por configuração incorreta, código personalizado ineficiente ou soluções de
terceiros ou uma implementação de solução ineficiente. As tabelas a seguir identificam
limites de problemas e possíveis opções de resolução. Algumas das opções sugerem
modificações ou atualizações de hardware.
79
Objetos e contadores
Problema
Opções de resolução
Processador
Processador - % Tempo de Mais de 75-85%
Processador
Atualizar o processador
Aumentar o número de
processadores
Adicionar servidor(es)
Disco
Comprimento Médio da Fila Aumentando gradualmente; Aumentar o número ou a
o sistema não está em um velocidade dos discos
de Disco
estado de equilíbrio e a fila Alterar configuração de matriz
está aumentando
para distribuição
Mover alguns dados para um
servidor alternativo
% Tempo Ocioso
Mais de 90%
Aumentar o número de discos
Mover dados para um disco ou
servidor alternativo
% de Espaço Livre
Menos de 30%
Aumentar o número de discos
Mover dados para um disco ou
servidor alternativo
Memória
Mbytes Disponíveis
Menos de 2 GB em um
servidor Web.
Adicionar memória.
Observação:
A memória disponível do SQL
Server será baixa, por design, e
isso nem sempre indica um
problema.
Falhas de Cache/s
Mais de 1
Adicionar memória
Aumente a velocidade ou o
tamanho do cache, se possível
Mover dados para um disco ou
servidor alternativo
Páginas/s
Mais de 10
Adicionar memória
Arquivo de Paginação
80
Objetos e contadores
Problema
Opções de resolução
% Usado e % Pico de Uso O arquivo de paginação do Adicionar memória
servidor, às vezes
chamado de arquivo de
troca, tem endereços de
memória "virtuais" em
disco. Falhas de página
ocorrem quando um
processo precisa parar e
esperar enquanto recursos
"virtuais" necessários são
recuperados do disco para
a memória. Elas serão mais
frequentes se a memória
física for inadequada.
NIC
Total de Bytes/s
Mais de 40-50% da
Continuar a investigar
capacidade da rede. Essa é monitorando Bytes recebidos/s
a taxa à qual os dados são e Bytes Enviados/s
enviados e recebidos
Reavaliar a velocidade da placa
através da placa de
de rede de interface
interface de rede.
Verificar o número, tamanho e
uso de buffers de memória
Processo
Conjunto de Trabalho
Mais de 80% da memória
total
% Tempo de Processador Mais de 75-85%.
Adicionar memória
Aumentar o número de
processadores
Redistribuir a carga de trabalho
para servidores adicionais
ASP.NET
Reciclagens do Pool de
Aplicativos
Várias por dia, causando
lentidão intermitente.
Verifique se você não
implementou configurações que
reciclam automaticamente o
pool de aplicativos sem
necessidade ao longo de todo o
dia.
Solicitações Enfileiradas
Centenas ou milhares de
solicitações enfileiradas.
Implementar servidores Web
adicionais
O máximo padrão para esse
contador é 5.000, e você pode
alterar essa configuração no
81
Objetos e contadores
Problema
Opções de resolução
arquivo Machine.config
Tempo de Espera da
Solicitação
À medida que aumenta o
número de eventos de
espera, os usuários
experimentam
desempenho de
renderização de páginas
degradado.
Implementar servidores Web
adicionais
Solicitações Rejeitadas
Mais de 0
Implementar servidores Web
adicionais
Consulte também
Conceitos
Visão geral do gerenciamento da capacidade e dimensionamento do SharePoint Server
2010
Testes de desempenho para SharePoint Server 2010
Planejamento de capacidade para SharePoint Server 2010
Planejamento e configuração de armazenamento e capacidade do SQL Server
(SharePoint Server 2010)
Outros recursos
Health Monitoring (SharePoint Server 2010)
82
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 estáticos que não podem ser excedidos por design

Limites: limites configuráveis que podem ser excedidos para atender a requisitos
específicos

Limites com suporte: limites configuráveis que foram definidos por padrão como
um valor testado.
Observação:
As informações 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 dinâmicas. No entanto, os resultados obtidos por você
provavelmente variarão com base no equipamento usado e nos recursos e na
funcionalidade implementados para seus sites.
Neste artigo:
 Visão geral de delimitadores e limites


Delimitadores, limites e limites com suporte

Como os limites são 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 conteúdo

Limites de conjuntos de sites

Limites de listas e bibliotecas

Limites de colunas

Limites de páginas

Limites por recurso

Limites de pesquisa

Limites de Serviço de Perfil de Usuário

Limites de implantação de conteúdo
83

Limites de blog

Limites de Serviços Corporativos de Conectividade

Limites de fluxos de trabalho

Limites de repositórios de termos de Metadados Gerenciados (bancos de dados)

Limites dos Serviços do Visio

Limites dos Serviços PerformancePoint

Limites do Word Automation Services

Limites do SharePoint Workspace

Limites do OneNote

Limites do Serviço Office Web Applications

Limites do Project Server
Visão geral de delimitadores e limites
Este artigo contém informações para ajudá-lo a entender os limites de desempenho e
capacidade testados do SharePoint Server 2010; além disso, oferece diretrizes sobre
como os limites estão relacionados ao desempenho aceitável. Use as informações deste
artigo para determinar se a implantação planejada se enquadra nos limites aceitáveis 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 adição de servidores à instalação pode não
aumentar os limites de capacidade dos objetos listados nas tabelas da seção Limites e
delimitadores, mais adiante neste tópico. Por outro lado, a adição de computadores
servidores aumenta a taxa de transferência de um farm de servidores, o que pode ser
necessário para a obtenção de um desempenho aceitável com muitos objetos. Em
alguns casos, os requisitos para um alto número de objetos em uma solução 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 recomendações deste artigo podem estar relacionados a recursos ou a
operações do usuário inexistentes no seu ambiente e, assim, talvez não sejam aplicáveis
à sua solução. Somente testes completos podem fornecer dados exatos relacionados ao
seu ambiente específico.
Delimitadores, limites e limites com suporte
No SharePoint Server 2010, há determinados limites que, por design, não podem ser
excedidos e outros limites definidos como valores padrão que podem ser alterados pelo
administrador do farm. Há também certos limites que não são representados por um
valor configurável, como o número de conjuntos de sites por aplicativo Web.
 Delimitadores são limites absolutos que não podem ser excedidos por design. É
importante entendê-los para garantir que você não faça pressuposições incorretas
ao projetar seu farm.
Um exemplo de delimitador é o limite de tamanho do documento de 2 GB. Não é
possível configurar o SharePoint Server para armazenar documentos com mais de 2
GB. Esse é um valor absoluto interno que não pode ser excedido por design.
84

Limites são aqueles que possuem um valor padrão que não pode ser excedido, a
menos que o valor seja modificado. Em determinadas circunstâncias, limites podem
ser excedidos para acomodar variações no design do farm, mas é importante
entender que isso pode afetar o desempenho do farm, além do valor efetivo de
outros limites.
O valor padrão de certos limites só pode ser excedido até um valor máximo absoluto.
Um bom exemplo disso é o limite de tamanho de documento. Por padrão, o limite de
tamanho de documento é definido como 50 MB, mas pode ser alterado para dar
suporte ao limite máximo de 2 GB.
 Limites com suporte definem o valor testado para um determinado parâmetro. Os
valores padrão para esses limites foram definidos por meio de testes e representam
as limitações 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 são os parâmetros configuráveis definidos por padrão
com o valor recomendado, enquanto outros limites com suporte estão relacionados a
parâmetros que não são representados por um valor configurável.
Um exemplo de limite com suporte é o número de conjuntos de sites por aplicativo Web.
O limite com suporte é de 250.000, que é o maior número de conjuntos de sites por
aplicativo Web que atenderam aos parâmetros de comparação 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 redução no desempenho à medida que o valor aumenta. Portanto, se
forem excedidos determinados limites, como o número de conjuntos de sites por
aplicativo Web, isso poderá resultar apenas em uma redução fracionária no desempenho
do farm. No entanto, na maioria dos casos, operar em um limite estabelecido ou próximo
a ele não é uma prática recomendada, pois as metas de desempenho e confiabilidade
aceitáveis são alcançadas mais facilmente quando o design de um farm possibilita um
equilíbrio razoável dos valores limite.
Limites e diretrizes de limites com suporte são determinados pelo desempenho. Em
outras palavras, você pode exceder os valores padrão dos limites, mas, à medida que
aumentar o valor limite, o desempenho do farm e o valor efetivo de outros limites
poderão ser afetados. Muitos limites no SharePoint Server podem ser alterados, mas é
importante entender como a alteração de um determinado limite afeta outras partes do
farm.
Como os limites são estabelecidos
No SharePoint Server 2010, limites e limites com suporte são estabelecidos por meio de
testes e da observação do comportamento do farm sob cargas crescentes, até o ponto
em que os serviços e as operações do farm atingirem seus limites operacionais efetivos.
Alguns serviços 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
média de vários fatores.
Por exemplo, as observações sobre o comportamento do farm sob carga quando
conjuntos de sites são adicionados indicam que certos recursos apresentam latência
inaceitavelmente alta, enquanto outros recursos ainda estão operando dentro dos
parâmetros aceitáveis. Portanto, o valor máximo atribuído ao número de conjuntos de
sites não é absoluto, sendo calculado com base em um conjunto esperado de
85
características de uso em que o desempenho geral do farm seria aceitável dentro do
limite específico na maioria das circunstâncias.
Obviamente, se alguns serviços estiverem operando de acordo com parâmetros que
sejam mais elevados do que aqueles usados para testar os limites, os limites máximos
efetivos de outros serviços serão reduzidos. Assim, é importante executar um
gerenciamento rigoroso da capacidade e dimensionar os exercícios de testes para
implantações específicas, de forma a estabelecer limites efetivos para esse ambiente.
Observação: não descrevemos o hardware que foi usado para validar os limites neste
documento, pois os limites foram coletados em vários farms e ambientes. Para obter
descrições dos farms usados nos testes, consulte Recomendações e resultados de
testes de desempenho e capacidade (SharePoint Server 2010) e Performance and
capacity technical case studies (SharePoint Server 2010) (em inglês).
A metáfora do equalizador
Você pode considerar limites e limites com suporte como controles deslizantes em um
equalizador gráfico, em que cada limite representa uma certa frequência. Nessa
metáfora, 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 número máximo de documentos por
biblioteca, um limite com suporte com um valor máximo testado de cerca de 30 milhões.
No entanto, esse valor depende de outro controle deslizante, que representa o tamanho
máximo de documentos no farm, um limite com valor padrão de 50 MB.
Se você alterar o tamanho máximo de documento para 1 GB para acomodar vídeos ou
outros objetos grandes, o número de documentos que a biblioteca pode fornecer aos
usuários com eficiência será reduzido de maneira correspondente. Por exemplo, a
configuração de hardware e a topologia de um determinado farm podem dar suporte a
um milhão de documentos, correspondendo a até 50 MB. No entanto, o mesmo farm
com o mesmo número de documentos não poderá atender às mesmas metas de latência
e taxa de transferência se o farm estiver servindo um tamanho médio de documento
maior, já que o tamanho limite foi definido como 1 GB.
O grau de redução do número máximo de documentos neste exemplo é difícil de prever
e se baseia no número de arquivos grandes na biblioteca, no volume de dados que eles
contêm, nas características de uso do farm e na disponibilidade de recursos de
hardware.
Limites e delimitadores
Esta seção lista os objetos que podem fazer parte de uma solução e fornece diretrizes
para o desempenho aceitável de cada tipo de objeto. Desempenho aceitável significa
que o sistema, da maneira como foi testado, pode dar suporte a esse número de objetos,
mas o número não pode ser excedido sem que ocorra uma certa redução do
desempenho ou do valor dos limites relacionados. Os objetos são listados por escopo e
por recurso. Dados de limites são fornecidos, juntamente com observações que
descrevem as condições em que o limite é obtido e links para informações adicionais,
sempre que estiverem disponíveis.
Use as diretrizes contidas neste artigo para rever os planos gerais da sua solução. Se
esses planos excederem as diretrizes recomendadas para um ou mais objetos, execute
uma ou mais das seguintes ações:
 Avalie a solução para garantir que haja compensações em outras áreas.
86

Sinalize essas áreas para testes e monitoramento à medida que criar sua
implantação.

Reprojete ou particione a solução para garantir que você não exceda as diretrizes de
capacidade.
Limites por hierarquia
Esta seção fornece limites organizados pela hierarquia lógica de um farm do SharePoint
Server 2010.
Limites de aplicativos Web
A tabela a seguir lista as diretrizes recomendadas para aplicativos Web.
Limite
Valor máximo
Tipo de
limite
Observações
Banco de dados de
conteúdo
300 por aplicativo Web
Com
suporte
Com 300 bancos de
dados de conteúdo por
aplicativo Web, não são
afetadas as operações de
usuários finais, como
abertura de sites ou de
conjuntos de sites.
Porém, operações
administrativas, como a
criação de um novo
conjunto de sites, terão
seu desempenho
reduzido. É recomendável
usar o Windows
PowerShell para
gerenciar o aplicativo
Web quando houver um
grande número de
bancos de dados de
conteúdo, pois a interface
de gerenciamento tornase lenta e difícil de
navegar.
Zona
5 por aplicativo Web
Delimitador O número de zonas
definidas para um farm é
embutido em código
como cinco. As zonas
são Padrão, Intranet,
Extranet, Internet e
Personalizada.
Caminho gerenciado
20 por aplicativo Web
Com
suporte
87
Os caminhos
gerenciados são
armazenados em cache
Limite
Tipo de
limite
Valor máximo
Observações
no servidor Web, e os
recursos da CPU são
usados para processar
solicitações recebidas em
relação à lista de
caminhos gerenciados.
Se for excedido o total de
20 caminhos gerenciados
por aplicativo Web, será
adicionada carga ao
servidor Web para cada
solicitação.
Se você planeja exceder
20 caminhos gerenciados
em um determinado
aplicativo Web, é
recomendável testar se o
sistema apresentará
desempenho aceitável.
Tamanho de cache de
solução
300 MB por aplicativo
Web
Limite
O cache de solução
permite que o serviço
InfoPath Forms
mantenha as soluções
em cache, para acelerar
a recuperação das
mesmas. Se o tamanho
do cache for excedido, as
soluções serão
recuperadas do disco, o
que poderá tornar os
tempos de resposta mais
lentos. Você pode
configurar o tamanho do
cache de solução por
meio do cmdlet SetSPInfoPathFormsService
do Windows PowerShell.
Para obter mais
informações, consulte
SetSPInfoPathFormsService.
Servidor Web e limites de servidor de aplicativos
A tabela a seguir lista as diretrizes recomendadas para servidores Web no farm.
88
Limite
Valor máximo
Tipo de Observações
limite
Pools de aplicativos
10 por servidor Web
Com O número máximo é
suporte determinado pelos recursos
de hardware.
Esse limite depende em
grande parte dos seguintes
itens:
 A quantidade de
memória RAM alocada
para os servidores Web

A carga de trabalho que
o farm está servindo, ou
seja, a base de usuários
e as características de
uso (um único pool de
aplicativos extremamente
ativo pode atingir 10 GB
ou mais)
Limites de bancos de dados de conteúdo
A tabela a seguir lista as diretrizes recomendadas para bancos de dados de conteúdo.
Limite
Valor máximo
Tipo de
limite
Observações
Tamanho do banco de
dados de conteúdo
200 GB por banco de
dados de conteúdo
Com
suporte
É altamente
recomendável limitar
o tamanho dos
bancos de dados de
conteúdo a 200 GB
para ajudar a
garantir o
desempenho do
sistema.
Há suporte para
tamanhos de bancos
de dados de
conteúdo de até
1 terabyte somente
para grandes
repositórios de um
único site e
89
Limite
Tipo de
limite
Valor máximo
Observações
arquivamentos com
E/S e padrões de
uso não
colaborativos, como
sites da Central de
Registros. Há
suporte para
tamanhos de bancos
de dados maiores
nesses cenários
porque seus padrões
de E/S e formatos
típicos de estrutura
de dados foram
projetados e
testados em escalas
maiores. Para obter
mais informações
sobre repositórios de
documentos em
grande escala,
consulte a seção
sobre estimativa de
requisitos de
desempenho e
capacidade para
repositórios de
documentos em
grande escala,
disponível em
Recomendações e
resultados de testes
de desempenho e
capacidade
(SharePoint Server
2010), e a seção
Cenários comuns de
gerenciamento de
conteúdo em grande
escala, disponível
em Enterprise
content storage
planning (SharePoint
Server 2010).
Um conjunto de sites
não deve ultrapassar
100 GB, a menos
90
Limite
Tipo de
limite
Valor máximo
Observações
que haja apenas um
conjunto de sites no
banco de dados.
Conjuntos de sites por
banco de dados de
conteúdo
2.000 recomendados
Máximo de 5.000
Com
suporte
É altamente
recomendável limitar
o número de
conjuntos de sites
em um banco de
dados de conteúdo
para 2000. No
entanto, há suporte
para até 5000
conjuntos de sites
em um banco de
dados.
Esses limites
referem-se à
velocidade de
atualização. Quanto
maior for o número
de conjuntos de sites
em um banco de
dados, mais lenta
será a atualização.
O limite quanto ao
número de conjuntos
de sites em um
banco de dados está
subordinado ao
limite de tamanho de
um banco de dados
de conteúdo que
tenha mais de um
conjunto de sites
(200 GB). Portanto,
à medida que o
número de conjuntos
de sites em um
banco de dados
aumentar, o
tamanho médio dos
conjuntos de sites
nele contidos deverá
diminuir.
Se você exceder o
limite de 2000
91
Limite
Tipo de
limite
Valor máximo
Observações
conjuntos de sites, o
tempo de inatividade
durante as
atualizações poderá
ser mais longo. Se
você planeja exceder
2000 conjuntos de
sites, é
recomendável ter
uma estratégia clara
de atualização e
obter hardware
adicional para
acelerar as
atualizações e as
atualizações de
software que afetam
os bancos de dados.
Para definir o nível
de alerta para o
número de sites em
um banco de dados
de conteúdo, use o
cmdlet SetSPContentDatabase
do Windows
PowerShell com o
parâmetro WarningSiteCount.
Para obter mais
informações,
consulte SetSPContentDatabase.
Subsistema de
Delimitador Quando o
O tempo até o primeiro
armazenamento RBS
SharePoint Server
byte de qualquer resposta
(Remote BLOB Storage) no do NAS não pode exceder
2010 estiver
Armazenamento NAS
configurado para
20 milissegundos
(Network Attached Storage)
usar o RBS, e os
BLOBs residirem no
armazenamento
NAS, considere o
delimitador a seguir.
Do momento em que
o SharePoint Server
2010 solicita um
BLOB até o
92
Limite
Tipo de
limite
Valor máximo
Observações
momento em que ele
recebe o primeiro
byte do NAS, não
podem decorrer
mais de 20
milissegundos.
Limites de conjuntos de sites
A tabela a seguir lista as diretrizes recomendadas para conjuntos de sites.
Limite
Valor máximo
Tipo de
limite
Observações
Site
250.000 por conjunto de
sites
Com
suporte
O número máximo
recomendado de
sites e subsites é
de 250.000 sites.
Você pode criar um
número 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
então, uma
hierarquia
profunda com 100
sites, cada um com
10 níveis de
subsites, também
conteria um total
de 100.000 sites.
Observação: a
exclusão ou a
criação de um site
ou subsite pode
afetar de maneira
significativa a
93
Limite
Tipo de
limite
Valor máximo
Observações
disponibilidade de
um site. O acesso
ao site e aos
subsites será
limitado enquanto
o site está sendo
excluído. A
tentativa de criar
vários subsites ao
mesmo tempo
também poderá
falhar.
Tamanho de conjunto de
sites
100 GB por conjunto de
sites
Limites de listas e bibliotecas
94
Com
suporte
Um conjunto de
sites não deve
ultrapassar
100 GB, a menos
que haja apenas
um conjunto de
sites no banco de
dados.
Certas ações de
conjuntos de sites,
como
backup/restauração
de conjuntos de
sites ou o cmdlet
Move-SPSite do
Windows
PowerShell,
causam grandes
operações do
Microsoft SQL
Server, que
poderão afetar o
desempenho ou
falhar se outros
conjuntos de sites
estiverem ativos no
mesmo banco de
dados. Para obter
mais informações,
consulte MoveSPSite.
A tabela a seguir lista as diretrizes recomendadas para listas e bibliotecas. Para obter
mais informações, consulte o white paper sobre o design de grandes listas e
maximização do desempenho de listas, disponível em Recomendações e resultados de
testes de desempenho e capacidade (SharePoint Server 2010).
Limite
Valor máximo
Tipo de
limite
Tamanho de
linha de lista
8.000 bytes por Limite
linha
Tamanho do
arquivo
2 GB
Documentos
30.000.000 por Com
biblioteca
suporte
Você pode criar bibliotecas de documentos
muito grandes aninhando pastas ou usando
a hierarquia de sites e modos de exibição
padrão. Esse valor pode variar dependendo
da forma como os documentos e as pastas
são organizados e conforme o tipo e o
tamanho dos documentos armazenados.
Versões
principais
400.000
Se você exceder esse limite, operações de
arquivo básicas, como abrir ou salvar
arquivos, excluir e exibir o histórico de
versões, talvez não tenham êxito.
Itens
30.000.000 por Com
lista
suporte
Você pode criar listas muito grandes usando
modos de exibição padrão, hierarquias de
sites e a navegação de metadados. Esse
valor pode variar dependendo do número de
colunas na lista e da utilização da lista.
Limite de
tamanho de
linhas
6 linhas de
Com
tabela internas suporte
ao banco de
dados usadas
para uma lista
ou um item da
biblioteca
Especifica o número máximo 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 várias colunas, cada item pode
ser quebrado em várias linhas de tabela
internas, até seis linhas por padrão. Isso é
Observações
Cada item da biblioteca ou lista pode ocupar
apenas um total de 8000 bytes no banco de
dados. São reservados 256 bytes para
colunas internas, o que deixa 7.744 bytes
para colunas de usuários finais. Para obter
detalhes sobre o espaço consumido por
cada tipo de campo, consulte Limites de
colunas.
Delimitador O tamanho de arquivo padrão máximo é de
50 MB. Ele pode ser aumentado para até 2
GB; no entanto, um alto volume de arquivos
muito grandes pode afetar o desempenho
do farm.
Com
suporte
95
Limite
Valor máximo
Tipo de
limite
Observações
configurável por administradores de farm
somente por meio do modelo de objeto. O
método de modelo de objeto é
SPWebApplication.MaxListItemRowStorage.
Operações em 100 itens por
operação em
massa
massa
Delimitador A interface do usuário permite que no
máximo 100 itens sejam selecionados para
operações em massa.
Limite de
8 operações de Limite
pesquisa no
junção por
modo de
consulta
exibição de lista
Especifica o número máximo de junções
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 junções, a
operação será bloqueada. Isso não se aplica
a operações de item único. Quando você
usa o modo de exibição máximo por meio do
modelo de objeto (sem especificar campos
de modo de exibição), o SharePoint retorna
até as primeiras oito pesquisas.
Limite do modo 5.000
de exibição de
lista
Limite
Especifica o número máximo de itens na
lista ou biblioteca que uma operação de
banco de dados, como uma consulta, pode
processar de uma única vez, fora da janela
de tempo diária definida pelo administrador
durante a qual as consultas são irrestritas.
Limite do modo 20.000
de exibição de
lista para
auditores e
administradores
Limite
Especifica o número máximo de itens na
lista ou biblioteca que uma operação de
banco de dados, como uma consulta, pode
processar de uma única vez quando é feita
por um auditor ou administrador com as
permissões apropriadas. Essa configuração
funciona em conjunto com Permitir
Substituição do Modelo do Objeto.
Subsite
2.000 por modo Limite
de exibição de
site
A interface para enumerar os subsites de
um determinado site não funciona
adequadamente quando o número de
subsites ultrapassa 2.000. Da mesma
forma, a página Todo o Conteúdo do Site e
o desempenho do controle de exibição de
árvore diminuirão significativamente à
medida que o número de subsites
aumentar.
Coautoria no
10 editores
O número máximo recomendado de
Limite
96
Limite
Valor máximo
Tipo de
limite
Observações
editores simultâneos é 10. O limite é 99.
Microsoft Word simultâneos por
e no Microsoft documento
PowerPoint
para arquivos
.docx, .pptx e
.ppsx
Se houver 99 coautores com um único
documento aberto para edição simultânea,
qualquer usuário após o centésimo verá um
erro do tipo "Arquivo em uso" e deverá
exibir uma cópia somente leitura.
Se houver mais de 10 coeditores, isso
prejudicará progressivamente a uma
experiência do usuário, com a ocorrência de
mais conflitos, e os usuários terão que
passar por mais iterações para que suas
alterações sejam carregadas com êxito.
Escopo de
segurança
1.000 por lista
Limite
O número máximo de escopos de
segurança exclusivos definidos para uma
lista não deve exceder 1.000.
Um escopo é o limite de segurança para um
objeto protegível e quaisquer de seus filhos
que não tenham um limite de segurança
separado definido. Um escopo contém uma
ACL (Lista de Controle de Acesso), mas,
diferentemente de outras ACLs de NTFS,
um escopo pode incluir entidades de
segurança específicas do SharePoint
Server. Os membros de uma ACL para um
escopo podem incluir usuários do Windows,
contas de usuário que não sejam de
usuários do Windows (como contas
baseadas em formulários), grupos do Active
Directory ou grupos do SharePoint.
Limites de colunas
Os dados do SharePoint Server 2010 são armazenados em tabelas do SQL Server. Para
permitir o número máximo de colunas possíveis em uma lista do SharePoint, o
SharePoint Server criará várias linhas no banco de dados quando os dados não
couberem em uma única linha. Isso é chamado de disposição de linhas.
Sempre que uma linha é disposta no SQL Server, uma carga de consulta adicional é
colocada no servidor quando esse item é consultado, porque uma instrução Join SQL
deve ser incluída na consulta. Para impedir uma carga excessiva, por padrão, são
permitidas no máximo seis linhas do SQL Server para um item do SharePoint. Esse
limite causa uma limitação específica quanto ao número de colunas de cada tipo que
podem ser incluídas em uma lista do SharePoint. A tabela a seguir descreve os limites
para cada tipo de coluna.
97
O parâmetro de disposição de linhas pode ser aumentado acima de seis, mas isso pode
resultar em carga excessiva no servidor. É recomendável realizar testes de desempenho
antes de exceder esse limite. Para obter mais informações, consulte o white paper sobre
o design de listas grandes e a maximização do desempenho de listas, que pode ser
acessado em Recomendações e resultados de testes de desempenho e capacidade
(SharePoint Server 2010).
Cada tipo de coluna tem um valor de tamanho listado em bytes. A soma de todas as
colunas em uma lista do SharePoint não pode exceder 8.000 bytes. Dependendo do uso
das colunas, os usuários podem atingir o limite de 8.000 bytes antes de atingirem o limite
de disposição de seis linhas.
Limite
Valor máximo
Tipo Tamanho por Observações
de
coluna
limite
Linha única de
texto
276
Limite 28 bytes
A disposição de linhas do SQL
Server ocorre após cada 64
colunas em uma lista do
SharePoint. O valor de
disposição padrão de seis
linhas permite um máximo de
384 colunas de linha de texto
única por lista do SharePoint (6
* 64 = 384). No entanto, como
o limite por item de lista do
SharePoint é de 8000 bytes,
dos quais 256 bytes são
reservados para colunas
internas do SharePoint, o limite
real é de 276 colunas de linha
de texto única.
Várias linhas de
texto
192
Limite 28 bytes
A disposição de linhas do SQL
Server ocorre após cada 32
colunas em uma lista do
SharePoint. O valor de
disposição padrão de seis
linhas permite um máximo de
192 colunas com várias linhas
de texto por lista do SharePoint
(6 * 32 = 192).
Opção
276
Limite 28 bytes
A disposição de linhas do SQL
Server ocorre após cada 64
colunas em uma lista do
SharePoint. O valor de
disposição padrão de seis
linhas permite um máximo de
384 colunas de Opção por lista
98
Limite
Valor máximo
Tipo Tamanho por Observações
de
coluna
limite
do SharePoint (6 * 64 = 384);
porém, como o limite por item
de lista do SharePoint é de
8000 bytes, dos quais 256
bytes são reservados para
colunas internas do
SharePoint, o limite real deve
ser de 276 colunas de opções.
Número
72
Limite 12 bytes
A disposição de linhas do SQL
Server ocorre após cada 12
colunas em uma lista do
SharePoint. O valor de
disposição padrão de seis
linhas permite um máximo de
72 colunas de Número por lista
do SharePoint (6 * 12 = 72).
Moeda
72
Limite 12 bytes
A disposição de linhas do SQL
Server ocorre após cada 12
colunas em uma lista do
SharePoint. O valor de
disposição padrão de seis
linhas permite um máximo de
72 colunas de Moeda por lista
do SharePoint (6 * 12 = 72).
Data e Hora
48
Limite 12 bytes
A disposição de linhas do SQL
Server ocorre após cada oito
colunas em uma lista do
SharePoint. O valor de
disposição padrão de seis
linhas permite um máximo de
48 colunas de Data e Hora por
lista do SharePoint (6 * 12 =
48).
Pesquisa
96
Limite 4 bytes
A disposição de linhas do SQL
Server ocorre após cada 16
colunas em uma lista do
SharePoint. O valor de
disposição padrão de seis
linhas permite um máximo de
96 colunas de Pesquisa de
valor único por lista do
SharePoint (6 * 16 = 96).
99
Limite
Valor máximo
Tipo Tamanho por Observações
de
coluna
limite
Sim/Não
96
Limite 5 bytes
A disposição de linhas do SQL
Server ocorre após cada 16
colunas em uma lista do
SharePoint. O valor de
disposição padrão de seis
linhas permite um máximo de
96 colunas de Sim/Não por lista
do SharePoint (6 * 16 = 96).
Pessoa ou grupo 96
Limite 4 bytes
A disposição de linhas do SQL
Server ocorre após cada 16
colunas em uma lista do
SharePoint. O valor de
disposição padrão de seis
linhas permite um máximo de
96 colunas de Pessoa ou
Grupo por lista do SharePoint
(6 * 16 = 96).
Hiperlink ou
imagem
138
Limite 56 bytes
A disposição de linhas do SQL
Server ocorre após cada 32
colunas em uma lista do
SharePoint. O valor de
disposição padrão de seis
linhas permite um máximo de
192 colunas de Hiperlink ou
Imagem por lista do SharePoint
(6 * 32 = 192); porém, como o
limite por item de lista do
SharePoint é de 8000 bytes,
dos quais 256 bytes são
reservados para colunas
internas do SharePoint, o limite
real deve ser de 138 colunas
de Hiperlink ou Imagem.
Calculada
48
Limite 28 bytes
A disposição de linhas do SQL
Server ocorre após cada oito
colunas em uma lista do
SharePoint. O valor de
disposição padrão de seis
linhas permite um máximo de
48 colunas de Calculada por
lista do SharePoint (6 * 8 = 48).
GUID
6
Limite 20 bytes
A disposição de linhas do SQL
Server ocorre após cada
100
Limite
Valor máximo
Tipo Tamanho por Observações
de
coluna
limite
coluna em uma lista do
SharePoint. O valor de
disposição padrão de seis
linhas permite um máximo de
seis colunas de GUID por lista
do SharePoint (6 * 1 = 6).
Inteiros
96
Limite 4 bytes
Metadados
gerenciados
94
Limite 40 bytes
São alocadas quatro colunas
para a
para o primeiro campo de
primeira e Metadados Gerenciados
32 bytes
adicionado a uma lista:
para cada  Um campo de pesquisa
uma
para a marca real
subsequente
 Um campo de texto oculto
para o valor da cadeia de
caracteres
A disposição de linhas do SQL
Server ocorre após cada 16
colunas em uma lista do
SharePoint. O valor de
disposição padrão de seis
linhas permite um máximo de
96 colunas de Inteiros por lista
do SharePoint (6 * 16 = 96).

Um campo de pesquisa
para o mecanismo de
coleta

Um campo de pesquisa
para transmissão do
mecanismo de coleta
Cada campo de Metadados
Gerenciados subsequente
adicionado a uma lista adiciona
duas colunas:
 Um campo de pesquisa
para a marca real

Um campo de texto oculto
para o valor da cadeia de
caracteres
O número máximo de colunas
de Metadados Gerenciados é
calculado como (14 (16 * (n1))), em que n é o valor de
101
Limite
Valor máximo
Tipo Tamanho por Observações
de
coluna
limite
mapeamento de linha (o
padrão é 6).
As colunas de dados externos seguem o conceito de uma coluna primária e colunas
secundárias. Ao adicionar uma coluna de dados externa, você pode selecionar alguns
campos secundários do tipo de conteúdo externo que deseja adicionar à lista. Por
exemplo, no caso do Tipo de Conteúdo Externo "Cliente", que tem campos como "ID",
"Nome", "País" e "Descrição", ao adicionar uma coluna de Dados Externos do tipo
"cliente" a uma lista, você pode adicionar campos secundários para mostrar a "ID", o
"Nome" e a "Descrição" do Cliente. Em geral, estas são as colunas adicionadas:
 Coluna primária: um campo de texto.

Coluna de Id Oculta: um campo de texto multilinha.

Colunas secundárias: cada coluna secundária é um texto/número/Booliano/texto
multilinha que se baseia no tipo de dados da coluna secundária, conforme definido
no modelo de Catálogo de Dados Corporativos. Por exemplo, a ID pode ser
mapeada para uma coluna de Número; o Nome pode ser mapeado para uma coluna
de Texto com uma linha; a Descrição pode ser mapeada para uma coluna de Texto
com várias linhas.
Limites de páginas
A tabela a seguir lista as diretrizes recomendadas para páginas.
Limite
Valor máximo
Web parts
25 por wiki ou página de Web Limite
parts
102
Tipo de
limite
Observações
Esse valor é
uma
estimativa
com base em
Web Parts
simples. A
complexidade
das Web
parts
determina
quantas
delas podem
ser usadas
em uma
página antes
que o
desempenho
seja afetado.
Limites de segurança
Limite
Tipo de Observações
limite
Valor máximo
Com Esse não é um imite rígido,
suporte mas é consistente com as
diretrizes do Active Directory.
Há vários itens que afetam
esse número:
5.000
Número de grupos do
SharePoint aos quais um
usuário pode pertencer
Usuários em um conjunto 2 milhões por conjunto
de sites
de sites

O tamanho do token de
usuário

O cache de grupos: o
SharePoint Server 2010
tem uma tabela que
armazena em cache o
número de grupos aos
quais um usuário
pertence, assim que
estes grupos são usados
em ACLs).

O tempo da verificação
de segurança: à medida
que aumenta o número
de grupos dos quais um
usuário é membro, o
tempo necessário para a
verificação de acesso
também aumenta.
Com Você pode adicionar milhões
suporte de pessoas a seu site
usando grupos de segurança
do Microsoft Windows para
gerenciar a segurança, em
vez de usar usuários
individuais.
Esse limite se baseia na
capacidade de
gerenciamento e na
facilidade de navegação na
interface do usuário.
Quando há muitas entradas
(grupos de segurança de
usuários) no conjunto de
sites (mais de mil), você deve
103
Limite
Tipo de Observações
limite
Valor máximo
usar o Windows PowerShell
para gerenciar os usuários,
em vez da interface do
usuário. Isso proporcionará
uma melhor experiência de
gerenciamento.
Princípios/Usuários do
Active Directory em um
grupo do SharePoint
Grupo do SharePoint
5.000 por grupo do
SharePoint
10.000 por conjunto de
sites
Com O SharePoint Server 2010
suporte permite adicionar usuários ou
grupos do Active Directory a
um grupo do SharePoint.
A existência de até 5.000
usuários (ou grupos ou
usuários do Active Directory)
em um grupo do SharePoint
proporciona desempenho
aceitável.
As atividades mais afetadas
por esse limite são:

A busca de usuários para
validar permissões. Essa
operação se torna
gradativamente mais
longa, com o crescimento
no número de usuários
em um grupo.

Renderização da
associação do modo de
exibição. Essa operação
sempre levará tempo.
Com Acima de 10.000 grupos, o
suporte tempo necessário para
executar operações aumenta
significativamente. Isso se
aplica particularmente à
adição de um usuário a um
grupo existente, à criação de
um novo grupo e à
renderização de modos de
exibição de grupos.
Entidade de segurança: 5.000 por ACL (Lista de Com O tamanho do escopo afeta
suporte os dados que são usados
tamanho do Escopo de Controle de Acesso)
Segurança
para um cálculo de
104
Limite
Tipo de Observações
limite
Valor máximo
verificação de segurança.
Esse cálculo ocorre sempre
que o escopo é alterado. Não
há um limite rígido, mas
quanto maior for o escopo,
mais tempo levará o cálculo.
Limites por recurso
Esta seção lista os limites classificados por recurso:
Limites de pesquisa
A tabela a seguir lista as diretrizes recomendadas para Pesquisa.
Limite
Tipo de
limite
Observações
Aplicativos de
20 por farm
serviço de pesquisa
do SharePoint
Com
suporte
Vários aplicativos do
serviço de pesquisa do
SharePoint podem ser
implantados no mesmo
farm, pois você pode
atribuir componentes de
pesquisa e bancos de
dados a servidores
separados. O limite
recomendado de 20 é
menor que o limite
máximo para todos os
aplicativos de serviço em
um farm.
Bancos de dados
de rastreamento e
Itens de bancos de
dados
Limite
O banco de dados de
rastreamento armazena
dados de rastreamento
(tempo/status etc.) sobre
todos os itens que foram
rastreados. O limite com
suporte é de 10 bancos de
dados de rastreamento
por aplicativo de serviço
de Pesquisa do
SharePoint.
O limite recomendado é
de 25 milhões de itens por
banco de dados de
rastreamento (ou um total
Valor máximo
10 bancos de dados de
rastreamento por aplicativo
de serviço de pesquisa
25 milhões de itens por
banco de dados de
rastreamento
105
Limite
Tipo de
limite
Valor máximo
Observações
de quatro bancos de
dados de rastreamento
por aplicativo de serviço
de pesquisa).
Componentes de
rastreamento
16 por aplicativo de serviço
de pesquisa
Limite
O limite recomendado por
aplicativo é um total de 16
componentes de
rastreamento, com dois
por banco de dados de
rastreamento e dois por
servidor, presumindo-se
que o servidor tenha, pelo
menos, oito
processadores (núcleos).
O número total de
componentes de
rastreamento por servidor
deve ser inferior a
128/(total de
componentes de consulta)
para minimizar a
degradação de E/S de
propagação. Se o limite
recomendado for
excedido, isso poderá não
aumentar o desempenho
de rastreamento, na
verdade, o desempenho
de rastreamento poderá
diminuir com base nos
recursos disponíveis no
servidor de rastreamento,
banco de dados e host de
conteúdo.
Partições de
indexação
20 por aplicativo de serviço
de pesquisa; total de 128
106
Limite
A partição de índice
contém um subconjunto
do índice de aplicativo de
serviço de pesquisa. O
limite recomendado é de
20. Se for aumentado o
número de partições de
índice, cada partição
conterá um subconjunto
menor do índice,
reduzindo a memória
Limite
Tipo de
limite
Valor máximo
Observações
RAM e o espaço em disco
necessários no servidor
de consulta que hospeda
o componente de consulta
atribuído à partição de
índice. O limite para o
número total de partições
de índice é de 128.
Itens indexados
100 milhões por aplicativo de Com
suporte
serviço de pesquisa; 10
milhões por partição de índice
A Pesquisa do SharePoint
dá suporte a partições de
índice, cada uma das
quais contendo um
subconjunto do índice de
pesquisa. O máximo
recomendado é de 10
milhões de itens em
qualquer partição. O
número máximo total de
itens recomendado (por
exemplo, pessoas, itens
de lista, documentos,
páginas da Web) é de 100
milhões.
Entradas do log de 100 milhões por aplicativo de Com
rastreamento
suporte
pesquisa
Esse é o número de
entradas de log
individuais no log de
rastreamento. Ele seguirá
o limite de "itens
indexados".
Bancos de dados
de propriedade
O banco de dados de
propriedade armazena os
metadados de itens em
cada partição de índice
associada a ele. Uma
partição de índice só pode
ser associada a um
repositório de
propriedades. O limite
recomendado é de 10
bancos de dados de
propriedade por aplicativo
de serviço de pesquisa. O
limite para partições de
índice é de 128.
10 por aplicativo de serviço
de pesquisa; total de 128
107
Limite
Limite
Valor máximo
Tipo de
limite
Observações
Componentes de
consulta
128 por aplicativo de
pesquisa; 64/(total de
componentes de
rastreamento) por servidor
Limite
O número total de
componentes de consulta
é limitado pela capacidade
dos componentes de
rastreamento de copiar
arquivos. O número
máximo de componentes
de consulta por servidor é
limitado pela capacidade
dos componentes de
consulta de absorver
arquivos propagados dos
componentes de
rastreamento.
Regras de escopo
100 regras de escopo por
escopo, total de 600 por
aplicativo de serviço de
pesquisa
Limite
Se esse limite for
excedido, isso reduzirá a
atualização do
rastreamento e atrasará
resultados potenciais de
consultas de escopo.
Escopos
200 por site
Limite
Esse é o limite
recomendado por site. Se
esse limite for excedido,
isso poderá reduzir a
eficiência do rastreamento
e, se os escopos forem
adicionados ao grupo de
exibição, isso afetará a
latência de navegador do
usuário final. Além disso,
a exibição dos escopos na
interface de administração
de pesquisa é prejudicada
à medida que o número
de escopos passa do
limite recomendado.
Limite
Grupos de exibição são
utilizados para uma
exibição agrupada de
escopos por meio da
interface do usuário. Se
esse limite for excedido,
isso começará a
prejudicar a experiência
Grupos de exibição 25 por site
108
Limite
Tipo de
limite
Valor máximo
Observações
de escopo na interface de
administração de
pesquisa.
Com
suporte
Esse é o limite testado.
Fontes de conteúdo 50 por aplicativo de serviço
de pesquisa
Limite
O limite recomendado de
50 pode ser excedido até
o limite de 500 por
aplicativo de serviço de
pesquisa. No entanto,
devem ser usados menos
endereços iniciais, e o
limite de rastreamento
simultâneo deve ser
seguido.
Endereços iniciais
100 por fonte de conteúdo
Limite
O limite recomendado
pode ser excedido até o
limite de 500 por origem
de conteúdo. No entanto,
quanto mais endereços
iniciais houver, menos
fontes de conteúdo
deverão ser usadas.
Quando há muitos
endereços iniciais, é
recomendável colocá-los
como links em uma
página HTML e rastrear
essa página com o
rastreador HTTP,
seguindo os links.
Rastreamentos
simultâneos
20 por aplicativo de pesquisa Limite
Este é o número de
rastreamentos em
andamento ao mesmo
tempo. Se esse número
for excedido, isso poderá
fazer com que a taxa de
rastreamento geral
diminua.
Propriedades
rastreadas
500.000 por aplicativo de
pesquisa
Com
suporte
Estas são propriedades
descobertas durante um
rastreamento.
Regra de impacto
100
Limite
Limite recomendado de
Alertas
1.000.000 por aplicativo de
pesquisa
109
Limite
Tipo de
limite
Valor máximo
de rastreamento
Observações
100 por farm. A
recomendação pode ser
excedida, porém, a
exibição das regras de
visitas do site na interface
de administração de
pesquisa é prejudicada.
Em cerca de 2000 regras
de visitas do site, a página
Gerenciar Regras de
Visitas do Site torna-se
ilegível.
Regras de
rastreamento
100 por aplicativo de serviço Limite
de pesquisa
Esse valor pode ser
excedido; no entanto, a
exibição das regras de
rastreamento na interface
de administração de
pesquisa é prejudicada.
Propriedades
gerenciadas
100.000 por aplicativo de
serviço de pesquisa
Limite
Estas são propriedades
utilizadas pelo sistema de
pesquisa em consultas.
Propriedades rastreadas
são mapeadas para
propriedades
gerenciadas.
Mapeamentos
100 por propriedade
gerenciada
Limite
Se esse limite for
excedido, isso poderá
diminuir a velocidade de
rastreamento e o
desempenho de consulta.
Com
suporte
Esse é o número máximo
recomendado de URLs
que devem ser removidas
do sistema em uma
operação.
Remoções de URL 100 remoções por operação
Páginas
autoritativas
1 página de nível superior e o Limite
mínimo de páginas de
segundo e terceiro nível por
aplicativo de serviço de
pesquisa
O limite recomendado é
de uma página autoritativa
de nível superior e o
menor número possível de
páginas de segundo e
terceiro nível para obter a
relevância desejada.
O limite é de 200 por nível
110
Limite
Tipo de
limite
Valor máximo
Observações
de relevância por
aplicativo de pesquisa,
mas a adição de páginas
pode não proporcionar a
relevância desejada.
Adicione o site principal
ao primeiro nível de
relevância. Adicione mais
sites principais no
segundo ou terceiro nível
de relevância, um de cada
vez, e avalie a relevância
após cada adição para
garantir que o efeito de
relevância desejado seja
obtido.
Palavras-chave
200 por conjunto de sites
Com
suporte
Propriedades de
metadados
reconhecidas
10.000 por item rastreado
Delimitador Esse é o número de
propriedades de
metadados que podem
ser determinadas e
potencialmente mapeadas
ou usadas para consultas
quando um item é
rastreado.
Limites de Serviço de Perfil de Usuário
111
O limite recomendado
pode ser excedido até o
limite máximo (imposto
pelo ASP.NET) de 5000
por conjunto de sites, com
cinco Melhores Opções
por palavra-chave. Se
você exceder esse limite,
a exibição de palavraschave na interface do
usuário de administração
de site será prejudicada.
Para modificar o limite
imposto pelo ASP.NET,
edite os arquivos
Web.Config e
Client.config
(MaxItemsInObjectGraph).
A tabela a seguir lista as diretrizes recomendadas para o Serviço de Perfil de Usuário.
Limite
Valor máximo
Tipo de
limite
Observações
Perfis de usuários
2.000.000 por aplicativo de
serviço
Com
suporte
Um aplicativo
de serviço de
perfil de
usuário pode
dar suporte a
até dois
milhões de
perfis de
usuário com
funcionalidade
completa de
recursos
sociais. Esse
número
representa o
número de
perfis que
podem ser
importados
para o
repositório de
perfis de
pessoas de
um serviço de
diretório e
também o
número de
perfis aos
quais um
aplicativo de
serviço de
perfil de
usuário pode
dar suporte
sem
prejudicar o
desempenho
dos recursos
sociais.
Com
suporte
Há suporte
para um total
de até 500
milhões de
Etiquetas de conteúdo social, 500.000.000 por banco de
observações e classificações dados social
112
Limite
Valor máximo
Tipo de
limite
Observações
etiquetas de
conteúdo
social,
observações e
classificações
em um banco
de dados
social, sem
redução
significativa
de
desempenho.
No entanto,
as operações
de
manutenção
do banco de
dados, como
backup e
restauração,
podem
apresentar
redução de
desempenho
nesse ponto.
Limites de implantação de conteúdo
A tabela a seguir lista as diretrizes recomendadas para implantação de conteúdo.
Limite
Tipo de Observações
limite
Valor máximo
Trabalhos de
20
implantação de
conteúdo executados
em caminhos diferentes
Com Para trabalhos de execução
suporte simultânea em caminhos que
estão conectados a conjuntos
de sites no mesmo banco de
dados de conteúdo de origem,
há maior risco de deadlocks no
banco de dados. Para trabalhos
que devem ser executados
simultaneamente, é
recomendável mover os
conjuntos de sites para bancos
de dados de conteúdos de
origem diferentes.
113
Limite
Tipo de Observações
limite
Valor máximo
Observação:
Não é possível haver trabalhos
em execução simultânea no
mesmo caminho.
Se você estiver usando
instantâneos do SQL Server
para implantação de conteúdo,
cada caminho criará um
instantâneo. Isso aumenta os
requisitos de E/S para o banco
de dados de origem.
Para obter mais informações,
consulte Sobre trabalhos e
caminhos de implantação.
Limites de blog
A tabela a seguir lista as diretrizes recomendadas para blogs.
Limite
Valor máximo
Tipo de limite Observações
Posts de blog
5000 por site
Com suporte O número
máximo de
posts de
blog é de
5000 por
site.
Comentários
1000 por post
Com suporte O número
máximo de
comentários
é de 1000
por post.
Limites de Serviços Corporativos de Conectividade
A tabela a seguir lista as diretrizes recomendadas para Serviços Corporativos de
Conectividade.
Limite
Tipo de
limite
Valor máximo
114
Observações
Limite
Valor máximo
Tipo de
limite
ECTs (Tipos de Conteúdo
Externo) (na memória)
5000 por servidor Web (por Limite
locatário)
Conexões externas do
sistema
500 por servidor Web
Delimitador Número de
conexões do
sistema externas
ativas/abertas em
um determinado
ponto no tempo. O
valor máximo
padrão é de 200; o
limite é de 500.
Esse limite é
imposto no escopo
do Servidor Web,
independentemente
do tipo de sistema
externo (por
exemplo, banco de
dados, assembly
.NET e assim por
diante). O máximo
padrão é usado
para restringir o
número de
conexões. Um
aplicativo pode
especificar um
limite maior por
meio do contexto
de execução; o
limite impõe o
máximo até mesmo
para aplicativos
que não respeitam
o padrão.
Itens de banco de dados
retornados por solicitação
2.000 por conector de
banco de dados
Limite
115
Observações
Número total de
definições de ECT
(tipo de conteúdo
externo)
carregadas na
memória em um
determinado ponto
no tempo em um
servidor Web.
Número de itens
por solicitação que
o conector de
Limite
Tipo de
limite
Valor máximo
Observações
banco de dados
pode retornar.
O padrão máximo
de 2.000 é usado
pelo conector de
banco de dados
para restringir o
número de
resultados que
podem ser
retornados por
página. O aplicativo
pode especificar
um limite maior por
meio do contexto
de execução; o
Máximo Absoluto
impõe o máximo
mesmo para
aplicativos que não
respeitam o padrão.
O limite para esse
valor é de
1.000.000.
Limites de fluxos de trabalho
A tabela a seguir lista as diretrizes recomendadas para fluxos de trabalho.
Limite
Valor máximo
Limite de adiamento de fluxo 15
de trabalho
116
Tipo de
limite
Observações
Limite
O número
máximo de
fluxos de
trabalho que
podem ser
executados em
relação a um
banco de
dados de
conteúdo ao
mesmo tempo
é 15, excluindo
as instâncias
em execução
Limite
Valor máximo
Tipo de
limite
Observações
no serviço de
timer. Quando
esse limite é
atingido, novas
solicitações
para ativar
fluxos de
trabalho são
colocadas em
fila para serem
executadas
pelo serviço de
timer de fluxo
de trabalho
mais tarde.
Quando a
execução não
relacionada ao
timer é
concluída, as
novas
solicitações
são contadas
em relação a
esse limite. O
limite pode ser
configurado
por meio do
cmdlet SetSPFarmConfig
do Windows
PowerShell.
Para obter
mais
informações,
consulte SetSPFarmConfig.
Observação:
esse limite não
se refere ao
número total
de instâncias
de fluxos de
trabalho que
estão em
andamento.
Em vez disso,
117
Limite
Valor máximo
Tipo de
limite
Observações
ele é o número
de instâncias
que estão
sendo
processadas.
Se o limite for
aumentado,
isso aumentará
a taxa de
transferência
de inicialização
e conclusão de
tarefas de fluxo
de trabalho,
mas também
aumentará a
carga em
relação ao
banco de
dados de
conteúdo e aos
recursos do
sistema.
Tamanho de lote de timer de 100
fluxo de trabalho
Limite
118
O número de
eventos que
cada execução
do trabalho de
timer de fluxo
de trabalho
selecionará e
entregará aos
fluxos de
trabalho. Esse
número pode
ser
configurado
por meio do
Windows
PowerShell.
Para permitir
eventos
adicionais,
você pode
executar
instâncias
adicionais do
Limite
Valor máximo
Tipo de
limite
Observações
Serviço de
Timer do Fluxo
de Trabalho do
Microsoft
SharePoint
Foundation.
Limites de repositórios de termos de Metadados Gerenciados
(bancos de dados)
A tabela a seguir lista as diretrizes recomendadas para repositórios de termos de
metadados gerenciados.
Limite
Valor máximo
Tipo de Observações
limite
Número máximo de
níveis de termos
aninhados em um
repositório de termos
7
Com Os termos em um conjunto de
suporte termos podem ser
representados de forma
hierárquica. Um conjunto de
termos pode ter até sete níveis
de termos (um termo pai e seis
níveis de aninhamento abaixo
dele).
1000
Número máximo de
conjuntos de termos em
um repositório de
termos
Com Pode haver até 1000 conjuntos
suporte de termos em um repositório de
termos.
30.000
Número máximo de
termos em um conjunto
de termos
Com O número máximo de termos
suporte em um conjunto de termos é
30.000.
Observação:
Rótulos adicionais para o
mesmo termo, como sinônimos
e traduções, não contam como
termos separados.
Número total de itens
em um repositório de
termos
Com Um item é um termo ou um
suporte conjunto de termos. A soma do
número de termos e conjuntos
1.000.000
119
Limite
Tipo de Observações
limite
Valor máximo
de termos não pode exceder
1.000.000. Rótulos adicionais
para o mesmo termo, como
sinônimos e traduções, não
contam como termos
separados.
Observação:
Não pode haver o número
máximo de conjuntos de termos
e o número máximo de termos
simultaneamente em um
repositório de termos.
Limites dos Serviços do Visio
A tabela a seguir lista as diretrizes recomendadas para instâncias dos Serviços do Visio
no Microsoft SharePoint Server 2010.
Limite
Tipo Observações
de
limite
Valor máximo
Tamanho de arquivo de 50 MB
desenhos da Web do
Visio
Limite Os Serviços do Visio têm uma
definição de configuração que
permite que o administrador
altere o tamanho máximo de
desenhos da Web que o Visio
processa.
Tamanhos de arquivo maiores
têm os seguintes efeitos
colaterais:
 Aumento do volume de
memória dos Serviços do
Visio.
120

Aumento do uso da CPU.

Redução das solicitações
de servidor de aplicativos
por segundo.

Aumento da latência total.
Limite
Tipo Observações
de
limite
Valor máximo

Tempo limite de
recálculo de desenhos
da Web do Visio
120 segundos
Aumento da carga de rede
de farm do SharePoint.
Limite Os Serviços do Visio têm uma
definição de configuração que
permite que o administrador
altere o tempo máximo que
pode ser gasto no recálculo de
um desenho após uma
atualização de dados.
Um tempo limite maior de
recálculo causa:

Redução na disponibilidade
da CPU e da memória.

Redução das solicitações
de aplicativos por segundo.

Aumento da latência média
para todos os documentos.
Um tempo limite menor de
recálculo causa:

Redução da complexidade
dos diagramas que podem
ser exibidos.

Aumento das solicitações
por segundo.

Diminuição da latência
média para todos os
documentos.
Idade mínima do cache Idade mínima do cache: Limite A idade mínima do cache se
0 a 24 horas
aplica a diagramas conectados
do Serviços do Visio
a dados. Ela determina o
(diagramas conectados
primeiro momento em que o
a dados)
diagrama atual pode ser
removido do cache.
A definição da Idade Mínima do
Cache com um valor muito
baixo reduzirá a taxa de
transferência e aumentará a
latência, pois a invalidação do
cache muitas vezes força o Visio
121
Limite
Tipo Observações
de
limite
Valor máximo
a recalcular com frequência e
reduz a disponibilidade da CPU
e da memória.
Idade máxima do cache Idade máxima do cache: Limite
0 a 24 horas
do Serviços do Visio
(diagramas não
conectados a dados)
A idade máxima do cache se
aplica a diagramas não
conectados a dados. Esse valor
determina por quanto tempo o
diagrama atual deve ser
mantido na memória.
O aumento da Idade Máxima do
Cache diminui a latência para
desenhos solicitados com
frequência.
No entanto, a definição da Idade
Máxima do Cache com um valor
muito alto aumenta a latência e
diminui a taxa de transferência
para os itens que não estão
armazenados em cache, pois os
itens já em cache consomem e
reduzem a memória disponível.
Limites dos Serviços PerformancePoint
A tabela a seguir lista as diretrizes recomendadas para os Serviços PerformancePoint no
Microsoft SharePoint Server 2010.
Limite
Valor máximo
Tipo de
limite
Células
1.000.000 por consulta em
uma fonte de dados dos
Serviços do Excel
Delimitador Um scorecard do
PerformancePoint
que chama uma
fonte de dados
dos Serviços do
Excel está sujeito
a um limite
máximo de
1.000.000 células
por consulta.
Colunas e linhas
15 colunas por 60.000 linhas Limite
122
Observações
O número
Limite
Valor máximo
Tipo de
limite
Observações
máximo 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
número de linhas
pode ser alterado
em função do
número de
colunas.
Consulta em uma lista do
SharePoint
15 colunas por 5000 linhas
Com
suporte
O número
máximo de
colunas e linhas
ao renderizar
qualquer objeto
de painel do
PerformancePoint
que use uma lista
do SharePoint
como fonte de
dados. O número
de linhas pode
ser alterado em
função do número
de colunas.
Consulta em uma fonte de
dados do SQL Server
15 colunas por 20000 linhas Com
suporte
O número
máximo de
colunas e linhas
ao renderizar
qualquer objeto
de painel do
PerformancePoint
que use uma
fonte de dados
de tabela do SQL
Server. O número
de linhas pode
ser alterado em
função do número
de colunas.
123
Limites do Word Automation Services
A tabela a seguir lista as diretrizes recomendadas para o Word Automation Services.
Limite
Valor máximo
Tamanho do
512 MB
arquivo de entrada
Observações
Delimitador Tamanho máximo de arquivo que
pode ser processado pelo Word
Automation Services.
Limite
Essa configuração determina a
frequência com que o trabalho de
timer do Word Automation Services é
executado. Um número mais baixo
torna mais rápida a execução do
trabalho de timer. Nossos testes
mostram que é mais útil executar o
trabalho de timer uma vez por minuto.
Número de
conversões a
iniciar por
processo de
conversão
Para formatos de Limite
saída PDF/XPS:
30 x M. Para todos
os outros formatos
de saída: 72 x
M, em que M é o
valor da
Frequência para
iniciar conversões
(minutos)
O número de conversões a iniciar
afeta a taxa de transferência do Word
Automation Services.
Se estes valores forem definidos
como mais elevados do que os níveis
recomendados, alguns itens de
conversão poderão começar a falhar
de forma intermitente, e as
permissões de usuário poderão
expirar. As permissões de usuário
expiram 24 horas a partir do momento
em que um trabalho de conversão é
iniciado.
Tamanho do
trabalho de
conversão
100.000 itens de
conversão
Um trabalho de conversão inclui um
ou mais itens de conversão, cada um
dos quais representa uma única
conversão a ser realizada em um
único arquivo de entrada no
SharePoint. Quando um trabalho de
conversão é iniciado (usando o
método ConversionJob.Start), esse
trabalho e todos os itens de conversão
são transmitidos para um servidor de
aplicativos que, em seguida,
armazena o trabalho no banco de
dados do Word Automation Services.
Um grande número de itens de
conversão aumentará o tempo de
Frequência para
iniciar as
conversões
(minutos)
1 minuto
(recomendado)
Tipo de
limite
15
minutos (padrão)
59 minutos (limite)
Com
suporte
124
Limite
Valor máximo
Tipo de
limite
Observações
execução do método Start e o número
de bytes transmitidos ao servidor de
aplicativos.
Total de processos N-1, em que N é o Limite
de conversão
número de núcleos
ativos
em cada servidor
de aplicativos
Um processo de conversão ativo pode
consumir um único núcleo de
processamento. Portanto, os clientes
não devem executar mais processos
de conversão do que o número de
núcleos de processamento existentes
em seus servidores de aplicativos. O
trabalho de timer de conversão e
outras atividades do SharePoint
também exigem o uso ocasional de
um núcleo de processamento.
É recomendável deixar sempre um
núcleo livre para uso pelo trabalho de
timer de conversão e pelo SharePoint.
Tamanho de
banco de dados
do Word
Automation
Services
2 milhões de itens Com
suporte
de conversão
O Word Automation Services mantém
uma fila persistente de itens de
conversão em seu banco de dados.
Cada solicitação de conversão gera
um ou mais registros.
O Word Automation Services não
exclui registros do banco de dados
automaticamente; assim, o banco de
dados pode crescer indefinidamente
sem manutenção. Os administradores
podem remover manualmente o
histórico de trabalhos de conversão
usando o cmdlet RemoveSPWordConversionServiceJobHistory
do Windows PowerShell. Para obter
mais informações, consulte RemoveSPWordConversionServiceJobHistory.
Limites do SharePoint Workspace
A tabela a seguir lista as diretrizes recomendadas para o Microsoft SharePoint
Workspace 2010.
Limite
Valor máximo
Tipo de limite Observações
Sincronização do SharePoint
Workspace
30.000 itens por lista
Delimitador O
SharePoint
125
Limite
Tipo de limite Observações
Valor máximo
Workspace
não
sincroniza
listas que
tenham mais
de 30.000
itens. Essa
restrição
existe
porque o
tempo
necessário
para baixar
uma lista
que tenha
mais de
30.000 itens
é muito
longo, e a
utilização de
recursos é
elevada.
Sincronização do SharePoint
Workspace
Limite de 1800 documentos no Delimitador Os usuários
SharePoint Workspace
são
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 Serviços do Microsoft
OneNote.
Limite
Valor máximo
Número de Seções e Consulte o limite para
Grupos de Seções em "Documentos" em
um Bloco de Anotações Limites de lista e
126
Tipo de
limite
Observações
Cada seção conta como uma
pasta e um documento na
lista. Cada grupo de seções
Limite
Valor máximo
Tipo de
limite
do OneNote (no
SharePoint)
biblioteca
conta como uma pasta e um
documento na lista.
Tamanho máximo de
uma seção
Consulte o limite para
"Tamanho de arquivo"
em Limites de lista e
biblioteca
Esse valor máximo exclui
imagens, arquivos inseridos
e impressões XPS do
OneNote com mais de 100
KB. Imagens e arquivos
inseridos com mais de 100
KB são separados em seus
próprios arquivos binários.
Isso significa que uma seção
com 100 KB de dados
digitados e quatro
documentos do Word
inseridos com 1 MB cada
serão considerados uma
seção de 100 KB.
Tamanho máximo de
uma imagem, arquivo
inserido e impressão
XPS do OneNote em
uma seção do
OneNote.
Consulte o limite para
"Tamanho de arquivo"
em Limites de lista e
biblioteca
Cada item é armazenado
como um arquivo binário
separado e, assim, está
sujeito a limites de tamanho
de arquivo. Cada operação
de impressão no OneNote
resultará em um binário de
impressão XPS, mesmo que
a impressão contenha várias
páginas.
Tamanho máximo de
todas as imagens,
arquivos inseridos e
impressões XPS em
uma única página do
OneNote.
Limite
O limite padrão é o
dobro do limite de
"Tamanho de arquivo".
Isso se aplica ao conteúdo
inserido em uma única
página do OneNote e não
uma Seção ou Bloco de
Anotações. Se os usuários
tiverem esse problema,
verão o seguinte erro no
OneNote:
jerrcStorageUrl_HotTableFull
(0xE0000794). Os usuários
podem resolver o problema
dividindo o conteúdo inserido
em páginas diferentes e
excluindo as versões
anteriores da página. Se os
usuários precisarem ajustar
esse valor ("Tamanho
127
Observações
Limite
Tipo de
limite
Valor máximo
Observações
Máximo de Tabela Ativa"), o
limite efetivo será a metade
do valor absoluto definido
por eles (por exemplo, se for
especificado um tamanho
máximo de tabela ativa de
400 MB, isso significa que o
tamanho máximo de todo o
conteúdo inserido em uma
página será limitado a 200
MB).
Operações de
mesclagem
Delimitador O OneNote mescla
Uma por núcleo de
alterações combinadas de
CPU por servidor Web
vários usuários que estão
realizando a coautoria de um
bloco de anotações. Se
nenhum núcleo de CPU
estiver disponível para
executar uma mesclagem,
uma página de conflito será
gerada em vez disso, o que
forçará o usuário a executar
a mesclagem manualmente.
Esse limite é aplicável quer o
OneNote esteja sendo
executado como um
aplicativo cliente, quer esteja
sendo executado como um
Microsoft Office Web Apps.
Limites do Serviço Office Web Applications
A tabela a seguir lista as diretrizes recomendadas para o Office Web Apps. Os limites de
aplicativos clientes do Office também são aplicáveis quando um aplicativo está sendo
executado como um aplicativo Web.
Limite
Valor máximo
Tipo de
limite
Observações
Tamanho do cache
100 GB
Limite
Espaço
disponível
para
renderizar
documentos,
criados como
128
Limite
Valor máximo
Tipo de
limite
Observações
parte de um
banco de
dados de
conteúdo. Por
padrão, o
cache
disponível
para
renderizar
documentos
é de 100 GB.
Não é
recomendável
aumentar o
cache
disponível.
Renderizações
Uma por documento por
segundo por núcleo de CPU
por servidor de aplicativos
(máximo de oito núcleos)
Delimitador Esse é o
número
médio
medido de
renderizações
de
documentos
"típicos" que
podem ser
executadas
no servidor
de aplicativos
em um
período de
tempo.
Limites do Project Server
A tabela a seguir lista as diretrizes recomendadas para o Microsoft Project Server. Para
obter mais informações sobre como planejar o Project Server, consulte Planning and
architecture for Project Server 2010.
Limite
Valor máximo
Tipo de limite Observações
Horário do final do projeto
Data: 31/12/2049
Delimitador
129
Planos do
Project não
podem
ultrapassar
a data de
Limite
Valor máximo
Tipo de limite Observações
31/12/2049.
Produtos por plano de projeto 1500 produtos
Número de campos em um
modo de exibição
256
Número de cláusulas em um 50
filtro para um modo de exibição
130
Delimitador
Planos do
Project não
podem
conter mais
de 1500
produtos.
Delimitador
Um usuário
não pode
ter mais de
256 campos
adicionados
a um modo
de exibição
que tenha
sido
definido no
Project Web
App.
Delimitador
Um usuário
não pode
adicionar
um filtro a
um modo
de exibição
que
contenha
mais de 50
cláusulas.
Performance and capacity technical case
studies (SharePoint Server 2010) (em
inglês)
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 inglês).
In this section:
 Publishing


Ambiente de publicação na intranet da empresa do Microsoft SharePoint Server
2010: análise técnica
Describes the published intranet environment used by employees at Microsoft.
Enterprise Intranet Collaboration


Enterprise intranet collaboration environment technical case study (SharePoint
Server 2010) (em inglês)
Describes an environment that hosts mission-critical team sites and publishing
portals for internal organizations, teams, and projects.
 Enterprise intranet collaboration environment lab study (SharePoint Server 2010)
(em inglês)
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 inglês)
131

Describes a departmental collaboration environment used by employees of one
department inside Microsoft.
 Divisional portal environment lab study (SharePoint Server 2010) (em inglês)
Describes lab testing performed on a similar environment to the departmental
collaboration environment.
Social


Social environment technical case study (SharePoint Server 2010) (em inglês)
Describes an environment that hosts My Sites that present employee information
to the wider organization. The environment serves as a central location for
personal sites and shared documents.
Microsoft SharePoint Server 2010 social environment: Lab study
Provides guidance on performance and capacity planning for a My Site and
social computing portal based on SharePoint Server 2010.
132
Ambiente de publicação na intranet da
empresa do Microsoft SharePoint Server
2010: análise técnica
Este documento descreve uma implantação específica do Microsoft SharePoint Server
2010. Ele inclui:
 Especificações de ambiente de estudo técnico de caso, como hardware, topologia
do farm e configuração

Carga de trabalho que inclui número e tipos de usuários ou clientes e características
de utilização de ambiente

Conjunto de dados de farm de estudo técnico de caso que inclui conteúdo de banco
de dados e índices de Pesquisa
 Dados de integridade e desempenho específicos do ambiente
Neste artigo:
 Informações sobre pré-requisitos

Introdução a este ambiente

Especificações

Carga de trabalho

Conjunto de dados

Dados de integridade e desempenho
Informações sobre pré-requisitos
Antes de ler este documento, você deve entender os principais conceitos subjacentes ao
gerenciamento de capacidade do SharePoint Server 2010. A seguinte documentação 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 informações
deste documento, além de definir os termos usados em todo o documento.
Para obter mais informações conceituais sobre desempenho e capacidade, que possam
ser úteis para a compreensão do contexto dos dados deste estudo técnico de caso,
consulte os seguintes documentos:
 Visão geral do gerenciamento da capacidade e dimensionamento do SharePoint
Server 2010

Gerenciamento de capacidade do SharePoint Server 2010: limites de software
Introdução a este ambiente
Este white paper descreve um ambiente real do SharePoint Server 2010 na Microsoft.
Use esse documento para comparação com as suas características de carga de trabalho
133
e uso planejados. Se o design planejado for semelhante, você poderá usar a
implantação aqui descrita como ponto de partida para sua própria instalação.
Este documento inclui:
 Especificações, que incluem hardware, topologia e configuração

Carga de trabalho, que é a demanda no farm que inclui a quantidade de usuários e
as características de utilização

Conjunto de dados que inclui tamanhos de bancos de dados
 Dados de integridade e desempenho específicos do ambiente
Este documento faz parte de uma série de Performance and capacity technical case
studies (SharePoint Server 2010) (em inglês) sobre ambientes do SharePoint na
Microsoft.
O
ambiente do SharePoint Server 2010 descrito neste documento é um ambiente de
produção de uma grande empresa multinacional. Os funcionários exibem conteúdo
variado, como notícias, artigos técnicos, perfis de funcionários, documentação e
recursos de treinamento. Esse ambiente também é usado pelos funcionários para
realizar consultas em todos os ambientes do SharePoint dentro da empresa. Os
funcionários recebem emails diariamente com links para artigos sobre o ambiente e
muitos dos funcionários definem esse ambiente como a home page do seu navegador.
Cerca de 48.000 usuários exclusivos visitam o ambiente em um dia movimentado,
gerando até 345 solicitações por segundo (RPS) nos horários de pico. Como é um site
de intranet, todos os usuários são autenticados. Embora o conteúdo seja publicado
usando um modelo de autor no local de ambiente único, o procedimento de publicação
do ambiente especifica que todo o conteúdo de rascunho seja publicado no mesmo
horário, à noite, fora dos horários de pico.
As informações fornecidas neste documento refletem o ambiente de publicação da
intranet da empresa em um dia normal.
Especificações
Esta seção traz informações detalhadas sobre hardware, software, topologia e
configuração do ambiente do estudo de caso.
Hardware
134
Esta seção traz detalhes sobre os computadores servidores usados nesse ambiente.
Observação:
O ambiente é dimensionado para acomodar compilações de pré-lançamento do
SharePoint Server 2010 e de outros produtos. Portanto, o hardware implantado tem
maior capacidade que o necessário para atender a demanda que geralmente ocorre
nesse ambiente. Esse hardware só é descrito para dar mais contexto ao ambiente e
serve como ponto de partida para ambientes semelhantes.
É importante direcionar seu gerenciamento de capacidade de acordo com a carga de
trabalho planejada e as características de utilização. Para obter mais informações sobre
o processo de gerenciamento da capacidade, consulte Visão geral do gerenciamento da
capacidade e dimensionamento do SharePoint Server 2010.
Servidores Web
Há quatro servidores Web no farm, cada um deles com hardware idêntico. Três para
conteúdo e o quarto é dedicado ao destino do rastreamento da pesquisa.
Servidor Web
WFE1-4
Processador(es)
2 núcleos quádruplos 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
Autenticação
Windows NTLM
Tipo de balanceador de carga
Balanceamento de carga do hardware
Versão do software
SharePoint Server 2010 (versão de prélançamento)
Serviços em execução no local
Administração Central
Email de Entrada do Microsoft SharePoint
Foundation
Aplicativo Web do Microsoft SharePoint
Foundation
Serviço de Timer do Fluxo de Trabalho do
Microsoft SharePoint Foundation
Serviço de Consulta de Pesquisa e
Configurações do Site
Pesquisa do SharePoint Server
135
Servidor Web
WFE1-4
Serviços consumidos de um farm de
serviços federados
Serviço de Perfil de Usuário
Serviço Web do Web Analytics
Serviço Conectividade de Dados
Corporativos
Serviço Web de Metadados Gerenciados
Servidor de aplicativos
Não há nenhum servidor de aplicativos no farm. Os serviços locais são hospedados nos
servidores Web. Outros serviços são consumidos de um farm de serviços federados.
Servidores de bancos de dados
Há um cluster SQL com dois servidores de bancos de dados, cada um deles com
hardware idêntico. Um dos servidores é ativo e o outro é passivo para fins de
redundância.
Servidor de Banco de Dados
DB1-2
Processador(es)
4 núcleos quádruplos a 2.4 GHz
RAM
32 GB
Sistema operacional
Windows Server 2008, 64 bits
Armazenamento e geometria
(1,25 TB * 6) + 3 TB
Discos 1-4: Dados SQL
Disco 5: Logs
Disco 6: TempDB
Quantidade de adaptadores de rede
2
Velocidade do adaptador de rede
1 Gigabit
Autenticação
Windows NTLM
Versão do software
SQL Server 2008
Topologia
O seguinte diagrama mostra a topologia desse farm.
136
Configuração
137
A tabela abaixo enumera configurações que foram alteradas e que afetam o
desempenho ou a capacidade do ambiente.
Configuração
Valor
Observações
Administração de Ativado
Conjunto de
Sites:
Cache de saída do
conjunto de sites
Habilitar o cache de saída aumenta a eficiência do
servidor, reduzindo chamadas no banco de dados em
busca de dados frequentemente solicitados.
Perfil do cache do Intranet
conjunto de sites (Site de
(selecionar)
Colaboraç
ão)
A opção “Permitir que os autores exibam o conteúdo
armazenado em cache” está selecionada, ignorando o
comportamento comum de não deixar que as pessoas
com permissão de edição tenham suas páginas
armazenadas em cache.
Cache de Objetos Ativado – O padrão é 100 MB. O aumento dessa configuração
(Desativado | n
500 MB permite o armazenamento de mais dados na memória do
MB)
servidor Web front-end.
Serviço de Uso:
Log de
Rastreamento –
dias para
armazenar
arquivos de log
(padrão: 14 dias)
5 dias
O padrão é 14 dias. Baixar essa configuração pode liberar
espaço em disco no servidor onde os arquivos de log
estão armazenados.
Limite de Registro 1 segundo O padrão é 5 segundos. Baixar essa configuração pode
de Consulta em
economizar largura de banda e CPU no servidor do
Log:
banco de dados.
Microsoft
SharePoint
Foundation Banco
de dados –
configurar
QueryLoggingThre
shold para 1
segundo
Servidor de
1
Banco de Dados –
Instância Padrão:
Grau máximo de
paralelismo
O padrão é 0. Para garantir um desempenho ideal, é
altamente recomendável definir o grau máximo de
paralelismo como 1 para servidores de banco de dados
que hospedam bancos de dados do SharePoint Server
2010. Para obter mais informações sobre como definir o
grau máximo de paralelismo, consulte Opção max degree
of
parallelism(http://go.microsoft.com/fwlink/?linkid=189030&
clcid=0x416).
138
Carga de trabalho
Esta seção descreve a carga de trabalho, que é a demanda no farm que inclui a
quantidade de usuários e as características de utilização.
Características da Carga de Trabalho
Valor
Média de Solicitações por Segundo (RPS)
100
Média de RPS no horário de pico (11h 15h)
226
Quantidade total de usuários diferentes por 33.580
dia
Média de usuários simultâneos
172
Máximo de usuários simultâneos
376
Quantidade total de solicitações por dia
3.800.000
Esta tabela mostra o número de solicitações para cada agente de usuário.
Agente de Usuário
Solicitações
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 seção descreve o conjunto de dados do farm de estudo de caso que inclui
tamanhos de bancos de dados e índices de Pesquisa.
Características do Conjunto de Dados
Valor
Tamanho do banco de dados (combinado)
49,9 GB
139
Características do Conjunto de Dados
Valor
Tamanho do BLOB
22,2 GB
Quantidade de bancos de dados de
conteúdo
3
Número de aplicativos Web
3
Número de conjuntos de sites
4
Número de sites
797
Tamanho do índice de pesquisa (número de 275.000
itens)
Dados de integridade e desempenho
Esta seção traz dados de integridade e desempenho específicos do ambiente do estudo
de caso.
Contadores Gerais
Métrica
Valor
Disponibilidade (tempo de ativação)
99,95%
Taxa de Falha
0,05%
Média de memória usada
1,08 GB
Máximo de memória usada
2,60 GB
% de Rastreamento de Pesquisa de Tráfego 6%
(solicitações de clientes de pesquisa/total de
solicitações)
Solicitações ASP.NET na Fila
0,00
Os gráficos abaixo mostram a utilização média de CPU e a latência desse ambiente.
140
Neste documento, a latência é dividida em quatro categorias. 50% da latência
geralmente são usados para medir a capacidade de resposta do servidor. Isto significa
que metade das solicitações são atendidas dentro desse tempo de resposta. 95% da
latência geralmente são usados para medir picos nos tempos de resposta do servidor.
141
Isto significa que 95% das solicitações são atendidas dentro desse tempo de resposta e,
portanto, 5% das solicitações têm tempos de resposta mais lentos.
Contadores de Bancos de Dados
Ao interpretar estatísticas de bancos de dados para esse ambiente de publicação da
empresa, é preciso saber que a maioria dos visitantes tem permissões somente leitura.
Métrica
Valor
Proporção Leitura/Gravação (E/S por Banco 99,999:0,001
de Dados)
Comprimento Médio da Fila de Disco
0,35
Comprimento da Fila de Disco: Leituras
34
Comprimento da Fila de Disco: Gravações
2,5
Leituras de disco/segundo
131,33
Gravações de disco/segundo
278,33
Compilações SQL/segundo
2,36
Recompilações SQL/segundo
94,80
Bloqueios SQL: Tempo Médio de Espera
0 ms
Bloqueios SQL: Tempo de Espera de
Bloqueio
0 ms
Bloqueios SQL: Deadlocks por Segundo
0
Travas SQL: Tempo Médio de Espera
0,25 ms
Taxa de Acertos do Cache SQL
>99%
142
Enterprise intranet collaboration
environment technical case study
(SharePoint Server 2010) (em inglês)
This article describes a specific deployment of Microsoft SharePoint Server 2010, that
includes the following:
 Technical case study environment specifications, such as hardware, farm topology
and configuration.

The workload, that includes the number, and types, of users or clients, and
environment usage characteristics.

Technical case study farm dataset, that includes database contents and search
indexes.
 Health and performance data that is specific to the environment.
In this article:
 Prerequisite information

Introduction to this environment

Specifications

Workload

Dataset

Health and Performance Data
Prerequisite information
Before reading this document, make sure that you understand the key concepts behind
SharePoint Server 2010 capacity management. The following documentation will help
you learn about the recommended approach to capacity management and provide
context for helping you understand how to make effective use of the information in this
document, and also define the terms used throughout this document.
For more conceptual information about performance and capacity that you might find
valuable in understanding the context of the data in this technical case study, see the
following documents:
 Capacity management and sizing for SharePoint Server 2010 (em inglês)

Gerenciamento de capacidade do SharePoint Server 2010: limites de software
Introduction to this environment
This white paper describes an actual SharePoint Server 2010 environment at Microsoft.
Use this document to compare to your planned workload and usage characteristics. If
143
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 inglês) 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.
144
Observação:
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 inglês).
Web Servers
There are four Web servers in the farm, each with identical hardware. Three serve
content, and the fourth is a dedicated search crawl target.
Web Server
WFE1-4
Processor(s)
2 quad core @ 2.33 GHz
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
145
Web Server
WFE1-4
Business Data Connectivity Service
Managed Metadata Web Service
Application Server
There are four application servers in the farm, each with identical hardware.
Application Server
APP1-4
Processor(s)
4 six core @ 2.40 GHz
RAM
64 GB
OS
Windows Server 2008, 64 bit
Size of the SharePoint drive
300 GB
Number of network adapters
1
Network adapter speed
1 Gigabit
Authentication
Windows NTLM
Load balancer type
Hardware load balancing
Software version
SharePoint Server 2010 (pre-release
version)
Services running locally
Office Web Apps
Excel
PowerPoint
Secure Store
Usage and Health
State Service
Database Servers
There is a SQL cluster with 2 database servers, each with identical hardware, one of the
servers is active and the other is passive for redundancy.
Database Server
DB1-2
Processor(s)
4 quad core @ 2.4 GHz
RAM
32 GB
OS
Windows Server 2008, 64-bit
Storage and geometry
(1.25 TB * 7) + 3 TB
146
Database Server
DB1-2
Disk 1-4: SQL Data
Disk 5: Logs
Disk 6: TempDB
Number of network adapters
2
Network adapter speed
1 Gigabit
Authentication
Windows NTLM
Software version
SQL Server 2008
Topology
The following diagram shows the topology for this farm.
147
Configuration
148
The following table enumerates settings that were changed that affect performance or
capacity in the environment.
Setting
Value
Notes
Usage Service
5 days The default is 14 days. Lowering this setting can save
disk space on the server where the log files are
Trace Log – days to store
stored.
log files (default: 14 days)
QueryLoggingThreshold 1
The default is 5 seconds. Lowering this setting can
second
save bandwidth and CPU on the database server.
SharePoint Foundation
Database – change
QueryLoggingThreshold
to 1 second
1
Database Server –
Default Instance
Max degree of parallelism
The default is 0. To ensure optimal performance, we
strongly recommend that you set max degree of
parallelism to 1 for database servers that host
SharePoint Server 2010 databases. For more
information about how to set max degree of
parallelism, see max degree of parallelism
Option(http://go.microsoft.com/fwlink/?LinkId=189030).
Workload
This section describes the workload, which is the demand on the farm that includes the
number of users, and the usage characteristics.
Workload Characteristics
Value
Average Requests per Second (RPS)
157
Average RPS at peak time (11 AM-3 PM)
350
Total number of unique users per day
69,702
Average concurrent users
420
Maximum concurrent users
1,433
Total # of requests per day
18,866,527
This table shows the number of requests for each user agent.
User Agent
Requests
Percentage of
Total
Search (crawl)
6,384,488
47%
DAV
2,446,588
18%
149
User Agent
Requests
Percentage of
Total
Browser
730,139
5%
OneNote
665,334
5%
Office Web Applications
391,599
3%
SharePoint Designer
215,695
2%
Dataset
This section describes the case study farm dataset that includes database sizes and
Search indexes.
Dataset Characteristics
Value
Database size (combined)
7.5 TB
BLOB size
6.8 TB
Number of content databases
87
Number of Web applications
2
Number of site collections
34,423
Number of sites
101,598
Search index size (number of items)
23 million
Health and Performance Data
This section provides health and performance data that is specific to the Case Study
environment.
General Counters
Metric
Value
Availability (uptime)
99.1%
Failure Rate
0.9%
Average memory used
3.4 GB
Maximum memory used
16.1 GB
Search Crawl % of Traffic (Search client
requests / total requests)
47%
150
Metric
Value
ASP.NET Requests Queued
0.00
The following charts show the average CPU utilization and latency for this environment:
151
In this document, latency is divided into four categories. The 50th percentile latency is
typically used to measure the server’s responsiveness. It means that half of the requests
are served within that response time. The 95th percentile latency is typically used to
measure spikes in server response times. It means that 95% of requests are served
within that response time, and therefore 5% of the requests experience slower response
times.
Database counters
Metric
Value
Read/Write Ratio (IO Per Database)
99.8 : 0.2
Average Disk queue length
2.3
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%
152
Enterprise intranet collaboration
environment lab study (SharePoint
Server 2010) (em inglês)
This article contains guidance on performance and capacity planning for an enterprise
intranet collaboration solution that is based on Microsoft SharePoint Server 2010. It
includes the following:
 Lab environment specifications, such as hardware, farm topology and configuration

Test farm dataset

Test results analysis which should help you determine the hardware, topology and
configuration that you must have to deploy a similar environment, and optimize your
environment for appropriate capacity and performance characteristics
In this article:
 Introduction to this environment

Glossary

Overview

Specifications

Results and Analysis
Introduction to this environment
This document provides guidance about scaling out and scaling up servers in a
SharePoint Server 2010 enterprise intranet collaboration solution, based on a testing
environment at Microsoft. Capacity planning informs decisions on purchasing hardware
and making system configurations to optimize your solution.
Different scenarios have different requirements. Therefore, it is important to supplement
this guidance with additional testing on your own hardware and in your own environment.
If your planned design and workload resembles the environment described in this
document, you can use this document to draw conclusions about scaling your
environment up and out.
This document includes the following:
 Specifications, which include hardware, topology, and configuration

The workload, which is the demand on the farm, includes the number of users, and
the usage characteristics

The dataset, such as database sizes

Test results and analysis for scaling out Web servers

Test results and analysis for scaling up Web servers

Test results and analysis for scaling out database servers
153

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 inglês).
Before reading this document, make sure that you understand the key concepts behind
capacity management in SharePoint Server 2010. The following documentation will help
you learn about the recommended approach to capacity management and provide
context for helping you understand how to make effective use of the information in this
document, and also define the terms used throughout this document.
 Visão geral do gerenciamento da capacidade e dimensionamento do SharePoint
Server 2010
 Gerenciamento de capacidade do SharePoint Server 2010: limites de software
Also, we encourage you to read the following:
 Planejamento e configuração de armazenamento e capacidade do SQL Server
(SharePoint Server 2010)
Glossary
There are some specialized terms that you will encounter in this document. Here are
some key terms and their definitions.
 RPS: Requests per second. The number of requests received by a farm or server in
one second. This is a common measurement of server and farm load.
Note that requests differ from page loads; each page contains several components,
each of which creates one or more requests when the page is loaded. Therefore, one
page load creates several requests. Typically, authentication checks and events
using insignificant resources are not counted in RPS measurements.
 Green Zone: This is the state at which the server can maintain the following set of
criteria:

The server-side latency for at least 75% of the requests is less than 1 second.

All servers have a CPU Utilization of less than 50%.
Observação:
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:
154

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,
155
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 inglês).
Methodology and Test Notes
This document provides results from a test lab environment. Because this was a lab
environment and not a production environment, we were able to control certain factors to
show specific aspects of performance for this workload. In addition, certain elements of
the production environment, listed here, were left out of the lab environment to simplify
testing overhead. We do not recommend omitting these elements for production
environments.
 Between test runs, we modified only one variable at a time, to make it easy to
compare results between test runs.

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 configuração de
armazenamento e capacidade do SQL Server (SharePoint Server 2010).
Specifications
This section provides detailed information about the hardware, software, topology, and
configuration of the lab environment.
Hardware
The following sections describe the hardware that was used in this lab environment.
Web and Application servers
There are from one to eight Web servers in the farm, plus one Application server.
Web Server
WFE1-8 and APP1
Processor(s)
2 quad-core 2.33 GHz processors
RAM
8 GB
Operating system
Windows 2008 Server R2
Size of the SharePoint drive
80 GB
Number of network adapters
2
Network adapter speed
1 Gigabit
Authentication
Windows NTLM
156
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, Serviços 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.
Observação:
If you enable usage reporting, we recommend that you store the logging database on a
separate Logical Unit Number (LUN). For large deployments and some medium
deployments, a separate LUN will not be sufficient, as the demand on the server’s CPU
may be too high. In that case, you will need a separate database server box for the
logging database. In this lab environment, the logging database was stored in a separate
instance of SQL Server, and its specifications are not included in this document.
Database Server – Default Instance
DB1-2
Processor(s)
4 dual-core 3.19 GHz processors
RAM
32 GB
Operating system
Windows 2008 Server R2
Storage and geometry
Direct Attached Storage (DAS)
Internal Array with 5 x 300GB 10krpm disk
External Array with 15 x 450GB 15krpm disk
6 x Content Data (External RAID0, 2
spindles 450GB each)
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)
157
Database Server – Default Instance
DB1-2
Number of network adapters
1
Network adapter speed
1 Gigabit
Authentication
Windows NTLM
Software version
SQL Server 2008 R2 (pre-release version)
Topology
The following diagram shows the topology in this lab environment:
158
Configuration
159
To allow for the optimal performance, the following configuration changes were made in
this lab environment.
Setting
Value
Notes
On
The default is Off. Enabling Blob Caching improves
server efficiency by reducing calls to the database
server for static page resources that may be frequently
requested.
Site Collection
Blob Caching
Database
Server – Default
Instance
Max degree of 1
parallelism
The default is 0. To ensure optimal performance, we
strongly recommend that you set max degree of
parallelism to 1 for database servers that host
SharePoint Server databases. For more information
about how to set max degree of parallelism, see max
degree of parallelism
Option(http://go.microsoft.com/fwlink/?LinkId=189030).
Workload
The transactional mix for the lab environment described in this document resembles the
workload characteristics of a production environment at Microsoft. For more information
about the production environment, see Enterprise intranet collaboration environment
technical case study (SharePoint Server 2010) (em inglês).
Here are the details of the mix for the lab tests run against SharePoint Server 2010
compared to the production environment. Although there are some minor differences in
the workloads, both represent a typical transactional mix on an enterprise collaboration
environment.
160
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 inglês).
Dataset Characteristics
Value
Database size (combined)
130 GB
BLOB size
108.3 GB
Number of content databases
2
Number of site collections
181
Number of Web applications
1
161
Dataset Characteristics
Value
Number of sites
1384
Results and Analysis
The following results are ordered based on the scaling approach described in the
Overview section of this document.
Web Server Scale Out
This section describes the test results that were obtained when we scaled out the number
of Web servers in this lab environment.
Test methodology

Add Web servers of the same hardware specifications, keeping the rest of the farm
the same.

Measure RPS, latency, and resource utilization.
Analysis
In our testing, we found the following:
 The environment scaled up to four Web servers per database server. However, the
increase in throughput was non-linear especially on addition of the fourth Web server.

After four Web servers, there are no additional gains to be made in throughput by
adding more Web servers because the bottleneck at this point was the database
server CPU Utilization.

The average latency was almost constant throughout the whole test, unaffected by
the number of Web servers and throughput.
Observação:
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.
162
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.
163
3. SQL Server I/O operations per section (IOPs) for MDF and LDF files
The following graphs show how the IOPs on the content databases change as the
number of Web servers is scaled out. These are measured by looking at the following
performance counters:
 PhysicalDisk: Disk Reads / sec
 PhysicalDisk: Disk Writes / sec
In this lab environment, we determined that our data on IOPs was not representative of a
production environment because our dataset was so small that we could fit much more of
it in cache than would be possible in the production environment we are modeling. We
calculated projected reads by multiplying the value of the data we had from the lab for
writes/second by the ratio of reads to writes in our production environment. The results in
this section are averages. But there are also spikes that occur during certain operations
which have to be accounted for. To learn more about how to estimate IOPs needed, see
Planejamento e configuração de armazenamento e capacidade do SQL Server
(SharePoint Server 2010).
Maximum:
164
Green Zone:
Example of how to read these graphs:
165
An organization with a workload similar to that described in this document that expects
300 RPS to be their green zone, could use 3x1x1 topology, and would use approximately
600 Physical Disk reads/sec on the MDF file.
Database Server Scale Out
This section describes the test results that were obtained when we scaled out the number
of database servers in this lab environment.
Test methodology

Have two content databases on one database server, and then split them to two
servers to effectively double the processor cores and memory available to the
database servers in the environment.

Keep the total IOPs capacity constant even while adding a database server. This
means that the number of reads/sec and writes/sec that the disks could perform for
each content database did not change despite splitting the content onto two
database servers instead of one.
Analysis

The first bottleneck in the 4x1x2 environment was the database server CPU
utilization. There was close to a linear scale when we added more processor and
memory power.

Scaling to four Web servers and 2 database servers did not provide much additional
RPS because the CPU utilization on the Web servers was close to 100%.

When we scaled out database servers (by adding one additional database server)
and added four Web servers, performance scaled almost linearly. The bottleneck at
that point shifted from being the database server CPU utilization to the content
database disk IOPs.

No additional tests were performed in this lab environment to scale out past 8x1x2.
However we expect that additional IOPs capacity would additionally increase
throughput.

A correlation between the IOPs used and the RPS achieved by the tests was
observed
Results graphs and charts
In the following graphs, the x axis is always showing four Web servers together with 1
application server and 1 database server (4x1x1) scaling out to eight Web servers
together with two database servers (8x1x2). Some also show 1x1x1 or 4x1x2.
1. Latency and RPS
The following graph shows how scaling out both Web servers and database servers
affects latency and RPS.
166
2. Processor utilization
The following graphs show how scaling out affects processor utilization.
167
3. Memory utilization at scale out
Throughout our testing, we’ve observed that the larger the number of site collections in
an environment, the more the memory consumed. For example, in the tests here where
181 site collections were accessed, the main w3wp process used up 1.8 GB of RAM. For
more examples, see the Performance and capacity technical case studies (SharePoint
Server 2010) (em inglês). 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
168
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.
169
Test methodology

Add more Web server processors, but keep the rest of the farm the same.
Analysis

Scale is linear up to eight processor cores.

Tests show that the environment can take advantage of a twenty-four core box,
although there is some degradation as twenty-four cores are approached.
Results graphs and charts
In the following graph, the x axis is the number of processors and the amount of RAM on
the Web server. The following graph shows how scaling up (adding processors) affects
RPS on the Web server.
Comparing SharePoint Server 2010 and Office SharePoint Server
2007
This section provides information about how the capacity testing for this workload varied
between SharePoint Server 2010 and Microsoft Office SharePoint Server 2007.
Workload
To compare SharePoint Server 2010 with Office SharePoint Server 2007, a different test
mix was used than the one outlined in the Specifications section, because some
SharePoint Server 2010 operations were not available in Office SharePoint Server 2007.
The test mix for Office SharePoint Server 2007 is inspired by the same production
170
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
171
Office SharePoint Server 2007. This reflects the improvements that were made in
SharePoint Server 2010 to sustain larger deployments.

When the web servers were scaled out to maximize the database server usage,
SharePoint Server 2010 was SQL Server CPU Utilization bound, whereas Office
SharePoint Server 2007 was Lock bound on the database tier. This means that
increasing the processing power available to the database servers enables
SharePoint Server 2010 to achieve better throughput than would be possible with the
same hardware using Office SharePoint Server 2007. This is caused by the locking
mechanisms in the database in Office SharePoint Server 2007 which are unaffected
by improved hardware so that we were unable to push the database server’s CPU
Utilization past 80%.

As a result of these findings outlined earlier in this section, on Office SharePoint
Server 2007 the maximum throughput possible was achieved in a 5x0x1 topology
whereas in SharePoint Server 2010 the maximum throughput possible with the same
workload was achieved in a 7x0x1 topology, and yielded a 25% increased total RPS.
Results graphs and charts
The following graph shows the throughput without scaling out Web servers.
The following graph shows the throughput when Web servers were at maximum scale
out.
172
173
Departmental collaboration environment
technical case study (SharePoint Server
2010) (em inglês)
This document describes a specific deployment of Microsoft SharePoint Server 2010. It
includes the following:
 Technical case study environment specifications, such as hardware, farm topology
and configuration

The workload that includes the number, and types, of users or clients, and
environment usage characteristics

Technical case study farm dataset that includes database contents and Search
indexes
 Health and performance data that is specific to the environment
In this article:
 Prerequisite information

Introduction to this environment

Specifications

Workload

Dataset

Health and Performance Data
Prerequisite information
Before reading this document, make sure that you understand the key concepts behind
SharePoint Server 2010 capacity management. The following documentation will help
you learn about the recommended approach to capacity management and provide
context for helping you understand how to make effective use of the information in this
document, and also define the terms used throughout this document.
For more conceptual information about performance and capacity that you might find
valuable in understanding the context of the data in this technical case study, see the
following documents:
 Visão geral do gerenciamento da capacidade e dimensionamento do SharePoint
Server 2010

Gerenciamento de capacidade do SharePoint Server 2010: limites de software
Introduction to this environment
This white paper describes an actual SharePoint Server 2010 environment at Microsoft.
Use this document to compare with your planned workload and usage characteristics. If
174
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 inglês) about SharePoint environments at Microsoft.
The
SharePoint Server 2010 environment described in this document is a production
environment at a large, geographically distributed company. Employees use this
environment to track projects, collaborate on documents, and share information within
their department. This environment is also used for internal testing, and is frequently
upgraded to the latest SharePoint Server pre-release versions as they become available.
As many as 9,000 unique users visit the environment on a busy day, generating up to
470 requests per second (RPS) during peak hours. Because this is an intranet site, all
users are authenticated.
The information that is provided in this document reflects the departmental collaboration
environment on a typical day.
Specifications
This section provides detailed information about the hardware, software, topology, and
configuration of the case-study environment.
Hardware
This section provides details about the server computers that were used in this
environment.
175
Observação:
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 Visão geral do gerenciamento da capacidade e
dimensionamento do SharePoint Server 2010.
Web Servers
There are four Web servers in the farm, each with identical hardware. Three serve
content, and the fourth is a dedicated search crawl target.
Web Server
WFE1-2
WFE3-4
Processor(s)
2 quad core @ 2.33 GHz
2 quad core @
2.33 GHz
RAM
32 GB
16 GB
Operating system
Windows Server 2008, 64 bit
Windows Server
2008, 64 bit
Size of the SharePoint drive
3x146GB 15K SAS (3 RAID 1
Disks) Disk 1: OS Disk 2: Swap
and BLOB Cache Disk 3: Logs and
Temp directory
3x146GB 15K
SAS (3 RAID 1
Disks) Disk 1:
OS Disk 2: Swap
and BLOB Cache
Disk 3: Logs and
Temp directory
Number of network adapters
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 (prerelease version)
SharePoint
Server 2010
(pre-release
version)
Services running locally
Search Query
WFE3 – No
services
176
Web Server
WFE1-2
WFE3-4
WFE4 – Search
crawl target
Application Server
There are four application servers in the farm.
Web Server
APP1-3
APP4
Processor(s)
2 quad core @ 2.33 GHz
2 quad core @
2.33 GHz
RAM
16 GB
16 GB
Operating system
Windows Server 2008, 64 bit
Windows Server
2008, 64 bit
Size of the SharePoint drive
3x146GB 15K SAS (3 RAID 1
Disks) Disk 1: OS Disk 2: Swap
and BLOB Cache Disk 3: Logs and
Temp directory
2x136GB 15K
SAS (RAID 0)
4x60GB SSD,
SATA (RAID 5)
Disk 1: OS Disk
2: Swap and
BLOB Cache
Disk 3: Logs and
Temp directory
Number of network adapters
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 (prerelease version)
SharePoint
Server 2010
(pre-release
version)
Services running locally
APP1 – Central Administration and Search Crawler
all applications except for Office
Web Applications
APP2 – All applications (including
Office Web Applications)
APP3 – Office Web Applications
Database Servers
177
There are three database servers, one running the default SQL Server instance housing
the content databases, one running the Usage and Web Analytics databases, and one
running the Search databases.
Database
DB1 – Default Instance
DB2
DB3
Processor(s)
4 quad core @ 3.2 GHz
2 quad core
@ 3.2 GHz
2 quad
core @
3.2 GHz
RAM
32 GB
16 GB
32 GB
Operating system
Windows Server 2008 SP1, 64 Windows
bit
Server 2008
SP1, 64 bit
Storage and geometry
5x146GB 15K SAS + SAN
6x450GB 15K 2x136GB
SAS
15K SAS
Disk 1: OS (2 disk RAID 10)
(RAID 0)
Disk 2: Swap (2 disk RAID 10) Directly
attached
6x60GB
Disk 3: Direct Attached Storage
14x146GB
SSD,
(16 disk RAID 10, Temp DB
15K SAS
SATA
data) SAS 146 GB 15K
Disk 1: Usage (RAID 5)
Disk 4: Direct Attached Storage
logs and OS Disk 1:
(16 disk RAID 10, Temp DB
Disk 2: Usage OS
data) SAS 146 GB 15K
data
Disk 2:
Disk 5-15: SAN using fiber
Swap
connection. When possible, one
and
database per two disks.
BLOB
Separating logs and data
Cache
between LUNs. 15K drives.
Disk 3:
Logs and
Temp
directory.
Solid
state
drives. 660GB
Solid
state
drives
(RAID 5)
Windows
Server
2008
SP1, 64
bit
Number of network adapters 2
2
2
Network adapter speed
1 Gigabit
1 Gigabit
1 Gigabit
Authentication
Windows NTLM
Windows
NTLM
Windows
NTLM
178
Database
DB1 – Default Instance
DB2
DB3
Software version
SQL Server 2008
SQL Server
2008
SQL
Server
2008 R2
Topology
The following diagram shows the topology for this farm.
179
Configuration
180
The following table enumerates settings that were made that affect performance or
capacity in the environment.
Setting
Value
Notes
Site collection:
On
Object Caching (On |
Disabled
Off)
Disabled
Anonymous Cache
On – 100GB
Profile (select)
60 seconds
Anonymous Cache
Profile (select)
Object Cache (Off | n
MB)
Cross List Query Cache
Changes (Every Time |
Every n seconds)
Enabling the output cache improves server
efficiency by reducing calls to the database for
data that is frequently requested.
Site collection cache
profile (select)
Intranet
(Collaboration
Site)
“Allow writers to view cached content” is
checked, bypassing the ordinary behavior of not
letting people with edit permissions to have
their pages cached.
Object Cache (Off | n
MB)
On – 500 MB
The default is 100 MB. Increasing this setting
enables additional data to be stored in the frontend Web server memory.
Usage Service:
Trace Log – days to
store log files (default:
14 days)
5 days
The default is 14 days. Lowering this setting
can save disk space on the server where the
log files are stored.
Query Logging
1 second
Threshold:
Microsoft SharePoint
Foundation Database –
configure
QueryLoggingThreshold
to 1 second
The default is 5 seconds. Lowering this setting
can save bandwidth and CPU on the database
server.
Database Server –
Default Instance:
Max degree of
parallelism
The default is 0. To ensure optimal
performance, we strongly recommend that you
set max degree of parallelism to 1 for database
servers that host SharePoint Server 2010
databases. For more information about how to
set max degree of parallelism, see max degree
of parallelism Option
(http://go.microsoft.com/fwlink/?LinkId=189030).
1
181
Workload
This section describes the workload, which is the demand on the farm that includes the
number of users, and the usage characteristics.
Workload Characteristics
Value
Average Requests per Second (RPS)
165
Average RPS at peak time (11 AM-3 PM)
216
Total number of unique users per day
9186
Average concurrent users
189
Maximum concurrent users
322
Total # of requests per day
7,124,943
This table shows the number of requests for each user agent.
User Agent
Requests
Percentage of
Total
Search (crawl)
4,373,433
67.61%
Outlook
897,183
13.87%
OneNote
456,917
7.06%
DAV
273,391
4.23%
Browser
247,303
3.82%
Word
94,465
1.46%
SharePoint Workspaces
70,651
1.09%
Office Web Applications
45,125
0.70%
Excel
8,826
0.14%
Access
1,698
0.03%
Dataset
This section describes the case study farm dataset that includes database sizes and
Search indexes.
Dataset Characteristics
Value
182
Dataset Characteristics
Value
Database size (combined)
1.8 TB
BLOB size
1.68 TB
Number of content databases
18
Total number of databases
36
Number of site collections
7,499
Number of Web applications
7
Number of sites
42,457
Search index size (number of items)
4.6 million
Health and Performance Data
This section provides health and performance data that is specific to the case study
environment.
General Counters
Metric
Value
Availability (uptime)
99.9995%
Failure Rate
0.0005%
Average memory used
0.89 GB
Maximum memory used
5.13 GB
Search Crawl % of Traffic (Search client
requests / total requests)
82.5%
The following charts show the average CPU utilization and latency for this environment:
183
In this document, latency is divided into four categories. The 50th percentile latency is
typically used to measure the server’s responsiveness. It means that half of the requests
184
are served within that response time. The 95th percentile latency is typically used to
measure spikes in server response times. It means that 95% of requests are served
within that response time, and therefore, 5% of the requests experience slower response
times.
Database Counters
Metric
Value
Average Disk queue length
1.42
Disk Queue Length: Reads
1.38
Disk Queue Length: Writes
0.04
Disk Reads/sec
56.51
Disk Writes/sec
17.60
SQL Compilations/second
13.11
SQL Re-compilations/second
0.14
SQL Locks: Average Wait Time
294.56 ms
SQL Locks: Lock Wait Time
867.53 ms
SQL Locks: Deadlocks Per Second
1.87
SQL Latches: Average Wait Time
5.10 ms
SQL Cache Hit Ratio
99.77%
185
Divisional portal environment lab study
(SharePoint Server 2010) (em inglês)
This document provides guidance on performance and capacity planning for a divisional
portal based on Microsoft SharePoint Server 2010. It includes the following:
 Test environment specifications, such as hardware, farm topology and configuration

Test farm dataset

Test data and recommendations for how to determine the hardware, topology and
configuration that you must have to deploy a similar environment, and how to
optimize your environment for appropriate capacity and performance characteristics
In this article:
 Introduction to this environment

Glossary

Overview

Specifications

Results and analysis
Introduction to this environment
This document outlines the test methodology and results to provide guidance for capacity
planning of a typical divisional portal. A divisional portal is a SharePoint Server 2010
deployment where teams mainly do collaborative activities and some content publishing.
This document assumes a "division" to be an organization inside an enterprise with 1,000
to 10,000 employees.
Different scenarios will have different requirements. Therefore, it is important to
supplement this guidance with additional testing on your own hardware and in your own
environment. If your planned design and workload resembles the environment described
in this document, you can use this document to draw conclusions about scaling your
environment up and out.
When you read this document, you will understand how to do the following:
 Estimate the hardware that is required to support the scale that you need to support:
number of users, load, and the features enabled.

Design your physical and logical topology for optimal reliability and efficiency. High
Availability/Disaster Recovery are not covered in this document.

Understand the effect of ongoing search crawls on RPS for a divisional portal
deployment.
The SharePoint Server 2010 environment described in this document is a lab
environment that mimics a production environment at a large company. For details about
the production environment, see Departmental collaboration environment technical case
study (SharePoint Server 2010) (em inglês).
186
Before reading this document, make sure that you understand the key concepts behind
capacity management in SharePoint Server 2010. The following documentation will help
you learn about the recommended approach to capacity management and provide
context for helping you understand how to make effective use of the information in this
document, and also define the terms used throughout this document.
 Visão geral do gerenciamento da capacidade e dimensionamento do SharePoint
Server 2010
 Gerenciamento de capacidade do SharePoint Server 2010: limites de software
Also, we encourage you to read the following:
 Planejamento e configuração de armazenamento e capacidade do SQL Server
(SharePoint Server 2010)
Glossary
There are some specialized terms that you will encounter in this document. Here are
some key terms and their definitions.
 RPS: Requests per second. The number of requests received by a farm or server in
one second. This is a common measurement of server and farm load.
Note that requests differ from page loads; each page contains several components,
each of which creates one or more requests when the page is loaded. Therefore, one
page load creates several requests. Typically, authentication checks and events
using insignificant resources are not counted in RPS measurements.
 Green Zone: This is the state at which the server can maintain the following set of
criteria:

The server-side latency for at least 75% of the requests is less than .5 second.

All servers have a CPU Utilization of less than 50%.
Observação:
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%.
187

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.
188
We started off with a minimal farm configuration of 1 Web server /application server and
1 database server. Through multiple iterations, we finally ended at 3 Web servers, 1
application server, 1 database server farm configuration, where the database server CPU
was maxed out. Below you will find a quick summary and charts of tests we performed on
each iteration to establish green zone and max zone for that configuration. That is
followed by comparison of green zone and max zone for different iterations, from which
we derive our recommendations.
The SharePoint Admin Toolkit team has built a tool that is named "Load Test Toolkit
(LTK)" which is publically available for customers to download and use.
Specifications
This section provides detailed information about the hardware, software, topology, and
configuration of the lab environment.
Hardware
The table that follows presents hardware specs for the computers that were used in this
testing. Every Web server that was added to the server farm during multiple iterations of
the test complies with the same specifications.
Web server
Application
Server
Processor(s)
[email protected]
[email protected] 4px4c@
3.19GHz
RAM
8 GB
8 GB
32 GB
Number of network
adapters
2
2
1
Network adapter speed
1 Gigabit
1 gigabit
1 Gigabit
Load balancer type
F5 - Hardware load balancer Not applicable
Not
applicable
ULS Logging level
Medium
Not
applicable
Medium
Database
Server
Software
The table that follows explains software installed and running on the servers that were
used in this testing effort.
Operating System
Web Server
Application
Server
Database
Server
Windows Server 2008 R2 x64
Windows
Server 2003
x64
Windows
Server
2008 x64
189
Web Server
Application
Server
Database
Server
Software version
SharePoint Server 2010 and
Office Web Applications, prerelease versions
SharePoint
Server 2010
and Office
Web
Applications,
pre-release
versions
SQL
Server
2008 R2
CTP3
Authentication
Windows NTLM
Windows
NTLM
Windows
NTLM
Load balancer type
F5 - Hardware load balancer
Not applicable Not
applicable
ULS Logging level
Medium
Medium
Not
applicable
Anti-Virus Settings
Disabled
Disabled
Disabled
Services running locally
Microsoft SharePoint
Foundation Incoming E-Mail
Microsoft SharePoint
Foundation Web Application
Microsoft SharePoint
Foundation Workflow Timer
Service
Search Query and Site Settings
Service
SharePoint Server Search
Central
Not
Administration applicable
Excel
Services
Managed
Metadata
Web Service
Microsoft
SharePoint
Foundation
Incoming EMail
Microsoft
SharePoint
Foundation
Web
Application
Microsoft
SharePoint
Foundation
Workflow
Timer Service
PowerPoint
Services
Search Query
and Site
Settings
Service
190
Web Server
Application
Server
Database
Server
SharePoint
Server
Search
Visio
Graphics
Services
Word Viewing
Service
The table indicates which services are provisioned in the test environment. Other
services such as the User Profile service and Web Analytics are not provisioned.
Topology and configuration
The following diagram shows the topology used for the tests. We changed the number of
Web servers from 1 to 2 to 3, as we moved between iterations, but otherwise the
topology remained the same.
191
Dataset and disk geometry
192
The test farm was populated with about 1.62 Terabytes of content, distributed across five
different sized content databases. The following table explains this distribution:
Content database
1
2
3
4
5
Content database size
36 GB
135 GB
175 1.2
75
GB terabytes GB
Number of sites
44
74
9
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
9
222
Transactional mix
The following are important notes about the transactional mix:
 There are no My Sites provisioned on the divisional portal. Also, the User Profile
service, which supports My Sites, is not running on the farm. The transactional mix
does not include any My Site page/web service hits or traffic related to Outlook Social
Connector.

The test mix does not include any traffic generated by co-authoring on documents.

The test mix does not include traffic from Search Crawl. However this was factored
into our tests by modifying the Green-zone definition to be 40 percent SQL Server
CPU usage instead of the standard 50 percent to allow for 10 percent for the search
crawl. Similarly, we used 80 percent SQL Server CPU as the criteria for max RPS.
The following table describes the overall transaction mix. The percentages total 100.
Feature or Service
Operation
Read/write
Percentage
of mix
ECM
Get static files
r
8.93%
View home page
r
1.52%
Display/Edit upsize list item and r
new forms
0.32%
Download file by using "Save
as"
1.39%
Microsoft InfoPath
r
Microsoft OneNote 2010
Open Microsoft Office OneNote r
2007 file
13.04%
Search
Search through
4.11%
193
r
Feature or Service
Operation
Read/write
Percentage
of mix
w
0.35%
OSSSearch.aspx or
SearchCenter
Workflow
Start autostart workflow
Microsoft Visio
Render Visio file in PNG/XAML r
0.90%
Office Web Applications PowerPoint
Render Microsoft PowerPoint, r
scroll to 6 slides
0.05%
Office Web Applications Word
Render and scroll Microsoft
Word doc in PNG/Silverlight
r
0.24%
Microsoft SharePoint
Foundation
List – Check out and then
check in an item
w
0.83%
List - Get list
r
0.83%
List - Outlook sync
r
1.66%
List - Get list item changes
r
2.49%
List - Update list items and
adding new items
w
4.34%
Get view and view collection
r
0.22%
Get webs
r
1.21%
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 r
page)
1.70%
Browse to Upload doc to doc lib w
0.05%
Browse to List/Library's default r
view
7.16%
Delete doc in doclib using DAV w
0.83%
Get doc from doclib using DAV r
6.44%
Lock and Unlock a doc in doclib w
using DAV
3.32%
Propfind list by using DAV
r
4.16%
Propfind site by using DAV
r
4.16%
List document by using FPSE
r
0.91%
194
Feature or Service
Operation
Read/write
Percentage
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%
Serviços do Excel
Render small/large Excel files
1.56%
Workspaces
WXP - Cobalt internal protocol r
23.00%
Full file upload using WXP
0.57%
r
w
Results and analysis
This section describes the test methodology and results to provide guidance for capacity
planning of a typical divisional portal.
Results from 1x1 farm configuration
Summary of results

On a 1 Web server and 1 database server farm, in addition to Web server duties, the
same computer was also acting as application server. Clearly this computer (still
called Web server) was the bottleneck. As presented in the data here, the Web
server CPU reached around 86% utilization when the farm was subjected to user
load of 125 users by using the transactional mix described earlier in this document.
At that point, the farm exhibited max RPS of 101.37.

Even at a small user load, Web server utilization was always too high to consider this
farm as a healthy farm. For the workload and dataset that we used for the test, we do
not recommend this configuration as a real deployment.

Going by definition of "green zone", there is not really a "green zone" for this farm. It
is always under stress, even at a small load. As for "max zone", at the smallest load,
where the farm was in "max zone", the RPS was 75.

Because the Web server was the bottleneck due to its dual role as an application
server, for the next iteration, we separated out the application server role onto its own
computer.
Performance counters and graphs
The following table presents various performance counters captured during testing a 1x1
farm at different steps in user load.
User Load
50
75
100
RPS
74.958
89.001
95.79 101.37
Latency
0.42
0.66
0.81 0.81
Web server CPU
79.6
80.1
89.9 86
195
125
User Load
50
75
100
125
Application server CPU
N/A
N/A
N/A
N/A
Database server CPU
15.1
18.2
18.6 18.1
75th Percentile (sec)
0.3
0.35
0.55 0.59
95th Percentile (sec)
0.71
0.77
1.03 1
The following chart shows the RPS and latency results for a 1x1 configuration.
The following chart shows performance counter data in a 1x1 configuration.
196
Results from 1x1x1 farm configuration
Summary of results

On a 1 Web server, 1 application server and 1 database server farm, the Web server
was the bottleneck. As presented in the data in this section, the Web server CPU
reached around 85% utilization when the farm was subjected to user load of 150
users by using the transactional mix described earlier in this document. At that point,
the farm exhibited max RPS of 124.1.

This configuration delivered "green zone" RPS of 99, with 75th percentile latency
being 0.23 sec, and the Web server CPU hovering around 56 % utilization. This
indicates that this farm can healthily deliver an RPS of around 99. "Max zone" RPS
delivered by this farm was 123 with latencies of 0.25 sec and the Web server CPU
hovering around 85%.

Because the Web server CPU was the bottleneck in this iteration, we relived the
bottleneck by adding another the Web server for the next iteration.
Performance counters and graphs
The following table presents various performance counters captured during testing a
1x1x1 farm, at different steps in user load.
User Load
25
50
197
75
100
125
150
User Load
25
50
75
100
125
RPS
53.38
91.8
112.2 123.25 123.25 124.1
Latency
34.2
56
71.7 81.5
84.5
84.9
Web server CPU
23.2
33.8
34.4 32
30.9
35.8
Application server CPU 12.9
19.7
24.1 25.2
23.8
40.9
Database server CPU
0.22
0.23
0.27 0.32
0.35
0.42
75th Percentile (sec)
0.54
0.52
0.68 0.71
0.74
0.88
The following chart shows RPS and latency results for a 1x1x1 configuration.
The following chart shows performance counter data in a 1x1x1 configuration.
198
150
Results from 2x1x1 farm configuration
Summary of results

On a 2 Web server, 1 application server and 1 database server farm, the Web server
was the bottleneck. As presented in the data in this section, Web server CPU
reached around 76% utilization when the farm was subjected to user load of 200
users by using the transactional mix described earlier in this document. At that point,
the farm exhibited max RPS of 318.

This configuration delivered "green zone" RPS of 191, with 75th percentile latency
being 0.37 sec, and Web server CPU hovering around 47 % utilization. This indicates
that this farm can healthily deliver an RPS of around 191. "Max zone" RPS delivered
by this farm was 291 with latencies of 0.5 sec and Web server CPU hovering around
75%.

Because the Web server CPU was the bottleneck in this iteration, we relived the
bottleneck by adding another Web server for the next iteration.
Performance counters and graphs
The following table presents various performance counters captured during testing a
2x1x1 farm, at different steps in user load.
User Load
40
80
199
115
150
175
200
User Load
40
80
115
150
175
200
RPS
109
190
251 287
304
318
Latency
0.32
0.37
0.42 0.49 0.54 0.59
Web server CPU
27.5
47.3
61.5 66.9 73.8 76.2
Application server CPU
17.6
29.7
34.7 38
Database server CPU
21.2
36.1
43.7 48.5 52.8 56.2
75th Percentile (sec)
0.205
0.23
0.27 0.3
95th Percentile (sec)
0.535
0.57
0.625 0.745 0.645 0.57
The following chart shows RPS and latency results for a 2x1x1 configuration.
The following chart shows performance counter data in a 2x1x1 configuration.
200
45
45.9
0.305 0.305
Results from 3x1x1 farm configuration
Summary of results

On a 3 Web server, 1 application server and 1 database server farm, finally, the
database server CPU was the bottleneck. As presented in the data in this section,
database server CPU reached around 76% utilization when the farm was subjected
to user load of 226 users by using the transactional mix described earlier in this
document. At that point, the farm exhibited max RPS of 310.

This configuration delivered "green zone" RPS of 242, with 75th percentile latency
being 0.41 sec, and database server CPU hovering around 44% utilization. This
indicates that this farm can healthily deliver an RPS of around 242. "Max zone" RPS
delivered by this farm was 318 with latencies of 0.5 sec and database server CPU
hovering around 75%.
 This was the last configuration in the series.
Performance counters and graphs
The following table presents various performance counters captured during testing a
3x1x1 farm, at different steps in user load.
User Load
66
103
141
RPS
193.8
218.5
269.8 275.5 318.25 310
201
17
202
226
User Load
66
103
141
17
202
Latency
0.3
0.41
0.47 0.58 0.54
0.78
Web server CPU
33
38.3
45.8 43.3 51
42.5
Application server CPU
28
32.6
46.5 40
45.1
43.7
Database server CPU
41.6
44.2
52.6 48
61.8
75
75th Percentile (sec)
0.22
0.24
0.30 0.65 0.78
0.87
95th Percentile (sec)
0.49
0.57
0.72 1.49 0.51
1.43
The following chart shows RPS and latency results in a 3x1x1 configuration.
The following chart shows performance counter data for a 3x1x1 configuration.
202
226
Comparison
From the iterative tests we performed, we found out the points at which a configuration
enters max zone or green zone. Here’s a table of those points.
The table and charts in this section provide a summary for all the results that were
presented earlier in this article.
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.
203
The following chart shows a summary of latency at different configurations.
204
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.
205
Tests with Search incremental crawl
As we mentioned before, all the tests until now were run without Search crawl traffic. In
order to provide information about how ongoing search crawl can affect performance of a
farm, we decided to find out the max user RPS and corresponding user latencies with
search crawl traffic in the mix. We added a separate Web server to 3x1x1 farm,
designated as a crawl target. We saw a 17% drop in RPS compared to original RPS
exhibited by 3x1x1.
In a separate test, on the same farm, we used Resource Governor to limit available
resources to search crawl 10%. We saw that as Search uses lesser resources, the max
RPS of the farm climbs up by 6%.
Baseline 3x1x1
Only
No
10%
Incremental Resource Resource
Crawl
Governor Governor
RPS
318
N/A
276
294.5
Percent RPS difference
from baseline
0%
N/A
83%
88%
Database server CPU (%)
83.40
8.00
86.60
87.3
SA Database server CPU
3.16
2.13
3.88
4.2
206
Baseline 3x1x1
Only
No
10%
Incremental Resource Resource
Crawl
Governor Governor
Web server CPU (%)
53.40
0.30
47.00
46.5
Application server CPU
(%)
22.10
28.60
48.00
41.3
16.50
15.00
12.1
(%)
Crawl Web server CPU (%) 0.50
The following chart shows results from tests with incremental Search crawl turned on.
207
Importante:
Here we are only talking about incremental crawl, on a farm where there are not very
many changes to the content. It is important to be aware that 10% resource utilization will
be insufficient for a full search crawl. It may also prove to be less if there are too many
changes. It is definitely not advised to limit resource utilization to 10% if you are running a
full search crawl, or your farm generally sees a high volume of content changes between
crawls.
Summary of results and recommendations
To paraphrase the results from all configurations we tested:
 With the configuration, dataset and test workload we had selected for the tests, we
could scale out to maximum 3 Web servers before SQL Server was bottlenecked on
CPU. The absolute max RPS we could reach that point was somewhere around 318.

With each additional Web server, increase in RPS was almost linear. We can
extrapolate that as long as SQL Server is not bottlenecked, you can add more Web
servers and additional increase in RPS is possible.

Latencies are not affected much as we approached bottleneck on SQL Server.

Incremental Search crawl directly affects RPS offered by a configuration. The effect
can be minimized by using Resource Governor.
Using the results, here are few recommendations on how to achieve even larger scale if
you must have more RPS from your divisional portal:
 1x1 farm can deliver up to 75 RPS. However, it is usually stressed. It’s not a
recommended configuration for a divisional portal in production.

Separate out content databases and services databases on separate instances of
SQL Server: In the test workload used in tests, when SQL Server was bottlenecked
on CPU, only 3% of the traffic was to the services databases. Thus this step would
have achieved slightly better scale out than what we saw. But, in general, increase in
scale out by separating out content databases and services databases is directly
proportional to the traffic to services database in your farm.

Separate out individual content databases on separate instances of SQL Server. In
the dataset used for testing, we had 5 content databases, all located on the same
instance of SQL Server. By separating them out on different computers, you will be
spreading CPU utilization across multiple computers. Therefore, you will see much
larger RPS numbers.

Finally when SQL Server is bottlenecked on CPU, adding more CPU to SQL Server
can increase RPS potential of the farm almost linearly.
How to translate these results into your deployment
In this article, we discussed results as measured by RPS and latency, but how do you
apply these in the real world? Here’s some math based on our experience from divisional
portal internal to Microsoft.
A divisional portal in Microsoft which supports around 8000 employees collaborating
heavily, experiences an average RPS of 110. That gives a Users to RPS ratio of ~72
208
(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.
209
Social environment technical case study
(SharePoint Server 2010) (em inglês)
This document describes a specific deployment of Microsoft SharePoint Server 2010. It
includes the following:
 Technical case study environment specifications, such as hardware, farm topology
and configuration

The workload that includes the number, and types, of users or clients, and
environment usage characteristics

Technical case study farm dataset that includes database contents and Search
indexes
 Health and performance data that is specific to the environment
In this article:
 Prerequisite information

Introduction to this environment

Specifications

Workload

Dataset

Health and Performance Data
Prerequisite information
Before reading this document, make sure that you understand the key concepts behind
SharePoint Server 2010 capacity management. The following documentation will help
you learn about the recommended approach to capacity management and provide
context for helping you understand how to make effective use of the information in this
document, and also define the terms used throughout this document.
For more conceptual information about performance and capacity that you might find
valuable in understanding the context of the data in this technical case study, see the
following documents:
 Visão geral do gerenciamento da capacidade e dimensionamento do SharePoint
Server 2010

Gerenciamento de capacidade do SharePoint Server 2010: limites de software
Introduction to this environment
This white paper describes an actual SharePoint Server 2010 environment at Microsoft.
Use this document to compare with your planned workload and usage characteristics. If
your planned design is similar, you can use the deployment described here as a starting
point for your own installation.
210
This document includes the following:
 Specifications, which include hardware, topology and configuration

Workload, which is the demand on the farm that includes the number of users, and
the usage characteristics

Dataset that includes database sizes
 Health and performance data specific to the environment
This document is part of a series of Performance and capacity technical case studies
(SharePoint Server 2010) (em inglês) about SharePoint environments at Microsoft.
The
SharePoint Server 2010 environment described in this document is a production
environment at a large, geographically distributed company. This environment hosts
SharePoint My Sites that connect employees with one another and the information that
they need. Employees use this environment to present personal information such as
areas of expertise, past projects, and colleagues to the wider organization. The
environment also hosts personal sites and documents for viewing, editing, and
collaboration. My Sites are integrated with Active Directory Domain Services (AD DS) to
provide a central location that can be accessed from the browser and various client
applications.
As many as 72,000 unique users visit the environment on a busy day, generating up to
180 requests per second (RPS) during peak hours. Because this is an intranet site, all
users are authenticated.
The information that is provided in this document reflects the enterprise social
environment on a typical day.
Specifications
This section provides detailed information about the hardware, software, topology, and
configuration of the case-study environment.
Hardware
This section provides details about the server computers that were used in this
environment.
211
Observação:
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 Visão geral do gerenciamento da capacidade e
dimensionamento do SharePoint Server 2010.
Web Servers
There are three Web servers in the farm, each with identical hardware. Two serve
content, and the third is a dedicated search crawl target.
Web Server
WFE1-3
Processor(s)
2 quad core @ 2.33 GHz
RAM
16 GB
Operating system
Windows Server 2008, 64 bit
Size of the SharePoint drive
400 GB
Number of network adapters
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
212
Web Server
WFE1-3
Business Data Connectivity Service
Managed Metadata Web Service
Application Server
There are two application servers in the farm, each with identical hardware.
Application Server
APP1-4
Processor(s)
2 quad core @ 2.33 GHz
RAM
16 GB
OS
Windows Server 2008, 64 bit
Size of the SharePoint drive
400 GB
Number of network adapters
1
Network adapter speed
1 Gigabit
Authentication
Windows NTLM
Load balancer type
Hardware load balancing
Software version
SharePoint Server 2010 (pre-release
version)
Services running locally
Office Web Apps
Excel
PowerPoint
Secure Store
Usage and Health
State Service
Database Servers
There is a SQL cluster with two database servers, each with identical hardware. One of
the servers is active and the other is passive for redundancy.
Database Server
DB1-2
Processor(s)
4 quad core @ 2.4 GHz
RAM
64 GB
Operating system
Windows Server 2008, 64 bit
Storage and geometry
(1.25 TB * 6)
213
Database Server
DB1-2
Disk 1-4: SQL Data
Disk 5: Logs
Disk 6: TempDB
Number of network adapters
2
Network adapter speed
1 @ 100MB, 1 @ 1GB
Authentication
Windows NTLM
Software version
SQL Server 2008
Topology
The following diagram shows the topology for this farm.
214
Configuration
215
The following table enumerates settings that were changed that affect performance or
capacity in the environment.
Setting
Value
Notes
Usage Service:
5 days The default is 14 days. Lowering this setting can save
disk space on the server where the log files are
Trace Log – days to store
stored.
log files (default: 14 days)
QueryLoggingThreshold 1
The default is 5 seconds. Lowering this setting can
second
save bandwidth and CPU on the database server.
Microsoft SharePoint
Foundation Database –
configure
QueryLoggingThreshold
to 1 second
1
Database Server –
Default Instance
Max degree of parallelism
The default is 0. To ensure optimal performance, we
strongly recommend that you set max degree of
parallelism to 1 for database servers that host
SharePoint Server 2010 databases. For more
information about how to set max degree of
parallelism, see max degree of parallelism
Option(http://go.microsoft.com/fwlink/?LinkId=189030).
Workload
This section describes the workload, which is the demand on the farm that includes the
number of users, and the usage characteristics.
Workload Characteristics
Value
Average Requests per Second (RPS)
64
Average RPS at peak time (11 AM-3 PM)
112
Total number of unique users per day
69,814
Average concurrent users
639
Maximum concurrent users
1186
Total # of requests per day
4,045,677
This table shows the number of requests for each user agent.
User Agent
Requests
216
Percentage of
Total
User Agent
Requests
Percentage of
Total
Outlook Social Connector Browser 1,808,963
44.71%
Search (crawl)
704,569
17.42%
DAV
459,491
11.36%
OneNote
266,68
6.59%
Outlook
372,574
9.21%
Browser
85,913
2.12%
Word
38,556
0.95%
Excel
30,021
0.74%
Office Web Applications
20,314
0.50%
SharePoint Workspaces
19,017
0.47%
Dataset
This section describes the case study farm dataset that includes database sizes and
Search indexes.
Dataset Characteristics
Value
Database size (combined)
1.5 TB
BLOB size
1.05 TB
Number of content databases
64
Number of Web applications
1
Number of site collections
87,264
Number of sites
119,400
Search index size (number of items)
5.5 million
Health and Performance Data
This section provides health and performance data that is specific to the case study
environment.
General Counters
217
Metric
Value
Availability (uptime)
99.61%
Failure Rate
0.39%
Average memory used
0.79 GB
Maximum memory used
4.53 GB
Search Crawl % of Traffic (Search client
requests / total requests)
17.42%
The following charts show average CPU utilization and latency for this environment.
218
In this document, latency is divided into four categories. The 50th percentile latency is
typically used to measure the server’s responsiveness. It means that half of the requests
are served within that response time. The 95th percentile latency is typically used to
measure spikes in server response times. It means that 95% of requests are served
within that response time, and therefore, 5% of the requests experience slower response
times.
Database Counters
219
Metric
Value
Read/Write Ratio (IO Per Database)
99.854 : 0.146
Average Disk queue length
8.702
Disk Queue Length: Reads
30.518
Disk Queue Length: Writes
4.277
Disk Reads/sec
760.886
Disk Writes/sec
180.644
SQL Compilations/second
3.129
SQL Re-compilations/second
0.032
SQL Locks: Average Wait Time
125 ms
SQL Locks: Lock Wait Time
33.322 ms
SQL Locks: Deadlocks Per Second
0
SQL Latches: Average Wait Time
0 ms
SQL Cache Hit Ratio
20.1%
220
Recomendações e resultados de testes
de desempenho e capacidade
(SharePoint Server 2010)
Esta seção contém uma série de white papers e artigos que descrevem o impacto no
desempenho e na capacidade causado por conjuntos de recursos específicos incluídos
no Microsoft SharePoint Server 2010. Os white papers e artigos incluem informações
sobre as características de desempenho e capacidade do recurso e sobre como ele foi
testado pela Microsoft, incluindo:
 Características do teste de farm

Resultados do teste

Recomendações

Solução de problemas de desempenho e escalabilidade
Observação:
Os white papers estão sendo atualizados e republicados em forma de artigos. Se você
baixar um white paper desta página, poderá haver informações atualizadas quando ele
for publicado novamente como um artigo.
Antes de ler os white papers e artigos, é importante que você entenda os conceitoschave que fundamentam o gerenciamento de capacidade do SharePoint Server 2010.
Para obter mais informações, consulte Capacity management and sizing for SharePoint
Server 2010 (em inglês).
A tabela a seguir descreve os white papers e artigos disponíveis. Se o conteúdo estiver
disponível como um white paper, ele será disponibilizado como um documento do
Microsoft Word na página sobre resultados do teste e recomendações sobre
desempenho e capacidade do SharePoint Server 2010.
Assunto
Descrição
Serviços do Access
Apresenta diretrizes sobre o impacto do uso dos
Serviços 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 inglês).
Serviços Corporativos de
Conectividade
Apresenta diretrizes sobre o volume de recursos que o
uso dos Serviços Corporativos de Conectividade requer
nas topologias que executam o SharePoint Server
2010. Baixe o white paper
221
Assunto
Descrição
(BCSCapacityPlanningDoc.docx).
Visão geral dos caches
Fornece informações sobre como os três caches do
SharePoint Server 2010 ajudam a ajustar a escala e o
crescimento do produto para atender as demandas do
seu aplicativo de negócios. Baixe o white paper
(SharePointServerCachesPerformance.docx).
Serviços do Excel no Microsoft
SharePoint Server 2010
Apresenta diretrizes de planejamento para os Serviços
do Excel no Microsoft SharePoint Server 2010.
Visualize o artigo em Estimate performance and
capacity requirements for Excel Services in SharePoint
Server 2010 (em inglês).
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 é específico do SharePoint Server 2010,
embora os limites abordados também se apliquem ao
Microsoft SharePoint Foundation 2010. Baixe o white
paper
(DesigningLargeListsMaximizingListPerformance.docx).
Repositórios de documentos de Apresenta diretrizes sobre o desempenho de
repositórios de documentos de larga escala em relação
larga escala
ao SharePoint Server 2010. Baixe o white paper
(LargeScaleDocRepositoryCapacityPlanningDoc.docx).
Meus Sites e computação social Apresenta diretrizes sobre o volume de recursos que o
uso de Meus Sites e outros recursos de computação
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).
Serviços PerformancePoint
Apresenta diretrizes sobre o volume de recursos que o
uso dos Serviços PerformancePoint requer nas
topologias que executam o SharePoint Server 2010.
Visualize o artigo em Estimar os requisitos de
desempenho e capacidade dos Serviços
PerformancePoint.
Pesquisa
Fornece informações sobre planejamento de
222
Assunto
Descrição
capacidade para diferentes implantações de Pesquisa
no SharePoint Server 2010, incluindo farms pequenos,
médios e grandes. Baixe o white paper
(SearchforSPServer2010CapacityPlanningDoc.docx).
Se estiver usando o FAST Search Server 2010 para
SharePoint como sua solução de pesquisa empresarial,
consulte Plan for performance and capacity (FAST
Search Server 2010 for SharePoint).
Serviços do Visio
Apresenta diretrizes sobre o volume de recursos que o
uso dos Serviços do Visio requer nas topologias que
executam o SharePoint Server 2010. Baixe o white
paper (VisioServicesCapacityPlanningDoc.docx).
Web Analytics
Apresenta diretrizes sobre o volume de recursos que o
uso do serviço 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 inglês).
Gerenciamento de Conteúdo da Apresenta diretrizes sobre o planejamento de
desempenho e capacidade para uma solução de
Web
Gerenciamento de Conteúdo da Web. Visualize o
artigo em Estimar os requisitos de desempenho e
capacidade do Gerenciamento de conteúdo da Web no
SharePoint Server 2010.
Word Automation Services
Apresenta diretrizes sobre o planejamento de
capacidade para o Word Automation Services no
SharePoint Server 2010. Baixe o white paper
(WASCapacityPlanningDoc.docx).
Fluxo de trabalho
Apresenta diretrizes sobre o volume de recursos que o
uso de Fluxo de Trabalho requer nas topologias que
executam o SharePoint Server 2010. Baixe o white
paper (WorkflowCapacityPlanningDoc.docx).
223
Estimate performance and capacity
requirements for Access Services in
SharePoint Server 2010 (em inglês)
This article provides guidance on the footprint that usage of Serviços do Access no
Microsoft SharePoint Server 2010 has on topologies that are running Microsoft
SharePoint Server 2010.
In this article:
 Test farm characteristics

Test results

Recommendations

Troubleshooting
Test farm characteristics
This section describes the dataset that was used during the testing; the workloads that
were placed on the product during performance gathering; the hardware that was used
during the testing; and the topology for how that hardware was deployed.
Dataset
Serviços 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, Serviços do Access applications were simulated on a
farm dedicated to Serviços do Access (no other SharePoint tests were running). The farm
contained the following representative sites:
 1,500 Serviços do Access applications that have a “Small” size profile; 100 items
maximum per list.


1,500 Serviços do Access applications that have a “Medium” size profile; 2,000 items
maximum per list.
1,500 Serviços 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. Serviços 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.
224

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. Serviços 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
225
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 Serviços 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.
226

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 Serviços 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 Serviços 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
227
Recommended results
The following graph shows the results for recommended sustainable throughput.
228
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 Serviços do Access, and in reality the front-end
Web servers are likely shared with other SharePoint workloads. The following graph
shows the results.
229
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.
230
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.
231
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.
232
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.
233
Detailed results
The following tables show the detailed results for the recommended configurations.
Overall
1x1
1x2
1x3
Req/Sec
14.96
28.76 45.22 48.01 14.85 28.77 58.02
Tests/Sec
2.00
3.81
Average Latency
235.80
241.21 247.21 244.87 240.70 242.26 250.94
6.11
1x4
6.42
2x1
1.99
2x2
3.81
2x4
7.80
Average front- 1x1
end Web
server tier
1x2
1x3
1x4
2x1
2x2
2x4
%CPU
24.40
41.02
43.62
6.31
12.48
26.18
13.82
234
Average front- 1x1
end Web
server tier
1x2
Max w3wp
9.46E+08
Private Bytes
2.31E+08 1.49E+09 1.55E+09 8.43E+08 9.84E+08 1.19E+09
Average
1x1
application
server
(Access Data
Services) tier
1x2
1x3
1x4
2x1
2x2
2x4
%CPU
46.30
42.83
43.74
34.51
46.56
43.45
42.13
%CPU w3wp 33.61
31.15
30.71
24.29
33.48
31.64
29.72
%CPU RS
7.94
9.17
6.84
9.03
8.02
8.71
8.62
1x3
1x4
2x1
2x2
2x4
Max total
4.80E+09
Private Bytes
4.89E+09 4.91E+09 4.62E+09 5.32E+09 4.82E+09 5.07E+09
Max w3wp
2.10E+09
Private Bytes
1.97E+09 2.04E+09 1.86E+09 2.00E+09 2.00E+09 2.07E+09
Max RS
1.78E+09
Private Bytes
2.00E+09 1.97E+09 1.86E+09 2.30E+09 1.89E+09 2.02E+09
Database
server (SQL
Server) tier
(single
computer)
1x1
1x2
1x3
1x4
2x1
2x2
2x4
%CPU
12.07
18.64
32.53
36.05
9.89
21.42
47.46
Avg Private
Bytes
2.96E+10
3.22E+10 3.25E+10 3.25E+10 2.89E+10 3.22E+10 3.25E+10
Max Private
Bytes
3.26E+10
3.25E+10 3.25E+10 3.25E+10 3.25E+10 3.25E+10 3.25E+10
Avg Disk
0.74
Queue Length
Total
1.18
1.64
1.77
0.67
1.24
The following tables show the detailed results for the maximum configurations.
235
2.18
Overall
1x1
1x2
1x3
Req/Sec
14.96
28.76 45.22 48.01 14.85 28.77 58.02
Tests/Sec
2.00
3.81
Average Latency
235.80
241.21 247.21 244.87 240.70 242.26 250.94
6.11
1x4
6.42
2x1
1.99
2x2
3.81
2x4
7.80
Average front- 1x1
end Web
server tier
1x2
1x3
1x4
2x1
2x2
2x4
%CPU
24.40
41.02
43.62
6.31
12.48
26.18
13.82
Max w3wp
9.46E+08
Private Bytes
2.31E+08 1.49E+09 1.55E+09 8.43E+08 9.84E+08 1.19E+09
Average
1x1
application
server
(Access Data
Services) tier
1x2
1x3
1x4
2x1
2x2
2x4
%CPU
46.30
42.83
43.74
34.51
46.56
43.45
42.13
%CPU w3wp 33.61
31.15
30.71
24.29
33.48
31.64
29.72
%CPU RS
7.94
9.17
6.84
9.03
8.02
8.71
8.62
Max total
4.80E+09
Private Bytes
4.89E+09 4.91E+09 4.62E+09 5.32E+09 4.82E+09 5.07E+09
Max w3wp
2.10E+09
Private Bytes
1.97E+09 2.04E+09 1.86E+09 2.00E+09 2.00E+09 2.07E+09
Max RS
1.78E+09
Private Bytes
2.00E+09 1.97E+09 1.86E+09 2.30E+09 1.89E+09 2.02E+09
Database
server (SQL
Server) tier
(single
computer)
1x1
1x2
1x3
1x4
2x1
2x2
2x4
%CPU
12.07
18.64
32.53
36.05
9.89
21.42
47.46
Avg Private
Bytes
2.96E+10
3.22E+10 3.25E+10 3.25E+10 2.89E+10 3.22E+10 3.25E+10
236
Database
server (SQL
Server) tier
(single
computer)
1x1
1x2
Max Private
Bytes
3.26E+10
3.25E+10 3.25E+10 3.25E+10 3.25E+10 3.25E+10 3.25E+10
Avg Disk
0.74
Queue Length
Total
1.18
1x3
1x4
1.64
1.77
2x1
0.67
2x2
1.24
2x4
2.18
Recommendations
This section provides general performance and capacity recommendations.
Serviços 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
Serviços 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 Serviços do Access scenario:
 To provide for more user load, check the CPU for the existing Serviços do Access
application servers. Add additional CPUs or cores, or both, to these servers if it is
possible. Add more Serviços 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.
237

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 Serviços do Access is to limit the
size and complexity of queries that can be performed. Serviços 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 Serviços 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 Serviços do Access augments to cover a broader
set of application scenarios. For Serviços 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, Serviços 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
238
To help you determine when you have to scale up or scale out the system, use
performance counters to monitor the health of the system. Use the information in the
following tables to determine which performance counters to monitor, and to which
process the performance counters should be applied.
Front-end Web servers
The following table shows performance counters and processes to monitor for Web
servers in your farm.
Performance counter
Apply to object
Notes
% Processor Time
Processor(_Total)
Shows the
percentage of
elapsed time that
this thread used
the processor to
execute
instructions.
Private Bytes
Process(w3wp)
This value should
not approach the
Max Private
Bytes set for
w3wp processes.
Iif it does,
additional
investigation is
needed into what
component is
using the
memory.
Access Data Services
The following table shows performance counters and processes to monitor for application
servers, or Access Data Services (Access Data Services) in this case, within your farm.
Performance counter
Apply to object
Notes
% Processor Time
Processor(_Total)
Shows the
percentage of
elapsed time that
this thread used
the processor to
execute
instructions.
% Processor Time
Process(w3wp)
The Access Data
Services runs
within its own
239
Performance counter
Apply to object
Notes
w2wp process,
and it will be
obvious which
w2wp process
this is as it will be
getting the bulk
of the CPU time.
Avg. Disk Queue Length
PhysicalDisk(_Total)
% Processor Time
Process(ReportingServicesService) Reports are
handled by SQL
Server Reporting
Services. If too
many reports are
being run, or if
the reports are
very complex,
then the CPU
and Private
Bytes for this
process will be
high.
Private Bytes
Process(w3wp)
Private Bytes
Process(ReportingSrevicesService) Reports are
handled by SQL
240
Watch for too
much disk writing
because of
logging.
Serviços do
Access caches
the results of
queries in
memory, until the
user’s session
expires (the timeout for which is
configurable). If
a large amount
of data is being
processed
through the
Access Data
Services,
memory
consumption for
the Access Data
Services’ w3wp
will increase.
Performance counter
Apply to object
Notes
Server Reporting
Services. If too
many reports are
being run, or
reports are very
complex, the
CPU and Private
Bytes for this
process will be
high.
Database servers
The following table shows performance counters and processes to monitor for database
servers in your farm.
Performance counter
Apply to object
Notes
% Processor Time
Processor(_Total)
Shows the
percentage of
elapsed time that
this thread used
the processor to
execute
instructions.
% Processor Time
Process(sqlservr)
Average values
larger than 80
percent indicate
that processor
capacity on the
database server
is insufficient.
Private Bytes
Process(sqlservr)
Shows the
average amount
of memory being
consumed by
SQL Server.
Avg. Disk Queue Length
PhysicalDisk(_Total)
Shows the
average disk
queue length; the
database
requests waiting
to be committed
to disk. This is
often a good
indicator that the
241
Performance counter
Apply to object
Notes
instance of SQL
Server is
becoming
overloaded, and
that possibly
additional disk
spindles would
help distribute
the load.
Troubleshooting
The following table lists some common bottlenecks and describes their causes and
possible resolutions.
Bottleneck
Cause
Resolution
Access Data
Services CPU
Serviços do Access Increase the number of CPUs or cores, or
depends on a large both, in the existing Access Data Services
computers. Add additional Access Data
amount of
Services computers if possible.
processing in the
application server
tier. If a 1x1, 1x2, or
1x3 configuration is
used, the first
bottleneck
encountered will
likely be the CPU on
the Access Data
Services servers.
Web server CPU
usage
When a Web server This issue can be resolved in one of two ways.
is overloaded with You can add more Web servers to the farm to
user requests,
distribute user load, or you can scale up the
average CPU usage Web server or servers by adding higher-speed
will approach 100
processors.
percent. This
prevents the Web
server from
responding to
requests quickly and
can cause timeouts
and error messages
on client computers.
Database server
disk I/O
When the number of Distributing data files across multiple physical
I/O requests to a
drives allows for parallel I/O. The blog
242
Bottleneck
Cause
Resolution
hard disk exceeds SharePoint Disk Allocation and Disk I/O
(http://go.microsoft.com/fwlink/?LinkId=129557)
the disk’s I/O
contains useful information about resolving
capacity, the
disk I/O issues.
requests will be
queued. As a result,
the time to complete
each request
increases.
Reporting Services The Reporting
CPU utilization
Services process is
using a large share
of the CPU
resources.
Dedicate a computer to Reporting Services,
taking load from the application server (Access
Data Services) tier (connected mode) or the
front-end Web server tier (local mode).
243
Estimate performance and capacity
requirements for Excel Services in
SharePoint Server 2010 (em inglês)
This article describes the effects of using Serviços 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.
Observação:
It is important to be aware that the specific capacity and performance figures presented in
this article will differ from the figures in real-world environments. The figures presented
are intended to provide a starting point for the design of an appropriately scaled
environment. After you have completed your initial system design, test the configuration
to determine whether the system will support the needs of your environment.
In this article:
 Test farm characteristics

Test Results
 Recommendations
For general information about how to plan and run your capacity planning for SharePoint
Server 2010, see Capacity management and sizing for SharePoint Server 2010 (em
inglês).
Test farm characteristics
This section describes the dataset, workloads, hardware settings, topology, and test
definitions that were used during the performance and capacity testing of Serviços do
Excel.
Dataset
Serviços 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:
244
Workbook Characteristics
Small
Large
Very
Large
Sheets
1-3
1-5
1-20
Columns
10-20
10-500
101,000
Rows
10-40
10-10,000
10030,000
Calculated Cells
0-20%
0-70%
0-70%
Number of Formats
1-10
1-15
1-20
Tables
0-1
0-2
0-5
Charts
0-1
0-4
0-4
Workbook Uses External Data
0%
20%
50%
Workbook Uses a Pivot Table
0%
3%
3%
Workbook Uses Conditional
Formats
0%
10%
20%
This test farm included 2,000 SharePoint Server sites. Each site contained one small,
one large, and one very large workbook. The distribution of the workbooks on the
SharePoint Server pages was 10% small workbooks and 90% large and very large
workbooks. Additionally, the test farm dataset included SharePoint Server pages that
contained 1-5 Excel Web Parts.
Workload
To simulate application usage, workloads were created to perform one or more of the
following operations:
Action Mix
Small Workbook
Large Workbook
View
50%
70%
Edit
35%
15%
Collaborative Viewing
10%
10%
Collaborative Editing
5%
5%
In addition, 17% of all the workbooks included external data. For large and very large
workbooks that included external data, refreshes were performed 80% of the time; small
workbooks do not include external data.
Each workload includes think time between user actions of 10 seconds. Think time refers
to user action delays that simulate how long a user might take to perform the actions.
245
This differs from other SharePoint Server 2010 capacity planning documents. Serviços
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, Serviços de Cálculo 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 Serviços de
Cálculo 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 Serviços de Cálculo
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
246
three application servers for Serviços do Excel and Serviços de Cálculo 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
Serviços de Cálculo 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 Serviços de Cálculo 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 Serviços de Cálculo do Excel and Web front-end
servers for the scale-up tests, and then varied the number of processors and available
memory in the Serviços de Cálculo do Excel computers.
Serviços de Cálculo 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 Serviços de Cálculo 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 Serviços 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 Serviços 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
Serviços de Cálculo do Excel computers to the farm. These throughput numbers are
specifically for the Serviços de Cálculo do Excel computers, and do not reflect the effect
on the overall farm.
247
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
248
Recommended Results
The following chart shows our results for recommended sustainable throughput.
249
The previous chart shows that there is overhead associated with adding Web front-end
computers to the farm. However, this is offset as Serviços de Cálculo do Excel computers
are added. A single Web front-end became the bottleneck after adding two additional
Serviços de Cálculo do Excel computers. This Web front-end bottleneck reversed any
benefit that was gained from the additional capacity of adding a second and third
Serviços de Cálculo do Excel computer. Also notice that three Web front-end computers
250
did not add any more throughput, as Serviços de Cálculo 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 Serviços de Cálculo do Excel computers, the CPU load is reaching
the maximum seen for a single Web front-end computer. This implies that adding another
Serviços de Cálculo 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.
251
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 Serviços de Cálculo 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 Serviços de Cálculo do Excel is the limiting
factor after the second Web front-end computer is added.
252
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 Serviços de Cálculo 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
253
1x3
2x1
2x2
2x3
3x1
3x2
3x3
Overall
1x1
1x2
1x3
Client Successful
RPS
30.56
34.55 31.67 26.03 45.94 68.37 20.71 38.82 63.70
Client Response
Time (sec.)
0.22
0.18 0.19 0.16 0.19 0.20 0.15 0.15 0.17
TPS
1.58
1.77 1.61 1.40 2.38 3.54 1.08 2.03 3.25
1x3
2x1
2x2
2x1
2x3
2x2
2x3
3x1
3x2
3x1 3x2
3x3
Web Front-end Tier
1x1
1x2
3x3
% CPU (average
over all Web Frontend computers
33.73
37.64 33.84 14.61 23.95 36.90 7.54 13.12 21.75
Serviços 1x1
de
Cálculo
do Excel
Tier
1x2
1x3
2x1
2x2
2x3
3x1
3x2
3x3
% CPU 30.56
(average
over all
Serviços
de
Cálculo
do Excel
computer
s)
34.55
31.67
26.03
45.94
68.37
20.71
38.82
63.70
Peak
5.94E+0 5.82E+0 5.79E+0 5.87E+0 6.09E+0 5.92E+0 5.79E+0 5.91E+0 5.85E+0
Private 9
9
9
9
9
9
9
9
9
Bytes
(maximu
m over all
Serviços
de
Cálculo
do Excel
computer
s)
Maximum Results
The following tables show the maximum results of our tests.
254
Overall
1x1
1x2
Client Successful
RPS
37.85
56.70 51.17 35.19 62.04 81.31 27.79 51.62 82.58
Client Response
Time (sec.)
0.19
0.28 0.23 0.16 0.20 0.25 0.16 0.16 0.22
TPS
1.92
2.96 2.59 1.81 3.21 4.60 1.41 2.72 4.30
Web Front-end Tier
1x1
1x2
% CPU (average
41.08
over all Web Frontend computers
1x3
1x3
2x1
2x1
2x2
2x2
2x3
2x3
3x1
3x1
3x2
3x2
3x3
3x3
67.78 58.59 19.44 34.11 45.97 10.19 17.79 28.69
Serviços 1x1
de
Cálculo
do Excel
Tier
1x2
1x3
% CPU 24.99
(average
over all
Serviços
de
Cálculo
do Excel
computer
s)
18…44 10.96
2x1
2x2
2x3
3x1
3x2
3x3
23.57
20.56
17.77
18.97
17.04
18.10
Peak
5.91E+ 5.85E+ 5.91E+ 5.88E+ 5.99E+ 6.502E+ 5.94E+ 5.94E+ 6.04E+
Private 09
09
09
09
09
09
09
09
09
Bytes
(maximu
m over
all
Serviços
de
Cálculo
do Excel
computer
s)
255
Scale Up Test results
We also measured the effect of adding CPUs and memory to the Serviços de Cálculo 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.
256
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 Serviços 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 Serviços de
Cálculo do Excel computer can support.
Recommendations
This section provides general performance and capacity recommendations for hardware,
Serviços do Excel settings, common bottlenecks and troubleshooting.
Note that Serviços 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.
257
Hardware Recommendations
Serviços 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
Serviços de Cálculo do Excel tier. Note that one of the first bottlenecks an Serviços de
Cálculo 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 Serviços do Excel scenario:
 To provide for more user load, check the CPU and memory for the existing Serviços
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 Serviços de Cálculo do Excel computers may be necessary.
Add additional Serviços de Cálculo 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. Serviços 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 user’s session.
Performance-Related Serviços do Excel Settings
One of the ways to control the performance characteristics of Serviços 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 Serviços do Excel > Global Settings:
 Maximum Private Bytes — By default, Serviços de Cálculo 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 Serviços de Cálculo 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 — Serviços de Cálculo do Excel will cache unused
objects (for example, read-only workbooks for which all sessions have timed out) in
memory. By default, Serviços de Cálculo 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 Serviços de Cálculo
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.
258

Maximum Unused Object Age — By default, Serviços de Cálculo do Excel will keep
objects in the memory cache as long as possible. To reduce the Serviços de Cálculo
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 Serviços 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, Serviços de Cálculo 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 Serviços de Cálculo do Excel tier
computers. However, there may be users in your organization that need these settings to
be increased for Serviços de Cálculo 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, Serviços de Cálculo 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 — Serviços de Cálculo do Excel can draw on external data
sources. However, the time that is required to draw upon the external source can be
significant, with potentially a large amount of data returned. If external data is
allowed, there are several additional settings that can help throttle the effect of this
feature.
Common bottlenecks and their causes
During performance testing, several different common bottlenecks were revealed.
Bottlenecks are defined as a state in which the capacity of a particular component of a
farm is reached. This causes a plateau or decrease in farm throughput.
The following table lists some common bottlenecks and describes their causes and
possible resolutions.
Troubleshooting performance and scalability
Bottleneck
Cause
Resolution
Serviços de Cálculo do Excel
Memory
Scale Up with
Serviços do Excel holds each
more memory in
workbook in memory throughout
the user's session. A large number the Serviços de
259
Bottleneck
Cause
Resolution
of workbooks, or large workbooks,
can cause Serviços de Cálculo do
Excel to consume all available
memory causing the actually
consumed "Private Bytes" to
exceed "Maximum Private Bytes."
Cálculo do Excel
tier computers, or
Scale Out with
the addition of
more Serviços de
Cálculo do Excel
computers. The
choice will partly
depend on if
CPU is also
reaching a
maximum.
Serviços de Cálculo do Excel CPU Serviços 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
Serviços de
Cálculo do Excel
computers, or
add Serviços de
Cálculo do Excel
computers.
Web server CPU usage
This issue can be
resolved in one
of two ways. You
can add Web
servers to the
farm to distribute
user load, or you
can scale up the
Web server or
servers by
adding faster
processors.
When a Web server is overloaded
with user requests, average CPU
usage will approach 100 percent.
This prevents the Web server from
responding to requests quickly and
can cause timeouts and error
messages on client computers.
Performance monitoring
To help you determine when you have to scale up or scale out the system, use
performance counters to monitor the health of the system. Use the information in the
following tables to determine which performance counters to monitor, and to which
process the performance counters should be applied.
Front-end Web server
The following table shows performance counters and processes to monitor for front-end
Web servers in your farm.
260
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.
Serviços de Cálculo do Excel
The following table shows performance counters and processes to monitor for application
servers, or in this case Serviços de Cálculo do Excel, within your farm.
Performance Counter
Apply to object
Notes
% Processor Time
Processor (_Total)
Shows the
percentage of
elapsed time that
all threads on the
server that used
the processor to
execute
instructions.
% Processor Time
Processor (w3wp)
The Serviços de
Cálculo do Excel
261
Performance Counter
Apply to object
Notes
runs within its
own w3wp
process, and it
will be obvious
which w3wp
process this is as
it will be getting
the bulk of the
CPU time.
Average Disk Queue Length
PhysicalDisk(_Total)
Watch for too
much disk writing
because of
logging.
Private Bytes
Process(w3wp)
Serviços 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
Serviços de
Cálculo do Excel,
memory
consumption for
the Serviços de
Cálculo do Excel
w3wp will
increase.
SQL Server
As we have previously described, Serviços do Excel is light on the SQL Server tier, as
workbooks are read once into memory on the Serviços de Cálculo do Excel tier during
the user's session. Follow general SharePoint Server guidelines for monitoring and
troubleshooting of the SQL Server tier.
262
Estimar os requisitos de desempenho e
capacidade dos Serviços
PerformancePoint
Este artigo descreve o efeito que o uso do Serviços PerformancePoint tem sobre
topologias que executam o Microsoft SharePoint Server 2010.
Observação:
É importante estar ciente de que os números específicos relativos à capacidade e ao
desempenho apresentados neste artigo serão diferentes daqueles usados em ambientes
reais. Os números aqui apresentados têm por objetivo fornecer um ponto de partida para
o design de um ambiente dimensionado adequadamente. Depois de concluído o design
inicial do sistema, teste a configuração para determinar se o sistema dará suporte aos
fatores do seu ambiente.
Neste artigo:
 Características do farm de teste

Resultados do teste
 Recomendações
Para obter informações 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 inglês).
Características 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 Serviços PerformancePoint e que continha um painel de médio porte
único. O painel continha dois filtros vinculados a um scorecard, dois gráficos 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
Descrição
Tamanho
Filtro Um
Filtro de seleção de membros
7 membros da
dimensão
263
Nome
Descrição
Tamanho
Filtro Dois
Filtro de seleção de membros
20 membros da
dimensão
Scorecard
Scorecard
15 linhas de
membros da
dimensão por 4
colunas (2 KPIs)
Gráfico Um
Gráfico de linhas
3 séries por 12
colunas
Gráfico Dois
Gráfico de barras empilhadas
37 séries por 3
colunas
Grade
Grade analítica
5 linhas por 3
colunas
O painel médio usou o modelo de Cabeçalho e Duas Colunas, e os tamanhos de itens
do painel foram definidos como dimensionamento automático ou como uma
porcentagem específica do painel. Cada item do painel foi renderizado com uma altura e
uma largura aleatórias entre 400 e 500 pixels para simular as diferenças nos tamanhos
de janelas de navegadores da Web. É importante alterar a altura e a largura de cada
item do painel porque gráficos são renderizados com base nos tamanhos de janelas dos
navegadores da Web.
Cenários e processos de teste
Esta seção define os cenários de teste e aborda os processos de teste que foram
usados para cada cenário. Informações detalhadas, como resultados de teste e
parâmetros específicos, são fornecidas nas seções "Resultados de teste", mais adiante
neste artigo.
Nome do teste
Descrição do teste
Renderize um painel e altere aleatoriamente 1. Renderize o painel.
um dos dois filtros cinco vezes, com 15
2. Selecione um dos dois filtros, selecione
segundos de pausa entre as interações.
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 aleatório.
Renderize um painel, selecione um gráfico e 1. Renderize o painel.
expanda e recolha-o cinco vezes com uma 2. Selecione um membro aleatório em um
pausa de 15 segundos entre interações.
264
Nome do teste
Descrição do teste
gráfico e expanda-o.
3. Selecione outro membro aleatório no
gráfico e recolha-o.
4. Selecione outro membro aleatório no
gráfico e expanda-o.
5. Selecione outro membro aleatório no
gráfico e recolha-o.
Renderize um painel, selecione uma grade 1. Renderize o painel. Selecione um
e expanda e recolha-a cinco vezes com
membro aleatório em uma grade e
uma pausa de 15 segundos entre
expanda o membro.
interações.
2. Selecione outro membro aleatório na
grade e expanda-o.
3. Selecione outro membro aleatório na
grade e recolha-o.
4. Selecione outro membro aleatório na
grade e expanda-o.
Uma única combinação de testes foi usada com as seguintes porcentagens de testes
iniciados.
Nome do teste
Combinação de testes
Renderize um painel e altere aleatoriamente 80%
um dos dois filtros cinco vezes.
Renderize um painel, selecione um gráfico e 10%
expanda e recolha-o cinco vezes.
Renderize um painel, selecione uma grade 10%
e expanda e recolha-a cinco vezes.
As ferramentas de Teste de Carga do Microsoft Visual Studio 2008 foram usadas para
criar um conjunto de testes da Web e testes de carga que simularam os usuários
alterando filtros aleatoriamente e navegando em grades e gráficos. Os testes usados
neste artigo continham uma distribuição normal de pausas de 15 segundos entre
interações, também conhecidas como "momentos de reflexão", e um momento de
reflexão entre iterações de teste de 15 segundos. A carga foi aplicada para produzir um
tempo de resposta médio de dois segundos para renderizar um scorecard ou um
relatório. O tempo médio de resposta foi medido durante um período de 15 minutos após
um tempo de aquecimento inicial de dez minutos.
265
Cada nova iteração de teste seleciona uma conta de usuário diferente de um pool de
cinco mil contas e um endereço IP aleatório (usando a Troca de IP do Visual Studio) de
um pool de aproximadamente 2.200 endereços.
A combinação de testes foi executada duas vezes para o mesmo painel de porte médio.
Na primeira execução, a autenticação da fonte de dados foi configurada para usar a
Conta de Serviço sem Supervisão, que usa uma conta comum para solicitar os dados.
Os resultados de dados são idênticos para vários usuários, e o Serviços
PerformancePoint pode usar um cache para melhorar o desempenho. Na segunda
execução, a autenticação da fonte de dados foi configurada para usar a identidade por
usuário, e o cubo do SQL Server Analysis Services foi configurado para usar a
segurança dinâmica. Nessa configuração, o Serviços PerformancePoint usa a identidade
do usuário para solicitar os dados. Como os resultados de dados podem ser diferentes,
nenhum cache pode ser compartilhado entre os usuários. Em alguns casos, o cache
para a identidade por usuário pode ser compartilhado quando a segurança dinâmica do
Analysis Services não está configurada e as funções do Analysis Services, às quais os
usuários e grupos do Microsoft Windows estão atribuídos, são idênticas.
Configuração e topologia de hardware
Hardware de laboratório
Para fornecer um alto nível de detalhes para o resultado do teste, várias configurações
de farm foram usadas para teste. As configurações do farm abrangeram de um a três
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 instalação
corporativa padrão do SharePoint Server 2010.
A tabela a seguir lista o hardware específico que foi usado para teste.
Servidor Web
Servidor Computador Computador
de
executando executando
aplicativos o SQL
o Analysis
Server
Services
Processador(es)
2px4c a 2.66 GHz
2px4c a 2px4c a
2.66 GHz 2.66 GHz
4px6c a 2.4
GHz
RAM
16 GB
32 GB
64 GB
Sistema operacional
Windows Server 2008 R2 Windows Windows
Enterprise
Server
Server
2008 R2 2008 R2
Enterprise Enterprise
NIC
1x1 gigabit
1x1
gigabit
Autenticação
NTLM e Kerberos
NTLM e NTLM e
Kerberos Kerberos
16 GB
Windows
Server
2008 R2
Enterprise
1x1 gigabit 1x1 gigabit
NTLM e
Kerberos
Depois que o farm foi dimensionado para vários servidores Web, um balanceador de
carga de hardware foi usado para balancear a carga de usuários entre vários servidores
266
Web por meio do uso de afinidade do endereço de origem. A afinidade do endereço de
origem registra o endereço IP de origem de solicitações recebidas e o host do serviço
para o qual elas tiveram a carga balanceada e encaminha todas as futuras transações
para o mesmo host.
Topologia
A topologia inicial consistia em dois servidores físicos, 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 número de servidores Web dedicados é listado
primeiro, seguido por servidores de aplicativos dedicados e, em seguida, por servidores
de banco de dados.
Os servidores Web também são conhecidos como WFE (front-ends da web) mais
adiante neste documento. A carga foi aplicada até a identificação 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 configuração da autenticação da
fonte de dados da Conta de Serviço sem Supervisão ou da Identidade por usuário com
segurança de cubo dinâmica.
Resultados do teste
Os resultados do teste contêm três medidas importantes para ajudar a definir a
capacidade do Serviços PerformancePoint.
Medida
Descrição
Contagem de usuários
Contagem total de usuários informada pelo Visual Studio.
SPS (solicitações por
segundo)
SPS total informado pelo Visual Studio, o que inclui todas as
solicitações e um arquivo estático de solicitações, como
imagens e folhas de estilo.
EPS (exibições por
segundo)
Total de exibições que o Serviços PerformancePoint pode
renderizar. Uma exibição é qualquer filtro, scorecard, grade
ou gráfico renderizado pelo Serviços PerformancePoint ou
qualquer solicitação da Web para a URL do serviço de
renderização que contém o RenderWebPartContent ou o
CreateReportHtml. Para saber mais sobre o
CreateReportHtml e o RenderWebPartContent, consulte
a especificação do protocolo RenderingService do
PerformancePoint Services
(http://go.microsoft.com/fwlink/?linkid=200609&clcid=0x416).
Os logs do IIS podem ser analisados para essas
solicitações a fim de ajudar a planejar a capacidade do
Serviços PerformancePoint. Além disso, o uso dessa
medida fornece um número que é muito menos dependente
da composição do painel. Um painel com duas exibições
pode ser comparado a um painel com dez exibições.
267
Dica:
Quando você está usando uma fonte de dados configurada para usar a autenticação da
Conta de Serviço sem Supervisão, a regra para o índice de servidores dedicados é um
servidor Web para cada dois servidores de aplicativos que executam o Serviços
PerformancePoint.
Dica:
Quando você está usando uma fonte de dados configurada para usar a autenticação por
usuário, a regra para o índice de servidores dedicados é um servidor Web para cada
quatro ou mais servidores de aplicativos que executam o Serviços PerformancePoint.
Em topologias maiores do que quatro servidores de aplicativos, é provável 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 vários servidores. Qualquer atraso no
tempo de consulta no servidor do Analysis Services aumentará significativamente o
tempo médio de resposta do Serviços PerformancePoint para além do limite desejado de
dois segundos.
As tabelas a seguir mostram um resumo dos resultados de teste para a autenticação da
Conta de Serviço sem Supervisão e para a autenticação por usuário, quando se
expande de dois para sete servidores. Os resultados detalhados que incluem contadores
de desempenho adicionais são incluídos mais adiante neste documento.
Resumo da autenticação da Conta de Serviço sem Supervisão
Topologia (WFE x APP x SQL)
Usuários
SPS
EPS
(solicitações (exibições
por segundo) por seg)
2C (1x0x1)
360
83
50
3C (1x1x1)
540
127
75
4C (1x2x1)
840
196
117
5C (1x3x1)
950
215
129
6C (2x3x1)
1.250
292
175
7C (2x4x1)
1.500
346
205
Resumo da autenticação por usuário
268
Topologia (WFE x APP x SQL)
Usuários
SPS
EPS
(solicitações (exibições
por segundo) por seg)
2C (1x0x1)
200
47
27
3C (1x1x1)
240
56
33
4C (1x2x1)
300
67
40
5C (1x3x1)
325
74
44
Topologias 2C e 3C
Para ajudar a explicar o custo de hardware por transação e a curva do tempo de
resposta, os testes de carga foram executados com quatro cargas de usuário crescentes
até a carga máxima de usuários para as topologias 2C e 3C.
Autenticação da Conta de Serviço sem Supervisão
Contagem de usuários
50
150
250
Média de CPU WFE/APP
19,20%
57,70%
94,00% 96,70%
SPS
18
53
83
83
Exibições por segundo
10,73
31,72
49,27
49,67
Tempo médio de resposta
(seg)
0,12
0,15
0,38
2
269
360
Autenticação por usuário
Contagem de usuários
50
100
150
Média de CPU WFE/APP
30,80%
61,30%
86,50% 93,30%
SPS
17
32
43
47
Exibições por segundo
10,3
19,32
26,04
27,75
Tempo médio de resposta
(seg)
0,28
0,45
0,81
2
270
200
Resultados do farm 3C (1x1x1)
Autenticação da Conta de Serviço sem Supervisão
Contagem de usuários
100
250
400 540
SPS
36
87
124 127
Exibições por segundo
21
52
74
Tempo médio de resposta (seg) 0,12
0,18
0,65 2
11%
28%
43% 46%
1,4 GB
2
2,4
GB GB
62%
94% 95%
10,8 GB
14,1 14,6
GB GB
Média de CPU WFE
Máximo de bytes privados WFE 0,7 GB
do processo de trabalho W3WP
do IIS (Serviços de Informações
da Internet) do SharePoint
Server.
Média de CPU APP
25%
Máximo de bytes privados APP 5,9 GB
do W3WP do Serviços
271
75
100
250
400 540
Contagem de usuários
50
120
180 240
SPS
17
39
52
56
Exibições por segundo
10
23
31
33
0,48
0,91 2
12%
17% 19%
1,3 GB
1,6 1,9
GB GB
57%
81% 81%
Contagem de usuários
PerformancePoint
Autenticação por usuário
Tempo médio de resposta (seg) 0,28
Média de CPU WFE
5%
Máximo de bytes privados WFE 0,78 GB
do W3WP do SharePoint
Server
Média de CPU APP
25%
272
Contagem de usuários
50
Máximo de bytes privados APP 19 GB
do W3WP do Serviços
PerformancePoint
120
180 240
20,1 GB
20,5 20,9
GB GB
Resultados para mais de 4C com
autenticação da Conta de Serviço sem
Supervisão
Começando com a topologia de 4C, a carga foi aplicada para produzir um tempo de
resposta médio de dois segundos para renderizar um scorecard ou um relatório. 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 combinação de testes foi
executada novamente. Esta lógica foi repetida até alcançar um total de sete servidores.
273
4C (1x2x1)
5C (1x3x1)
6C
7C
(2x3x1) (2x4x1)
Contagem de usuários
840
950
1.250 1.500
SPS
196
216
292
346
Exibições por segundo
117
131
175
206
Média de CPU WFE
77%
63%
54%
73%
Máximo de bytes privados
WFE do W3WP do
SharePoint Server
2,1 GB
1,7 GB
2,1
GB
2 GB
Média de CPU APP
83%
94%
88%
80%
Máximo de bytes privados
APP do W3WP do Serviços
PerformancePoint
16 GB
12 GB
15 GB 15 GB
Resultados para mais de 4C com
autenticação por usuário
Os mesmos testes foram repetidos para uma fonte de dados configurada para
autenticação por usuário. Observe que adicionar um servidor de aplicativos para criar
uma topologia de quatro servidores de aplicativos não aumentou o número de usuários
ou solicitações por segundo para o qual havia suporte do Serviços PerformancePoint por
causa dos atrasos de consulta que o Analysis Services produziu.
3C (1x1x1)
4C (1x2x1)
5C
6C
(1x3x1) (1x4x1)
Contagem de usuários
240
300
325
325
RPS
56
67
74
74
Exibições por segundo
33
40
44
45
Média de CPU WFE
19%
24%
26%
12%
Máximo de bytes privados
WFE do W3WP do
SharePoint Server
2,1 GB
1,9 GB
1,9
GB
1,5
GB
Média de CPU APP
89%
68%
53%
53%
Máximo de bytes privados
APP do W3WP do Serviços
PerformancePoint
20 GB
20 GB
20 GB 20 GB
274
CPU do Analysis Services
3C (1x1x1)
4C (1x2x1)
5C
6C
(1x3x1) (1x4x1)
17%
44%
57%
68%
Recomendações
Recomendações de hardware
Os contadores de memória e processador das tabelas de teste devem ser usados para
determinar os requisitos de hardware para uma instalação do Serviços
PerformancePoint. Para servidores Web, o Serviços 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 Serviços
PerformancePoint consome uma grande quantidade de memória. Isso acontece quando
as fontes de dados são configuradas para a autenticação por usuário ou quando o
servidor de aplicativos executa vários painéis com longos tempos limites da fonte de
dados.
O servidor de banco de dados não se tornou um afunilamento nos testes e alcançou o
máximo de uso de CPU de 31% no painel 7C autenticado pela Conta de Serviço sem
275
Supervisão. As definições de conteúdo do Serviços PerformancePoint, como relatórios,
scorecards e KPIs, são armazenadas em listas do SharePoint e são armazenadas em
cache na memória pelo Serviços PerformancePoint, reduzindo a carga no servidor de
banco de dados.
Consumo de memória
O Serviços PerformancePoint pode consumir grandes quantidades de memória em
algumas configurações, e é importante monitorar o uso de memória do pool de
aplicativos do Serviços PerformancePoint. O Serviços PerformancePoint armazena em
cache vários itens em memória, 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
padrão de dez minutos). Quando você está usando uma fonte de dados configurada
para autenticação de Conta de Serviço sem Supervisão, esses resultados de consulta
são apenas armazenados uma vez e compartilhados entre vários usuários. No entanto,
quando você usa uma fonte de dados configurada para autenticação por usuário e a
segurança do cubo dinâmico do Analysis Services, os resultados de consulta são
armazenados uma vez por usuário e por exibição (ou seja, uma combinação "por filtro").
A API do cache subjacente que o Serviços 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 também é conhecido como corte) com base em limites de
memória, para evitar erros de falta de memória. O limite de memória padrão é 60% da
memória física. Depois de alcançar esses limites, o Serviços PerformancePoint ainda
renderizou exibições, mas os tempos de resposta aumentaram significativamente
durante o curto período 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 Serviços PerformancePoint pode ser usado para monitorar os
cortes de cache do ASP.NET que ocorrem por pressão da memória. Se esse contador
for maior do que zero, examine a tabela a seguir para encontrar possíveis soluções.
Problema
Solução
O uso do processador do servidor de
aplicativos é baixo e outros serviços estão
em execução no servidor de aplicativos.
Adicione mais memória física ou limite a
memória do cache ASP.NET.
O uso do processador do servidor de
aplicativos é baixo e apenas o Serviços
PerformancePoint está em execução no
servidor de aplicativos.
Se aceitável, configure as definições de
cache do ASP.NET para que o cache use
mais memória ou adicione mais memória.
O uso do processador do servidor de
aplicativos é alta.
Adicione outro servidor de aplicativos.
Uma fonte de dados configurada para usar a autenticação por usuário pode compartilhar
resultados de consulta e entradas de cache quando os conjuntos de associação de
funções do Analysis Services dos usuários são idênticos e quando a segurança do cubo
dinâmico não está configurada. Esse é um novo recurso do Serviços PerformancePoint
no Microsoft SharePoint Server 2010. Por exemplo, se o usuário A estiver nas funções 1
276
e 2, o usuário B estiver nas funções 1 e 2 e o usuário C estiver nas funções 1, 2 e 3,
somente o usuário A e o usuário B compartilharão entradas de cache. Se houver
segurança de cubo dinâmico, os usuários A, B e C não compartilharão as entradas de
cache.
Analysis Services
Quando o Serviços PerformancePoint estava sendo testado com autenticação por
usuário, duas propriedades do Analysis Services foram alteradas para melhorar o
desempenho da produtividade para vários usuários. A tabela a seguir mostra as
propriedades que foram alteradas e um novo valor de cada propriedade.
Propriedade do Analysis Services
Valor
Memória \ HeapTypeForObjects
0
Memória \ MemoryHeapType
2
Essas duas definições de memória 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 adição de carga de usuário, 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
(exibições de gerenciamento dinâmico) do Analysis Services, que apresentaram um
aumento de tempos de consulta individuais de 10 milissegundos para 5.000
milissegundos. Esses resultados levaram à modificação das configurações de memória
acima.
É importante observar que, embora isso tenha melhorado significativamente a
produtividade, segundo a equipe do Analysis Services, a alteração dessas configurações
tem um custo pequeno, mas mensurável em consultas de um único usuário.
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 práticas
recomendadas sobre como melhorar o desempenho da produtividade para vários
usuários.
Afunilamentos comuns e suas causas
Durante o teste de desempenho, vários afunilamentos comuns foram revelados. Um
afunilamento é uma condição em que a capacidade de um elemento específico de um
farm é alcançada. Isso causa uma estabilização ou uma diminuição na produtividade do
farm. Quando a alta utilização do processador é encontrada como um afunilamento,
servidores adicionais são adicionados para resolver o afunilamento. A tabela a seguir
lista alguns afunilamentos comuns e possíveis soluções, considerando uma baixa
utilização do processador e não o afunilamento.
277
Possível
afunilamento
Causa e o que
monitorar
Desempenho
do heap de
memória do
Analysis
Services
Altere o Analysis Services para usar o heap do
Por padrão, o
Windows. Consulte a seção "Analysis Services"
Analysis
Services usa
anteriormente neste artigo e o white paper do SQL
seu próprio heap Server 2008 sobre o guia de desempenho do Analysis
de memória em Services
vez do heap do (http://go.microsoft.com/fwlink/?linkid=165486&clcid=0x4
Windows, o que 16) para obter instruções.
proporciona
baixo
desempenho de
produtividade
para vários
usuários. Analise
os tempos de
consulta do
Analysis
Services usando
DMV (exibições
de
gerenciamento
dinâmico) para
ver se os
tempos de
consulta
aumentam com
a carga dos
usuários e se a
utilização do
processador do
Analysis
Services é
baixa.
Threads de
Por padrão, o
processament Analysis
o e consulta Services limita o
do Analysis número de
Services
threads de
consulta e
processamento
para consultas.
Consultas de
execução longa
e altas cargas
de usuário
podem usar
todos os threads
Solução
Aumente o número de threads disponíveis para consulta
e processos. Consulte a seção do Analysis Services e o
white paper do SQL Server 2008 sobre o guia de
desempenho do Analysis Services
(http://go.microsoft.com/fwlink/?linkid=165486&clcid=0x4
16) para obter instruções.
278
Possível
afunilamento
Causa e o que
monitorar
Solução
disponíveis.
Monitore os
threads ociosos
e contadores de
desempenho da
fila de trabalhos
na categoria
MSAS
2008:Threads.
Memória do
servidor de
aplicativos
O Serviços
Adicione memória ou aumente os limites padrão da
PerformancePoi memória cache do ASP.NET. Consulte a seção
nt armazena em Consumo de memória anteriormente neste documento
cache o Analysis para obter informações adicionais. Além disso, consulte
Services e
as configurações de elementos do cache do ASP.NET
outros
(http://go.microsoft.com/fwlink/?linkid=200610&clcid=0x4
resultados de
16) e a postagem do blog de Thomas Marquardt sobre o
consulta da
histórico dos limites de memória cache do ASP.NET
fonte de dados (http://go.microsoft.com/fwlink/?linkid=200611&clcid=0x4
em memória
16).
pelo tempo de
vida do cache
da fonte de
dados. Esses
itens podem
consumir uma
grande
quantidade de
memória.
Monitore o
contador
Aplicativos
ASP.NET \
Cortes de API
de Cache do
pool de
aplicativos do
Serviços
PerformancePoi
nt para
determinar se as
remoções ou
cortes de cache
estão sendo
forçadas pelo
ASP.NET por
causa de baixa
memória.
279
Possível
afunilamento
Causa e o que
monitorar
Solução
Configurações O Serviços
Se necessário, altere o comportamento de limitação do
de limitação PerformancePoi WCF (Windows Communication Foundation. Consulte os
nt é
comportamentos de limitação do serviço WCF
de WCF
implementado (http://go.microsoft.com/fwlink/?linkid=200612&clcid=0x4
como um serviço 16) e a postagem do blog de Wenlong Dong sobre
limitação de solicitações do WCF e escalabilidade do
WCF. O WCF
limita o número servidor
(http://go.microsoft.com/fwlink/?linkid=200613&clcid=0x4
máximo de
16).
chamadas
simultâneas
como um
comportamento
de limitação do
serviço. Embora
consultas de
execução longa
possam atingir
esse
afunilamento,
esse é um
afunilamento
incomum.
Monitore as
chamadas
pendentes do
contador de
desempenho do
WCF / Modelo
de Serviço para
o Serviços
PerformancePoi
nt e compare-as
com o número
máximo atual de
chamadas
simultâneas.
Monitoramento de desempenho
Para ajudar você a determinar quando é necessário aumentar a escala do sistema ou
expandi-lo, use contadores de desempenho para monitorar a integridade do sistema. O
Serviços PerformancePoint é um serviço WCF do ASP.NET e pode ser monitorado com
o uso dos mesmos contadores de desempenho utilizados para monitorar qualquer outro
serviço WCF do ASP.NET. Além disso, use as informações nas tabelas a seguir para
280
determinar contadores de desempenho suplementares a serem monitorados e para qual
processo os contadores de desempenho devem ser aplicados.
Contador de
desempenho
Instância do
contador
Observações
Aplicativos ASP.NET \ Pool de
Se o valor for maior do que zero, leia "Consumo
Cortes de API de Cache aplicativos do de memória".
Serviços
PerformanceP
oint
MSAS 2008:Threads / N/A
threads ociosos do pool
de consultas
Se o valor for zero, leia a seção "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 seção
"Analysis Services" e o white paper do SQL
Server 2008 sobre o guia de desempenho do
Analysis Services
(http://go.microsoft.com/fwlink/?linkid=165486&cl
cid=0x416).
MSAS 2008:Threads / N/A
threads ociosos do pool
de processamento
Se o valor for maior do que zero, leia a seção
"Analysis Services" e o white paper do SQL
Server 2008 sobre o guia de desempenho do
Analysis Services
(http://go.microsoft.com/fwlink/?linkid=165486&cl
cid=0x416).
MSAS 2008:Threads /
tamanho da fila de
trabalhos do pool de
processamento
Se o valor for maior do que zero, leia a seção
"Analysis Services" e o white paper do SQL
Server 2008 sobre o guia de desempenho do
Analysis Services
(http://go.microsoft.com/fwlink/?linkid=165486&cl
cid=0x416).
N/A
WCF
Instância do Se o valor for maior do que zero, consulte o
CountersServiceModelS PerformanceP artigo sobre limitação de solicitações de WCF e
ervice
oint Service escalabilidade do servidor
3.0.0.0(*)\Chamadas
(http://go.microsoft.com/fwlink/?linkid=200613&cl
pendentes
cid=0x416).
Consulte também
Outros recursos
281
Plan for PerformancePoint Services (SharePoint Server 2010)
282
Capacity requirements for Web Analytics
Shared Service in SharePoint Server
2010 (em inglês)
Initial capacity testing was performed for a simulated midsized deployment of Microsoft
SharePoint Server 2010 and other applications that included 30,000 SharePoint entities.
This article describes the results of the capacity testing activities and contains guidance
on capacity management for the Web Analytics service application in SharePoint Server
2010.
In SharePoint Server 2010, the Web Analytics service application enables you to collect,
report, and analyze the usage and effectiveness of SharePoint Server 2010 sites. Web
Analytics features include reporting, Web Analytics workflow, and Web Analytics Web
Part. For more information, see Reporting and usage analysis overview.
The aspects of capacity planning that are described in this article include the following:
 Description of the architecture and topology.

Capacity planning guidelines based on the key factors such as total expected traffic
and number of SharePoint components.

Description of the other factors that affect the performance and capacity
requirements.
Before you continue to read this article, make sure that you understand key concepts
related to SharePoint Server 2010 capacity management. The resources that are listed in
this section can help you learn about frequently used terms and get an overview of the
recommended approach to capacity management. These resources can also help you
use the information that is provided in this article more effectively.
For more conceptual information about performance and capacity management, see the
following articles:
 Gerenciamento de desempenho e capacidade (SharePoint Server 2010)
 Capacity management and sizing for SharePoint Server 2010 (em inglês)
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:
283

Traffic

Search
 Inventory
SharePoint Web Analytics reports are typically aggregated for various SharePoint
entities, such as sites, site collections, and Web applications for each farm. To view an
architectural overview of the Web Analytics service application in a SharePoint
deployment, see Architectural overview later in this article.
The Web Analytics shared service requires resources primarily at the application server
and database server level. This article does not cover the Web Server layer capacity
planning, because the Web Analytics service’s capacity requirements are minimal at this
level.
This article contains the capacity requirements for several application servers and
Microsoft SQL Server based computers, according to the following criteria:
 Total expected site traffic (clicks, search queries, ratings).

Number of SharePoint components (Site, Site Collection, and Web Application) for
each farm.
Other less significant factors which can affect the capacity requirements are summarized
in Other factors later in this article.
Architectural overview
The following diagram (Figure 1) shows the flow of the site usage data from a Web
browser to the analytics databases, and then back to the Web browser as reports. The
usage data is logged to the usage files on the Web servers. The usage timer job calls the
Logging Web Service to submit the raw data from the usage files. The Logging Web
Service writes it to the staging database, where the raw data is stored for seven days
(this is not configurable). The Web Analytics components Log Batcher and User Behavior
Analyzer clean and process the raw data on the staging database. The Report
Consolidator runs one time every 24 hours. The Report Consolidator aggregates the raw
data from the staging database on various dimensions, and then writes it to the reporting
database. The aggregated data is stored in the reporting database for a default period of
25 months (this is configurable).
284
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
285
performance of the Log Batcher and User Behavior Analyzer depends primarily on the
analytics staging database. The Read and Write activities that are performed by all the
different components can cause the analytics staging database to slow down the
process. (Scaling out is available for the staging database.) The performance of the
Report Consolidator also primarily depends on the reporting database. (Scaling out of
reporting database is not supported.)
Hardware specifications and topology
This section provides detailed information about the hardware, software, topology, and
configuration of a case study environment.
Hardware
Observação:
This environment is scaled to accommodate prerelease builds of SharePoint Server 2010
and other products. Therefore, the deployed hardware has larger capacity than
necessary to serve the demand typically experienced by this environment. This hardware
is described only to provide additional context for this environment and serve as a
starting point for similar environments. It is important to conduct your own capacity
management based on your planned workload and usage characteristics. For more
information about the capacity management process, see Gerenciamento de
desempenho e capacidade (SharePoint Server 2010).
Web servers
This article does not cover the Web server layer capacity planning, because the Web
Analytic service’s capacity requirements are minimal at this level.
Application servers
The following table describes the configuration of each application server. Based on the
site traffic and the number of SharePoint components that are involved, users will need
one or more application servers.
Application server
Minimum requirement
Processors
4 quad core @ 2.33 GHz
RAM
8 GB
Operating system
Windows Server 2008, 64 bit
Size of the SharePoint drive
300 GB
Number of network adapters
1
Network adapter speed
1 GB
Authentication
NTLM
Load balancer type
SharePoint Load Balancer
286
Application server
Minimum requirement
Software version
SharePoint Server 2010 (prerelease
version)
Services running locally

Central Administration

Microsoft SharePoint Foundation
Incoming E-mail

Microsoft SharePoint Foundation Web
Application

Microsoft SharePoint Foundation
Workflow Timer Service

Search Query and Site Settings Service

SharePoint Server Search

Web Analytics Data Processing Service

Web Analytics Web Service
Database servers
The following table describes the configuration of each database server. Instances of
SQL Server were required for both the staging and reporting databases.
Database server
Minimum requirement
Processors
4 quad core @ 2.4 GHz
RAM
32 GB
Operating system
Windows Server 2008, 64-bit
Disk size
3 terabytes
Observação:
Although we used this disk size for our
capacity testing, your environment will likely
require a much larger disk size to support
Web Analytics.
Number of network adapters
1
Network adapter speed
1 GB
Authentication
NTLM
Software version
SQL Server 2008
287
Topology
The following diagram (Figure 2) shows the Web Analytics topology.
288
Figure 2. Web Analytics topology
289
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.
290
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.
291
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).
292

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.
293
Configuration
1S+R
1S1R
1S1R
2S1R
2S1R
Staging + Reporting
Staging Reporting Staging Reporting
Total sum of percentage 19
of processor time for 8
processor computer
192
5.78
100
13.4
SQL Server buffer hit
ratio
99
100
100
100
100
% Disk time
7,142
535
5.28
59.3
98.2
Disk queue length
357
28.6
0.26
2.97
4.91
Other factors
Many other factors can affect the performance of various analytics components and can
affect the capacity planning. These factors primarily affect the performance of the Report
Extractor component because they can affect the size of the data aggregated each day.
The total size of the data in the reporting database also affects the performance of the
Reporting Extractor, although this is not significant because the data is partitioned daily.
Some of these other factors are as follows:
 Number of unique queries each day.

Number of unique users each day.

Total number of unique assets clicked each day.

Existing data size in the reporting warehouse, based on the data retention in the
warehouse.
The overall effect of these factors is less significant than the total data volume and the
number of site entities. However, it is important to conduct your own capacity
management based on your planned workload and usage characteristics. For more
information about the capacity management process, see Gerenciamento de
desempenho e capacidade (SharePoint Server 2010).
Remaining issues
There are current known issues that significantly affect the current performance of the
Web Analytics service application for deployments that have a large site hierarchy, which
includes approximately 100,000 or more SharePoint components. This article might be
updated with the capacity requirements for larger site hierarchies when more information
is available.
Consulte também
Conceitos
Gerenciamento de desempenho e capacidade (SharePoint Server 2010)
Outros recursos
SharePoint 2010 Administration Toolkit (SharePoint Server 2010)
294
Estimar os requisitos de desempenho e
capacidade do Gerenciamento de
conteúdo 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 Publicação
habilitada. Este documento é específico ao SharePoint Server 2010 e as informações
abordadas não se aplicam ao SharePoint Foundation.
Este artigo aborda os seguintes cenários:
 Site de publicação na Internet - um site de presença corporativa.
Esse tipo de site é publicado na Internet e permite que usuários anônimos da
Internet localizem informações sobre uma corporação. Sites como esse contêm uma
marca, e o conteúdo é rigorosamente controlado.
 Site de publicação na intranet - site interno de notícias.
Esse tipo de site é publicado internamente, dentro de uma organização. Seu
principal uso é compartilhar informações com usuários autenticados, dentro da
organização. As informações do site podem ser gerenciadas com rigor ou, em
algumas áreas, elas podem ser menos gerenciadas.
 Wiki corporativo - um repositório de conhecimentos.
Um wiki corporativo é um site de farm único, que cresce organicamente à medida
que os colaboradores criam novas páginas e as vinculam a outras páginas, que
podem ou não existir. Os wikis corporativos geralmente são publicados no ambiente
interno de uma organização. Esse site permite que as pessoas em uma empresa ou
organização capturem e compartilhem conhecimentos, usando uma solução
integrada e aprimorada pelo ambiente do SharePoint.
Após a leitura deste documento, você compreenderá os seguintes conceitos:
 A principal métrica (taxa de transferência) que você deve maximizar para aceitar
diversas operações de leitura.

Os vários afunilamentos possíveis relevantes a uma implantação de Gerenciamento
de Conteúdo da Web do SharePoint Server 2010.

A importância do cache de saída para a maximização da taxa de transferência.
 O efeito das operações de gravação na experiência de leitura do usuário final.
Neste artigo:
 Informações sobre pré-requisitos

Detalhes e abordagem do teste

Implantações de Gerenciamento de Conteúdo da Web

O que otimizar
295

Resultados do teste e recomendações

Sobre os autores
Informações sobre pré-requisitos
Antes de ler este documento, você deve entender os principais conceitos subjacentes ao
gerenciamento de capacidade do SharePoint Server 2010. A seguinte documentação 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 informações
deste documento.
Para obter mais informações 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 técnicos de caso de desempenho e capacidade (SharePoint Server 2010)
Detalhes e abordagem do teste
Em cada teste, as variáveis que podem existir no mundo real foram resumidas para
mostrar recomendações específicas. Dessa forma, é muito importante testar e monitorar
seu próprio ambiente, para verificar se você o dimensionou corretamente para atender
ao volume de solicitações esperado. Para saber mais sobre os conceitos de
gerenciamento de capacidade, consulte Visão geral do gerenciamento da capacidade e
dimensionamento do SharePoint Server 2010.
Este artigo aborda o desempenho com os Recursos de Conjunto de Sites, a
Infraestrutura de Publicação do SharePoint Server e o Cache de saída. Esses recursos
só estão disponíveis quando a Infraestrutura de Publicação do SharePoint Server está
habilitada. Por padrão, esse recurso está habilitado nos Portais de Publicação.
Conjunto de dados
Os testes foram conduzidos com o uso de um conjunto de dados que compartilha
características comuns às implantações reais de Gerenciamento de Conteúdo da Web.
Embora o carregamento fosse constante, diferentes páginas foram solicitadas. A tabela
a seguir descreve o conjunto de dados usado para esses testes.
Conjunto de dados
Objeto
Site de publicação
Tamanho dos bancos de dados de
conteúdo
2.63 GB
Quantidade de bancos de dados de
conteúdo
1
Quantidade de conjuntos de sites
1
Quantidade de aplicativos Web
1
Quantidade de sites
50
296
Objeto
Site de publicação
Número de páginas
20.000 páginas divididas em 20 pastas com
1.000 páginas cada
Composição das páginas
Páginas de artigos em HTML básico, com
referências a duas imagens
Tamanho da página
42 KB descompactada; 12 KB compactada
Imagens
3.000 a 30 KB até 1.3 MB cada
É recomendável configurar o IIS (Serviços de Informações da Internet) para sempre
compactar arquivos, em vez da configuração padrão de compactar arquivos
dinamicamente. Quando a compactação dinâmica está habilitada, o IIS compacta
páginas até que a utilização da CPU exceda um determinado limite e, nesse ponto, o IIS
para de compactar páginas até que a utilização fique abaixo do limite. Os testes deste
artigo foram realizados com a compactação sempre ativada.
Esse conjunto de dados de teste utilizou apenas os recursos padrão do SharePoint
Server 2010, que estão incluídos no produto. Seu site provavelmente incluirá
personalizações, além desses recursos básicos. Portanto, é importante testar o
desempenho da sua própria solução.
Hardware
O número de servidores Web do farm variou em cada teste, mas todos tinham hardware
idêntico. A tabela a seguir descreve o hardware de servidor Web e de servidor de
aplicativos que foi usado durante os testes.
Especificações de hardware para servidores de aplicativos e
servidores Web
Servidor Web
Processadores
2 núcleos quádruplos a 2.33 GHz
RAM
8 GB
Sistema operacional
Windows Server 2008, 64 bits
Tamanho da unidade do SharePoint
300 GB
Quantidade de adaptadores de rede
2
Velocidade do adaptador de rede
1 gigabit
Autenticação
Básica do Windows
Tipo de balanceador de carga
Balanceamento de carga do hardware
Versão do software
SharePoint Server 2010 (versão de prélançamento)
Serviços em execução no local
Administração Central
297
Servidor Web
Email de entrada do Microsoft SharePoint
Foundation
Aplicativo Web do Microsoft SharePoint
Foundation
Serviço de Timer do Fluxo de Trabalho do
Microsoft SharePoint Foundation
A tabela a seguir descreve o hardware do servidor de banco de dados usado para esses
testes.
Especificações de hardware para servidores de banco de dados
Servidor de banco de dados
Processadores
4 núcleos quádruplos a 3.19 GHz
RAM
16 GB
Sistema operacional
Windows Server 2008, 64 bits
Armazenamento
15 discos de 300 GB a 15.000 RPM
Quantidade de adaptadores de rede
2
Velocidade do adaptador de rede
1 gigabit
Autenticação
NTLM
Versão do software
Microsoft SQL Server 2008
Glossário
Há alguns termos especializados que você encontrará neste documento. Aqui estão
alguns dos principais termos e suas definições:
 RPS Solicitações por segundo. O número de solicitações recebidas por um farm ou
servidor em um segundo. Esta é uma medida comum de carga de servidor e farm.
Observe que as solicitações diferem dos carregamentos de página; cada página
contém vários componentes, cada um deles cria uma ou mais solicitações quando a
página é carregada. Portanto, um carregamento de página cria várias solicitações.
Em geral, as verificações e os eventos de autenticação que usam recursos
insignificantes não são contados nas medições RPS.
 Zona Verde Este é o estado em que o servidor pode manter o seguinte conjunto de
critérios:

A latência no servidor para pelo menos 75% das solicitações é menor que 1
segundo.

Todos os servidores têm uma utilização de CPU menor que 50%.

A taxa de falha é menor que 0,01%.
298
Implantações de Gerenciamento de Conteúdo
da Web
Há dois modelos que baseiam a autoria de conteúdo nos sites de publicação 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 conteúdo a qualquer momento, o que leva
a distribuições variáveis de operações de leitura e gravação durante todo o dia. Esse
farm de servidores geralmente passa por incontáveis leituras e uma quantidade
moderada de gravações.
O diagrama a seguir mostra como a criação no local funciona de uma perspectiva
topológica.
No modelo implantação de conteúdo, vários conjuntos de sites, separada e
exclusivamente, oferecem suporte à criação e publicação de conteúdo. O conteúdo é
criado e atualizado no ambiente de criação e, em seguida, é implantado no ambiente de
publicação de acordo com uma agenda, para ser lido pelos visitantes. O ambiente de
publicação atende primeiramente às solicitações de leitura, exceto quando o conteúdo
está sendo implantado a partir do ambiente de criação. Diferentemente do modelo autor
no local, a carga do servidor gerada pela implantação de conteúdo pode ser ajustada
para intervalos agendados.
O diagrama a seguir mostra como a implantação de conteúdo funciona de uma
perspectiva topológica.
Esses modelos de criação de conteúdo são mutuamente exclusivos.
Embora os sites de publicação na Internet e os sites de publicação na intranet possam
usar o modelo autor no local ou o modelo de implantação de conteúdo, os wikis
corporativos funcionam melhor com o modelo autor no local. Um wiki corporativo
geralmente apresenta um volume maior de operações de gravação em relação às
operações de leitura, porque uma proporção maior de usuários pode editar páginas. As
páginas de wiki corporativo diferem das páginas de artigo de publicação e exibem
características diferentes de desempenho.
O que otimizar
Esta seção aborda as informações de otimização do ambiente de Gerenciamento de
Conteúdo da Web. A otimização do ambiente inclui saber como gerenciar taxas de
transferência, afunilamentos e armazenamentos em cache.
299
Nesta seção:
 Taxa de transferência é a métrica principal

Afunilamentos e correção

Ajuda do armazenamento em cache
Taxa de transferência é a métrica principal
Taxa de transferência e tempo de resposta são as métricas mais importantes a serem
otimizadas quando você faz o planejamento de capacidade para uma implantação de
Gerenciamento de Conteúdo da Web do SharePoint Server 2010. A taxa de
transferência é o número de operações que um farm de servidores pode executar por
segundo, medida em RPS (solicitações por segundo).
Afunilamentos e correção
Afunilamento é o recurso do sistema que, quando atingido, impede que o farm de
servidores atenda a solicitações 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.
300
Utilização da CPU do servidor Web
A CPU do servidor Web deve ser o afunilamento de uma topologia bem ajustada, pois é
o componente mais facilmente escalonável. O balanceador de carga faz o roteamento de
301
solicitações entre os servidores Web e garante que nenhum servidor seja muito mais
utilizado do que seus pares.
Embora outros usuários possam visitar o site após a total utilização da CPU do servidor
Web, o tempo de resposta do servidor é maior para esses usuários. Esse
comportamento é útil ao gerenciamento de picos no volume de solicitações. Entretanto,
uma carga constante que exceda a capacidade de um farm de servidores, com o tempo,
resultará em uma lista de pendências de solicitações grande o bastante para ultrapassar
o limite de solicitações em espera. Nesse ponto, os servidores Web aceleram as
solicitações e respondem com um erro HTTP 503. Na ilustração a seguir, o tempo de
resposta do servidor diminui após o limite de solicitações em espera ter sido atingido
porque somente erros HTTP são exibidos.
As seguintes alterações são mostradas neste diagrama:
1. O tempo de resposta aumenta à medida que a utilização da CPU do servidor Web se
aproxima dos 100%.
2. Depois que o limite de solicitações em espera é atingido, solicitações adicionais são
exibidas com erros.
Outros afunilamentos
302
Se a CPU do servidor Web não apresentar afunilamento, os próximos itens a serem
investigados para detecção de afunilamentos são a topologia do farm, a configuração do
farm ou o conteúdo das páginas em exibição. Alguns possíveis afunilamentos desses
elementos incluem o seguinte:
1. Rede Em situações de alta taxa de transferência, a rede pode ficar saturada entre o
servidor Web e o servidor de banco de dados ou entre o servidor Web e os usuários
finais. Para que isso não aconteça, é recomendável 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 adição de servidores Web ao farm de servidores não
poderá aumentar a taxa de transferência máxima aceita pelo farm. Um afunilamento
na CPU de banco de dados, mas não nas CPUs de servidores Web, pode refletir
duas situações:
a) Configurações inadequadas do cache ou páginas muito lentas,
especialmente aquelas não armazenadas no cache de saída. Isso se
caracteriza por uma alta utilização da CPU do servidor de banco de dados,
mas uma taxa de transferência baixa ou média e uma utilização baixa ou
média do servidor Web.
b) servidor de banco de dados pode ter atingido a capacidade da taxa de
transferência necessária ao farm. Isso se caracteriza por uma alta utilização
da CPU do servidor Web e do servidor de banco de dados, em uma
condição de alta taxa de transferência.
Ajuda do armazenamento em cache
O SharePoint Server 2010 usa três tipos de cache. O objetivo mais comum desses
caches é melhorar a eficiência, reduzindo as chamadas ao banco de dados para
obtenção de dados solicitados com frequência. As solicitações subsequentes de uma
página podem ser atendidas pelo cache no servidor Web, o que resulta em uma
utilização consideravelmente reduzida de recursos nos servidores Web e nos servidores
de banco de dados.
Estes são os três tipos de cache:
 Cache de saída Esse cache armazena o conteúdo de página solicitado na
memória do servidor Web. Para obter mais informações sobre o cache de saída,
consulte o artigo sobre cache de saída e perfis de cache
(http://go.microsoft.com/fwlink/?linkid=121543&clcid=0x416).

Cache de objetos Esse cache armazena objetos do SharePoint, como metadados
de item da Web e de lista, na memória do servidor Web. Para obter mais
informações sobre o cache de objetos, consulte o artigo sobre cache de objetos
(http://go.microsoft.com/fwlink/?linkid=123948&clcid=0x416).

Cache baseado em disco para BLOBs (objetos binários grandes) Esse cache
armazena arquivos de imagem, áudio e vídeo, e outros arquivos binários grandes,
no disco. Para obter mais informações sobre o cache BLOB, consulte o artigo sobre
cache baseado em disco para objetos binários grandes
(http://go.microsoft.com/fwlink/?linkid=123947&clcid=0x416).
Cada um desses caches é importante para sustentar uma taxa de transferência alta.
Entretanto, o cache de saída tem o maior efeito e é abordado em detalhes em todo este
artigo.
303
Resultados do teste e recomendações
Esta seção aborda as áreas específicas que foram testadas e inclui recomendações
resultantes desses testes.
Nesta seção:
 Efeito da habilitação do cache de saída

Usuários anônimos e usuários autenticados

Características de expansão das operações de leitura e gravação

Advertências do cache de saída

Efeito do volume de leitura na CPU e no tempo de resposta

Efeito das operações de gravação na taxa de transferência

Efeito da implantação de conteúdo

Efeito do instantâneo de banco de dados durante a exportação da implantação de
conteúdo

Características de conteúdo
Efeito da habilitação do cache de saída
O cache de saída é um recurso valioso para otimizar uma solução do SharePoint Server
2010 para muitas operações de leitura.
Nestes testes, para determinar a RPS máxima, o número de usuários ativos fazendo
solicitações no farm foi aumentado até que a utilização 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 expansão de servidores Web em diferentes
taxas de acertos do cache de saída.
Taxa de acertos do cache de saída
A taxa de acertos do cache de saída é uma medida dos acertos do cache de saída em
relação aos erros.
 Um acerto ocorre quando o cache recebe uma solicitação de dados de objeto já
armazenados no cache.

Um erro de cache ocorre quando uma solicitação é recebida para dados de objeto
não armazenados no cache. A ocorrência de um erro faz com que o cache tente
armazenar os dados de objeto solicitados, de modo que as solicitações posteriores
por esses dados resultem em um acerto de cache.
Há vários motivos que explicam por que uma solicitação de página pode resultar em um
erro de cache.
 Páginas configuradas para não usar o cache de saída.

Páginas personalizadas; por exemplo, páginas com dados específicos do usuário
atual.

Primeira navegação por chave de variação do cache de saída.
 Primeira navegação após a expiração do conteúdo armazenado em cache.
O diagrama a seguir mostra o efeito do cache de saída na taxa de transferência de pico
em farms com um a quatro servidores Web e um servidor de banco de dados.
304
Observação:
O ponto de dados de uma RPS máxima em um farm de servidores 4x1 com uma taxa de
acertos de 100% no cache de saída foi extrapolado e não foi efetivamente observado. O
volume de solicitações do farm de servidores atingiu o limite de largura de banda da
rede, ou seja, a taxa de transferência de dados alcançou 1 gigabit por segundo. Em
todos os casos, a utilização da CPU do servidor Web é de 100%.
A tabela a seguir lista os efeitos das taxas de acertos do cache de saída 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 saída em diferentes
topologias de farm
305
Taxa Medida
de
acertos
do
cache
de
saída
1x1
2x1
4x1
RPS máxima
3.463
7.331
11.032
Utilização da CPU
do SQL Server
0%
0%
0%
RPS máxima
2.137
3.945
5.937
Utilização da CPU
do SQL Server
5,93%
12,00%
21,80%
RPS máxima
1.518
2.864
4.518
Utilização da CPU
do SQL Server
7,12%
14,40%
28,00%
RPS máxima
459
913
1.596
Utilização da CPU
do SQL Server
9,86%
19,50%
42,00%
RPS máxima
172
339
638
Utilização da CPU
do SQL Server
9,53%
19,00%
36,30%
100%
95%
90%
50%
0%
Conclusões e recomendações referentes ao efeito da habilitação do
cache de saída
306
Uma taxa de acertos mais alta do cache de saída produz aumentos significativos da
RPS máxima. Por isso, é recomendável habilitar o cache de saída para otimizar a
solução de publicação do SharePoint Server 2010. É possível configurar o cache de
saída na página Configurações do Cache de Saída do conjunto de sites. Para obter mais
informações, consulte o artigo sobre definição da página de configurações do cache de
saída 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 saída estava habilitado, a primeira solicitação que
armazenou uma página no cache foi excluída, ou seja, uma determinada porcentagem
de páginas já havia sido armazenada no cache. Quando um usuário solicita pela
primeira vez uma página não armazenada em cache, essa página é 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 período curto em um ambiente, durante o
qual o cache de saída habilitado é preenchido após sua liberação. 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 situação em que haja uma taxa de acertos do cache de 0% para o rápido período
entre a reciclagem do pool de aplicativos e a próxima solicitação e armazenamento em
cache de páginas. A taxa de acertos do cache de 0% também simula um ambiente em
que o cache de saída não está habilitado.
Usuários anônimos e usuários autenticados
O teste anterior pressupõe que todas as solicitações ao site são feitas por leitores
anônimos. Entretanto, no seu site, alguns ou todos os usuários talvez sejam
autenticados. Exemplos de cenários de leitura autenticados incluem um site de
publicação de intranet corporativo e conteúdo destinado somente para membros em um
site da Internet.
Com os perfis de cache de saída, é possível especificar que o comportamento do cache
de saída para usuários autenticados seja diferente do comportamento para usuários
anônimos.
Perfis de cache
Os perfis de cache agregam configurações que podem ser aplicadas a páginas, itens
de página, tipos de conteúdo e níveis de escala em uma implantação de site. Um perfil
de cache define os seguintes tipos de comportamento de cache:
 Quanto tempo os itens devem ser mantidos no cache.

A política de filtragem de segurança.

A expiração das configurações; por exemplo, duração e alterações.

As variações de conteúdo armazenado em cache; por exemplo, com base em
permissões do usuário, direitos do usuário e outras variáveis personalizadas.
Qualquer alteração feita em um perfil de cache afeta imediatamente todo o conteúdo
aplicável no site. Você pode definir diferentes perfis de cache para usuários anônimos e
para usuários autenticados.
O perfil de cache de saída Internet Pública (Somente Anônimo) foi usado para os
usuários anônimos e o perfil Extranet (Site Publicado) foi usado para os usuários
autenticados.
307
O gráfico a seguir mostra os efeitos da taxa de transferência autenticada sobre a
utilização da CPU do servidor de banco de dados.
O modelo de autenticação era Autenticação Básica do Windows. Embora não seja
recomendável usar essa autenticação para sites da Internet, esse método de
autenticação foi selecionado para demonstrar o mínimo de sobrecarga que foi imposta
pela autenticação. O tamanho dessa sobrecarga varia de acordo com o seu mecanismo
de autenticação específico. Ao testar sua implantação, você deve considerar o efeito do
seu mecanismo de autenticação. Para obter mais informações sobre mecanismos de
autenticação compatíveis com o SharePoint Server 2010, consulte Plan authentication
methods (SharePoint Server 2010).
Conclusões e recomendações para usuários anônimos e
autenticados
Os usuários autenticados experimentam menor RPS e potencial de expansão porque o
trabalho adicional de validação de credenciais gera carga no servidor de banco de
dados. Como demonstrado nos resultados do teste, a RPS máxima observada quando
os usuários são autenticados é consideravelmente menor do que a observada em um
farm de acesso anônimo.
Características de expansão das operações de leitura e gravação
Nossos testes foram criados para registrar gravações por hora. Neste artigo, uma
gravação é definida como sendo a criação e o check-in de uma nova Página de
Publicação ou a edição e o check-in de uma Página de Publicação existente.
Para os testes a seguir, leitores foram adicionados ao sistema até que a utilização da
CPU do servidor Web atingisse cerca de 80-90% e, em seguida, as operações de
308
gravação foram executadas no ambiente usando atraso artificial. O total de gravações
por hora do teste foi de aproximadamente 500. Usamos uma taxa de acertos do cache
de saída de 90% em todos os testes. Executamos o mesmo teste em um farm 1x1, 2x1 e
4x1, e observamos a utilização da CPU do servidor Web e do SQL Server, além da taxa
de transferência geral de leitura de cada configuração. Além disso, testamos uma
configuração somente leitura anônima como uma linha de base e testamos também uma
configuração com leitores autenticados, usando a Autenticação Básica do Windows.
Embora a CPU do servidor Web tenha sido 100% utilizada durante os testes de
expansão somente leitura, mantivemos a CPU do servidor Web entre 80-90% para os
testes de expansão com gravações. Assim foi feito para deixar espaço para alguma
utilização adicional da CPU durante a execução da atividade de gravação.
O gráfico a seguir mostra a RPS geral de leitura observada durante cada teste. A RPS
de leitura é expandida linearmente à medida que mais servidores Web são adicionados,
inclusive na atividade de gravação. Entretanto, há uma perda de RPS quando as
gravações são incorporadas.
A utilização da CPU do servidor de banco de dados cresceu quando o número de
servidores Web aumentou. O gráfico a seguir mostra o padrão de crescimento da
309
utilização da CPU do SQL Server nas várias configurações. Conforme observado na
seção anterior Usuários anônimos e usuários autenticados deste artigo, a autenticação
afeta a utilização da CPU do servidor de banco de dados, e isso fica mais evidente
quando a atividade de gravação é adicionada (o que também afeta a utilização da CPU
do servidor de banco de dados).
A tendência extrapolada do uso do SQL Server demonstra que o SQL Server
apresentará afunilamento com seis servidores Web que tenham solicitações de leitura
autenticadas. Entretanto, no caso de leitura anônima, a expansão para um número maior
de servidores Web mostra-se funcional.
É importante saber que fatores adicionais em uma implantação usual afetam a carga no
servidor de banco de dados, e esses fatores são relevantes e devem ser considerados
durante o planejamento da capacidade. Para saber mais sobre como determinar uma
zona verde para uma típica utilização da CPU do servidor de banco de dados, consulte
Visão geral do gerenciamento da capacidade e dimensionamento do SharePoint Server
2010.
Conclusões e recomendações para características de expansão das
operações de leitura e gravação
310
Nossos dados mostram que a expansão do número de servidores Web será uma
estratégia eficiente para o aumento da taxa de transferência se o servidor de banco de
dados não apresentar afunilamento. Em média, o teste misto de leitura anônima e
gravações autenticadas gerou um aumento de 52% na utilização da CPU do servidor
Web em comparação com um teste misto de leitura anônima e nenhuma gravação. Além
disso, as leituras autenticadas agregam uma grande carga adicional ao SQL Server,
porque cada solicitação incorre em mais verificações de autenticação, o que exige uma
viagem de ida e volta ao SQL Server.
O gráfico a seguir mostra o efeito da taxa de transferência sobre a utilização da CPU do
servidor de banco de dados.
Advertências do cache de saída
Se a única preocupação do planejamento de capacidade fosse maximizar a RPS, estes
testes recomendariam uma taxa ideal de acertos do cache de 100%. Entretanto, pode
não ser viável nem desejável habilitar o cache de saída de algumas ou de todas as
páginas por causa dos requisitos de atualização de dados ou das restrições de memória.
311
Atualização de dados
Os dados apresentados no cache de saída talvez não tenham as atualizações feitas
recentemente no conteúdo original. Na fonte da implantação de conteúdo ou (para
autores autenticados) em um cenário de autor em produção, pode ser conveniente aos
autores ver as alterações mais recentes logo após terem atualizado o conteúdo
existente.
Em geral, isso é possibilitado pela definição da propriedade Duração no perfil do cache,
que especifica o tempo de persistência de uma página armazenada no cache de saída
antes que ela expire. Quando uma página expira, ela é removida do cache e uma
solicitação posterior resulta em um erro de cache que atualiza o conteúdo da página.
A propriedade de perfil de cache Verificar Alterações também pode ser definida,
determinando que o servidor compare o horário do armazenamento da página no cache
com o horário em que o conteúdo foi modificado pela última vez em um conjunto de
sites. Uma solicitação de página com carimbos de data/hora não correspondentes causa
a invalidação do cache para todas as páginas no conjunto de sites. Como a propriedade
Verificar Alterações afeta todas as páginas em um conjunto de sites, é recomendável
habilitar essa opção apenas quando houver uma solução de autor no local autenticado
que não seja atualizada com frequência e que seja basicamente estática. A combinação
dessa opção com uma longa duração permite que todas as páginas sejam atendidas no
cache até que uma atualização seja feita no site.
Por padrão, a propriedade Verificar Alterações não está habilitada. Isso significa que o
servidor Web exibe dados do cache de saída em resposta a solicitações de uma página
que ainda não expirou, independentemente de a página ASPX subjacente e original ter
sido ou não modificada.
Nesse teste, realizado em um farm de servidores 1x1, todas as variáveis são as mesmas
dos testes apresentados na seção Características de expansão das operações de leitura
e gravação, com exceção da propriedade Verificar Alterações. Quando a propriedade
Verificar Alterações é ativada, o cache é liberado com mais frequência, resultando em
uma taxa menor de acertos do cache de saída.
O gráfico a seguir mostra o efeito da propriedade Verificar Alterações na taxa de
transferência.
312
É recomendável evitar a propriedade Verificar Alterações do perfil de cache de saída,
exceto em casos específicos. Um site que usa o modelo autor no local e apresenta
alterações pouco frequentes no conteúdo pode se beneficiar dessa configuração para
usuários autenticados juntamente com uma longa duração de cache, mas outros tipos de
sites provavelmente terão alguma degradação da RPS.
Dependendo das suas necessidades, convém ativar o conteúdo com detecção de hora
instantaneamente ou com mais rapidez do que o permitido pelas configurações padrão.
Nesse caso, você deve diminuir a duração ou não habilitar o cache de saída.
Conclusões e recomendações para advertências do cache de saída
O cache de saída não resolve todos os problemas relacionados ao gerenciamento da
capacidade. Há algumas situações em que o cache de saída é inadequado, e você deve
considerá-las ao habilitá-lo e configurar perfis de cache de saída.
Efeito do volume de leitura na CPU e no tempo de resposta
Esse teste foi realizado em um farm 1x1 com acesso anônimo e cache de saída
habilitado.
O gráfico a seguir mostra o efeito do volume de leitura na CPU e no tempo de resposta.
313
Conclusões e recomendações para o efeito do volume de leitura na
CPU e no tempo de resposta
Como discutido na seção Afunilamentos e correção, o tempo de resposta do servidor
geralmente é constante até o servidor Web receber um volume de solicitações 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 solicitações.
Efeito das operações de gravação na taxa de transferência
A taxa de criação para operações de edição foi distribuída de maneira uniforme no
decorrer dos testes. Os valores de gravações por hora foram testados até
aproximadamente 500, pois a criação ou a edição de mais de 500 páginas por hora está
fora do intervalo de operação da maioria das implantações do SharePoint. O teste não
cobriu os processos automatizados, como a implantação de conteúdo, que foi abordada
na seção Efeito da implantação de conteúdo. Essas operações de criação e edição
podem resultar em várias operações do SQL Server. Portanto, é importante saber que
as gravações avaliadas nesses testes não estão no nível do SQL Server, mas sim,
representam o que um usuário considera como uma operação de gravação. Todos os
testes de RPS versus gravações por hora foram realizados em um farm 1x1.
Primeiro, adicionamos operações de leitura ao teste até que a CPU do servidor Web
estivesse entre 60 e 80%, para deixar um buffer para picos de tráfego, e mantivemos
esse nível médio de utilização no decorrer de todo o teste. Em seguida, introduzimos
314
gravações usando um atraso artificial para controlar o número de operações de
gravação. Entretanto, houve picos de crescimento do uso da CPU do servidor Web e do
SQL Server durante a execução das gravações. Alguns desses picos de algumas taxas
de acertos do cache excederam o limite da operação comum, conforme mostrado no
gráfico a seguir, embora a média tenha permanecido dentro do intervalo de operação
regular.
Como mostrado no gráfico anterior, há uma pequena redução na taxa de transferência à
medida que as gravações são adicionadas ao ambiente. O gráfico demonstra a alteração
na taxa de transferência entre um cenário somente leitura e as operações de leitura
durante aproximadamente 500 gravações por hora. Dois pontos de dados foram
registrados para cada taxa de acertos do cache de saída. Portanto, a relação entre os
pontos de dados não é necessariamente linear.
A redução percentual é mais pronunciada nas taxas menores de acertos do cache,
conforme mostrado no gráfico a seguir. A RPS geral de leitura continua muito
relacionada à taxa de acertos do cache, independentemente das gravações.
315
O gráfico a seguir demonstra que a utilização da CPU do servidor de banco de dados
não aumentou significativamente quando as gravações foram adicionadas ao sistema.
Observe que a escala vertical é de 0 a 10% da capacidade da CPU.
316
Carga adicional do SQL Server foi observada durante as operações de gravação, o que
era esperado. Entretanto, o maior aumento foi de 2,06%, o que é irrelevante. A utilização
média 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 número de servidores Web for expandido, tema
abordado com mais detalhes em Características de expansão das operações de leitura e
gravação.
A utilização da CPU do servidor Web também foi avaliada durante os testes. O gráfico a
seguir demonstra que o uso médio da CPU do servidor Web permaneceu na faixa de 6080% no decorrer de todos os testes, mesmo quando as gravações por hora se
aproximaram a 500.
317
Entretanto, a real utilização da CPU medida atingiu o pico quando as gravações
ocorreram, conforme mostrado no gráfico a seguir. Em geral, esses picos de CPU não
representam um problema. O objetivo da zona verde é fornecer espaço livre de CPU
para absorver alguns picos de carga de CPU. Além disso, à medida que mais servidores
Web forem adicionados, o efeito dos picos será distribuído entre esses servidores, para
que o efeito na CPU de um único servidor Web seja reduzido. Contudo, é preciso saber
que esses picos são esperados em uma implantação real; a atividade de gravação não é
distribuída de maneira uniforme, embora ela geralmente ocorra de modo intermitente.
318
Uma taxa de acertos do cache de 90% é muito baixa para uma implantação típica. A
maioria das implantações do SharePoint Server 2010, com inúmeras operações de
leitura, tem uma taxa de acertos do cache de saída de 95% ou mais.
Conclusões e recomendações para o efeito das operações de
gravação na taxa de transferência
Os dados apresentados indicam que as operações de gravação não terão um grande
efeito negativo na taxa geral de transferência do sistema para os leitores. É preciso
reconhecer que a atividade de gravação pode causar picos de uso da CPU, e você deve
planejar sua configuração típica para esperar esses picos. Uma estratégia de
redistribuição desses picos é expandir para vários servidores Web. Isso traz duas
vantagens:
 Propaga a carga de gravação para vários servidores Web, o que ameniza os picos
gerais.

Proporciona RPS de leitura maior, especialmente em altas taxas de acertos do
cache de saída.
Efeito da implantação de conteúdo
319
Uma alternativa ao modelo autor no local, que usa um único ambiente para edição e
leitura, é dividir o ambiente único em dois ambientes separados — um para criação e
outro para produção — e usar a implantação de conteúdo para copiar o conteúdo do
ambiente de criação para o ambiente de produção.
Nessa configuração, o ambiente de produção abrange desde pouca atividade de
gravação até nenhuma, exceto quando a implantação de conteúdo está importando
conteúdo. Para esses testes, foram adicionadas leituras até que a utilização da CPU do
servidor Web entrasse na faixa de 70-80%. O trabalho de implantação de conteúdo
exportou 10 sites, com 500 páginas cada um, do conjunto de sites de criação como um
pacote e importou esse pacote para o conjunto de sites de publicação. O tamanho do
pacote implantado era maior do que geralmente se observa em ambientes do mundo
real, visando estender suficientemente a duração do trabalho de implantação de
conteúdo para ver os resultados do teste. Para obter mais informações sobre as
características do conteúdo implantado, consulte a seção Conjunto de dados.
Quando a exportação foi concluída, importamos o conteúdo para um conjunto de sites
separado e avaliamos o servidor de aplicativos e a carga do SQL Server, e também a
taxa de transferência, enquanto a importação estava em andamento. O teste de
importação foi executado para várias taxas de acertos do cache de saída.
A principal observação é que a importação teve apenas um pequeno efeito na RPS
global de leitura, conforme mostrado no gráfico a seguir. Também observamos que a
importação não teve nenhum efeito significativo na utilização da CPU do servidor Web,
conforme mostrado nas tabelas a seguir, independentemente da taxa de acertos do
cache. Entretanto, houve um efeito mais perceptível na CPU do SQL Server, mostrado
no gráfico a seguir. Isso é esperado, porque o servidor de banco de dados apresenta
carga adicional durante a importação de conteúdo. O uso da CPU do SQL Server,
porém, ficou abaixo dos 12% em todas as taxas de acertos do cache testadas, mesmo
durante a importação.
320
As tabelas a seguir mostram o efeito da importação da implantação de conteúdo na
utilização da CPU do servidor Web e do servidor de banco de dados.
Efeito da importação da implantação de conteúdo na utilização 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 importação
70,93%
74,45% 69,56% 74,12% 70,95% 67,93% 63,94%
Efeito da importação da implantação de conteúdo na utilização da
CPU do servidor de banco de dados
Acerto do cache
100%
99%
321
98%
95%
90%
50%
0%
Acerto do cache
100%
99%
98%
95%
90%
50%
0%
Linha de base
1,19%
1,64% 2,01% 3,00% 3,73% 5,40% 6,82%
Com importação
6,03%
6,82% 6,97% 7,96% 8,52% 10,29% 10,56%
Conclusões e recomendações para o efeito da implantação de
conteúdo
Os resultados de nossos testes mostram que a execução de operações de implantação
de conteúdo durante as operações comuns do site não implica em uma preocupação
relevante quanto ao desempenho. Esses resultados mostram que não é estritamente
necessário implantar conteúdo durante períodos de pouco tráfego, visando minimizar o
efeito da operação no desempenho geral, e que os tempos de implantação podem ser
direcionados principalmente pelas necessidades comerciais, e não pelos requisitos de
desempenho.
Efeito do instantâneo de banco de dados durante a exportação da
implantação de conteúdo
No SharePoint Server 2010, a implantação de conteúdo pode ser configurada para criar
um instantâneo do banco de dados de conteúdo de origem antes da exportação de
conteúdo. Isso realmente protege o processo de exportação contra atividades de criação
que possam ocorrer durante a exportação. Entretanto, os instantâneos podem afetar o
desempenho de gravação do servidor de banco de dados, pois o instantâneo atua como
um multiplicador das gravações. Por exemplo, se você tiver dois instantâneos 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 instantâneo e gravará os novos dados no
banco de dados de origem. Isso significa que uma única gravação no banco de dados de
origem, na verdade, implica três gravações:
Para determinar o efeito de um instantâneo no ambiente de criação, medimos a RPS de
gravação, o tempo de resposta e a utilização da CPU dos servidores Web, do servidor
de banco de dados e do servidor de aplicativos durante uma operação de exportação
com atividade de gravação em andamento. As tabelas a seguir exibem os resultados.
Efeito dos instantâneos de banco de dados durante a implantação de
conteúdo
Métrica
4 WPH - Nenhum instantâneo
4 WPH - Com
instantâneos
RPS de gravação
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%
322
Efeito dos instantâneos de banco de dados durante a implantação de
conteúdo
Métrica
8 WPH - Nenhum instantâneo
8 WPH - Com
instantâneos
RPS de gravação
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%
Conclusões e recomendações para o efeito do instantâneo de banco
de dados durante a exportação da implantação de conteúdo
Os resultados de nossos testes mostram que não há nenhum efeito significativo em
qualquer ponto de dados avaliado com instantâneos de banco de dados. Toda a
variação registrada estava dentro da margem de erro. Isso confirma que os instantâneos
de banco de dados podem ser usados sem grandes considerações quanto ao
desempenho.
Características de conteúdo
Os testes foram realizados em um único conjunto de dados criado para responder a um
conjunto específico de questões. Seu conjunto de dados será diferente e mudará ao
longo do tempo. Esta seção investiga como as características de conteúdo; por exemplo,
o número de páginas na biblioteca de páginas e os recursos incluídos nas páginas,
podem comunicar decisões referentes ao gerenciamento de capacidade.
Número de páginas
A RPS máxima em muitos tamanhos de biblioteca de páginas foi testada. Esse teste foi
realizado em uma topologia 4x4 com cache de saída desabilitado e acesso anônimo.
Todas as páginas tinham 42 KB quando descompactadas e 12 KB quando compactadas.
A tabela a seguir mostra os resultados do teste.
Efeito da contagem de páginas da biblioteca na RPS
Número de páginas
3
1.000
20.000
RPS máxima
860
801
790
O aumento do número de páginas para 20.000 não apresentou efeito significativo na
RPS máxima.
Campos de pesquisa de múltiplos valores
Um campo de pesquisa de múltiplos valores é uma coluna, em uma lista, que faz
referência a um ou mais itens em outra lista; por exemplo, colunas que usam metadados
323
corporativos gerenciados. Esses campos geralmente são usados como palavras-chave
de pesquisa para uma página e não são necessariamente renderizados. Em alguns
casos, como nos wikis corporativos, faz sentido renderizar esses valores de campo no
conteúdo de páginas. Por exemplo, páginas podem ser arquivadas em categorias
quando são criadas (em um site de notícias, pode haver Notícias do Mundo, Interesses
Humanitários e Esportes), e a página mestra pode incluir um espaço reservado que
mostra ao usuário em qual categoria a página foi marcada.
Campos de pesquisa de múltiplos valores provocam a busca de mais dados sempre que
uma página é solicitada. Por isso, a existência de muitos campos de pesquisa de
múltiplos valores em uma página pode afetar o desempenho.
O gráfico a seguir mostra o efeito de campos de pesquisa de múltiplos valores na taxa
de transferência.
O gráfico a seguir mostra o efeito de campos de pesquisa de múltiplos valores na
utilização de recursos do farm.
324
A degradação da RPS máxima ocorre à medida que o número de campos de pesquisa
de múltiplos valores cresce devido ao efeito na rede, entre o servidor Web e o servidor
de banco de dados.
Efeito do relatório de uso
O relatório de uso é um serviço que ajuda os administradores a monitorar as estatísticas
referentes ao uso de sites. Para obter mais informações sobre o relatório de uso,
consulte Configure usage and health data collection (SharePoint Server 2010).
Testamos o efeito dos trabalhos de timer de relatório de uso sobre a RPS máxima 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
325
BD de uso
desativado
Diferença
BD de uso ativado
BD de uso
desativado
Diferença
Cache de saída ativado
3.459
3.463
4
Cache de saída desativado
629
638
9
Os resultados mostram que a habilitação do log de uso não afeta significativamente a
RPS em um cenário 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.
326
Estimate performance and capacity
planning for workflow in SharePoint
Server 2010 (em inglês)
This performance and capacity planning article provides guidance on the effect that the
use of workflow has on topologies that run Microsoft SharePoint Server 2010.
For general information about capacity planning for SharePoint Server 2010, see
Gerenciamento de desempenho e capacidade (SharePoint Server 2010).
Contents

Test farm characteristics

Test results

Recommendations

Troubleshooting
Test farm characteristics
The following sections describe the characteristics of the test farm:
 Dataset

Workload

Hardware, settings, and topology
Dataset
To get benchmarks, most tests ran on a default Team Site on a single site collection in
the farm. The manual start tests started workflows by using a list that has 8,000 items.
Workload
Testing for this scenario helps develop estimates of how different farm configurations
respond to changes to the following variables:
 Effect of the number of front-end servers on throughput for manually starting
declarative workflows across multiple computers

Effect of the number of front-end servers on throughput for automatically starting
declarative workflows on item creation across multiple computers

Effect of the number of front-end servers on throughput for completing tasks across
multiple computers
The specific capacity and performance figures presented in this article will differ from the
figures in real-world environments. The figures presented are intended to provide a
starting point for the design of an appropriately scaled environment. After you complete
the initial system design, test the configuration to determine whether it will support the
factors in your environment.
327
This section defines the test scenarios and discusses the test process that was used for
each scenario. Detailed information such as test results and specific parameters are
given in each test result section later in this article.
Test name
Test description
Throughput for starting workflows manually 1. Associate the included MOSS Approval
workflow with a list that creates one
task.
2. Populate the list with list items.
3. Call the StartWorkflow Web service
method on Workflow.asmx against the
items in the list for five minutes.
4. Calculate throughput by looking at the
number of workflows in progress.
Throughput for starting workflows
automatically when an item is created
1. Associate the included MOSS Approval
workflow with a list that creates one
task, set to automatically start when an
item is created.
2. Create items in the list for five minutes.
3. Calculate throughput by looking at the
number of workflows in progress.
Throughput for completing workflow tasks
1. Associate the included MOSS Approval
workflow with a list that creates one
task, set to automatically start when an
item is created.
2. Create items in the list.
3. Call the AlterToDo Web service method
on Workflows.asmx against the items in
the task list that was created by the
workflows that started.
4. Calculate throughput by looking at the
number of workflows completed.
Hardware, settings, and topology
Topologies that were used for these tests use a single computer for the content database
and from one to four front-end computers that have the default installation for SharePoint
Server 2010. Although the workflows that were used in these tests are not available in
Microsoft SharePoint Foundation 2010, the results can be used to estimate similar
scenarios on those deployments. The dataset that was used for these tests contains a
328
single site collection with a single site that is based on the Team Site template on a single
content database.
To provide a high level of test-result detail, several farm configurations were used for
testing. Farm configurations ranged from one to four Web servers and a single computer
that is running Microsoft SQL Server 2008. Testing was performed with one client
computer. The database server and all Web servers were 64-bit, and the client computer
was 32-bit.
The following table lists the specific hardware that was used for testing.
Web server
Database server
Processor
[email protected]
[email protected]
RAM
4 GB
16 GB
Operating system
Windows Server 2008 R2 x64
Windows Server
2003 x64
Storage
680 GB
4.2 terabyte
Number of network adapters
2
2
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
329
330
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
331
Automatically starting workflows when items are created throughput
The test in the following table shows how the addition of front-end servers affects the
throughput of starting workflows automatically when items are created. This test was run
with a user load of 150 concurrent users continuously calling the list Web service to
create new list items in a single list and no other operations on the server. The list started
as an empty list.
Topology
Approval workflow maximum RPS
1x1
13.0
2x1
25.11
3x1
32.11
4x1
32.18
The following graph shows how throughput changes. The throughput is very close to the
manual start operations. Similar to the manual start test, throughput peaks at
approximately three or four front-end servers at approximately 32 workflows per second
maximum. Adding more than three or four front-end servers will have an insignificant
effect.
Autostart workflow throughput
332
Task completion throughput
The test in the following table shows how the addition of front-end servers affects the
throughput of completing workflow tasks. The task list that was used by autostart
workflows in the previous test was the list that was used to complete tasks. This test was
run with a user load of 25 concurrent users continuously calling the AlterToDo method on
Workflow.asmx and no other operations on the server. The list started as an empty list.
Topology
Approval workflow maximum RPS
1x1
13.5
2x1
23.86
3x1
27.06
4x1
27.14
333
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
334
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
335
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.
336
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
337
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.
Observação:
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
338
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.
Observação:
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:
339

Balance Postpone Threshold and Workflow Batchsize so that batch size is small
enough or timer job frequency high enough that a timer job can be completed
before the next timer job starts in order to avoid building up too many parallel
timer job runs that cannot finish.

To avoid table locks, do not set either of the two batch size settings larger than
5,000.
Dica:
Offset the frequency of the workflow, work item, and failover timer jobs so that they are
not always executing at the same times. To get a large list that has workflows, four
minutes for the workflow timer job and six minutes for the failover worked well in our data
population scripts.
Improving scaling for task and history lists
Workflows generate many tasks and history items per instance. By default, these lists are
indexed to help with scaling, but as these lists grow, performance will always decrease.
To reduce the rate of the decrease, keep separate history and task lists for different
workflow associations, and periodically change these lists in the workflow association
settings as lists become large.
Workflow also has a daily timer job (job-workflow-autoclean) that will automatically delete
workflow instances and tasks for instances that have been finished for more than 60
days. Leave this timer job on to keep the task lists and events on the task list as clean as
possible. If data must be preserved, write the data to other lists or archive locations.
Workflow history items are not deleted by this timer job. If you have to clean these up,
this should be done with a script or manually through the list user interface.
Other considerations
Removing columns on lists causes a database operation proportional to the number of
items in the list. Removing workflow associations will remove the workflow status column
from the list. This causes a large operation on large lists. If you know that a list has
millions of items, set the workflow to No New Instance instead of removing workflows.
Troubleshooting
Bottleneck
Cause
Database contention Database locks
(locks)
prevent multiple
users from making
conflicting
modifications to a
set of data. When a
set of data is locked
by a user or
process, no other
user or process can
Resolution
To help reduce the incidence of database
locks, you can do the following:
 Distribute workflows to more document
libraries.

Scale up the database server.

Tune the database server hard disk for
read/write.
Methods exist to circumvent the database
340
Bottleneck
Cause
Resolution
change that same
set of data until the
first user or process
is complete,
changing the data
and relinquishing
the lock.
locking system in SQL Server 2005, such as
the NOLOCK parameter. However, we do not
recommend or support use of this method
because of the possibility of data corruption.
Database server
disk I/O
When the number of Distributing data files across multiple physical
I/O requests to a
drives allows for parallel I/O. The blog
hard disk exceeds SharePoint Disk Allocation and Disk I/O
the disk's I/O
(http://go.microsoft.com/fwlink/?LinkId=129557)
capacity, the
contains useful information about resolving
requests will be
disk I/O issues.
queued. As a result,
the time to complete
each request
increases.
Web server CPU
utilization
When a Web server This issue can be resolved in one of two ways.
is overloaded with You can add Web servers to the farm to
user requests,
distribute user load, or you can scale up the
average CPU
Web server or servers by adding faster
utilization will
processors.
approach 100
percent. This
prevents the Web
server from
responding to
requests quickly and
can cause timeouts
and error messages
on client computers.
Web servers
The following table shows performance counters and processes to monitor for Web
servers in a farm.
Performance counter
Apply to object
Notes
Processor time
Total
Shows the
percentage of
elapsed time that
this thread used
the processor to
execute
instructions.
341
Performance counter
Apply to object
Notes
Memory utilization
Application pool
Shows the
average
utilization of
system memory
for the
application pool.
You must
determine the
correct
application pool
to monitor.
The basic
guideline is to
determine peak
memory
utilization for a
given Web
application, and
assign that
number plus 10
to the associated
application pool.
Database servers
The following table shows performance counters and processes to monitor for database
servers in your farm.
Performance counter
Apply to object
Notes
Average disk queue length
Hard disk that contains
SharedServices.mdf
Average values
larger than 1.5
per spindle
indicate that the
write times for
that hard disk are
insufficient.
Processor time
SQL Server process
Average values
larger than 80
percent indicate
that processor
capacity on the
database server
is insufficient.
Processor time
Total
Shows the
percentage of
342
Performance counter
Apply to object
Notes
elapsed time that
this thread used
the processor to
execute
instructions.
Memory utilization
Total
Shows the
average
utilization of
system memory.
Consulte também
Outros recursos
Workflow Scalability and Performance in Windows SharePoint Services 3.0
(http://go.microsoft.com/fwlink/?LinkId=207353)
343
Planejamento e configuração 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 informações 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 são 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
pressupõe um grande entendimento do SharePoint Server e do SQL Server.
Este artigo pressupõe que você está familiarizado com os conceitos apresentados em
Capacity management and sizing for SharePoint Server 2010 (em inglês).
Processo de design e configuração do
armazenamento e da camada do banco de
dados dos Produtos SharePoint 2010
É recomendável que você divida o processo de design do armazenamento e da camada
do banco de dados nas etapas a seguir. Cada seção fornece informações detalhadas
sobre cada etapa de design, incluindo requisitos e práticas recomendadas de
armazenamento:
 Coletar requisitos de armazenamento e de espaço e E/S do SQL Server

Escolher a versão e a edição do SQL Server

Projetar a arquitetura de armazenamento com base em requisitos de capacidade e
E/S

Estimar requisitos de memória

Entender os requisitos de topologia de rede

Configurar o SQL Server

Validar e monitorar o desempenho do armazenamento e do SQL Server
344
Coletar requisitos de armazenamento e de
espaço e E/S do SQL Server
Vários fatores de arquitetura do SharePoint Server 2010 influenciam o design do
armazenamento. A quantidade usada de conteúdo, recursos e aplicativos de serviço, o
número de farms e a necessidade de disponibilidade são fatores-chave.
Antes de começar a planejar o armazenamento, você deve conhecer os bancos de
dados que o SharePoint Server 2010 pode usar.
Nesta seção:
 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 serviço 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 seção fornece
um resumo dos bancos de dados instalados com o SharePoint Server 2010. Para obter
informações detalhadas, consulte Database types and descriptions (SharePoint Server
2010) e o artigo sobre modelo de banco de dados
(http://go.microsoft.com/fwlink/?linkid=187968&clcid=0x416).
Versão e edição do produto
Bancos de dados
SharePoint Foundation 2010
Configuração
Conteúdo da Administração Central
Conteúdo (um ou mais)
Coleta de Dados de Uso e Integridade
Conectividade de Dados Corporativos
Serviço de Registro de Aplicativo (em caso
de atualização do Catálogo de Dados
Corporativos do Microsoft Office SharePoint
Server 2007)
Serviço de Configurações de Inscrição (se
habilitado por meio do Windows
PowerShell)
Bancos de dados adicionais para o
SharePoint Server 2010 Standard Edition
Aplicativo de serviço de pesquisa:

Administração de pesquisa

Rastreamento (um ou mais)
 Propriedades (uma ou mais)
Aplicativo de serviço de Perfil de Usuário:
345
Versão e edição do produto
Bancos de dados

Perfil

Sincronização
 Marcação social
Aplicativo de serviço do Web Analytics

Preparo
 Relatórios
Repositório seguro
Estado
Metadados Gerenciados
Serviços de Automação do Word
Bancos de dados adicionais para o
SharePoint Server 2010 Enterprise Edition
PerformancePoint
Bancos de dados adicionais para o Project Rascunho
Server 2010
Publicado
Arquivo morto
Relatórios
Bancos de dados adicionais para o FAST
Search Server
Administração de pesquisa
Se você estiver fazendo uma integração mais completa com o SQL Server, seu
ambiente também poderá inclui bancos de dados adicionais, como ocorre nos seguintes
cenários:
 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ê também 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 informações,
consulte o artigo sobre como planejar uma implantação do PowerPivot em um farm
do SharePoint (http://go.microsoft.com/fwlink/?linkid=186698&clcid=0x416).

O plug-in do Microsoft SQL Server 2008 Reporting Services (SSRS) pode ser usado
com qualquer ambiente dos Produtos do SharePoint 2010. Se estiver usando o plugin, planeje oferecer suporte para os dois bancos de dados do SQL Server 2008
Reporting Services e para a carga adicional necessária 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 rápida possível do subsistema de E/S.
Uma quantidade maior de discos ou matrizes mais rápidos fornecem IOPS (operações
de E/S por segundo) suficientes, embora mantendo baixa latência e enfileiramento em
todos os discos.
346
Uma baixa resposta do subsistema de E/S não pode ser compensada pela inclusão de
outros tipos de recursos, como CPU ou memória; no entanto, ela pode influenciar e
causar problemas para todo o farm. Planeje uma latência mínima antes da implantação e
monitore os sistemas existentes.
Antes de implantar um novo farm, é recomendável que você avalie o desempenho do
subsistema de E/S usando a ferramenta de parâmetro de comparação de subsistema de
disco SQLIO. Para obter detalhes, consulte o artigo sobre a ferramenta de parâmetro de
comparação de subsistema de disco SQLIO
(http://go.microsoft.com/fwlink/?linkid=105586&clcid=0x416).
Para obter informações detalhadas sobre como analisar os requisitos de IOPS do ponto
de vista do SQL Server, consulte o documento sobre como analisar características de
E/S e dimensionar sistemas de armazenamento para aplicativos de bancos de dados do
SQL Server (http://sqlcat.com/whitepapers/archive/2010/05/10/analyzing-i-ocharacteristics-and-sizing-storage-systems-for-sql-server-database-applications.aspx).
Estimar as necessidades de IOPS e armazenamento central
O armazenamento da configuração e do conteúdo e as IOPS são a camada básica que
você deve planejar em todas as implantações do SharePoint Server 2010.
Armazenamento de configuração e IOPS
Os requisitos de armazenamento para o banco de dados de Configuração e o banco de
dados de conteúdo da Administração Central não são grandes. É recomendável alocar 2
GB para o banco de dados de Configuração e 1 GB para o banco de dados de conteúdo
da Administração Central. Com o tempo, o banco de dados de Configuração pode
crescer e passar de 1 GB, mas isso não acontece rapidamente — ele cresce
aproximadamente 40 MB para cada 50 mil conjuntos de sites.
Os logs de transação do banco de dados de Configuração podem ser grandes. É
recomendável, portanto, que você altere o modelo de recuperação do banco de dados
de completo para simples.
Observação:
Se desejar usar o espelhamento do banco de dados do SQL Server para fornecer
disponibilidade para o banco de dados de Configuração, você deverá usar o modelo de
recuperação completo.
Os requisitos de IOPS para o banco de dados de Configuração e o banco de dados de
conteúdo da Administração Central são mínimos.
Armazenamento de conteúdo e IOPS
A estimativa do armazenamento e das IOPS necessárias para bancos de dados de
conteúdo não é uma atividade precisa. Ao testar e explicar as informações a seguir,
pretendemos ajudar você a obter estimativas a serem usadas para determinar o
tamanho inicial da sua implantação. No entanto, quando seu ambiente estiver em
execução, esperamos que você recalcule suas necessidades de capacidade com base
nos dados do ambiente real.
Para obter mais informações sobre nossa metodologia geral de planejamento de
capacidade, consulte Capacity management and sizing for SharePoint Server 2010 (em
inglês).
347
Estimar o armazenamento do banco de dados de conteúdo
O seguinte processo descreve como estimar de modo aproximado o armazenamento
necessário para bancos de dados de conteúdo, sem considerar os arquivos de log:
1. Calcule o número esperado de documentos. Esse valor é expresso na fórmula como
D.
A forma de cálculo do número de documentos será determinada pelos recursos que
você estiver usando. Por exemplo, para sites do Meu Site ou sites de colaboração, é
recomendável calcular o número esperado de documentos por usuário e multiplicar
esse valor pelo número de usuários. Para sites de gerenciamento de registros ou de
publicação de conteúdo, você pode calcular o número de documentos gerenciados e
gerados por um processo.
Se você estiver migrando de um sistema atual, talvez seja mais fácil extrapolar o uso
e a taxa de crescimento atual. Se estiver criando um novo sistema, avalie os
compartilhamentos de arquivos existentes ou outros repositórios e faça a estimativa
com base nessa taxa de uso.
2. Estime o tamanho médio dos documentos que está armazenando. Esse valor é
expresso na fórmula como S.Talvez valha a pena estimar médias para diferentes
tipos ou grupos de sites. O tamanho médio do arquivo para sites do Meu Site,
repositórios de mídia e diferentes portais de departamentos pode variar
significativamente.
3. Estime o número de itens da lista no ambiente. Esse valor é expresso na fórmula
como L.
É mais difícil estimar itens da lista do que documentos. Geralmente usamos uma
estimativa equivalente a três vezes o número de documentos (D), mas isso varia
com base em como você espera usar seus sites.
4. Determine o número aproximado de versões. Estime o número médio de versões
que qualquer documento de uma biblioteca terá (esse valor geralmente será muito
menor do que o número máximo permitido de versões). Esse valor é expresso na
fórmula como V.
O valor de V deve ser maior do que zero.
5. Use a seguinte fórmula para estimar o tamanho de seus bancos de dados de
conteúdo:
Tamanho do banco de dados = ((D × V) × S) + (10 KB × (L + (V × D)))
O valor de 10 KB na fórmula é uma constante que estima aproximadamente a
quantidade de metadados exigidos pelo SharePoint Server 2010. Se o seu sistema
exigir o uso significativo de metadados, convém aumentar essa constante.
Como exemplo, se você pretendesse usar a fórmula para estimar a quantidade de
espaço de armazenamento necessário para os arquivos de dados de um banco de
dados de conteúdo em um ambiente de colaboração com as características a seguir,
seriam necessários aproximadamente 105 GB.
Entrada
Valor
Número de documentos (D)
200.000
Calculado como 10.000 usuários vezes 20
348
Entrada
Valor
documentos
Tamanho médio dos documentos (S)
250 KB
Itens da lista (L)
600.000
Número de versões não atuais (V)
2
Presumindo que o máximo permitido de
versões é 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 conteúdo
O uso dos seguintes recursos do SharePoint Server 2010 pode afetar significativamente
o tamanho dos bancos de dados de conteúdo:
 Lixeiras Enquanto um documento não for totalmente excluído das lixeiras de
primeiro e segundo estágio, ele ocupará espaço em um banco de dados de
conteúdo. Calcule quantos documentos são excluídos a cada mês para determinar o
efeito das lixeiras no tamanho dos bancos de dados de conteúdo. Para obter mais
informações, consulte Configure Recycle Bin settings (SharePoint Server 2010).


Auditoria Os dados de auditoria podem compor e usar grandes quantidades de
espaço em um banco de dados de conteúdo, especialmente se a auditoria de
exibição 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 regulatórios ou para controles internos.
Use as seguintes diretrizes para estimar o espaço que precisará reservar para dados
de auditoria:

Estime o número de novas entradas de auditoria para um site e multiplique esse
número por 2 KB (as entradas geralmente estão limitadas a 4 KB, com um
tamanho médio aproximado de 1 KB).

Com base no espaço que você deseja alocar, determine o número 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
conteúdo. Por padrão, o cache do Office Web Apps é configurado como 100 GB.
Para obter mais informações 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 conteúdo
Os requisitos de IOPS para bancos de dados de conteúdo variam muito de acordo com o
modo como o seu ambiente está sendo usado e com a quantidade existente de espaço
em disco e servidores. Em geral, é recomendável comparar a carga de trabalho prevista
em seu ambiente com uma das soluções testadas. Para obter mais informações,
consulte Recomendações e resultados de testes de desempenho e capacidade
(SharePoint Server 2010).
349
Importante:
O teste do conteúdo desta seção ainda não foi concluído. Verifique a existência de
informações adicionais.
Estimar necessidades de armazenamento do aplicativo de serviço e
IOPS
Depois de estimar as necessidades de armazenamento de conteúdo e de IOPS, você
deverá determinar o armazenamento e as IOPS exigidas pelos aplicativos de serviço
que estão sendo usados em seu ambiente.
Requisitos de IOPS e armazenamento de aplicativos de serviço do
SharePoint Foundation 2010
Para estimar os requisitos de armazenamento dos aplicativos de serviço no sistema,
primeiro você deve conhecer os aplicativos de serviço e saber como usá-los. Os
aplicativos de serviço disponíveis no SharePoint Foundation 2010 que têm bancos de
dados são listados na tabela a seguir.
Banco de dados de aplicativos de serviço
Recomendação 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 colaboração
que usam configurações predefinidas, um
milhão de solicitações HTTP exige 2 GB de
armazenamento.
Use uma das seguintes fórmulas para
estimar a quantidade necessária de IOPS:

115 × visitas/segundo
 5 × solicitações HTTP
Se você precisar restringir o tamanho do
banco de dados de uso, é recomendável
começar registrando em log apenas as
solicitações de páginas. Você também pode
restringir o tamanho do banco de dados
definindo o intervalo de dados padrão a ser
mantido como inferior a duas semanas.
Se possível, coloque o banco de dados de
Uso em seu próprio disco ou eixo.
Serviço Conectividade de Dados
Corporativos
O tamanho do banco de dados dos serviços
Conectividade de Dados Corporativos é
afetado principalmente pelo número de tipos
de conteúdo externo a que você planeja dar
350
Banco de dados de aplicativos de serviço
Recomendação de estimativa de tamanho
suporte. Aloque 0,5 MB para cada tipo de
conteúdo externo. Se você não sabe de
quantos tipos de conteúdo externo poderá
precisar, é recomendável alocar 50 MB. Os
requisitos de IOPS são mínimos.
Serviço de Registro de Aplicativo
Aloque 1 GB apenas se estiver fazendo
uma atualização do Catálogo de Dados
Corporativos do Microsoft Office SharePoint
Server 2007. Os requisitos de IOPS são
mínimos.
Configurações de inscrição
Aloque 1 GB. Os requisitos de IOPS são
mínimos.
Requisitos de IOPS e armazenamento de aplicativos de serviço do
SharePoint Server 2010
Para estimar os requisitos de armazenamento dos aplicativos de serviço no sistema,
primeiro você deve conhecer os aplicativos de serviço e saber como usá-los. Os
aplicativos de serviço disponíveis no SharePoint Server 2010 que têm bancos de dados
são listados na tabela a seguir.
Aplicativo de serviço
Recomendação de estimativa de tamanho
Pesquisa
A Pesquisa exige três bancos de dados.
Seu ambiente pode incluir vários bancos de
dados de Propriedade e Rastreamento.
O banco de dados de administração de
Pesquisa geralmente é pequeno: aloque
10 GB.
Para estimar o armazenamento necessário
para seus bancos de dados de Propriedade
e Rastreamento, use os seguintes
multiplicadores:
 Rastreamento: 0,046 × (soma dos
bancos de dados de conteúdo)

Propriedade: 0,015 × (soma dos bancos
de dados de conteúdo)
Os requisitos de IOPS para Pesquisa são
significativos.
 Para o banco de dados de
Rastreamento, a pesquisa exige de
3.500 a 7.000 IOPS.

351
Para o banco de dados de Propriedade,
Aplicativo de serviço
Recomendação de estimativa de tamanho
a pesquisa precisa de 2.000 IOPS.
Para obter informações detalhadas sobre
como estimar a capacidade necessária para
Pesquisa, consulte Recomendações e
resultados de testes de desempenho e
capacidade (SharePoint Server 2010).
Perfil do Usuário
O aplicativo de serviço do Perfil do Usuário
está associado a três bancos de dados:
Perfil, Sincronização e Marcação Social.
Para estimar o armazenamento necessário
para os bancos de dados, use as seguintes
informações:

Perfil. Com configurações predefinidas,
em um ambiente configurado para usar
o Active Directory, o banco de dados de
perfil exigirá aproximadamente 1 MB
por perfil de usuário.

Sincronização. Com configurações
predefinidas, em um ambiente com
poucos grupos por usuário, o banco de
dados de sincronização exigirá
aproximadamente 630 KB por perfil de
usuário. O arquivo de dados usará 90%
do espaço.

Marcação social. Com configurações
prévias, o banco de dados de marcação
social exigirá aproximadamente
0,009 MB por marca, comentário ou
classificação. Para estimar quantas
marcas ou notas os usuários criarão,
analise as seguintes informações sobre
o site del.icio.us:


Aproximadamente 10% dos
usuários são considerados ativos.
Os usuários ativos criam 4,5
marcas e 1,8 comentários por mês.
Em um ambiente de colaboração dinâmica
com 160.000 perfis de usuários, cinco
grupos, 79.000 marcas, comentários e
classificações (2.500 comentários, 76.000
marcas e 800 classificações) e
configurações predefinidas, temos os
seguintes tamanhos para estes bancos de
dados:
352
Aplicativo de serviço
Recomendação de estimativa de tamanho
Nome do banco de
dados
Tamanho do banco de
dados
Perfil
155 GB
Sincronização
96 GB
Marcação social
0,66 GB
Metadados gerenciados
O aplicativo de serviço Metadados
Gerenciados tem um banco de dados. O
tamanho do banco de dados é afetado pelo
número de tipos de conteúdo e palavraschave usados no sistema. Muitos ambientes
incluirão várias instâncias do aplicativo de
serviço Metadados Gerenciados. Para obter
informações detalhadas sobre como estimar
o tamanho e os requisitos de IOPS desse
banco de dados, consulte Recomendações
e resultados de testes de desempenho e
capacidade (SharePoint Server 2010).
Web Analytics
O Web Analytics tem dois bancos de dados:
Preparo e Relatórios. Muitos fatores
influenciam o tamanho dos bancos de
dados. Entre eles, estão o período de
retenção, o volume diário de dados
rastreados e o número de conjuntos de
sites, sites e subsites no aplicativo Web que
está sendo analisado. Para obter
informações detalhadas sobre como estimar
seus requisitos de tamanho e IOPS,
consulte Recomendações e resultados de
testes de desempenho e capacidade
(SharePoint Server 2010).
Repositório seguro
O tamanho do banco de dados do aplicativo
de serviço de Repositório Seguro é
determinado pelo número de credenciais no
repositório e pelo número de entradas na
tabela de auditoria. É recomendável alocar
5 MB para cada 1.000 credenciais para ele.
A necessidade de IOPS é mínima.
Estado
O aplicativo de serviço de Controle de
Sessão tem um banco de dados. É
recomendável alocar 1 GB para ele. A
353
Aplicativo de serviço
Recomendação de estimativa de tamanho
necessidade de IOPS é mínima.
Serviço Word Automation
O aplicativo de serviço Word Automation
tem um banco de dados. É recomendável
alocar 1 GB para ele. A necessidade de
IOPS é mínima.
PerformancePoint
O aplicativo de serviço PerformancePoint
tem um banco de dados. É recomendável
alocar 1 GB para ele. A necessidade de
IOPS é mínima.
Determinar as necessidades de disponibilidade
A disponibilidade é um grau pelo qual um ambiente do SharePoint Server 2010 é
percebido por usuários como disponível. Um sistema disponível é um sistema flexível —
ou seja, incidentes que afetem o serviço ocorrem com pouca frequência e ações
oportunas e eficientes são tomadas quando eles ocorrem.
Os requisitos de disponibilidade podem aumentar significativamente suas necessidades
de armazenamento. Para obter informações detalhadas, consulte Plan for availability
(SharePoint Server 2010).
Escolher a versão e a edição 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 recomendável 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, segurança e gerenciamento por ela fornecidos. Para obter mais
informações sobre os benefícios 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:
 Compactação de backup A compactação de backup pode agilizar qualquer
backup do SharePoint e está disponível no SQL Server 2008 Enterprise Edition ou
no SQL Server 2008 R2 Standard Edition. Ao configurar a opção de compactação
em seu script de backup ou ao configurar o servidor que está executando o SQL
Server para compactar por padrão, você pode reduzir significativamente o tamanho
do seus backups de bancos de dados e logs remetidos. Para obter mais
informações, consulte o artigo sobre compactação de backup (SQL Server)
(http://go.microsoft.com/fwlink/?linkid=129381&clcid=0x416).
354
Observação:
Não há suporte para a compactação de dados do SQL Server para o Produtos do
SharePoint 2010.

Criptografia de dados transparente Se os seus requisitos de segurança incluírem
a necessidade de criptografia de dados transparente, você deverá usar o SQL
Server Enterprise Edition.

Aplicativo de serviço do Web Analytics Se você planeja usar o aplicativo de
serviço do Web Analytics para análise significativa, avalie o uso do SQL Server
Enterprise Edition para que o sistema se beneficie do particionamento de tabelas.

Implantação de conteúdo Se você planeja usar o recurso de implantação de
conteúdo, avalie o uso do SQL Server Enterprise Edition para que o sistema se
beneficie dos instantâneos 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
conteúdo, use o SQL Server 2008 ou o SQL Server 2008 R2 Enterprise Edition.

Administrador de recursos O Administrador de Recursos é uma tecnologia
lançada no SQL Server 2008 para gerenciar cargas de trabalho e recursos do SQL
Server por meio da especificação de limites para o consumo de recursos por
solicitações de entrada. O Administrador de Recursos permite diferenciar cargas de
trabalho e alocar CPU e memória à medida que elas são solicitadas, com base nos
em limites especificados por você. Ele está disponível apenas no SQL Server 2008
ou no SQL Server 2008 R2 Enterprise Edition. Para obter mais informações sobre o
uso do Administrador de Recursos, consulte o artigo sobre como gerenciar cargas
de trabalho do SQL Server com o Administrador de Recursos.
É recomendável 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 prática
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 colocação de bancos de dados entre computadores que estão
executando o SQL Server.
PowerPivot para SharePoint 2010
Permite que os usuários
compartilhem análises e modelos de dados gerados por usuários e colaborem neles
no Excel e no navegador enquanto atualiza automaticamente essas análises. 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.
355
Nesta seção:
 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 conexão
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 conteúdo configurados para utilizar remote BLOB storage.
Sua escolha depende de fatores da sua solução de negócios 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 latência. Para ter suporte, o
sistema deve retornar de modo consistente o primeiro byte de dados dentro
20 milissegundos (ms).
DAS (armazenamento de conexão direta)
O DAS é um sistema de armazenamento digital diretamente conectado a um servidor ou
a uma estação de trabalho, sem uma rede de armazenamento intermediária. Os tipos de
disco físico DAS incluem SAS (Serial Attached SCSI) e SATA (Serial Attached ATA).
Em geral, é recomendável que você escolha uma arquitetura DAS quando uma
plataforma de armazenamento compartilhada não possa assegurar um tempo de
resposta de 20 ms e capacidade suficiente para IOPS médio e máximo.
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, é recomendável escolher uma SAN quando os benefícios do armazenamento
compartilhado sejam importantes para a sua organização.
Estes são alguns benefícios do armazenamento compartilhado:
 Realocação mais fácil de armazenamento em disco entre servidores.

Pode atender a vários servidores.

Nenhuma limitação de número de discos que podem ser acessados.
NAS (armazenamento conectado à rede)
Uma unidade de NAS é um computador autônomo conectado a uma rede. Seu único
objetivo é fornecer serviços 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).
356
Observação:
O suporte para NAS se restringe apenas ao uso com bancos de dados de conteúdo
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 restrição não 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 médio de
busca. O SharePoint Server 2010 dá suporte aos seguintes tipos de unidades:
 SCSI

SATA

SAS

FC

Interface IDE

Unidade de estado sólido ou Disco Flash
Escolher tipos de RAID
O RAID (Redundant Array of Independent Disks) é usado geralmente para melhor as
características de desempenho de discos individuais (por meio da distribuição de dados
por vários discos) e para fornecer proteção contra falhas de disco individuais.
Todos os tipos de RAID dão suporte ao SharePoint Server 2010; no entanto, é
recomendável usar o RAID 10 ou uma solução de RAID específica de um fornecedor
com desempenho equivalente.
Ao configurar uma matriz RAID, não se esqueça de alinhar o sistema de arquivos ao
deslocamento informado pelo fornecedor. Na ausência de orientação do fornecedor,
consulte o artigo sobre práticas recomendadas de E/S pré-implantação do SQL Server
(http://go.microsoft.com/fwlink/?linkid=105583&clcid=0x416).
Para obter mais informações sobre como provisionar RAID e o subsistema de E/S do
SQL Server, consulte o artigo sobre práticas recomendadas do SQL Server
(http://go.microsoft.com/fwlink/?linkid=168612&clcid=0x416).
Estimar requisitos de memória
A memória necessária para o SharePoint Server 2010 está diretamente relacionada ao
tamanho dos bancos de dados de conteúdo hospedados em um servidor que executa o
SQL Server.
À medida que você adiciona aplicativos de serviço e recursos, seus requisitos tendem a
crescer. A tabela a seguir dá diretrizes sobre a quantidade de memória recomendável.
357
Observação:
Nossas definições de implantações pequenas e médias são descritas na seção
"Arquiteturas de referência" do artigo Capacity management and sizing for SharePoint
Server 2010 (em inglês).
Tamanho combinado de bancos de dados de RAM recomendada para computadores que
executam o SQL Server
conteúdo
Mínimo para pequenas implantações de
produção
8 GB
Mínimo para médias implantações de
produção
16 GB
Recomendação para até 2 terabytes
32 GB
Recomendação para a faixa entre 2
terabytes até o máximo de 5 terabytes
64 GB
Observação:
Esses valores são maiores do que os recomendados como mínimos para o SQL Server
devido à distribuição dos dados necessários para um ambiente do SharePoint Server
2010. Para obter mais informações sobre requisitos de sistema do SQL Server, consulte
Requisitos de hardware e software para a instalação do SQL Server 2008
(http://go.microsoft.com/fwlink/?linkid=129377&clcid=0x416).
Estes são alguns dos outros fatores que podem influenciar a memória 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 conexões de rede dentro dos farms e entre eles. É recomendável usar uma
rede de baixa latência.
A lista a seguir fornece algumas práticas recomendadas:
 Todos os servidores no farm devem ter largura de banda e latência de LAN (rede
local) para o servidor que está executando o SQL Server. A latência não deve ser
maior do que 1 ms.

Não é recomendável uma topologia de WAN (rede de longa distância) em que um
servidor que esteja executando o SQL Server seja implantado remotamente de
358
outros componentes do farm através de uma rede com latência maior do que 1 ms.
Essa topologia não 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.

É recomendável que os servidores Web e os servidores de aplicativos tenham dois
adaptadores de rede: um para gerenciar o tráfego do usuário final e o outro para
gerenciar a comunicação com os servidores que executam o SQL Server.
Configurar o SQL Server
As seções a seguir descrevem como planejar a configuração do SQL Server para o
SharePoint Server 2010.
Nesta seção:
 Determinar quantas instâncias ou servidores são necessários

Configurar o armazenamento e a memória

Definir opções do SQL Server

Configurar bancos de dados
Estimar quantos servidores são necessários
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 número de servidores de médio porte que executam o SQL Server do que
com apenas alguns grandes servidores.
Sempre coloque o SQL Server em um servidor dedicado que não esteja executando
qualquer outra função de farm ou hospedando bancos de dados de qualquer outro
aplicativo, a menos que você esteja implantando o sistema em um servidor autônomo.
A seguir, é apresentada uma orientação 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
conteúdo ultrapassarem 5 terabytes.
Observação:
A Microsoft dá suporte a configurações de servidor que não seguem esta orientação.
Para promover o armazenamento seguro de credenciais quando estiver executando o
aplicativo de serviço Repositório Seguro, é recomendável que o banco de dados de
repositório seguro esteja hospedado em uma instância separada de banco de dados em
que o acesso seja limitado a um administrador.
Configurar o armazenamento e a memória
No servidor que está executando o SQL Server 2008, é recomendável que o cache L2
por CPU tenha um mínimo de 2 MB para melhorar a memória.
359
Siga as recomendações de configuração de armazenamento do
fornecedor
Para obter um desempenho ideal ao configurar uma matriz de armazenamento física,
siga as recomendações de configuração de hardware informadas pelo fornecedor de
armazenamento, em vez de adotar os valores padrão do sistema operacional.
Se você não receber orientações do fornecedor, recomendamos que use o utilitário de
configuração de disco DiskPart.exe para configurar o armazenamento para o SQL
Server 2008. Para obter mais informações, consulte o artigo sobre melhores práticas de
E/S de pré-implantação (http://go.microsoft.com/fwlink/?linkid=105583&clcid=0x416).
Forneça o máximo de recursos possível
Verifique se os canais de E/S do SQL Server para os discos não são compartilhados por
outros aplicativos, como o arquivo de paginação e os logs do IIS (Serviços de
Informações da Internet).
Forneça o máximo possível de banda larga. Maior banda larga de barramento ajuda a
melhorar a confiabilidade e o desempenho. Lembre-se de que o disco não é o único
usuário da banda larga de barramento — por exemplo, você também deve considerar o
acesso à rede.
Definir opções do SQL Server
As seguintes configurações e opções do SQL Server devem ser definidas antes da
implantação do SharePoint Server.
 Não habilite estatísticas de criação automática em um SQL Server que esteja dando
suporte ao SharePoint Server. O SharePoint Server implementa estatísticas
específicas. Nenhuma estatística adicional é necessária. As estatísticas de criação
automática podem alterar significativamente o plano de execução de uma consulta
de uma instância do SQL Server para outra instância 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 cenários.

Para garantir um desempenho ideal, é altamente recomendável definir o grau
máximo de paralelismo como 1 para servidores de banco de dados que hospedam
bancos de dados do SharePoint Server 2010. Para obter mais informações sobre
como definir o grau máximo de paralelismo, consulte o artigo sobre a opção de
grau máximo de paralelismo
(http://go.microsoft.com/fwlink/?linkid=189030&clcid=0x416).

Para facilitar a manutenção, configure aliases de conexão do SQL Server para cada
servidor de banco de dados em seu farm. Um alias de conexão é um nome
alternativo que pode ser usado para estabelecer uma conexão com uma instância do
SQL Server. Para obter mais informações, consulte o artigo sobre como definir um
alias do SQL Server (SQL Server Management Studio)
(http://go.microsoft.com/fwlink/?linkid=132064&clcid=0x416).
Configurar bancos de dados
As orientações a seguir descrevem práticas recomendadas de planejamento na
configuração de cada banco de dados em seu ambiente.
Separe e priorize seus dados em discos
360
De modo ideal, você deve colocar o banco de dados tempdb, os bancos de dados de
conteúdo, o banco de dados de Uso, os bancos de dados de pesquisa e os logs de
transações do SQL Server 2008 em discos rígidos separados.
A lista a seguir fornece algumas práticas recomendadas de priorização de dados:
 Ao priorizar dados em discos mais rápidos, use a seguinte classificação:
1. Arquivos de dados tempdb e logs de transações
2. Arquivos de log de transações do banco de dados
3. Bancos de dados de pesquisa, com exceção do banco de dados de
administração de Pesquisa

4. Arquivos de dados de banco de dados
Em um site de portal fortemente orientado à leitura, priorize dados em relação 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 operação de leitura
média ou a operação de gravação média exigir mais do que 20 ms — talvez você
precise reduzir o afunilamento separando os arquivos em discos ou substituindo os
discos por outros mais rápidos.

Para melhorar o desempenho, coloque o tempdb em uma matriz RAID 10. O número
de arquivos de dados do tempdb deve ser igual ao número de núcleos de CPUs e os
arquivos de dados do tempdb devem ser definidos com o mesmo tamanho. Conte
processadores de núcleo duplo como duas CPUs para essa finalidade. Conte cada
processador que dê suporte a hyperthreading como uma CPU. Para obter mais
informações, consulte o artigo sobre como otimizar o desempenho do tempdb
(http://go.microsoft.com/fwlink/?linkid=148537&clcid=0x416).

Separe dados de banco de dados e arquivos de log de transações em diferentes
discos. Se os arquivos precisarem compartilhar discos porque os arquivos são muito
pequenos para justificar o uso de um disco inteiro ou de uma faixa inteira, ou se
faltar espaço em disco, coloque os arquivos que têm padrões de uso diferentes no
mesmo disco para minimizar solicitações de acesso simultâneo.

Consulte o fornecedor do seu hardware de repositório para obter informações sobre
como configurar todos os logs e os bancos de dados de pesquisa a fim de otimizar a
gravação em sua solução de repositório específica.
Use vários arquivos de dados para bancos de dados de conteúdo
Siga estas recomendações para melhorar o desempenho:
 Crie apenas arquivos no grupo de arquivos primário do banco de dados.

Distribua os arquivos por discos separados.

O número de arquivos de dados deve ser menor ou igual ao número de núcleos de
CPUs. Conte processadores de núcleo 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.
361
Importante:
Embora você possa usar as ferramentas de backup e recuperação internas do
SharePoint Server 2010 para fazer backup e recuperar vários arquivos de dados, se
você substituí-los no mesmo local, as ferramentas não poderão restaurar vários arquivos
de dados em um local diferente. Por esse motivo, é altamente recomendável que, ao
usar vários arquivos de dados para um banco de dados de conteúdo, você use as
ferramentas de backup e recuperação do SQL Server. Para obter mais informações
sobre como fazer backup e recuperar o SharePoint Server 2010, consulte Plan for
backup and recovery (SharePoint Server 2010).
Para obter mais informações sobre como criar e gerenciar grupos de arquivos, consulte
o artigo sobre arquivos e grupos de arquivos físicos de banco de dados
(http://go.microsoft.com/fwlink/?linkid=117909&clcid=0x416).
Limite o tamanho do banco de dados de conteúdo 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 atualização do seu ambiente.
Para ajudar a garantir o desempenho do sistema, é altamente recomendável limitar o
tamanho dos bancos de dados de conteúdo a 200 GB.
Um conjunto de sites não 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 conteúdo de até 1 terabyte somente
para grandes repositórios de um único site e arquivos nos quais os dados permanecem
razoavelmente estáticos, como sistemas de gerenciamento de documentos de referência
e sites de Central de Registros. Há suporte para tamanhos de bancos de dados maiores
nesses cenários porque seus padrões de E/S e formatos típicos de estrutura de dados
foram projetados e testados em escalas maiores.
Se o seu design exigir um banco de dados maior do que o padrão recomendado, siga
esta orientação:
 Para bancos de dados que contenham muitos arquivos grandes armazenados como
BLOBs (objetos binários grandes), avalie a possibilidade de usar RBS (remote BLOB
storage). O RBS é adequado nas seguintes circunstâncias:
1. Quando você estiver executando sites que contenham arquivos grandes pouco
acessados, como repositórios de conhecimento.
2. Quando você tiver terabytes de dados.
3. Para arquivos de vídeo ou mídia.
362
Para obter mais informações, consulte Plan for remote BLOB storage (RBS)
(SharePoint Server 2010).
 Siga práticas recomendadas de exibição de dados de grandes bancos de dados.
Para obter mais informações, consulte Gerenciamento de capacidade do SharePoint
Server 2010: limites de software.
Para obter mais informações sobre repositórios de documentos em grande escala,
consulte a seção sobre estimativa de requisitos de desempenho e capacidade para
repositórios de documentos em grande escala, disponível em Recomendações e
resultados de testes de desempenho e capacidade (SharePoint Server 2010).
Gerencie de modo proativo o crescimento dos arquivos de dados e
log
É recomendável gerenciar de maneira proativa o crescimento dos arquivos de dados e
log, considerando as seguintes recomendações:
 Sempre que possível, expanda previamente todos os arquivos de dados e log para
seu tamanho final previsto.


É recomendável habilitar o aumento automático por razões de segurança. Não
confie nas configurações padrão de aumento automático. Leve em conta as
seguintes diretrizes ao configurar o aumento automático:

Quando planejar bancos de dados de conteúdo que ultrapassem o tamanho
recomendado (200 GB), defina o valor de aumento automático do banco de
dados para um número fixo de megabytes, e não para uma porcentagem. Isso
reduz a frequência com que o SQL Server aumenta o tamanho de um arquivo.
Aumentar o tamanho do arquivo é uma operação de bloqueio que envolve o
preenchimento do novo espaço com páginas vazias.

Defina o valor de aumento automático para o banco de dados de Repositório de
Propriedades do aplicativo de serviço de Pesquisa como 10 por cento.

Se não houver previsão de que o tamanho calculado do banco de dados de
conteúdo alcance o tamanho máximo recomendado de 200 GB dentro de um
ano, defina-o como o tamanho máximo que o banco de dados deve alcançar em
um ano (com 20% de margem adicional de erro) usando a propriedade ALTER
DATABASE MAXSIZE. Revise periodicamente essa configuração para verificar
se ela ainda tem um valor adequado com base nas taxas de crescimento
anteriores.
Mantenha um nível de pelo menos 25 por cento de espaço disponível nos discos
para estabelecer padrões de crescimento e uso máximo. Se você estiver
gerenciando o crescimento por meio da inclusão de discos em uma matriz RAID ou
da alocação de mais armazenamento, monitore o tamanho do disco cuidadosamente
para evitar ficar sem espaço.
Validar e monitorar o desempenho do
armazenamento e do SQL Server
Teste se a solução de desempenho e backup do seu hardware permite que você cumpra
seus SLAs (contratos de nível de serviço). Teste especificamente o subsistema de E/S
363
do computador que está executando o SQL Server para garantir que o desempenho seja
satisfatório.
Teste a solução de backup que você está usando para garantir que ela possa fazer
backup do sistema dentro da janela de manutenção disponível. Se a solução de backup
não puder atender aos SLAs exigidos por seu negócio, avalie a possibilidade de usar
uma solução 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, memória, taxa de acertos do cache e subsistema de E/S.
Quando um ou mais dos componentes parecerem lentos ou sobrecarregados, analise a
estratégia apropriada com base na carga de trabalho atual e projetada. Para obter mais
informações, consulte o artigo sobre como solucionar problemas de desempenho no
SQL Server 2008 (http://go.microsoft.com/fwlink/?linkid=168448&clcid=0x416).
A seção a seguir relaciona os contadores de desempenho de uso recomendado para
monitorar o desempenho dos bancos de dados do SQL Server que estão sendo
executados em seu ambiente do SharePoint Server 2010. Também estão descritos
valores aproximados de integridade para cada contador.
Para obter detalhes sobre como monitorar o desempenho e usar contadores de
desempenho, consulte o artigo sobre como monitorar desempenho
(http://go.microsoft.com/fwlink/?linkid=189032&clcid=0x416).
Contadores do SQL Server a serem monitorados
Monitore os seguintes contadores do SQL Server para garantir a integridade de seus
servidores:
 Estatísticas gerais Este objeto fornece contadores para monitorar a atividade
geral em todo o servidor, como o número de conexões atuais e o número de
usuários que se conectam e desconectam por segundo de computadores que
executam uma instância do SQL Server. Avalie a possibilidade de monitorar o
seguinte contador:


Bancos de dados Este objeto fornece contadores para monitorar operações de
cópia em massa, produtividade de backup e restauração e atividades de log de
transações. Monitore as transações e o log de transações para determinar o volume
de atividades dos usuários no banco de dados e o quanto o log de transações está
ficando cheio. O volume de atividades dos usuários pode determinar o desempenho
do banco de dados e afetar o tamanho do log, o bloqueio e a replicação. Monitorar a
atividade de log de baixo nível para medir a atividade dos usuários e o uso de
recursos pode ajudar você a identificar afunilamentos de desempenho. Avalie a
possibilidade de monitorar o seguinte contador:


Conexões de usuário Este contador mostra a quantidade de conexões de
usuário no seu computador que executa o SQL Server. Se você vir esse número
crescer 500 por cento em relação à linha de base, talvez experimente uma
redução do desempenho.
Transações/s Este contador mostra a quantidade de transações por segundo
em um determinado banco de dados ou no servidor inteiro. Esse número é mais
para a sua linha de base e para ajudar você a solucionar problemas.
Bloqueios Este objeto fornece informações sobre bloqueios do SQL Server em
tipos de recursos individuais. Avalie a possibilidade de monitorar os seguintes
contadores:
364





Tempo de Espera Médio (ms) Este contador mostra a quantidade média de
tempo de espera para cada solicitação 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 número de bloqueios por
segundo que não puderam ser atendidos imediatamente e precisaram esperar
recursos.

Número de deadlocks Este contador mostra o número de deadlocks por
segundo no computador que executa o SQL Server. O valor não deve ser maior
do que 0.
Travas Este objeto fornece contadores para monitorar bloqueios internos de
recursos do SQL Server chamados travas. A monitoração de travas para determinar
a atividade dos usuários e o uso de recursos pode ajudar você a identificar os
afunilamentos de desempenho. Avalie a possibilidade de monitorar os seguintes
contadores:

Tempo Médio de Espera de Trava (ms) Este contador mostra o tempo médio
de espera de trava para solicitações de trava que precisaram esperar.

Esperas de Trava/s Este contador mostra o número de solicitações de trava
que não puderam ser atendidas imediatamente.
Estatísticas SQL Este objeto fornece contadores para monitorar a compilação e o
tipo de solicitações enviadas para uma instância do SQL Server. A monitoração do
número de compilações e recompilações de consultas e do número de lotes
recebidos por uma instância do SQL Server indica a rapidez com que o SQL Server
está processando as consultas de usuários e a eficiência com que o otimizador de
consulta está processando as consultas. Avalie a possibilidade de monitorar os
seguintes contadores:

Compilações de SQL/s Este contador indica o número de vezes que o
caminho de código de compilação é inserido por segundo.

Recompilações de SQL/s Este contador indica o número de recompilações da
instrução por segundo.
Gerenciador de Buffer Este objeto fornece contadores para monitorar como o
SQL Server usa a memória para armazenar páginas de dados, estruturas de dados
internas e o cache de procedimento, bem como contadores para monitorar o E/S
físico enquanto o SQL Server lê e grava páginas 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 páginas encontradas no cache do buffer
sem a necessidade de ler do disco. A taxa é o número total de acertos de cache
dividido pelo número total de pesquisas de cache nos últimos mil acessos a
páginas. Como ler do cache é muito mais caro do que ler do disco, convém que
essa taxa seja alta. Geralmente, você pode aumentar a taxa de acertos do
cache do buffer aumentando a quantidade de memória disponível para o SQL
Server.
Cache de Planos Este objeto fornece contadores para monitorar como o SQL
Server usa a memória para armazenar objetos como procedimentos armazenados,
365
instruções 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 físico 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 número
de threads na fila do processador. Monitore este contador para assegurar que ele
permaneça inferior ao dobro do número de núcleos de CPU.

Memória: Mbytes Disponíveis Este contador mostra a quantidade de memória
física, em megabytes, disponível para processos executados no computador.
Monitore este contador para assegurar a manutenção de um nível de pelo menos
20 por cento do total de RAM física disponível.

Memória: Páginas/s Este contador mostra a taxa em que as páginas são lidas do
disco ou nele gravadas para resolver falhas de página de hardware. Monitore este
contador para assegurar que ele permaneça abaixo de 100.
Para obter mais informações e métodos de solução de problemas de memória, consulte
o artigo sobre o monitoramento do uso da memória pelo SQL Server 2005
(http://go.microsoft.com/fwlink/?linkid=105585&clcid=0x416).
Contadores de disco a serem monitorados
Monitore os seguintes contadores para assegurar a integridade dos discos. Observe que
os seguintes valores são medidos ao longo do tempo — não são valores que ocorrem
durante um pico repentino e não se baseiam em uma única medição.
 Disco Físico: % Tempo de Disco: DataDrive Este contador mostra a
porcentagem do tempo decorrido em que a unidade de disco selecionada está
ocupada atendendo a solicitações de leitura ou gravação – é 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 solicitações do sistema estão aguardando
o acesso ao disco. O número de solicitações de E/S em espera deve ser mantido em
não mais de 1,5 a 2 vezes o número de eixos que constituem o disco físico.

Disco Lógico: Transferências de Disco/s Este contador mostra a taxa em que
são executadas as operações de leitura e gravação no disco. Use este contador
para monitorar as tendências de crescimento e fazer previsões adequadamente.

Disco Lógico: Bytes de Leitura de Disco/s e Disco Lógico: Bytes de Gravação
de Disco/s Estes contadores mostram a taxa em que os bytes são transferidos do
disco durantes as operações de leitura e gravação.
366

Disco Lógico: Média de Bytes de Disco/Leitura Este contador mostra o número
médio de bytes transferidos do disco durante as operações de leitura. Esse valor
pode refletir a latência do disco — operações de leitura maiores podem resultar em
latência ligeiramente maior.

Disco Lógico: Média de Bytes de Disco/Gravação Este contador mostra o
número médio de bytes transferidos para o disco durante as operações de gravação.
Esse valor pode refletir a latência do disco — operações de gravação maiores
podem resultar em latência ligeiramente maior.

Disco Lógico: Comprimento da Fila de Disco Atual Este contador mostra o
número de solicitações pendentes no disco no momento em que os dados de
desempenho são coletados. Para este contador, valores menores são melhores.
Valores maiores do que 2 por disco podem indicar um afunilamento e devem ser
investigados. Isso significa que um valor até 8 é aceitável para uma LUN (unidade
lógica) constituída de quatro discos. Os afunilamentos podem criar uma lista de
pendências capaz de se difundir para além do servidor atual que está acessando o
disco e provocar longos tempos de espera para os usuários. As possíveis soluções
para um afunilamento são adicionar mais discos à matriz de RAID, substituir os
discos existentes por discos mais rápidos ou mover alguns dados para outros discos.

Disco Lógico: Comprimento Médio da Fila de Disco Este contador mostra o
número médio de solicitações de leitura e gravação que foram enfileiradas para o
disco selecionado durante o intervalo da amostra. A regra é que deve haver no
máximo duas solicitações pendentes de leitura e gravação por eixo, mas isso pode
ser difícil de medir por causa da virtualização do armazenamento e de diferenças em
níveis de RAID entre configurações. Procure comprimentos de fila de disco maiores
do que a média em combinação com latências de disco maiores do que a média.
Essa combinação 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 Lógico: Média de Disco s/Leitura e Disco Lógico: Média de Disco
s/Gravação Estes contadores mostram o tempo médio, em segundos, de uma
operação de leitura ou gravação no disco. Monitore estes contadores para assegurar
que eles permaneçam abaixo de 85 por cento da capacidade do disco. O tempo de
acesso a disco aumenta exponencialmente se operações de leitura ou gravação
representarem mais de 85 por cento da capacidade do disco. Para determinar a
capacidade específica do seu hardware, consulte a documentação do fornecedor ou
use a Ferramenta de Parâmetro de Comparação de Subsistema de Disco SQLIO
para calculá-la. Para obter mais informações, consulte o artigo sobre a Ferramenta
de Parâmetro de Comparação de Subsistema de Disco SQLIO
(http://go.microsoft.com/fwlink/?linkid=105586&clcid=0x416).

Disco Lógico: Média de Disco s/Leitura Este contador mostra o tempo
médio, em segundos, de uma operação de leitura do disco. Em um sistema bem
ajustado, os valores ideais vão 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).
Latências maiores podem ocorrer durante momentos de pico, mas se forem
registrados valores maiores regularmente, você deverá investigar a causa.

Disco Lógico: Média de Disco s/Gravação Este contador mostra o tempo
médio, em segundos, de uma operação de gravação no disco. Em um sistema
367
bem ajustado, os valores ideais vão 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). Latências maiores podem ocorrer durante momentos de pico, mas se
forem registrados valores maiores regularmente, você deverá investigar a causa.
Quando você usar configurações de RAID com os contadores Média de Disco
s/Leitura ou Média de Disco s/Gravação, use as fórmulas relacionadas na
tabela a seguir para determinar a taxa de entrada e saída no disco.
Nível de RAID
Fórmula
RAID 0
E/Ss por disco = (leituras + gravações) /
número de discos
RAID 1
E/Ss por disco = [leituras + (2 × gravações)]
/2
RAID 5
E/Ss por disco = [leituras + (4 × gravações)]
/ número de discos
RAID 10
E/Ss por disco = [leituras + (2 × gravações)]
/ número de discos
Por exemplo, se você tiver um sistema RAID 1 com dois discos físicos
e seus contadores tiverem os valores mostrados na tabela a seguir:
Contador
Valor
Média de Disco s/Leitura
80
Disco Lógico: Média de Disco s/Gravação 70
Comprimento Médio 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 situação, você tem um afunilamento de E/S limítrofe.
Outras ferramentas de monitoração
Você também pode monitorar a latência de disco e analisar tendências usando a
exibição de gerenciamento dinâmico sys.dm_io_virtual_file_stats no SQL Server 2008.
Para obter mais informações, consulte o artigo sobre sys.dm_io_virtual_file_stats
(Transact-SQL) (http://go.microsoft.com/fwlink/?linkid=105587&clcid=0x416).
368