Share Pt Serv Plan Cap

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.

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








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

Planejamento de capacidade para SharePoint Server 2010 .......................................... 1

Obtendo ajuda ..................................................................................................................... 7

Gerenciamento de desempenho e capacidade (SharePoint Server 2010) ........................ 8

Capacity management and sizing for SharePoint Server 2010 (em inglês) ..................... 10

Visão geral do gerenciamento da capacidade e dimensionamento do SharePoint Server

2010 ............................................................................................................................... 11

Glossário ........................................................................................................................ 11

Quem deve ler os artigos sobre gerenciamento de capacidade? ................................. 12

Quatro fundamentos de desempenho ........................................................................... 14

Gerenciamento de capacidade versus planejamento de capacidade ........................... 19

Superdimensionamento versus subdimensionamento .................................................. 21

Limites e delimitadores de software .............................................................................. 22

Principais diferenças: SharePoint Server 2010 versus Office SharePoint Server 200724

Diferenciadores de chave de implantação do SharePoint Server 2010 ........................ 32

Arquiteturas de referência ............................................................................................. 34

Consulte também ........................................................................................................... 38

Planejamento de capacidade para SharePoint Server 2010 ............................................ 40

Etapa 1: Modelo ............................................................................................................. 40

Etapa 2: Design ............................................................................................................. 49

Etapa 3: Piloto, Teste e Otimização .............................................................................. 53

Etapa 4: Implantação ..................................................................................................... 55

Etapa 5: Monitoração e Manutenção ............................................................................. 56

Consulte também ........................................................................................................... 56

Testes de desempenho para SharePoint Server 2010 ..................................................... 57

Criar um plano de teste ................................................................................................. 58

Criar o ambiente de teste .............................................................................................. 58

Crie testes e ferramentas .............................................................................................. 60

Consulte também ........................................................................................................... 64

Monitorando e mantendo o SharePoint Server 2010 ....................................................... 66

Configurando o monitoramento ..................................................................................... 66

Removendo afunilamentos ............................................................................................ 77

Consulte também ........................................................................................................... 80

Gerenciamento de capacidade do SharePoint Server 2010: limites de software ............ 81

Visão geral de delimitadores e limites ........................................................................... 82

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

Performance and capacity technical case studies (SharePoint Server 2010) (em inglês)

..................................................................................................................................... 129

Ambiente de publicação na intranet da empresa do Microsoft SharePoint Server 2010:

análise técnica ............................................................................................................. 131

Informações sobre pré-requisitos ................................................................................ 131

Introdução a este ambiente ......................................................................................... 131

Especificações ............................................................................................................. 132

Carga de trabalho ........................................................................................................ 137

Conjunto de dados ....................................................................................................... 137

Dados de integridade e desempenho .......................................................................... 138

Enterprise intranet collaboration environment technical case study (SharePoint Server

2010) (em inglês) ......................................................................................................... 141

Prerequisite information ............................................................................................... 141

Introduction to this environment .................................................................................. 141

Specifications ............................................................................................................... 142

Health and Performance Data ..................................................................................... 148

Enterprise intranet collaboration environment lab study (SharePoint Server 2010) (em

inglês) .......................................................................................................................... 151


Glossary ....................................................................................................................... 152

Overview ...................................................................................................................... 153

Specifications ............................................................................................................... 154

Results and Analysis ................................................................................................... 160

Departmental collaboration environment technical case study (SharePoint Server 2010)

(em inglês) ................................................................................................................... 172



Specifications ............................................................................................................... 173

Workload ...................................................................................................................... 180

Dataset......................................................................................................................... 180


Divisional portal environment lab study (SharePoint Server 2010) (em inglês) ............. 184


Glossary ....................................................................................................................... 185

Overview ...................................................................................................................... 186

Specifications ............................................................................................................... 187

Results and analysis .................................................................................................... 193

About the authors ........................................................................................................ 207

Social environment technical case study (SharePoint Server 2010) (em inglês) ........... 208



Specifications ............................................................................................................... 209

Workload ...................................................................................................................... 214

Dataset......................................................................................................................... 215


Recomendações e resultados de testes de desempenho e capacidade (SharePoint

Server 2010) ................................................................................................................ 219

Estimate performance and capacity requirements for Access Services in SharePoint

Server 2010 (em inglês) .............................................................................................. 222

Test farm characteristics.............................................................................................. 222

Test results .................................................................................................................. 225

Recommendations ....................................................................................................... 235

Troubleshooting ........................................................................................................... 240

Estimate performance and capacity requirements for Excel Services in SharePoint Server

2010 (em inglês) .......................................................................................................... 242


Test Results ................................................................................................................. 245


Estimar os requisitos de desempenho e capacidade dos Serviços PerformancePoint . 261

Características do farm de teste .................................................................................. 261

Cenários e processos de teste .................................................................................... 262

Configuração e topologia de hardware ........................................................................ 264

Resultados do teste ..................................................................................................... 265

Topologias 2C e 3C ..................................................................................................... 267

Resultados para mais de 4C com autenticação da Conta de Serviço sem Supervisão

.................................................................................................................................. 271

Resultados para mais de 4C com autenticação por usuário ....................................... 272

Recomendações .......................................................................................................... 273

Analysis Services ......................................................................................................... 275

Afunilamentos comuns e suas causas ........................................................................ 275

Monitoramento de desempenho .................................................................................. 278

Consulte também ......................................................................................................... 279

Capacity requirements for Web Analytics Shared Service in SharePoint Server 2010 (em

inglês) .......................................................................................................................... 281

Introduction .................................................................................................................. 281

Hardware specifications and topology ......................................................................... 284

Capacity requirements ................................................................................................. 288

Consulte também ......................................................................................................... 292

Estimar os requisitos de desempenho e capacidade do Gerenciamento de conteúdo da

Web no SharePoint Server 2010 ................................................................................. 293

Informações sobre pré-requisitos ................................................................................ 294

Detalhes e abordagem do teste .................................................................................. 294

Implantações de Gerenciamento de Conteúdo da Web ............................................. 297

O que otimizar ............................................................................................................. 297

Resultados do teste e recomendações ....................................................................... 302

Sobre os autores ......................................................................................................... 324

Estimate performance and capacity planning for workflow in SharePoint Server 2010 (em

inglês) .......................................................................................................................... 325


Test results .................................................................................................................. 329


Troubleshooting ........................................................................................................... 338

Consulte também ......................................................................................................... 341

Planejamento e configuração de armazenamento e capacidade do SQL Server

(SharePoint Server 2010) ............................................................................................ 342

Processo de design e configuração do armazenamento e da camada do banco de

dados dos Produtos SharePoint 2010 ..................................................................... 342

Coletar requisitos de armazenamento e de espaço e E/S do SQL Server ................. 343

Escolher a versão e a edição do SQL Server ............................................................. 352

Projetar a arquitetura de armazenamento com base em requisitos de capacidade e E/S

.................................................................................................................................. 353

Estimar requisitos de memória .................................................................................... 355

Entender os requisitos de topologia de rede ............................................................... 356

Configurar o SQL Server ............................................................................................. 357

Validar e monitorar o desempenho do armazenamento e do SQL Server ................. 361

7

Obtendo ajuda

Todo 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

8

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.


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.


(SharePoint Server 2010)

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

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

9

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

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

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

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

10

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:


Server 2010




11

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


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

12

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:


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


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:

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

13


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:


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:


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:


Server 2010)

Para obter informações sobre dimensionamento e desempenho, consulte o seguinte artigo:



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:


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

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

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

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

14

Para obter informações adicionais sobre gerenciamento de capacidade, consulte os seguintes artigos complementares a este artigo de visão geral:




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:


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:


Server 2010)

Para obter informações sobre dimensionamento e desempenho, consulte o seguinte artigo:



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:



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:




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

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

15

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.

16

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.

17

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:

18

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.



19

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

20

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.

21

Defina objetivos de desempenho e confiabilidade do farm.

Analise os logs do IIS do SharePoint Server 2010.

Etapa 2: Design Depois de coletar os dados na Etapa 1, você poderá projetar seu

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

22

Ao projetar seu farm, verifique se ele pode atender aos objetivos de desempenho e de capacidade estabelecidos, tanto sob cargas de pico regulares como para picos inesperados. O design, os testes e a 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.

23

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


24

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

25

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

CPU do servidor de aplicativos

RAM do servidor de aplicativos:

CPU do SQL Server

IOPS do SQL Server

Armazenamento do SQL Server

Serviço do

SharePoint

XXX XXX XX XXX XXX

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

26

Aplicativo de

Serviço

CPU do servidor Web

RAM do servidor Web



CPU do SQL Server

IOPS do SQL Server


Foundation

Serviço da

Administração

Central

XX XX X X X

Serviço de Log * XX XX XX XXX XXX

Serviço de

Pesquisa do SharePoint

XXX XXX XXX XXX XXX XXX XXX

Aplicativo de

serviço de

Exibição do Word

*

X X XXX XX

Serviço

PowerPoint *

XX XX XXX XX

Serviço de

Cálculo do Excel

XX X XX XXX

Serviço do Visio * X X XXX XXX X X X

Serviço do

Access *

X X XXX XX X X X

Serviço de Perfil

de Usuário

X XX XX XX XXX XXX XX

Serviço de

Metadados Gerenciados *

X XX XX XX X X XX

Serviço do Web

Analytics *

X X XXX XXX XXX

Serviço de

Conectividade de Dados Corporativos *

XX 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

27

Aplicativo de

Serviço

CPU do servidor Web

RAM do servidor Web



CPU do SQL Server

IOPS do SQL Server


Aplicativo de

Serviço do

PerformancePoint *

XX XX XXX XXX X X X

Serviço do

Project *

X X X X XXX XXX XX

Soluções de Área

Restrita *

X X XXX XXX

Recursos de fluxo de trabalho *

XXX XXX

Serviço de Timer XX XX XX XX

PowerPivot * X X XXX XXX XX XX 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,

28

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



29

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

30

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

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

31

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

32

SharePoint Server, nas quais ele for um recurso de uso frequente, você deverá

esperar carga adicional nos servidores Web.

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

farm do SharePoint Server de uma forma semelhante à 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

33

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

34

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.

35

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.

36

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

37

conteúdo e dos bancos de dados de serviços de aplicativo habilitados no farm. Espera-se 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.

38

Consulte também Conceitos





39

Recomendações e resultados de testes de desempenho e capacidade (SharePoint Server 2010)


Outros recursos

Hardware and software requirements (SharePoint Server 2010)


40


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.

41

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


Social


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)

42

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

43

44

Estimando sua carga de trabalho de produção

45

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

46

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-a3f7-2e0be6d5532e&displaylang=en).

É possível baixar o Analisador de Logs 2.2 pelo site http://www.microsoft.com/downloads/en/details.aspx?FamilyID=890CD06B-ABF8-4C25-91B2-F8D975CF8C07&displayLang=en.

Conjunto de dados

O conjunto de dados descreve o volume de 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.

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

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

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

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

47

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

48

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.

49

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

(Padrão

ou virtual)

Número de

computadores

Processamentos RAM IOPS

necessário

Tamanho do disco SO+Log

Unidade de dados

Servidores Web

Virtual 4 4 núcleos 8 N/A 400 GB N/A

Servidor de banco de dados de

conteúdo

Padrão 1 cluster 4 núcleos

quádruplos 2.33

(GHz)

48 2 mil 400 GB 20 discos de 300 GB

A 15 mil RPM

50

Função Tipo

(Padrão

ou virtual)

Número de

computadores

Processamentos RAM IOPS

necessário

Tamanho do disco SO+Log

Unidade de dados

Servidores de aplicativos


Servidor Web de Destino de Rastreamento de Pesquisa


Servidor de Consulta de Pesquisa

Padrão 2 2 núcleos

quádruplos 2.33

(GHz)

32 N/A 400 GB 500 GB

Servidor do Rastreador de Pesquisa

Padrão 2 2 núcleos

quádruplos 2.33

(GHz)

16 400 400 GB N/A

Servidor de banco de dados de Rastreamento de Pesquisa


quádruplos 2.33

(GHz)

48 4 mil (ajustado para leitura)

100 GB 16 discos de 150 GB a 15 mil RPM

Banco de dados de

Repositório

de Propriedades de Pesquisa + Servidor de banco de dados de

administração


quádruplos 2.33

(GHz)

48 2 mil (ajustado para gravação)

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

51

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/pt-br/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/71c203cd-7534-47b0-9122-657d72ff0080(Office.14).aspx).

Diretrizes de seleção de hardware

Escolhendo processadores

http://technet.microsoft.com/pt-br/library/cc261716.aspx




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

52

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

53

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

54

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.

55

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

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

56

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 indicadores-chave 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:


Solução de problemas (http://blogs.msdn.com/b/ecm/archive/2010/06/22/variations-propagate-pages-on-your-terms.aspx)





Planejamento e configuração de armazenamento e capacidade do SQL Server (SharePoint Server 2010)

Outros recursos



http://blogs.msdn.com/b/ecm/archive/2010/06/22/variations-propagate-pages-on-your-terms.aspx


57


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

58

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.

59

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

60

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-427a-81c3-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

http://msdn.microsoft.com/pt-br/library/fda2bad5.aspx

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

61

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

62

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

in dele e publicá-lo. Também é necessário o estado de reserva entre as etapas – por

63

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



64

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.





65


Outros recursos



66


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:



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

de Eventos

Desabilitado O valor padrão é

Habilitado. Ele pode ser desabilitado para coletar a quantidade



67


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.

Provedores de Diagnóstico

Habilitar todos os provedores de

diagnóstico

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

68


padrão.

Definir intervalos de agendamento de "job-diagnostics-performance-counter-wfe-provider" e "job-diagnostics-performance-counter-sql-provider"

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


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


Desabilitado. Se essa

configuração for

habilitada,

permitirá o

diagnóstico de

páginas lentas ou

69


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

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

Habilitado 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 Add-SPDiagnosticsPerformanceCounter do PowerShell para adicionar o contador % Tempo de Processador ao banco de dados de uso. Isso só precisa ser executado em um dos servidores Web:

Código da cópia

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

70

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.

71

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

Disco

O número médio de solicitações de

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.

72


- 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

73


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

74


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.


geração 1 foram submetidos a coleta de lixo

desde que o aplicativo foi iniciado.


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.


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

75


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

76


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

77


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.

78

Objetos e contadores Problema Opções de resolução

Processador

Processador - % Tempo de Processador

Mais de 75-85% Atualizar o processador

Aumentar o número de

processadores

Adicionar servidor(es)

Disco

Comprimento Médio da Fila

de Disco

Aumentando gradualmente;

o sistema não está em um

estado de equilíbrio e a fila

está aumentando

Aumentar o número ou a

velocidade dos discos

Alterar configuração de matriz

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


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


Páginas/s Mais de 10 Adicionar memória

Arquivo de Paginação

79


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

Adicionar memória

NIC

Total de Bytes/s Mais de 40-50% da

capacidade da rede. Essa é

a taxa à qual os dados são

enviados e recebidos

através da placa de

interface de rede.

Continuar a investigar monitorando Bytes recebidos/s e Bytes Enviados/s

Reavaliar a velocidade da placa de rede de interface

Verificar o número, tamanho e

uso de buffers de memória

Processo

Conjunto de Trabalho Mais de 80% da memória

total

Adicionar memória

% Tempo de Processador Mais de 75-85%. 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

80


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






Outros recursos



81


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

82

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.

83

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

84

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.

85

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

se 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

Os caminhos

gerenciados são

armazenados em cache

86


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 Set-SPInfoPathFormsService do Windows PowerShell. Para obter mais

informações, consulte

Set-SPInfoPathFormsService.

Servidor Web e limites de servidor de aplicativos

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

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

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

87


Observações

Pools de aplicativos 10 por servidor Web Com suporte

O número máximo é

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.


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

88


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

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




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




89


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

90


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 Set-SPContentDatabase do Windows PowerShell com o

parâmetro -

WarningSiteCount. Para obter mais

informações,

consulte Set-SPContentDatabase.

Subsistema de armazenamento RBS (Remote BLOB Storage) no Armazenamento NAS (Network Attached Storage)

O tempo até o primeiro

byte de qualquer resposta do NAS não pode exceder

20 milissegundos

Delimitador Quando o SharePoint Server 2010 estiver configurado para usar o RBS, e os BLOBs residirem no armazenamento NAS, considere o delimitador a seguir.

Do momento em que o SharePoint Server 2010 solicita um

BLOB até o

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

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

91


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.


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

92


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

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

Limites de listas e bibliotecas

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

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

93

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


Observações

Tamanho de linha de lista

8.000 bytes por linha

Limite Cada item da biblioteca ou lista pode ocupar apenas um total de 8000 bytes no banco de dados. 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.

Tamanho do arquivo

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

Documentos 30.000.000 por biblioteca

Com suporte

Você pode criar bibliotecas de documentos

muito grandes aninhando pastas ou usando

a hierarquia de sites e modos de 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 Com suporte

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 lista

Com 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 tabela internas ao banco de dados usadas para uma lista ou um item da biblioteca

Com suporte

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 é

94


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

massa

100 itens por

operação em

massa

Delimitador A interface do usuário permite que no

máximo 100 itens sejam selecionados para

operações em massa.

Limite de pesquisa no modo de

exibição de lista

8 operações de

junção por

consulta

Limite 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 de exibição de

lista

5.000 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 de exibição de

lista para auditores e administradores

20.000 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

de exibição de

site

Limite 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 Limite O número máximo recomendado de

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

95


Observações

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

simultâneos por

documento

editores simultâneos é 10. O limite é 99.

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.

96

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.


Tamanho por coluna

Observações

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





384 colunas de Opção por lista

97


Tamanho por coluna

Observações

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





72 colunas de Número por lista

do SharePoint (6 * 12 = 72).

Moeda 72 Limite 12 bytes A disposição de linhas do SQL





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




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


colunas em uma lista do SharePoint. O valor de disposição padrão de seis


96 colunas de Pesquisa de

valor único por lista do

SharePoint (6 * 16 = 96).

98


Tamanho por coluna

Observações

Sim/Não 96 Limite 5 bytes A disposição de linhas do SQL





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


colunas em uma lista do SharePoint. O valor de disposição padrão de seis


96 colunas de Pessoa ou Grupo por lista do SharePoint (6 * 16 = 96).

Hiperlink ou imagem






192 colunas de Hiperlink ou Imagem por lista do SharePoint

(6 * 32 = 192); 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




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

99


Tamanho por coluna

Observações

coluna em uma lista do SharePoint. O valor de disposição padrão de seis


seis colunas de GUID por lista do SharePoint (6 * 1 = 6).

Inteiros 96 Limite 4 bytes A disposição de linhas do SQL





96 colunas de Inteiros por lista do SharePoint (6 * 16 = 96).

Metadados gerenciados

94 Limite 40 bytes para a primeira e 32 bytes para cada uma subsequente

São alocadas quatro colunas

para o primeiro campo de Metadados Gerenciados adicionado a uma lista:

Um campo de pesquisa

para a marca real

Um campo de texto oculto

para o valor da cadeia de

caracteres


para o mecanismo de

coleta


para transmissão do

mecanismo de coleta

Cada campo de Metadados Gerenciados subsequente adicionado a uma lista adiciona duas colunas:


para a marca real

Um campo de texto oculto

para o valor da cadeia de

caracteres

O número máximo de colunas

de Metadados Gerenciados é

calculado como (14 (16 * (n-1))), em que n é o valor de

100


Tamanho por coluna

Observações

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.


Observações

Web parts 25 por wiki ou página de Web

parts

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

101

Limites de segurança


Observações

Número de grupos do

SharePoint aos quais um

usuário pode pertencer

5.000 Com suporte

Esse não é um imite rígido,

mas é consistente com as

diretrizes do Active Directory.

Há vários itens que afetam

esse número:

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.

Usuários em um conjunto

de sites

2 milhões por conjunto

de sites

Com suporte

Você pode adicionar milhões

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

102


Observações

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

5.000 por grupo do SharePoint

Com suporte

O SharePoint Server 2010 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.

Grupo do SharePoint 10.000 por conjunto de sites

Com suporte

Acima de 10.000 grupos, o

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:

tamanho do Escopo de

Segurança

5.000 por ACL (Lista de Controle de Acesso)

Com suporte

O tamanho do escopo afeta

os dados que são usados

para um cálculo de

103


Observações

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.


Observações

Aplicativos de

serviço de pesquisa

do SharePoint

20 por farm 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

10 bancos de dados de rastreamento por aplicativo

de serviço de pesquisa

25 milhões de itens por

banco de dados de rastreamento

Limite O banco de dados de rastreamento armazena dados de rastreamento (tempo/status etc.) sobre todos os itens que foram rastreados. O limite com suporte é 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

104


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


de pesquisa; total de 128

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

105


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

serviço de pesquisa; 10

milhões por partição de índice

Com suporte

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 rastreamento

100 milhões por aplicativo de

pesquisa

Com suporte

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


de pesquisa; total de 128

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

106


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.

Grupos de exibição 25 por site 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

107


Observações

de escopo na interface de

administração de

pesquisa.

Alertas 1.000.000 por aplicativo 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


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

108


Observações

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


de pesquisa

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

Remoções de URL 100 remoções por operação Com suporte

Esse é o número máximo

recomendado de URLs que devem ser removidas do sistema em uma

operação.

Páginas

autoritativas

1 página de nível superior e o

mínimo de páginas de

segundo e terceiro nível por


pesquisa

Limite 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

109


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

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

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

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

110

A tabela a seguir lista as diretrizes recomendadas para o Serviço de Perfil de Usuário.


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.

Etiquetas de conteúdo social,

observações e classificações

500.000.000 por banco de dados social

Com suporte

Há suporte

para um total

de até 500

milhões de

111


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.


Observações

Trabalhos de implantação de

conteúdo executados

em caminhos diferentes

20 Com suporte

Para trabalhos de execução

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.

112


Observações

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.


Observações

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

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

113


Observações

ECTs (Tipos de Conteúdo

Externo) (na memória)

5000 por servidor Web (por

locatário)

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

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 Número de itens

por solicitação que

o conector de

114


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.


Observações

Limite de adiamento de fluxo de trabalho

15 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

115


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 Set-SPFarmConfig do Windows PowerShell. Para obter mais informações,

consulte Set-SPFarmConfig.

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,

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

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

116


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 fluxo de trabalho

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

117


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.


Observações

Número máximo de

níveis de termos

aninhados em um

repositório de termos

7 Com suporte

Os termos em um conjunto de 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).

Número máximo de

conjuntos de termos em

um repositório de

termos

1000 Com suporte

Pode haver até 1000 conjuntos

de termos em um repositório de

termos.

Número máximo de

termos em um conjunto de termos

30.000 Com suporte

O número máximo de termos

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

1.000.000 Com suporte

Um item é um termo ou um

conjunto de termos. A soma do

número de termos e conjuntos

118


Observações

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.


Observações

Tamanho de arquivo de desenhos da Web do Visio

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

Aumento do uso da CPU.

Redução das solicitações

de servidor de aplicativos

por segundo.

Aumento da latência total.

119


Observações

Aumento da carga de rede

de farm do SharePoint.

Tempo limite de

recálculo de desenhos

da Web do Visio

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

do Serviços do Visio

(diagramas conectados a dados)

Idade mínima do cache:

0 a 24 horas

Limite A idade mínima do cache se

aplica a diagramas conectados a dados. Ela determina o primeiro momento em que o diagrama atual pode ser removido do cache.

A 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

120


Observações

a recalcular com frequência e

reduz a disponibilidade da CPU

e da memória.

Idade máxima do cache

do Serviços do Visio

(diagramas não

conectados a dados)

Idade máxima do cache:

0 a 24 horas

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


Observações

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 O número

121


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.

122

Limites do Word Automation Services

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


Observações

Tamanho do arquivo de entrada

512 MB Delimitador Tamanho máximo de arquivo que

pode ser processado pelo Word Automation Services.

Frequência para

iniciar as

conversões

(minutos)

1 minuto

(recomendado)

15 minutos (padrão)

59 minutos (limite)

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

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)

Limite 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

Com suporte

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

123


Observações

execução do método Start e o número

de bytes transmitidos ao servidor de aplicativos.

Total de processos

de conversão

ativos

N-1, em que N é o

número de núcleos

em cada servidor de aplicativos

Limite 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

de conversão

Com suporte

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 Remove-SPWordConversionServiceJobHistory do Windows PowerShell. Para obter

mais informações, consulte Remove-

SPWordConversionServiceJobHistory.

Limites do SharePoint Workspace

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


Sincronização do SharePoint

Workspace

30.000 itens por lista Delimitador O SharePoint

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

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

124


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

Delimitador Os usuários

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.


Observações

Número de Seções e

Grupos de Seções em

um Bloco de Anotações

Consulte o limite para "Documentos" em Limites de lista e

Cada seção conta como uma

pasta e um documento na

lista. Cada grupo de seções

125


Observações

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.

O limite padrão é o

dobro do limite de "Tamanho de arquivo".

Limite 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

126


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

Uma por núcleo de

CPU por servidor Web

Delimitador O OneNote mescla

alterações combinadas de

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.


Observações

Tamanho do cache 100 GB Limite Espaço

disponível

para renderizar documentos, criados como

127


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.


Horário do final do projeto Data: 31/12/2049 Delimitador Planos do

Project não

podem ultrapassar a data de

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

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

128


31/12/2049.

Produtos por plano de projeto 1500 produtos Delimitador Planos do

Project não

podem conter mais de 1500 produtos.

Número de campos em um

modo de exibição

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

Número de cláusulas em um

filtro para um modo de exibição

50 Delimitador Um usuário

não pode

adicionar um filtro a um modo

de exibição

que contenha mais de 50 cláusulas.

129


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)

130

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.

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

131

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:


Server 2010


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

132

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

133

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


Serviço de Consulta de Pesquisa e

Configurações do Site

Pesquisa do SharePoint Server

134

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


Armazenamento e geometria (1,25 TB * 6) + 3 TB

Discos 1-4: Dados SQL

Disco 5: Logs

Disco 6: TempDB


Velocidade do adaptador de rede 1 Gigabit

Autenticação Windows NTLM

Versão do software SQL Server 2008

Topologia

O seguinte diagrama mostra a topologia desse farm.

135

Configuração

136

A tabela abaixo enumera configurações que foram alteradas e que afetam o desempenho ou a capacidade do ambiente.


Administração de

Conjunto de Sites:

Cache de saída do

conjunto de sites

Ativado 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 conjunto de sites (selecionar)

Intranet (Site de

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 (Desativado | n MB)

Ativado –

500 MB

O padrão é 100 MB. O aumento dessa configuração

permite o armazenamento de mais dados na memória do

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 de Consulta em Log:

Microsoft SharePoint Foundation Banco

de dados –

configurar QueryLoggingThreshold para 1 segundo

1 segundo O padrão é 5 segundos. Baixar essa configuração pode

economizar largura de banda e CPU no servidor do banco de dados.

Servidor de

Banco de Dados –

Instância Padrão:

Grau máximo de

paralelismo

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




137

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

dia

33.580

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

138

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

itens)

275.000

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

(solicitações de clientes de pesquisa/total de

solicitações)

6%

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.

139

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.

140

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

de Dados)

99,999:0,001

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%

141

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:



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

142

your planned design is similar, you can use the deployment described here as a starting point for your own installation.

This document includes the following:

Specifications, which include hardware, topology, and configuration.

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

the usage characteristics.

Dataset that includes database sizes.

Health and performance data that is specific to the environment.

This document is part of a series of Performance and capacity technical case studies (SharePoint Server 2010) (em 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.

143

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

144

Web Server WFE1-4

Business Data Connectivity Service

Managed Metadata Web Service

Application Server

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

Application Server APP1-4

Processor(s) 4 six core @ 2.40 GHz

RAM 64 GB

OS Windows Server 2008, 64 bit







Services running locally Office Web Apps

Excel

PowerPoint

Secure Store

Usage and Health

State Service

Database Servers

There is a SQL cluster with 2 database servers, each with identical hardware, one of the servers is active and the other is passive for redundancy.

Database Server DB1-2


RAM 32 GB

OS Windows Server 2008, 64-bit

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

145


Disk 1-4: SQL Data

Disk 5: Logs

Disk 6: TempDB




Software version SQL Server 2008

Topology

The following diagram shows the topology for this farm.

146

Configuration

147

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

Setting Value Notes

Usage Service

Trace Log – days to store

log files (default: 14 days)

5 days The default is 14 days. Lowering this setting can save disk space on the server where the log files are stored.

QueryLoggingThreshold

SharePoint Foundation Database – change

QueryLoggingThreshold to 1 second

1 second

The default is 5 seconds. Lowering this setting can save bandwidth and CPU on the database server.

Database Server –

Default Instance

Max degree of parallelism

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

Workload

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

Workload Characteristics Value

Average Requests per Second (RPS) 157

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

Total number of unique users per day 69,702

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%

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


148


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%

149

Metric Value

ASP.NET Requests Queued 0.00

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

150

In this document, latency is divided into four categories. The 50th percentile latency is typically used to measure the 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%

151

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:


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.


Specifications, which include hardware, topology, and configuration

The workload, which is the demand on the farm, includes the number of users, and

the usage characteristics

The dataset, such as database sizes

Test results and analysis for scaling out Web servers

Test results and analysis for scaling up Web servers

Test results and analysis for scaling out database servers

152

Comparison between Microsoft Office SharePoint Server 2007 and SharePoint

Server 2010 about throughput and effect on the web and database servers

The SharePoint Server 2010 environment described in this document is a lab environment that mimics a production environment at a large company. The production environment hosts very important team sites and publishing portals for internal teams for enterprise collaboration, organizations, teams, and projects. Employees use that production environment to track projects, collaborate on documents, and share information within their organization. The environment includes a large amount of small sites used for ad-hoc projects and small teams. For details about the production environment, see Enterprise intranet collaboration environment technical case study (SharePoint Server 2010) (em 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.


Server 2010


Also, we encourage you to read the following:



Glossary There are some specialized terms that you will encounter in this document. Here are some key terms and their definitions.

RPS: Requests per second. The number of requests received by a farm or server in

one second. This is a common measurement of server and farm load.

Note that requests differ from page loads; each page contains several components, each of which creates one or more requests when the page is loaded. Therefore, one page load creates several requests. Typically, authentication checks and events using insignificant resources are not counted in RPS measurements.

Green Zone: This is the state at which the server can maintain the following set of

criteria:

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

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

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:

153

HTTP request throttling feature is enabled, but no 503 errors (Server Busy) are

returned.

Failure rate is less than 0. 1%.

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

Database server CPU utilization is less than 80%, which allows for 10% to be

reserved for the Search crawl load, limited by using SQL Server Resource

Governor.

AxBxC (Graph notation): This is the number of Web servers, application servers,

and database servers respectively in a farm. For example, 8x1x2 means that this

environment has 8 Web servers, 1 application server, and 2 database servers.

MDF and LDF: SQL Server physical files. For more information, see Files

and Filegroups Architecture.

Overview This section provides an overview to our scaling approach, to the relationship between this lab environment and a similar case study environment, and to our test methodology.

Scaling approach

This section describes the specific order that we recommend for scaling servers in your environment, and is the same approach we took for scaling this lab environment. This approach will enable you to find the best configuration for your workload, and can be described as follows:

First, we scaled out the Web servers. These were scaled out as far as possible under

the tested workload, until the database server became the bottleneck and was

unable to accommodate any more requests from the Web servers.

Second, we scaled out the database server by moving half of the content databases

to another database server. At this point, the Web servers were not creating

sufficient load on the database servers. Therefore, they were scaled out additionally.

In order to test scale up, we tried another option which is scaling up the Web servers

instead of scaling them out. Scaling out the Web servers is generally preferred over

scaling them up because scaling out provides better redundancy and availability.

Correlating the lab environment with a production environment

The lab environment outlined in this document is a smaller scale model of a production environment at Microsoft, and although there are significant differences between the two environments, it can be useful to examine them side by side because both are enterprise collaboration environments where the patterns observed should be similar.

The lab environment contains a subset of the data from the production environment, and also some modifications to the workload. This influences the test results with regard to Web server memory usage, because the object cache on the production environment receives a larger amount of hits on unique sites, and therefore uses more memory. The lab environment also has less data, and most of it is cached in memory as opposed to the production environment which carries over seven terabytes of data, so that the database server on the production environment is required to perform more disk reads than the database server in the lab environment. Similarly, the hardware that was used in the lab environment is significantly different from the production environment it models,

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


154

because there is less demand on those resources. The lab environment relies on more easily available hardware.

To get a better understanding of the differences between the environments, read the Specifications section in this document, and compare it to the specifications in the Enterprise intranet collaboration environment technical case study (SharePoint Server 2010) (em 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





155

Web Server WFE1-8 and APP1

Load balancer type Windows NLB

Services running locally WFE 1-8: Basic Federated Services. This included the following: Timer Service, Admin Service, and Trace Service. APP1: Word

Automation Services, 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)

156

Database Server – Default Instance DB1-2




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

Topology

The following diagram shows the topology in this lab environment:

157

Configuration

158

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

Setting Value Notes

Site Collection

Blob Caching On The default is Off. Enabling Blob Caching improves server efficiency by reducing calls to the database server for static page resources that may be frequently requested.

Database

Server – Default

Instance


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

Workload

The transactional mix for the lab environment described in this document resembles the workload characteristics of a production environment at Microsoft. For more information about the production environment, see Enterprise intranet collaboration environment technical case study (SharePoint Server 2010) (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.




159

Dataset

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


Database size (combined) 130 GB

BLOB size 108.3 GB


Number of site collections 181


160


Number of sites 1384

Results and Analysis The following results are ordered based on the scaling approach described in the Overview section of this document.

Web Server Scale Out

This section describes the test results that were obtained when we scaled out the number of Web servers in this lab environment.

Test methodology

Add Web servers of the same hardware specifications, keeping the rest of the farm

the same.

Measure RPS, latency, and resource utilization.

Analysis

In our testing, we found the following:

The environment scaled up to four Web servers per database server. However, the

increase in throughput was non-linear especially on addition of the fourth Web server.

After four Web servers, there are no additional gains to be made in throughput by

adding more Web servers because the bottleneck at this point was the database

server CPU Utilization.

The average latency was almost constant throughout the whole test, unaffected by

the number of Web servers and throughput.

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.

161

2. Processor utilization

The following graph shows how scaling out the Web servers affects processor utilization on the Web server(s) and the database server.

162

3. SQL Server I/O operations per section (IOPs) for MDF and LDF files

The following graphs show how the IOPs on the content databases change as the number of Web servers is scaled out. These are measured by looking at the following performance counters:

PhysicalDisk: Disk Reads / sec

PhysicalDisk: Disk Writes / sec

In this lab environment, we determined that our data on IOPs was not representative of a production environment because our dataset was so small that we could fit much more of it in cache than would be possible in the production environment we are modeling. We calculated projected reads by multiplying the value of the data we had from the lab for writes/second by the ratio of reads to writes in our production environment. The results in this section are averages. But there are also spikes that occur during certain operations which have to be accounted for. To learn more about how to estimate IOPs needed, see Planejamento e configuração de armazenamento e capacidade do SQL Server (SharePoint Server 2010).

Maximum:

163

Green Zone:

Example of how to read these graphs:

164

An organization with a workload similar to that described in this document that expects 300 RPS to be their green zone, could use 3x1x1 topology, and would use approximately 600 Physical Disk reads/sec on the MDF file.

Database Server Scale Out

This section describes the test results that were obtained when we scaled out the number of database servers in this lab environment.

Test methodology

Have two content databases on one database server, and then split them to two

servers to effectively double the processor cores and memory available to the

database servers in the environment.

Keep the total IOPs capacity constant even while adding a database server. This

means that the number of reads/sec and writes/sec that the disks could perform for

each content database did not change despite splitting the content onto two

database servers instead of one.

Analysis

The first bottleneck in the 4x1x2 environment was the database server CPU

utilization. There was close to a linear scale when we added more processor and

memory power.

Scaling to four Web servers and 2 database servers did not provide much additional

RPS because the CPU utilization on the Web servers was close to 100%.

When we scaled out database servers (by adding one additional database server)

and added four Web servers, performance scaled almost linearly. The bottleneck at

that point shifted from being the database server CPU utilization to the content

database disk IOPs.

No additional tests were performed in this lab environment to scale out past 8x1x2.

However we expect that additional IOPs capacity would additionally increase

throughput.

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

observed


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

1. Latency and RPS

The following graph shows how scaling out both Web servers and database servers affects latency and RPS.

165

2. Processor utilization

The following graphs show how scaling out affects processor utilization.

166

3. Memory utilization at scale out

Throughout our testing, 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

167

Green Zone RPS

Web server Scale Up

This section describes the test results that were obtained when we scaled up the Web servers in this lab environment.

168

Test methodology

Add more Web server processors, but keep the rest of the farm the same.

Analysis

Scale is linear up to eight processor cores.

Tests show that the environment can take advantage of a twenty-four core box,

although there is some degradation as twenty-four cores are approached.


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

Comparing SharePoint Server 2010 and Office SharePoint Server 2007

This section provides information about how the capacity testing for this workload varied between SharePoint Server 2010 and Microsoft Office SharePoint Server 2007.

Workload

To compare SharePoint Server 2010 with Office SharePoint Server 2007, a different test mix was used than the one outlined in the Specifications section, because some SharePoint Server 2010 operations were not available in Office SharePoint Server 2007. The test mix for Office SharePoint Server 2007 is inspired by the same production

169

environment that the SharePoint Server 2010 tests follow. However this was recorded before the upgrade to SharePoint Server 2010 on that environment.

The following graph shows the test mix for the lab and production environments for Office SharePoint Server 2007.

Test methodology

The tests performed for this comparison were performed by creating an Office

SharePoint Server 2007 environment, testing it with the workload outlined earlier in

this section, and then upgrading the content databases to SharePoint Server 2010

without changing the clients using the environment, nor doing a visual upgrade. This

upgraded environment was then re-tested for the SharePoint Server 2010 results

with the same test mix which includes only Office SharePoint Server 2007

operations.

The dataset was not modified after the content database upgrade for the SharePoint

Server 2010 tests.

The test mix for Office SharePoint Server 2007 excludes any new SharePoint Server

2010 specific operations, and resembles the enterprise intranet collaboration solution

on the same production environment for Office SharePoint Server 2007, as described

under the Workload section.

Analysis

When the same number of Web servers are stressed to their maximum throughput

on SharePoint Server 2010 and Office SharePoint Server 2007, SharePoint Server

2010 achieves 20% less throughput compared to Office SharePoint Server 2007.

When the Web servers were scaled out to maximize the database server usage,

SharePoint Server 2010 was able to achieve 25% better throughput compared to

170

Office SharePoint Server 2007. This reflects the improvements that were made in

SharePoint Server 2010 to sustain larger deployments.

When the web servers were scaled out to maximize the database server usage,

SharePoint Server 2010 was SQL Server CPU Utilization bound, whereas Office

SharePoint Server 2007 was Lock bound on the database tier. This means that

increasing the processing power available to the database servers enables

SharePoint Server 2010 to achieve better throughput than would be possible with the

same hardware using Office SharePoint Server 2007. This is caused by the locking

mechanisms in the database in Office SharePoint Server 2007 which are unaffected

by improved hardware so that we were unable to push the database server‘s CPU

Utilization past 80%.

As a result of these findings outlined earlier in this section, on Office SharePoint

Server 2007 the maximum throughput possible was achieved in a 5x0x1 topology

whereas in SharePoint Server 2010 the maximum throughput possible with the same

workload was achieved in a 7x0x1 topology, and yielded a 25% increased total RPS.


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

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

171

172

Departmental collaboration environment technical case study (SharePoint Server 2010) (em inglês)

This document describes a specific deployment of Microsoft SharePoint Server 2010. It includes the following:


and configuration

The workload that includes the number, and types, of users or clients, and

environment usage characteristics

Technical case study farm dataset that includes database contents and Search

indexes

Health and performance data that is specific to the environment

In this article:



Specifications

Workload

Dataset





Server 2010


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

173

your planned design is similar, you can use the deployment described here as a starting point for your own installation.


Specifications, which include hardware, topology and configuration



Dataset that includes database sizes



The SharePoint Server 2010 environment described in this document is a production environment at a large, geographically distributed company. Employees use this environment to track projects, collaborate on documents, and share information within their department. This environment is also used for internal testing, and is frequently upgraded to the latest SharePoint Server pre-release versions as they become available.


The information that is provided in this document reflects the departmental collaboration environment on a typical day.

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

Hardware


174

Observação:


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


SharePoint Server 2010 (pre-release version)

Services running locally Search Query WFE3 – No

services

175

Web Server WFE1-2 WFE3-4

WFE4 – Search

crawl target

Application Server

There are four application servers in the farm.

Web Server APP1-3 APP4


RAM 16 GB 16 GB

Operating system Windows Server 2008, 64 bit Windows Server 2008, 64 bit

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

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


Network adapter speed 1 Gigabit 1 Gigabit


Load balancer type Hardware load balancing Hardware load balancing


SharePoint Server 2010 (pre-release version)

Services running locally APP1 – Central Administration and

all applications except for Office Web Applications

APP2 – All applications (including

Office Web Applications)

APP3 – Office Web Applications

Search Crawler

Database Servers

176

There are three database servers, one running the default SQL Server instance housing the content databases, one running the Usage and Web Analytics databases, and one running the Search databases.

Database DB1 – Default Instance DB2 DB3


2 quad core @ 3.2 GHz

RAM 32 GB 16 GB 32 GB

Operating system Windows Server 2008 SP1, 64 bit

Windows Server 2008 SP1, 64 bit

Windows Server 2008 SP1, 64 bit

Storage and geometry 5x146GB 15K SAS + SAN

Disk 1: OS (2 disk RAID 10)

Disk 2: Swap (2 disk RAID 10)

Disk 3: Direct Attached Storage (16 disk RAID 10, Temp DB data) SAS 146 GB 15K

Disk 4: Direct Attached Storage (16 disk RAID 10, Temp DB data) SAS 146 GB 15K

Disk 5-15: SAN using fiber connection. When possible, one database per two disks. Separating logs and data between LUNs. 15K drives.

6x450GB 15K SAS

Directly attached 14x146GB 15K SAS

Disk 1: Usage logs and OS

Disk 2: Usage data

2x136GB 15K SAS (RAID 0)

6x60GB SSD, SATA (RAID 5)

Disk 1: OS

Disk 2: Swap and BLOB Cache

Disk 3: Logs and Temp directory. Solid state drives. 6-60GB Solid state drives (RAID 5)

Number of network adapters 2 2 2

Network adapter speed 1 Gigabit 1 Gigabit 1 Gigabit


Windows NTLM

177

Database DB1 – Default Instance DB2 DB3

Software version SQL Server 2008 SQL Server 2008

SQL Server 2008 R2

Topology


178

Configuration

179

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

Setting Value Notes

Site collection:

Object Caching (On | Off)

Anonymous Cache Profile (select)

Anonymous Cache Profile (select)

Object Cache (Off | n MB)

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

On

Disabled

Disabled

On – 100GB

60 seconds

Enabling the output cache improves server efficiency by reducing calls to the database for data that is frequently requested.

Site collection cache profile (select)

Intranet (Collaboration Site)

“Allow writers to view cached content” is

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

Object Cache (Off | n MB)

On – 500 MB The default is 100 MB. Increasing this setting enables additional data to be stored in the front-end Web server memory.

Usage Service:

Trace Log – days to

store log files (default: 14 days)


Query Logging Threshold:

Microsoft SharePoint

Foundation Database –

configure QueryLoggingThreshold to 1 second

1 second The default is 5 seconds. Lowering this setting can save bandwidth and CPU on the database server.

Database Server –

Default Instance:


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



180

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




Total number of unique users per day 9186


Maximum concurrent users 322




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.


181



BLOB size 1.68 TB


Total number of databases 36




Search index size (number of items) 4.6 million

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

General Counters

Metric Value


Failure Rate 0.0005%




82.5%

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

182

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

183

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


Disk Queue Length: Reads 1.38






SQL Locks: Average Wait Time 294.56 ms

SQL Locks: Lock Wait Time 867.53 ms

SQL Locks: Deadlocks Per Second 1.87

SQL Latches: Average Wait Time 5.10 ms

SQL Cache Hit Ratio 99.77%

184

Divisional portal environment lab study (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:


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

185

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.


Server 2010


Also, we encourage you to read the following:



Glossary There are some specialized terms that you will encounter in this document. Here are some key terms and their definitions.

RPS: Requests per second. The number of requests received by a farm or server in

one second. This is a common measurement of server and farm load.

Note that requests differ from page loads; each page contains several components, each of which creates one or more requests when the page is loaded. Therefore, one page load creates several requests. Typically, authentication checks and events using insignificant resources are not counted in RPS measurements.

Green Zone: This is the state at which the server can maintain the following set of

criteria:

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

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

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

186

AxBxC (Graph notation): This is the number of Web servers, application servers,

and database servers respectively in a farm. For example, 2x1x1 means that this

environment has 2 Web servers, 1 application server, and 1 database server.

MDF and LDF: SQL Server physical files. For more information, see Files

and Filegroups Architecture.

Overview This section provides an overview to our assumptions and our test methodology.

Assumptions

For our testing, we made the following assumptions:

In the scope of this testing, we did not consider disk I/O as a limiting factor. It is

assumed that an infinite number of spindles are available.

The tests model only peak time usage on a typical divisional portal. We did not

consider cyclical changes in traffic seen with day-night cycles. That also means that

timer jobs which generally require scheduled nightly runs are not included in the mix.

There is no custom code running on the divisional portal deployment in this case. We

cannot guarantee behavior of custom code/third-party solutions installed and running

in your divisional portal.

For the purpose of these tests, all of the services databases and the content

databases were put on the same instance of Microsoft SQL Server. The usage

database was maintained on a separate instance of SQL Server.

For the purpose of these tests, BLOB cache is enabled.

Search crawl traffic is not considered in these tests. But to factor in the effects of an

ongoing search crawl, we modified definitions of a healthy farm. (Green-zone

definition to be 40 percent for SQL Server to allow for 10 percent tax from Search

crawls. Similarly, we used 80 percent SQL Server CPU as the criteria for max RPS.)

Test methodology

We used Visual Studio Team System for Test 2008 SP2 to perform the performance testing. The testing goal was to find the performance characteristic of green zone, max zone and various system stages in between for each topology. Detailed definitions of "max zone" and "green zone" are given in the Glossary as measured by specific values for performance counters, but in general, a farm configuration performing around "max zone" breakpoint can be considered under stress, whereas a farm configuration performing "green zone" breakpoint can be considered healthy.

The test approach was to start by using the most basic farm configuration and run a set of tests. The first test is to gradually increase the load on the system and monitor its performance characteristic. From this test we derived the throughput and latency at various user loads and also identified the system bottleneck. After we had this data, we identified at what user load did the farm exhibit green zone and max zone characteristics. We ran separate tests at those pre-identified constant user loads for a longer time. These tests ensured that the farm configuration can provide constant green zone and max zone performance at respective user loads, over longer period of time.

Later, while doing the tests for the next configuration, we scaled out the system to eliminate bottlenecks identified in previous run. We kept iterating in this manner until we hit SQL Server CPU bottleneck.



187

We started off with a minimal farm configuration of 1 Web server /application server and 1 database server. Through multiple iterations, we finally ended at 3 Web servers, 1 application server, 1 database server farm configuration, where the database server CPU was maxed out. Below you will find a quick summary and charts of tests we performed on each iteration to establish green zone and max zone for that configuration. That is followed by comparison of green zone and max zone for different iterations, from which we derive our recommendations.

The SharePoint Admin Toolkit team has built a tool that is named "Load Test Toolkit (LTK)" which is publically available for customers to download and use.

Specifications 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

Database Server

Processor(s) [email protected] [email protected] 4px4c@ 3.19GHz

RAM 8 GB 8 GB 32 GB

Number of network adapters

2 2 1

Network adapter speed 1 Gigabit 1 gigabit 1 Gigabit

Load balancer type F5 - Hardware load balancer Not applicable Not applicable

ULS Logging level Medium Medium Not applicable

Software

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

Web Server Application Server

Database Server

Operating System Windows Server 2008 R2 x64 Windows Server 2003 x64

Windows Server 2008 x64

188


Database Server

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

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

SQL Server 2008 R2 CTP3


Windows NTLM

Load balancer type F5 - Hardware load balancer Not applicable Not applicable

ULS Logging level Medium Medium Not applicable

Anti-Virus Settings Disabled Disabled Disabled

Services running locally Microsoft SharePoint Foundation Incoming E-Mail





Central Administration

Excel Services





PowerPoint Services


Not applicable

189


Database Server


Visio Graphics Services

Word Viewing Service

The table indicates which services are provisioned in the test environment. Other services such as the User Profile service and Web Analytics are not provisioned.

Topology and configuration

The following diagram shows the topology used for the tests. We changed the number of Web servers from 1 to 2 to 3, as we moved between iterations, but otherwise the topology remained the same.

190

Dataset and disk geometry

191

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

Content database 1 2 3 4 5

Content database size 36 GB 135 GB 175 GB

1.2 terabytes

75 GB

Number of sites 44 74 9 9 222

Number of webs 1544 2308 2242 2041 1178

RAID configuration 0 0 0 0 0

Number of spindles for MDF

1 1 5 3 1

Number of spindles for LDF

1 1 1 1 1

Transactional mix

The following are important notes about the transactional mix:

There are no My Sites provisioned on the divisional portal. Also, the User Profile

service, which supports My Sites, is not running on the farm. The transactional mix

does not include any My Site page/web service hits or traffic related to Outlook Social

Connector.

The test mix does not include any traffic generated by co-authoring on documents.

The test mix does not include traffic from Search Crawl. However this was factored

into our tests by modifying the Green-zone definition to be 40 percent SQL Server

CPU usage instead of the standard 50 percent to allow for 10 percent for the search

crawl. Similarly, we used 80 percent SQL Server CPU as the criteria for max RPS.

The following table describes the overall transaction mix. The percentages total 100.

Feature or Service Operation Read/write Percentage of mix

ECM Get static files r 8.93%

View home page r 1.52%

Microsoft InfoPath Display/Edit upsize list item and new forms

r 0.32%

Download file by using "Save as"

r 1.39%

Microsoft OneNote 2010 Open Microsoft Office OneNote 2007 file

r 13.04%

Search Search through r 4.11%

192


OSSSearch.aspx or SearchCenter

Workflow Start autostart workflow w 0.35%

Microsoft Visio Render Visio file in PNG/XAML r 0.90%

Office Web Applications - PowerPoint

Render Microsoft PowerPoint, scroll to 6 slides

r 0.05%

Office Web Applications - Word

Render and scroll Microsoft Word doc in PNG/Silverlight

r 0.24%


List – Check out and then

check in an item

w 0.83%

List - Get list r 0.83%

List - Outlook sync r 1.66%

List - Get list item changes r 2.49%

List - Update list items and adding new items

w 4.34%

Get view and view collection r 0.22%

Get webs r 1.21%

Browse to Access denied page r 0.07%

View Browse to list feeds r 0.62%

Browse to viewlists r 0.03%

Browse to default.aspx (home page)

r 1.70%

Browse to Upload doc to doc lib w 0.05%

Browse to List/Library's default view

r 7.16%

Delete doc in doclib using DAV w 0.83%

Get doc from doclib using DAV r 6.44%

Lock and Unlock a doc in doclib using DAV

w 3.32%

Propfind list by using DAV r 4.16%

Propfind site by using DAV r 4.16%

List document by using FPSE r 0.91%

193


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 r 1.56%

Workspaces WXP - Cobalt internal protocol r 23.00%

Full file upload using WXP w 0.57%

Results and analysis This section describes the test methodology and results to provide guidance for capacity planning of a typical divisional portal.

Results from 1x1 farm configuration

Summary of results

On a 1 Web server and 1 database server farm, in addition to Web server duties, the

same computer was also acting as application server. Clearly this computer (still

called Web server) was the bottleneck. As presented in the data here, the Web

server CPU reached around 86% utilization when the farm was subjected to user

load of 125 users by using the transactional mix described earlier in this document.

At that point, the farm exhibited max RPS of 101.37.

Even at a small user load, Web server utilization was always too high to consider this

farm as a healthy farm. For the workload and dataset that we used for the test, we do

not recommend this configuration as a real deployment.

Going by definition of "green zone", there is not really a "green zone" for this farm. It

is always under stress, even at a small load. As for "max zone", at the smallest load,

where the farm was in "max zone", the RPS was 75.

Because the Web server was the bottleneck due to its dual role as an application

server, for the next iteration, we separated out the application server role onto its own

computer.

Performance counters and graphs

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

User Load 50 75 100 125

RPS 74.958 89.001 95.79 101.37

Latency 0.42 0.66 0.81 0.81

Web server CPU 79.6 80.1 89.9 86

194

User Load 50 75 100 125

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

Database server CPU 15.1 18.2 18.6 18.1

75th Percentile (sec) 0.3 0.35 0.55 0.59

95th Percentile (sec) 0.71 0.77 1.03 1

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

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

195

Results from 1x1x1 farm configuration

Summary of results

On a 1 Web server, 1 application server and 1 database server farm, the Web server

was the bottleneck. As presented in the data in this section, the Web server CPU

reached around 85% utilization when the farm was subjected to user load of 150

users by using the transactional mix described earlier in this document. At that point,

the farm exhibited max RPS of 124.1.

This configuration delivered "green zone" RPS of 99, with 75th percentile latency

being 0.23 sec, and the Web server CPU hovering around 56 % utilization. This

indicates that this farm can healthily deliver an RPS of around 99. "Max zone" RPS

delivered by this farm was 123 with latencies of 0.25 sec and the Web server CPU

hovering around 85%.

Because the Web server CPU was the bottleneck in this iteration, we relived the

bottleneck by adding another the Web server for the next iteration.


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

User Load 25 50 75 100 125 150

196

User Load 25 50 75 100 125 150

RPS 53.38 91.8 112.2 123.25 123.25 124.1

Latency 34.2 56 71.7 81.5 84.5 84.9

Web server CPU 23.2 33.8 34.4 32 30.9 35.8

Application server CPU 12.9 19.7 24.1 25.2 23.8 40.9

Database server CPU 0.22 0.23 0.27 0.32 0.35 0.42

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

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

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

197


Summary of results

On a 2 Web server, 1 application server and 1 database server farm, the Web server

was the bottleneck. As presented in the data in this section, Web server CPU

reached around 76% utilization when the farm was subjected to user load of 200

users by using the transactional mix described earlier in this document. At that point,

the farm exhibited max RPS of 318.


being 0.37 sec, and Web server CPU hovering around 47 % utilization. This indicates

that this farm can healthily deliver an RPS of around 191. "Max zone" RPS delivered

by this farm was 291 with latencies of 0.5 sec and Web server CPU hovering around

75%.

Because the Web server CPU was the bottleneck in this iteration, we relived the

bottleneck by adding another Web server for the next iteration.



User Load 40 80 115 150 175 200

198

User Load 40 80 115 150 175 200

RPS 109 190 251 287 304 318

Latency 0.32 0.37 0.42 0.49 0.54 0.59

Web server CPU 27.5 47.3 61.5 66.9 73.8 76.2

Application server CPU 17.6 29.7 34.7 38 45 45.9

Database server CPU 21.2 36.1 43.7 48.5 52.8 56.2



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

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

199


Summary of results

On a 3 Web server, 1 application server and 1 database server farm, finally, the

database server CPU was the bottleneck. As presented in the data in this section,

database server CPU reached around 76% utilization when the farm was subjected

to user load of 226 users by using the transactional mix described earlier in this

document. At that point, the farm exhibited max RPS of 310.


being 0.41 sec, and database server CPU hovering around 44% utilization. This

indicates that this farm can healthily deliver an RPS of around 242. "Max zone" RPS

delivered by this farm was 318 with latencies of 0.5 sec and database server CPU

hovering around 75%.

This was the last configuration in the series.



User Load 66 103 141 17 202 226

RPS 193.8 218.5 269.8 275.5 318.25 310

200

User Load 66 103 141 17 202 226

Latency 0.3 0.41 0.47 0.58 0.54 0.78

Web server CPU 33 38.3 45.8 43.3 51 42.5

Application server CPU 28 32.6 46.5 40 45.1 43.7

Database server CPU 41.6 44.2 52.6 48 61.8 75



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

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

201

Comparison

From the iterative tests we performed, we found out the points at which a configuration enters max zone or green zone. 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.

202

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

203

A note on disk I/O

Disk I/O based bottlenecks are not considered while prescribing recommendations in this document. However, it is still interesting to observe the trend. Here are the numbers:

Configuration 1x1 1x1x1 2x1x1 3x1x1

Max RPS 75 154 291 318

Reads/Sec 38 34 54 58

Writes/Sec 135 115 230 270

Because we ran the tests in durations of 1 hour and the test uses only a fixed set of sites/webs/document libraries and so on, SQL Server could cache all the data. Thus, our testing caused very little Read IO. We see more write I/O operations that read. It is important to be aware that this is an artifact of the test methodology, and not a good representation of real deployments. Most of the typical divisional portals would have more read operations 3 to 4 times more than write operations.

The following chart shows I/Ops at different RPS.

204

Tests with Search incremental crawl

As we mentioned before, all the tests until now were run without Search crawl traffic. In order to provide information about how ongoing search crawl can affect performance of a farm, we decided to find out the max user RPS and corresponding user latencies with search crawl traffic in the mix. We added a separate Web server to 3x1x1 farm, designated as a crawl target. We saw a 17% drop in RPS compared to original RPS exhibited by 3x1x1.

In a separate test, on the same farm, we used Resource Governor to limit available resources to search crawl 10%. We saw that as Search uses lesser resources, the max RPS of the farm climbs up by 6%.

Baseline 3x1x1 Only Incremental Crawl

No Resource Governor

10% Resource Governor

RPS 318 N/A 276 294.5

Percent RPS difference from baseline

0% N/A 83% 88%

Database server CPU (%) 83.40 8.00 86.60 87.3

SA Database server CPU 3.16 2.13 3.88 4.2

205

Baseline 3x1x1 Only Incremental Crawl

No Resource Governor

10% Resource Governor

(%)

Web server CPU (%) 53.40 0.30 47.00 46.5

Application server CPU (%)

22.10 28.60 48.00 41.3

Crawl Web server CPU (%) 0.50 16.50 15.00 12.1

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

206

Importante:

Here we are only talking about incremental crawl, on a farm where there are not very many changes to the content. It is important to be aware that 10% resource utilization will be insufficient for a full search crawl. It may also prove to be less if there are too many changes. It is definitely not advised to limit resource utilization to 10% if you are running a full search crawl, or your farm generally sees a high volume of content changes between crawls.

Summary of results and recommendations

To paraphrase the results from all configurations we tested:

With the configuration, dataset and test workload we had selected for the tests, we

could scale out to maximum 3 Web servers before SQL Server was bottlenecked on

CPU. The absolute max RPS we could reach that point was somewhere around 318.

With each additional Web server, increase in RPS was almost linear. We can

extrapolate that as long as SQL Server is not bottlenecked, you can add more Web

servers and additional increase in RPS is possible.

Latencies are not affected much as we approached bottleneck on SQL Server.

Incremental Search crawl directly affects RPS offered by a configuration. The effect

can be minimized by using Resource Governor.

Using the results, here are few recommendations on how to achieve even larger scale if you must have more RPS from your divisional portal:

1x1 farm can deliver up to 75 RPS. However, it is usually stressed. 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

207

(that is, 8000/110). Using the ratio, and the results discussed earlier in this article, we can estimate how many users a particular farm configuration can support healthily:

Farm configuration "Green Zone" RPS Approximate number of users it can support

1x1x1 99 7128

2x1x1 191 13452

3x1x1 242 17424

Of course, this is only directly applicable if your transactional mix and hardware is exactly same as the one used for these tests. Your divisional portal may have different usage pattern. Therefore, the ratio may not directly apply. However, we expect it to be approximately applicable.

About the authors Gaurav Doshi is a Program Manager for SharePoint Server at Microsoft.

Raj Dhrolia is a Software Test Engineer for SharePoint Server at Microsoft.

Wayne Roseberry is a Principal Test Lead for SharePoint Server at Microsoft.

208

Social environment technical case study (SharePoint Server 2010) (em inglês)

This document describes a specific deployment of Microsoft SharePoint Server 2010. It includes the following:


and configuration

The workload that includes the number, and types, of users or clients, and

environment usage characteristics

Technical case study farm dataset that includes database contents and Search

indexes


In this article:



Specifications

Workload

Dataset





Server 2010


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.

209


Specifications, which include hardware, topology and configuration



Dataset that includes database sizes

Health and performance data specific to the environment


The SharePoint Server 2010 environment described in this document is a production environment at a large, geographically distributed company. This environment hosts SharePoint My Sites that connect employees with one another and the information that they need. Employees use this environment to present personal information such as areas of expertise, past projects, and colleagues to the wider organization. The environment also hosts personal sites and documents for viewing, editing, and collaboration. My Sites are integrated with Active Directory Domain Services (AD DS) to provide a central location that can be accessed from the browser and various client applications.


The information that is provided in this document reflects the enterprise social environment on a typical day.

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

Hardware


210

Observação:


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


RAM 16 GB

Operating system Windows Server 2008, 64 bit













Services consumed from a federated services farm

User Profile Service


211

Web Server WFE1-3

Business Data Connectivity Service


Application Server

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

Application Server APP1-4


RAM 16 GB

OS Windows Server 2008, 64 bit







Services running locally Office Web Apps

Excel

PowerPoint

Secure Store

Usage and Health

State Service

Database Servers

There is a SQL cluster with two database servers, each with identical hardware. One of the servers is active and the other is passive for redundancy.



RAM 64 GB


Storage and geometry (1.25 TB * 6)

212


Disk 1-4: SQL Data

Disk 5: Logs

Disk 6: TempDB


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



Topology


213

Configuration

214

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

Setting Value Notes

Usage Service:

Trace Log – days to store

log files (default: 14 days)


QueryLoggingThreshold

Microsoft SharePoint Foundation Database –

configure QueryLoggingThreshold to 1 second

1 second

The default is 5 seconds. Lowering this setting can save bandwidth and CPU on the database server.

Database Server –

Default Instance


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

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




Total number of unique users per day 69,814


Maximum concurrent users 1186






215


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.



BLOB size 1.05 TB





Search index size (number of items) 5.5 million

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

General Counters

216

Metric Value


Failure Rate 0.39%




17.42%

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

217

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

218

Metric Value

Read/Write Ratio (IO Per Database) 99.854 : 0.146


Disk Queue Length: Reads 30.518






SQL Locks: Average Wait Time 125 ms

SQL Locks: Lock Wait Time 33.322 ms

SQL Locks: Deadlocks Per Second 0

SQL Latches: Average Wait Time 0 ms

SQL Cache Hit Ratio 20.1%

219

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

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



220

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

larga escala

Apresenta diretrizes sobre o desempenho de repositórios de documentos de larga escala em relação

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










221

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

Web

Apresenta diretrizes sobre o planejamento de

desempenho e capacidade para uma solução de

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


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

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






222

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.

223

Projects A simple task and project tracking applications, dominated by two lists

(projects and tasks associated with each project).

Orders A simple order entry system, similar to the Northwind Traders sample of

Microsoft Access, but scaled down, and included many interrelated lists (orders,

order details, invoices, invoice details, purchase orders, purchase order details, and

so on).

Workload

To simulate application usage, workloads were created to perform one or more of the following operations:

Opening forms

Paging through the forms

Filtering and sorting data sheets

Updating, deleting and inserting records

Publishing application

Render reports

Each workload includes ―think time‖ between user actions, ranging from 5 to 20 seconds. This differs from other SharePoint capacity planning documents. 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

224

bottleneck, we looked at %CPU, memory usage (private bytes), disk queue length, network I/O, and other resources that could result in a bottleneck.

Both the green and red zone tests were run for 1 hour at a fixed user load.

Your results might vary

The specific capacity and performance figures presented in this article will differ from figures in a real-world environment. This simulation is only an estimate of what actual users might do. The figures presented are intended to provide a starting point for the design of an appropriately scaled environment. After you have completed the initial system design, you should test the configuration to determine whether the system will support the factors in your environment.

Hardware setting and topology

Lab Hardware

To provide a high level of test-result detail, several farm configurations were used for testing. Farm configurations ranged from one to four front-end Web servers, one to four application servers (if there is 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.

225

1x1: One front-end Web server computer to one Access Data Services computer

1x2: One front-end Web server computer to two Access Data Services computers

1x3: One front-end Web server computer to three Access Data Services computers

1x4: One front-end Web server computer to four Access Data Services computers

2x1: Two front-end Web server computers to one Access Data Services computer

2x2: Two front-end Web server computers to two Access Data Services computers

2x4: Two front-end Web server computers to four Access Data Services computers

The computer running SQL Server is a relatively strong computer and at no time did it become the bottleneck (although it started to approach CPU saturation on our 2x4 test), so we did not vary this in our topologies. Depending on the queries that are a part of a real-world application mix, it is expected that the database server (SQL Server) tier could become the bottleneck.

Reporting Services was running in connected mode for all of our tests, running in the application server (Access Data Services) tier.

Test results The following tables show the test results of 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

226

Recommended results

The following graph shows the results for recommended sustainable throughput.

227

As described earlier in this article, adding the fourth Access Data Services computer shifts the bottleneck to the front-end Web server, and that adding a second front-end Web server resolves the resource constraint on the front-end Web server tier. This would imply, that 1x1, 1x2, and 1x3 are reasonable configurations. However, when the fourth Access Data Services computer is added, a front-end Web server should also be added. Because scaling is in a linear manner (straight line between from 1x1 to 1x4), it can be assumed that the addition of a seventh Access Data Services computer would also imply the addition of a third front-end Web server, and so on, to satisfy the needs of the farm.

Remember that these results are based on a simulated work load only, and that an actual deployment should be monitored to find the point at which additional front-end Web servers are needed to support additional Access Data Services computers. Also, the front-end Web servers are dedicated to 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.

228

The following graph shows the response time at this throughput level. The response time is very fast, at less than ¼ second on average per request.

229

These results show that the SQL Server computer was not a bottleneck, because adding a second front-end Web server resolved the resource shortage, and the SQL Server CPU was always less than 50 percent. However, be aware that the instance of SQL Server is shared with other SharePoint services and SharePoint itself, and so the cumulative effect might drive CPU or disk I/O queue lengths to the point that they do become a bottleneck.

Maximum

The following graph shows the results, in which throughput was pushed beyond what could be sustained.

In this graph we see that again a second front-end Web server was needed to maximum the usefulness of the fourth Access Data Services computer. Again, your results might vary, because this is highly dependent on the applications and their usage patterns.

230

In this case, the response time is increased, as the overall system is under stress. However, these levels are still approximately one second, and acceptable to most users.

It might seem odd that with four Access Data Services computers, two front-end Web servers have an increased response time than one front-end Web server. This is because the overall throughput of the system is increased with two front-end Web servers.

231

SQL Server is again not a limiting factor here, because adding the second front-end Web server put us back on a linear scaling line. However, we are reaching almost 90 percent CPU usage on the instance of SQL Server. Therefore, there is very little headroom remaining. If we were to add a fifth Access Data Services computer, the SQL Server computer likely would have become the bottleneck.

232

Detailed results

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

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

Req/Sec 14.96 28.76 45.22 48.01 14.85 28.77 58.02

Tests/Sec 2.00 3.81 6.11 6.42 1.99 3.81 7.80

Average Latency 235.80 241.21 247.21 244.87 240.70 242.26 250.94

Average front-end Web server tier

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

%CPU 13.82 24.40 41.02 43.62 6.31 12.48 26.18

233


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

Max w3wp Private Bytes

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

Average application server (Access Data Services) tier

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

%CPU 46.30 42.83 43.74 34.51 46.56 43.45 42.13

%CPU w3wp 33.61 31.15 30.71 24.29 33.48 31.64 29.72

%CPU RS 8.62 7.94 9.17 6.84 9.03 8.02 8.71

Max total Private Bytes

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


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

Max RS Private Bytes

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

Database server (SQL Server) tier (single computer)

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

%CPU 12.07 18.64 32.53 36.05 9.89 21.42 47.46

Avg Private Bytes

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

Max Private Bytes

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

Avg Disk Queue Length Total

0.74 1.18 1.64 1.77 0.67 1.24 2.18

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

234

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

Req/Sec 14.96 28.76 45.22 48.01 14.85 28.77 58.02

Tests/Sec 2.00 3.81 6.11 6.42 1.99 3.81 7.80

Average Latency 235.80 241.21 247.21 244.87 240.70 242.26 250.94


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

%CPU 13.82 24.40 41.02 43.62 6.31 12.48 26.18


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

Average application server (Access Data Services) tier

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

%CPU 46.30 42.83 43.74 34.51 46.56 43.45 42.13

%CPU w3wp 33.61 31.15 30.71 24.29 33.48 31.64 29.72

%CPU RS 8.62 7.94 9.17 6.84 9.03 8.02 8.71

Max total Private Bytes

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


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

Max RS Private Bytes

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


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

%CPU 12.07 18.64 32.53 36.05 9.89 21.42 47.46

Avg Private Bytes

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

235


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

Max Private Bytes

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

Avg Disk Queue Length Total

0.74 1.18 1.64 1.77 0.67 1.24 2.18

Recommendations This section provides general performance and capacity recommendations.

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.

236

In our tests, SQL Server was not a bottleneck. However, our tests were run in

isolation from other SharePoint Server 2010 services. SQL Server CPU and disk I/O

should be monitored and additional servers or spindles added as needed.

Performance-related Access Services settings

One way to control the performance characteristics of 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

237

To help you determine when you have to scale up or scale out the system, use performance counters to monitor the health of the system. Use the information in the following tables to determine which performance counters to monitor, and to which process the performance counters should be applied.

Front-end Web servers

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

Performance counter Apply to object Notes

% Processor Time Processor(_Total) Shows the percentage of elapsed time that this thread used the processor to execute instructions.

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

Access Data Services

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



% Processor Time Process(w3wp) The Access Data Services runs within its own

238


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

Avg. Disk Queue Length PhysicalDisk(_Total) Watch for too much disk writing because of logging.

% Processor Time Process(ReportingServicesService) Reports are handled by SQL Server Reporting Services. If too many reports are being run, or if the reports are very complex, then the CPU and Private Bytes for this process will be high.

Private Bytes Process(w3wp) Serviços do

Access caches the results of queries in memory, until the

user’s session

expires (the time-out for which is configurable). If a large amount of data is being processed through the Access Data Services, memory consumption for the Access Data

Services’ w3wp

will increase.

Private Bytes Process(ReportingSrevicesService) Reports are handled by SQL

239


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

Database servers

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



% Processor Time Process(sqlservr) Average values larger than 80 percent indicate that processor capacity on the database server is insufficient.

Private Bytes Process(sqlservr) Shows the average amount of memory being consumed by SQL Server.

Avg. Disk Queue Length PhysicalDisk(_Total) Shows the average disk queue length; the database requests waiting to be committed to disk. This is often a good indicator that the

240


instance of SQL Server is becoming overloaded, and that possibly additional disk spindles would help distribute the load.

Troubleshooting The following table lists some common bottlenecks and describes their causes and possible resolutions.

Bottleneck Cause Resolution

Access Data Services CPU

Serviços do Access

depends on a large amount of processing in the application server tier. If a 1x1, 1x2, or 1x3 configuration is used, the first bottleneck encountered will likely be the CPU on the Access Data Services servers.

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

Web server CPU usage

When a Web server is overloaded with user requests, average CPU usage will approach 100 percent. This prevents the Web server from responding to requests quickly and can cause timeouts and error messages on client computers.

This issue can be resolved in one of two ways. You can add more Web servers to the farm to distribute user load, or you can scale up the Web server or servers by adding higher-speed processors.

Database server disk I/O

When the number of I/O requests to a

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

241


hard disk exceeds

the disk’s I/O

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

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

Reporting Services CPU utilization

The Reporting Services process is using a large share of the CPU resources.

Dedicate a computer to Reporting Services, taking load from the application server (Access Data Services) tier (connected mode) or the front-end Web server tier (local mode).


242

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

243

Workbook Characteristics Small Large Very Large

Sheets 1-3 1-5 1-20

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

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

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

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

Tables 0-1 0-2 0-5

Charts 0-1 0-4 0-4

Workbook Uses External Data 0% 20% 50%

Workbook Uses a Pivot Table 0% 3% 3%

Workbook Uses Conditional Formats

0% 10% 20%

This test farm included 2,000 SharePoint Server sites. Each site contained one small, one large, and one very large workbook. The distribution of the workbooks on the SharePoint Server pages was 10% small workbooks and 90% large and very large workbooks. Additionally, the test farm dataset included SharePoint Server pages that contained 1-5 Excel Web Parts.

Workload

To simulate application usage, workloads were created to perform one or more of the following operations:

Action Mix Small Workbook Large Workbook

View 50% 70%

Edit 35% 15%

Collaborative Viewing 10% 10%

Collaborative Editing 5% 5%

In addition, 17% of all the workbooks included external data. For large and very large workbooks that included external data, refreshes were performed 80% of the time; small workbooks do not include external data.

Each workload includes think time between user actions of 10 seconds. Think time refers to user action delays that simulate how long a user might take to perform the actions.

244

This differs from other SharePoint Server 2010 capacity planning documents. 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

245

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.

246

Topology Baseline Maximum (RPS) Baseline Recommended (RPS)

1x1 38 31

1x2 35 26

1x3 28 21

2x1 57 35

2x2 62 46

2x3 52 39

3x1 51 32

3x2 81 69

3x3 83 64

247

Recommended Results

The following chart shows our results for recommended sustainable throughput.

248

The previous chart shows that there is overhead associated with adding Web front-end computers to the farm. However, this is offset as 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

249

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.

250

Similar to our recommended results, we see that a single Web front-end computer is the limiting factor as we add a second and third 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.

251

The results in the previous chart show that multiple Web front-end computers do not become as heavily loaded as a single Web front-end computer configuration. This indicates that the 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 1x3 2x1 2x2 2x3 3x1 3x2 3x3

252


Client Successful RPS

30.56 34.55 31.67 26.03 45.94 68.37 20.71 38.82 63.70

Client Response Time (sec.)

0.22 0.18 0.19 0.16 0.19 0.20 0.15 0.15 0.17

TPS 1.58 1.77 1.61 1.40 2.38 3.54 1.08 2.03 3.25

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

% CPU (average over all Web Front-end computers

33.73 37.64 33.84 14.61 23.95 36.90 7.54 13.12 21.75

Serviços

de

Cálculo

do Excel Tier

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

% CPU (average over all Serviços

de

Cálculo

do Excel computers)

30.56 34.55 31.67 26.03 45.94 68.37 20.71 38.82 63.70

Peak Private Bytes (maximum over all

Serviços

de

Cálculo

do Excel computers)

5.94E+09

5.82E+09

5.79E+09

5.87E+09

6.09E+09

5.92E+09

5.79E+09

5.91E+09

5.85E+09

Maximum Results

The following tables show the maximum results of our tests.

253


Client Successful RPS

37.85 56.70 51.17 35.19 62.04 81.31 27.79 51.62 82.58

Client Response Time (sec.)

0.19 0.28 0.23 0.16 0.20 0.25 0.16 0.16 0.22

TPS 1.92 2.96 2.59 1.81 3.21 4.60 1.41 2.72 4.30

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

% CPU (average over all Web Front-end computers

41.08 67.78 58.59 19.44 34.11 45.97 10.19 17.79 28.69

Serviços

de

Cálculo

do Excel Tier

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

% CPU (average over all Serviços

de

Cálculo

do Excel computers)

24.99 18…44 10.96 23.57 20.56 17.77 18.97 17.04 18.10

Peak Private Bytes (maximum over all

Serviços

de

Cálculo

do Excel computers)

5.91E+09

5.85E+09

5.91E+09

5.88E+09

5.99E+09

6.502E+09

5.94E+09

5.94E+09

6.04E+09

254

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.

255

The red zone line in the previous chart shows however, that adding memory does have a significant effect on throughput, especially at peak times. In this test, the same hardware was used throughout. However, the Maximum Private Bytes for the 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.

256

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.

257

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


Serviços de Cálculo do Excel

Memory

Serviços do Excel holds each

workbook in memory throughout the user's session. A large number

Scale Up with more memory in

the Serviços de

258


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

This issue can be resolved in one of two ways. You can add Web servers to the farm to distribute user load, or you can scale up the Web server or servers by adding faster processors.

Performance monitoring

To help you determine when you have to scale up or scale out the system, use performance counters to monitor the health of the system. Use the information in the following tables to determine which performance counters to monitor, and to which process the performance counters should be applied.

Front-end Web server

The following table shows performance counters and processes to monitor for front-end Web servers in your farm.

259

Performance Counter Apply to object Notes

% Processor Time Processor (w3wp) Shows the percentage of elapsed time that this thread used the processor to execute instructions.

% Processor Time Processor (_Total) Shows the percentage of elapsed time that all threads on the server computer that used the processor to execute instructions.

Private Bytes Process (w3wp) This value should not approach the Max Private Bytes set for w3wp processes. If it does, additional investigation is needed into what component is using the memory.

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.


% 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

260


runs within its own w3wp process, and it will be obvious which w3wp process this is as it will be getting the bulk of the CPU time.

Average Disk Queue Length PhysicalDisk(_Total) Watch for too much disk writing because of logging.

Private Bytes Process(w3wp) 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.

261

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

262

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 um dos dois filtros cinco vezes, com 15

segundos de pausa entre as interações.

1. Renderize o painel.

2. Selecione um dos dois filtros, selecione

aleatoriamente um valor de filtro e

aguarde até que o painel seja

renderizado novamente.

3. Repita mais quatro vezes, selecionando

aleatoriamente um dos dois filtros e um

valor de filtro aleatório.

Renderize um painel, selecione um gráfico e

expanda e recolha-o cinco vezes com uma

pausa de 15 segundos entre interações.

1. Renderize o painel.

2. Selecione um membro aleatório em um

263

Nome do teste Descrição do teste

gráfico e expanda-o.

3. Selecione outro membro aleatório no

gráfico e recolha-o.


gráfico e expanda-o.


gráfico e recolha-o.

Renderize um painel, selecione uma grade e expanda e recolha-a cinco vezes com uma pausa de 15 segundos entre interações.

1. Renderize o painel. Selecione um

membro aleatório em uma grade e

expanda o membro.

2. Selecione outro membro aleatório na

grade e expanda-o.


grade e recolha-o.


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 um dos dois filtros cinco vezes.

80%

Renderize um painel, selecione um gráfico e

expanda e recolha-o cinco vezes.

10%

Renderize um painel, selecione uma grade e expanda e recolha-a cinco vezes.

10%

As ferramentas de Teste de Carga do Microsoft Visual Studio 2008 foram usadas para criar um conjunto de testes da Web e testes de carga que simularam os 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.

264

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

Computador executando o SQL Server

Computador executando o Analysis Services

Processador(es) 2px4c a 2.66 GHz 2px4c a 2.66 GHz

2px4c a 2.66 GHz

4px6c a 2.4 GHz

RAM 16 GB 32 GB 16 GB 64 GB

Sistema operacional Windows Server 2008 R2 Enterprise

Windows Server 2008 R2 Enterprise



NIC 1x1 gigabit 1x1 gigabit

1x1 gigabit 1x1 gigabit

Autenticação NTLM e Kerberos NTLM e Kerberos

NTLM e Kerberos

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

265

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.



266

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

(solicitações

por segundo)

EPS

(exibições

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

267

Topologia (WFE x APP x SQL) Usuários SPS

(solicitações

por segundo)

EPS

(exibições

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 360

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

268

Autenticação por usuário


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

269

Resultados do farm 3C (1x1x1)

Autenticação da Conta de Serviço sem Supervisão


SPS 36 87 124 127

Exibições por segundo 21 52 74 75

Tempo médio de resposta (seg) 0,12 0,18 0,65 2

Média de CPU WFE 11% 28% 43% 46%

Máximo de bytes privados WFE

do processo de trabalho W3WP do IIS (Serviços de Informações

da Internet) do SharePoint Server.

0,7 GB 1,4 GB 2 GB

2,4 GB

Média de CPU APP 25% 62% 94% 95%

Máximo de bytes privados APP

do W3WP do Serviços

5,9 GB 10,8 GB 14,1 GB

14,6 GB

270


PerformancePoint

Autenticação por usuário


SPS 17 39 52 56


Tempo médio de resposta (seg) 0,28 0,48 0,91 2


Máximo de bytes privados WFE

do W3WP do SharePoint Server

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

1,9 GB


271


Máximo de bytes privados APP

do W3WP do Serviços

PerformancePoint

19 GB 20,1 GB 20,5 GB

20,9 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.

272

4C (1x2x1) 5C (1x3x1) 6C (2x3x1)

7C (2x4x1)

Contagem de usuários 840 950 1.250 1.500

SPS 196 216 292 346



Máximo de bytes privados

WFE do W3WP do SharePoint Server

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

2 GB



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 (1x3x1)

6C (1x4x1)


RPS 56 67 74 74




WFE do W3WP do SharePoint Server

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

1,5 GB



APP do W3WP do Serviços

PerformancePoint

20 GB 20 GB 20 GB 20 GB

273

3C (1x1x1) 4C (1x2x1) 5C (1x3x1)

6C (1x4x1)

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

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

274

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

275

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.



276

Possível

afunilamento

Causa e o que monitorar

Solução

Desempenho do heap de memória do

Analysis Services

Por padrão, o

Analysis Services usa

seu próprio heap

de memória em

vez do heap do Windows, o que 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.

Altere o Analysis Services para usar o heap do

Windows. Consulte a seção "Analysis Services"

anteriormente neste artigo e o white paper do SQL Server 2008 sobre o guia de desempenho do Analysis Services (http://go.microsoft.com/fwlink/?linkid=165486&clcid=0x4

16) para obter instruções.

Threads de processamento e consulta do Analysis Services

Por padrão, o

Analysis Services limita o

número de

threads de consulta e processamento para consultas. Consultas de

execução longa

e altas cargas de usuário

podem usar todos os threads

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.






277

Possível

afunilamento


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

PerformancePoint armazena em cache o Analysis Services e outros resultados de consulta da fonte de dados

em memória

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

PerformancePoint para determinar se as

remoções ou

cortes de cache estão sendo

forçadas pelo

ASP.NET por causa de baixa memória.

Adicione memória ou aumente os limites padrão da

memória cache do ASP.NET. Consulte a seção

Consumo de memória anteriormente neste documento

para obter informações adicionais. Além disso, consulte

as configurações de elementos do cache do ASP.NET

(http://go.microsoft.com/fwlink/?linkid=200610&clcid=0x416) e a postagem do blog de Thomas Marquardt sobre o

histórico dos limites de memória cache do ASP.NET

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



278

Possível

afunilamento


Solução

Configurações

de limitação

de WCF

O Serviços

PerformancePoint é

implementado

como um serviço

WCF. O WCF limita o número

máximo de

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

PerformancePoint e compare-as

com o número

máximo atual de

chamadas

simultâneas.

Se necessário, altere o comportamento de limitação do

WCF (Windows Communication Foundation. Consulte os comportamentos de limitação do serviço WCF

(http://go.microsoft.com/fwlink/?linkid=200612&clcid=0x416) e a postagem do blog de Wenlong Dong sobre

limitação de solicitações do WCF e escalabilidade do

servidor (http://go.microsoft.com/fwlink/?linkid=200613&clcid=0x416).

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





279

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 \ Cortes de API de Cache

Pool de aplicativos do

Serviços

PerformancePoint

Se o valor for maior do que zero, leia "Consumo

de memória".

MSAS 2008:Threads / threads ociosos do pool de consultas

N/A 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&clcid=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&clcid=0x416).

MSAS 2008:Threads / threads ociosos do pool de processamento



MSAS 2008:Threads / tamanho da fila de trabalhos do pool de processamento



WCF CountersServiceModelService 3.0.0.0(*)\Chamadas pendentes

Instância do

PerformancePoint Service

Se o valor for maior do que zero, consulte o

artigo sobre limitação de solicitações de WCF e

escalabilidade do servidor (http://go.microsoft.com/fwlink/?linkid=200613&clcid=0x416).

Consulte também Outros recursos















280

Plan for PerformancePoint Services (SharePoint Server 2010)

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

281

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:



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:

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

282

Traffic

Search

Inventory

SharePoint Web Analytics reports are typically aggregated for various SharePoint entities, such as sites, site collections, and Web applications for each farm. To view an architectural overview of the Web Analytics service application in a SharePoint deployment, see Architectural overview later in this article.

The Web Analytics shared service requires resources primarily at the application server and database server level. This article does not cover the Web Server layer capacity planning, because the Web Analytics 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).

283

Figure 1. SharePoint Server 2010 Web Analytics architectural overview

The performance of the Logging Web Service primarily depends on the number of application servers. (Scaling out is available for the application servers.) The

284

performance of the Log Batcher and User Behavior Analyzer depends primarily on the analytics staging database. The Read and Write activities that are performed by all the different components can cause the analytics staging database to slow down the process. (Scaling out is available for the staging database.) The performance of the Report Consolidator also primarily depends on the reporting database. (Scaling out of reporting database is not supported.)

Hardware specifications and topology 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




Network adapter speed 1 GB

Authentication NTLM

Load balancer type SharePoint Load Balancer

285

Application server Minimum requirement

Software version SharePoint Server 2010 (prerelease version)



Incoming E-mail

Microsoft SharePoint Foundation Web

Application


Workflow Timer Service



Web Analytics Data Processing Service


Database servers

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

Database server Minimum requirement

Processors 4 quad core @ 2.4 GHz

RAM 32 GB

Operating system Windows Server 2008, 64-bit

Disk size 3 terabytes

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.


Network adapter speed 1 GB

Authentication NTLM


286

Topology

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

287

Figure 2. Web Analytics topology

288

Capacity requirements Testing methodology

This section presents the capacity requirements with regard to the total amount of site traffic (this is measured by number of clicks, search queries, and ratings) per day that can be supported by different numbers of application servers and SQL Server based computers. The numbers presented currently are for a midsize SharePoint deployment that has about 30,000 SharePoint entities. The Web Analytics shared service aggregates the data for each day. Therefore, the data volume that is presented corresponds to the total number of records (this is measured by number of clicks, search queries, and ratings) that the SharePoint farm is expected to receive each day.

This section provides diagrams that show the daily site traffic that can be supported by one, two, or three application servers (Figure 3) and the daily site traffic that can be supported that corresponds to the various database configurations (Figure 4). In the diagrams, data is shown by using two colors:

Green Green values indicate the safe limit for the site traffic that can be processed

for the corresponding number of application servers and SQL Server based

computers.

Yellow Yellow values indicate the expected limit for the site traffic that can be

processed for the corresponding number of application servers and SQL Server

based computers.

The green and yellow values are estimates that are based on two key factors:

Total site traffic, measured by number of page view clicks, search queries, and

ratings.

Number of SharePoint entities, such as sites, site collections, and Web applications,

for each farm.

The estimates also depend on other properties of the data and the data retention period in the reporting database. For testing, the other properties of the data were maintained as constant as described in Dataset description later in this section.

Also, in smaller SharePoint deployment environments, you can share the application servers and SQL Server based computers together with other SharePoint services and databases. This article contains information about the capacity of the application servers and the SQL Server based computers that are in a test environment so that the Web Analytics shared service is the only major service that is running on the servers. The actual performance results for environments that actively use other shared services at the same time running might vary.

To determine the capacity requirements for your environment, make sure that you estimate the expected daily site traffic and the number of components that you might use for a SharePoint deployment. Then, the number of application servers and SQL Server based computers should be estimated independently, as shown in Figure 3 and Figure 4.

Dataset description

The dataset that was selected for the test environment is a mid-sized dataset that has approximately 30,000 SharePoint components, which includes all web applications, site collections, and sites. Other characteristics of the data that were kept constant in the environment are also listed in the following table.

289

Dataset characteristics Value

Number of SharePoint components 30,000

Number of unique users 117,000

Number of unique queries 68,000

Number of unique assets 500,000

Data size in the reporting database 200 GB

The total site traffic, measured by number of clicks, search queries, and ratings, was increased as part of this case study to establish the number of records that can be supported by the corresponding topology.

Importante:

Some typically used topologies generally exceed the capacity planning guidance. Those topologies include the following:

Team sites

My Site Web sites

Self-provisioning portals

If you anticipate that you might exceed the capacity planning guidelines, we recommend that you turn off the Web Analytics service application. For more information about how to turn off a service application, see Starting or stopping a service.

Application servers

The following diagram (Figure 3) shows the daily site traffic that can be supported by one, two, or three application servers. The site traffic is represented in millions of records (each click, search query, or rating makes up a record) each day. The yellow line represents the expected number of records for the corresponding topology, whereas the green line represents the safe assumption for the number of records.

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

290

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

The application servers are not very CPU-intensive or memory intensive. Thus, the CPU and the memory usage are not summarized for this section.

SQL Server based computers

The following diagram (Figure 4) shows the daily site traffic that can be supported that corresponds to the following configurations:

One instance of SQL Server for both staging and reporting databases (1S+R).

Two instances of SQL Server, one staging database and one reporting database

(1S1R).

291

Three instances of SQL Server, two staging databases and one reporting database

(2S1R).

The site traffic is represented in millions of records (each click, search, or rating makes up a record) each day. The yellow line represents the expected number of records for the corresponding topology, whereas the green line represents the safe assumption for the number of records.

Figure 4. Daily site traffic vs. SQL Server topology

The following table summarizes the CPU and memory usage of the various components on the instances of SQL Server that are hosting the staging database and the reporting database.

292

Configuration 1S+R 1S1R 1S1R 2S1R 2S1R

Staging + Reporting Staging Reporting Staging Reporting

Total sum of percentage of processor time for 8 processor computer

19 192 5.78 100 13.4

SQL Server buffer hit ratio

99 100 100 100 100

% Disk time 7,142 535 5.28 59.3 98.2

Disk queue length 357 28.6 0.26 2.97 4.91

Other factors

Many other factors can affect the performance of various analytics components and can affect the capacity planning. These factors primarily affect the performance of the Report Extractor component because they can affect the size of the data aggregated each day. The total size of the data in the reporting database also affects the performance of the Reporting Extractor, although this is not significant because the data is partitioned daily. Some of these other factors are as follows:

Number of unique queries each day.

Number of unique users each day.

Total number of unique assets clicked each day.

Existing data size in the reporting warehouse, based on the data retention in the

warehouse.

The overall effect of these factors is less significant than the total data volume and the number of site entities. However, it is important to conduct your own capacity management based on your planned workload and usage characteristics. For more information about the capacity management process, see Gerenciamento de desempenho e capacidade (SharePoint Server 2010).

Remaining issues

There are current known issues that significantly affect the current performance of the Web Analytics service application for deployments that have a large site hierarchy, which includes approximately 100,000 or more SharePoint components. This article might be updated with the capacity requirements for larger site hierarchies when more information is available.



Outros recursos

SharePoint 2010 Administration Toolkit (SharePoint Server 2010)

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

293

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

294

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



295

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


Tamanho da unidade do SharePoint 300 GB


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

296

Servidor Web

Email de entrada do Microsoft SharePoint Foundation

Aplicativo Web do Microsoft SharePoint Foundation

Serviço de Timer do Fluxo de Trabalho do


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


Armazenamento 15 discos de 300 GB a 15.000 RPM


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

297

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.

298

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.

299

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

300

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

301

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


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


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


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.

http://msdn.microsoft.com/pt-br/library/aa661294.aspx



302

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.

303

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

304

Taxa de acertos do cache de

saída

Medida 1x1 2x1 4x1

100%

RPS máxima

Utilização da CPU

do SQL Server

3.463

0%

7.331

0%

11.032

0%

95%

RPS máxima

Utilização da CPU

do SQL Server

2.137

5,93%

3.945

12,00%

5.937

21,80%

90%

RPS máxima

Utilização da CPU

do SQL Server

1.518

7,12%

2.864

14,40%

4.518

28,00%

50%

RPS máxima

Utilização da CPU

do SQL Server

459

9,86%

913

19,50%

1.596

42,00%

0%

RPS máxima

Utilização da CPU

do SQL Server

172

9,53%

339

19,00%

638

36,30%

Conclusões e recomendações referentes ao efeito da habilitação do cache de saída

305

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.

http://office.microsoft.com/pt-br/ha101785628.aspx

http://office.microsoft.com/pt-br/ha101785628.aspx

306

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

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

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

307

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

308

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

309

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.

310

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.

311

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

312

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

313

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.

314

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.

315

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 60-80% no decorrer de todos os testes, mesmo quando as gravações por hora se aproximaram a 500.

316

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.

317

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

318

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.

319

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% 98% 95% 90% 50% 0%

320

Acerto do cache 100% 99% 98% 95% 90% 50% 0%

Linha de base 1,19% 1,64% 2,01% 3,00% 3,73% 5,40% 6,82%

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

321

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

322

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.

323

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 BD de uso desativado

Diferença

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

324

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.

325

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

326

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

Test name Test description

Throughput for starting workflows manually 1. Associate the included MOSS Approval

workflow with a list that creates one

task.

2. Populate the list with list items.

3. Call the StartWorkflow Web service

method on Workflow.asmx against the

items in the list for five minutes.

4. Calculate throughput by looking at the

number of workflows in progress.

Throughput for starting workflows automatically when an item is created

1. Associate the included MOSS Approval


task, set to automatically start when an

item is created.

2. Create items in the list for five minutes.


number of workflows in progress.

Throughput for completing workflow tasks 1. Associate the included MOSS Approval


task, set to automatically start when an

item is created.

2. Create items in the list.

3. Call the AlterToDo Web service method

on Workflows.asmx against the items in

the task list that was created by the

workflows that started.


number of workflows completed.

Hardware, settings, and topology

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

327

single site collection with a single site that is based on the Team Site template on a single content database.

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

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

Web server Database server

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


Network adapter speed 1 gigabit 1 gigabit

Authentication NTLM NTLM

Software version 4747 SQL Server 2008 R1

Number of SQL Server instances 1 1

Load balancer type No load balancer No load balancer

ULS logging level Medium Medium

Workflow Capacity Planning Topology

328

329

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

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

Effect of scaling the Web server on throughput

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

An entry in the Workflows table to store workflow status

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

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

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

Manual start throughput

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

Topology Approval workflow maximum RPS

1x1 14.35

2x1 24.08

3x1 29.7

4x1 30.77

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

Manual start throughput

330

Automatically starting workflows when items are created throughput

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.


1x1 13.0

2x1 25.11

3x1 32.11

4x1 32.18

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

Autostart workflow throughput

331

Task completion throughput

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


1x1 13.5

2x1 23.86

3x1 27.06

4x1 27.14

332

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

Task completion throughput

Effect of list size and number of workflow instances on throughput

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

To maintain reliability during data population, we had to keep workflow queuing turned on to avoid reaching the maximum number of connections on the database server. If no connections are available and a workflow operation cannot connect to the content

333

database, the operation will be unable to run. See Recommendations for more information about workflow queuing.

Number of items or workflows Baseline solution maximum (RPS)

0 32.18

10 32

1,000 28.67

10,000 27.16

100,000 16.98

1,000,000 9.27

Autostart throughput as number of items and workflows increases

334

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

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

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

335

Throughput with different list configurations (workflows started per second)

Million item task list Empty task list

Million item list 9.27 12

Empty item list 9.3 13

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

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

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

Scaled-out topologies

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

Estimating throughput targets

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

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

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

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

Workflow queuing and performance-related settings

Workflow uses a queuing system to control workflow-related stress on farm resources and the content database. By using this system, when the number of workflows executing against a database reaches an administrator-configured threshold, successive workflow


336

operations are added to the queue to be run by the Workflow Timer service. By default, this service receives a batch of workflow work items through timer jobs every minute.

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

Understanding the basic queue settings

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

Workflow Postpone Threshold (Set-SPFarmConfig –WorkflowPostponeThreshold

<integer>)

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

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

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

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

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

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

337

1,000 and set the timer job to run every minute, the operations would all begin execution after a minute. If you set the postpone threshold higher, more operations will run synchronously, reducing the number of requests that get queued and reducing the total time that is required to process those workflows.

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:

338

Balance Postpone Threshold and Workflow Batchsize so that batch size is small

enough or timer job frequency high enough that a timer job can be completed

before the next timer job starts in order to avoid building up too many parallel

timer job runs that cannot finish.

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

5,000.

Dica:

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

Improving scaling for task and history lists

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

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

Other considerations

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

Troubleshooting


Database contention (locks)

Database locks prevent multiple users from making conflicting modifications to a set of data. When a set of data is locked by a user or process, no other user or process can

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

Distribute workflows to more document

libraries.

Scale up the database server.

Tune the database server hard disk for

read/write.

Methods exist to circumvent the database

339


change that same set of data until the first user or process is complete, changing the data and relinquishing the lock.

locking system in SQL Server 2005, such as the NOLOCK parameter. However, we do not recommend or support use of this method because of the possibility of data corruption.

Database server disk I/O

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

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

Web server CPU utilization

When a Web server is overloaded with user requests, average CPU utilization will approach 100 percent. This prevents the Web server from responding to requests quickly and can cause timeouts and error messages on client computers.

This issue can be resolved in one of two ways. You can add Web servers to the farm to distribute user load, or you can scale up the Web server or servers by adding faster processors.

Web servers

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


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


340


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

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

Database servers

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


Average disk queue length Hard disk that contains SharedServices.mdf

Average values larger than 1.5 per spindle indicate that the write times for that hard disk are insufficient.

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

Processor time Total Shows the percentage of

341


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

Memory utilization Total Shows the average utilization of system memory.

Consulte também Outros recursos

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



342


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

343

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:

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

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


344

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

Rascunho

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

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



345

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



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



346

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

347

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

http://technet.microsoft.com/library/abcf2ba8-86f6-4116-8461-b3e5fc6fedfb(Office.14).aspx

http://technet.microsoft.com/library/9a75a461-6c86-4b61-be98-bcaf9290f2da(Office.14).aspx

348

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

349

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.

Para o banco de dados de Propriedade,

350


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:

351


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

chave 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

352


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://technet.microsoft.com/library/04812402-43d6-4605-960c-1dd5ec65bef1(Office.14).aspx

http://technet.microsoft.com/library/04812402-43d6-4605-960c-1dd5ec65bef1(Office.14).aspx

http://technet.microsoft.com/library/665876e1-2706-42ad-bd76-8e4d1da0ce92(Office.14).aspx

http://technet.microsoft.com/library/665876e1-2706-42ad-bd76-8e4d1da0ce92(Office.14).aspx


353

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.

http://msdn.microsoft.com/pt-br/library/bb933866.aspx

http://msdn.microsoft.com/pt-br/library/bb933866.aspx

354

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

355

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.



356

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

conteúdo

RAM recomendada para computadores que executam o SQL Server

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


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


357

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.

http://technet.microsoft.com/library/3d7496d6-1a0b-4efd-bfe4-6e15c98ea932(Office.14).aspx#Section6_1




358

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


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)


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







359

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


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.


360

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.

http://technet.microsoft.com/library/01abe8d2-33f8-48fe-af76-40522a5afe08(Office.14).aspx

http://technet.microsoft.com/library/01abe8d2-33f8-48fe-af76-40522a5afe08(Office.14).aspx


361

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



362

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:

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.

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:

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:




363

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,

364

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.


365

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


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



366

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


/ número de discos


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



Documents

Share Pt Serv Plan Cap