Ambiente social do Microsoft SharePoint Server 2010: estudo de laboratório

 

Aplica-se a: SharePoint Server 2010

Tópico modificado em: 2016-11-30

Este artigo fornece orientações sobre o desempenho e o planejamento de capacidade para um Meu Site e um portal de computação social com base no Microsoft SharePoint Server 2010. Este artigo descreve o seguinte:

• Especificações de ambiente de teste, como hardware, topologia do farm e configuração.

• Conjunto de dados do farm de teste.

• Dados de teste e recomendações sobre como determinar o hardware, a topologia e a configuração que deve ser implantada em um ambiente de tese e sobre como otimizar um ambiente para obter características apropriadas de capacidade e desempenho.

Resumo executivo

Estes são os principais resultados do nosso teste do Meu site e do portal de computação social:

• O ambiente foi ampliado para oito servidores Web front-end para um servidor de aplicativos e um servidor de banco de dados (8×1×1). O aumento na taxa de transmissão foi quase linear. Não houve ganhos adicionais em taxa de transmissão adicionando mais de oito servidores Web front-end, pois o afunilamento nesse momento era o uso da CPU por parte do servidor de banco de dados.

• Realizamos uma ampliação maior separando o banco de dados de conteúdo e o banco de dados de serviços em servidores de bancos de dados distintos (8×1×2).

• Obtivemos a taxa de transferência máxima usando a topologia 8x1x2. Nesse momento, a utilização do servidor Web front-end e a utilização da CPU do servidor de aplicativos eram o afunilamento. Com isso, considerando o hardware, o conjunto de dados e a carga de trabalho de teste, a quantidade máxima possível de solicitações por segundo (RPS) era representada pelo RPS Máximo de Zona para 8x1x2, que seria cerca de 1.877 RPS.

• Ao observar as tendências, acreditamos que pode ser possível extrair a mesma taxa de transferência de um farm íntegro se os afunilamentos no servidor Web front-end e o servidor de aplicativos foram solucionados. O afunilamento do servidor Web front-end pode ser solucionado adicionando mais servidores Web front-end. O afunilamento do servidor de aplicativos pode ser solucionando utilizando dois computadores para exercer a função do servidor de aplicativos. No entanto, não tentamos essa solução no laboratório.

• A latência não é afetada pelas variações na taxa de transferência.

• Se a sua filtragem de segurança estiver ativada, um servidor Web front-end poderá oferecer suporte par 8 a 10 RPS de tráfego do Outlook Social Connector. Isso significa que um servidor Web front-end poderá oferecer suporte para cerca de 28.000 a 36.000 funcionários utilizando o Outlook Social Connector o dia inteiro. Portanto, se você distribuir o Outlook Social Connector para 100.000, será necessário ter três servidores Web front-end para oferecer suporte para o tráfego do Outlook Social Connector. Esses valores podem variar dependendo do uso de marcações sociais em sua empresa. Se você determinar que sua empresa terá uma quantidade menor de atividades de marcação social do que a utilizada neste teste, a sua taxa de transferência por servidor Web front-end poderá exceder a faixa de 8 a 10 RPS.

• O rastreamento incremental Pesquisa exerce pouca influência na taxa de transferência do farm desde que o farm seja mantido em um estado de integridade.

Introdução a este ambiente

A metodologia de teste e os resultados neste artigo oferecem orientações para o planejamento da capacidade de um portal e computação social. Um portal de computação social é uma implantação de SharePoint Server 2010 no qual cada membro da empresa pode manter um perfil de usuário, localizar especialistas na empresa e conectar-se com outros funcionários por meio de feeds de notícias e manter um site pessoa para armazenar e compartilhar documentos. Além do tráfego gerado pelos recursos de computação social, é criado um tráfego de colaboração significativa por usuários que carregam, compartilham, visualizam e atualizam documentos em seus sites pessoais. Esses resultados devem ajudar a projetar um portal separado dedicado aos Meus Sites e aos recursos sociais.

Cenários diferentes possuem requisitos diferentes. Portanto, você deve suplementar essas orientações com testes adicionais em seu próprio hardware e no seu próprio ambiente.

Após ler este artigo, você compreenderá como:

• Fazer uma estimativa o hardware necessário para a ampliação que você precisa suportar. Essa estimativa deve incluir o número de usuários, a carga e os recursos habilitados.

• Criar a topologia física e lógica para perfeita confiabilidade e eficiência. A alta disponibilidade e a recuperação de desastres não são abordadas neste artigo.

• Considerar o efeito do rastreamento contínuo da Pesquisa de Pessoas e das sincronizações de perfis no RPS de uma implantação de portal de computação social.

Antes de ler este artigo, você deve ler:

• Capacity management and sizing for SharePoint Server 2010

• Gerenciamento de capacidade do SharePoint Server 2010: Limites de software

• Social environment technical case study (SharePoint Server 2010)

Caso você se interesse em ler as orientações de planejamento de capacidade sobre típicos cenários de colaboração, consulte Enterprise intranet collaboration environment technical case study (SharePoint Server 2010)

Glossário

A lista a seguir contém as definições dos principais termos deste artigo:

• 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áginas. 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%.

  Observação

  Como este ambiente de laboratório não apresentava um rastreamento de pesquisa ativo em execução, o servidor do banco de dados foi mantido em uma utilização de 40% da CPU ou menos para reservar 10% para a carga do rastreamento de pesquisa. Isso pressupõe que o Administrador de Recursos do Microsoft SQL Server será usado na produção para limitar a carga do rastreamento de pesquisa para 10% da utilização da CPU.

  • A taxa de falha é menor que 0,01%.

• Zona Vermelha (Máx.): Este é o estado em que o servidor pode manter o seguinte conjunto de critérios:

  • O recurso de limitação de solicitações HTTP está habilitado, mas não são retornados erros 503 (Servidor Ocupado).

  • A taxa de falha para solicitações HTTP é menor que %0,1%.

  • A latência no lado do servidor para pelo menos 75% das solicitações é menor que 1 segundo.

  • A utilização da CPU do servidor de banco de dados é menor que 80%. Isso permite que 10% da utilização seja reservada para a carga do rastreamento de pesquisa e que ela seja limitada usando o Administrador de Recursos do SQL Server.

• AxBxC (Notação de gráfico): Este é o número de servidores Web front-end, servidores de aplicativos e servidores de bancos de dados em um farm. Por exemplo, 8x1x2 significa que o ambiente possui oito servidores Web front-end, um servidor de aplicativos e um servidor de banco de dados.

• Carga do VSTS Esses são os threads usados internamente pelo Visual Studio Team System (VSTS) para simular usuários virtuais. Nós aumentamos a carga do VSTS para gerar uma quantidade cada vez maior de RPS para a topologia.

• MDF e LDF: Arquivos físicos doSQL Server. Para obter mais informações, consulte o artigo sobre a arquitetura de arquivos e grupos de arquivos.

Visão geral

Esta seção resume a nossa abordagem de dimensionamento, a relação entre esse ambiente de laboratório e o ambiente de um estudo de caso similar, e a nossa metodologia de teste.

Abordagem de dimensionamento

Recomendamos que você dimensione os computadores do seu ambiente em uma ordem específica. Essa é a mesma abordagem de dimensionamento utilizada em nosso ambiente de laboratório. Essa abordagem permitirá que você identifique a melhor configuração para a sua carga de trabalho. A abordagem que utilizamos foi a seguinte:

1. Primeiramente, ampliamos os servidores Web front-end. Eles foram ampliados o máximo possibilitado pela carga de trabalho testada até que o servidor do banco de dados não mais pudesse acomodar mais solicitações dos servidores Web front-end.

2. Até esse momento, os bancos de dados de conteúdo e os bancos de dados de serviços (como os bancos de dados de perfis e os bancos de dados sociais) estavam no mesmo servidor de banco de dados. Quando percebemos que o servidor de banco de dados era o afunilamento, ampliamos o servidor de banco de dados movendo os bancos de dados de conteúdo para outro servidor de banco de dados. Consequentemente, a carga dos servidores de bancos de dados criada pelos servidores Web front-end foi reduzida até que foi possível ampliar os servidores Web front-end ainda mais.

3. No ambiente de laboratório, não testamos o dimensionamento além desse momento. No entanto, caso você precise de um dimensionamento maior, a próxima etapa lógica seria dividir as responsabilidades do servidor de aplicativos entre dois computadores.

Começamos com uma configuração mínima de farm, que consistia em um servidor Web front-end, um servidor de aplicativos e um computador baseado no SQL Server. Após várias iterações interrompe o teste na configuração de farm de oito servidores Web front-end, um servidor de aplicativos e dois SQL Server. Na seção Resultados e análise posteriormente neste artigo, você encontrará uma comparação entre as características de desempenho da Zona Verde e da Zona Máxima em diferentes iterações. A forma com a qual descobrimos a Zona Verde e a Zona Máxima para cada iteração é abordada na seção Resultados das iterações.

Correlacionando o ambiente de laboratório com um ambiente de produção

O ambiente de laboratório descrito neste artigo é um modelo em menor escala de um ambiente de produção da Microsoft. Apesar de haver diferenças significativas entre os dois ambientes, pode ser útil visualizá-los lado a lado, pois ambos são ambientes de Meu Site e de computação social. Consequentemente, os padrões observados deverão ser similares.

O ambiente de laboratório contém um conjunto de dados que emula o conjunto de dados do ambiente de produção. A carga de trabalho usada para o teste é significativamente similar à carga de trabalho observada no ambiente de produção, com algumas diferenças importantes. A diferença mais importante é que, no ambiente de laboratório, utilizamos uma quantidade menor de usuários distintos para realizar as operações e essas operações são executadas em um número menor de perfis de usuário em comparação com o ambiente de produção. Além disso, os testes de laboratório ocorrem ao longo de um curto período. Todos esses fatores afetam o número de acertos de cache ocorridos para o cache de perfis de usuário mantido no servidor de aplicativos.

O serviço de Perfil de Usuário armazena em cache os perfis de usuário usados recentemente no servidor de aplicativos. O tamanho padrão do cache é 256 MB, o que resulta em aproximadamente 500.000 perfis de usuário. Como o número de perfis de usuário usados para o teste foi limitado a 1.500 e a duração dos testes foi menor do que o tempo de reciclagem do cache, geralmente ocorriam acertos de cache. Portanto, os valores de taxa de transferência apresentados neste artigo serão maiores. Você deverá considerar os erros de cache do seu ambiente e pressupor um valor menor para a taxa de transferência.

Cada obter um estudo de caso detalhado sobre a produção de um Meu Site e um portal de computação social da Microsoft, consulte Social environment technical case study (SharePoint Server 2010).

Metodologia e anotações do teste

Este artigo fornece os resultados de um ambiente de laboratório d teste. Como se tratava de um ambiente de laboratório, foi possível controlarmos certos fatores para mostrar aspectos específicos do desempenho dessa carga de trabalho. Além disso, alguns elementos do ambiente de produção foram excluídos do ambiente para simplificar a sobrecarga do teste. Observe que não recomendamos a omissão desses elementos em ambientes de produção:

• Entre os testes, modificamos somente uma variável por vez para facilitar a comparação dos resultados entre os testes executados.

• O servidor de banco de dados usado nesse ambiente de laboratório não faz parte de um cluster, pois a redundância não era necessária para os fins desses testes.

O rastreamento de pesquisa não estava em execução durante os testes, mas em um ambiente de produção ele poderá estar. Para considerar esse fator, reduzimos a utilização de CPU do SQL Server em nossa definição de Zona Verde e Zona Vermelha (Máx.) para acomodar os recursos que um rastreamento de pesquisa teria consumido se estivesse em execução durante os nossos testes.

Especificações

Esta seção apresenta informações detalhadas sobre o hardware, o software, a topologia e a configuração do ambiente de laboratório.

Hardware

A tabela a seguir lista as especificações de hardware para os computadores usados no teste. Os servidores Web front-end adicionados ao farm de servidores durante as várias iterações do teste também estavam em conformidade com essas especificações.

	Servidor Web front-end	Servidor de aplicativos	Servidor de banco de dados
Processador	2px4c com 2,33 GHz	2px4c com 2,33 GHz	4px4c com 3,10 GHz
RAM	8 GB	8 GB	32 GB
Quantidade de adaptadores de rede	2	2	1
Velocidade do adaptador de rede	1 gigabit	1 gigabit	1 gigabit
Tipo de balanceador de carga	F5 - Balanceador de carga de hardware	Não aplicável	Não aplicável
Nível de log ULS	Médio	Médio	Não aplicável

Software

A tabela a seguir lista as especificações de software para os computadores usados no teste. Os servidores Web front-end adicionados ao farm de servidores durante as várias iterações do teste também estavam em conformidade com essas especificações.

	Servidor Web front-end	Servidor de aplicativos	Servidor de banco de dados
Sistema operacional	Windows Server 2008 R2 x64	Windows Server 2008 R2 x64	Windows Server 2008 x64
Versão do software	Microsoft SharePoint 4763.1000 (RTM), Office Web Applications 4763.1000 (RTM)	Microsoft SharePoint 4763.1000 (RTM), WAC 4763.1000 (RTM)	SQL Server 2008 R2 CTP3
Tipo de balanceador de carga	F5 - Balanceador de carga de hardware	Não aplicável	Não aplicável
Nível de log ULS	Médio	Médio	Não aplicável
Configurações de antivírus	Desabilitado	Desabilitado	Desabilitado
Serviços em execução	Email de entrada do SharePoint Foundation Aplicativo Web do SharePoint Foundation Serviço de Timer do Fluxo de Trabalho do SharePoint Foundation	Administração Central Serviços de Cálculo do Excel Serviço Web de Metadados Gerenciados Email de entrada do SharePoint Foundation Aplicativo Web do SharePoint Foundation Serviço de Timer do Fluxo de Trabalho do SharePoint Foundation Serviço PowerPoint Serviço de Perfil de Usuário Serviço de Sincronização de Perfis de Usuário Serviço de Exibição do Word

Topologia

O seguinte diagrama mostra a topologia desse ambiente de laboratório.

Geometria do conjunto de dados e do disco

O farm de teste foi populado:

• 116,5 GB de conteúdo do Meu Site, distribuído homogeneamente entre 10 bancos de dados de conteúdo

• 27,7 GB de conteúdo de bancos de dados de Perfis

• 3,7 GB de conteúdo de bancos de dados sociais (GUIDs etiquetas de conteúdo social, anotações e classificações)

• 0,14 GB de conteúdo de bancos de dados de Metadados Gerenciados (texto para etiquetas de conteúdo social e os GUIDs correspondentes)

A tabela a seguir explica o conjunto de dados com detalhes.

Número de perfis de usuário	Aprox. 150K
Número médio de associações por usuário	74
Número médio de relatórios diretos por usuário	6
Número médio de colegas por usuário	28
Número do total de propriedades de perfil	101
Número de propriedades de vários valores	21
Número de audiências	130
Número de Meus Sites	Aprox. 10K
Número de sites de blog	Aprox. 600
Número total de eventos no feed de atividades	798K*
Número de etiquetas de conteúdo social e de classificações	5,04 milhões**

* Um estudo sobre marcações sociais de del.icio.us sugere que um usuário ativo cria 4,2 etiquetas/mês. As etiquetas, nesse contexto, referem-se a qualquer atividade que atribua metadados a URLs. Isso inclui etiquetas de palavras-chave, classificações e anotações. Isso significa que um usuário ativo cria 4,2 etiquetas/30 dias = 0,14 etiquetas/dia. Pressupondo que um terço dos usuários do portal social criem marcações, há 150K/3 × 0,14 eventos de marcação por dia. As tabelas do feed de atividades mantêm atividades por 14 dias. Portanto, o número total de eventos de marcação na tabela do feed de atividades é igual a 150K/3 × 0,14 × 14. Além dos eventos de marcação, se pressupormos que os usuários ativos geram um evento adicional por dia, como uma atualização das propriedades do perfil ou uma atualização de status, temos 150K/3 × 1 × 14 eventos a serem adicionados às tabelas do feed de atividades. Portanto, o número total de eventos nas tabelas do feed de atividades é igual a 150K/3 × 1,14 × 14 = 798K. Desses eventos, 98K são atividades de marcação que podem disparar a filtragem de segurança. O restante dos eventos será distribuído aleatoriamente entre as atualizações de status e as alterações das propriedades do perfil.

** Pressupõe que um terço da população são usuários ativos e que cada um deles cria 4,2 etiquetas por mês, onde essas etiquetas podem ser uma etiqueta de palavra-chave, uma anotação ou uma classificação. Pressupondo que o farm existe há dois anos, o número total de etiquetas será 150K/3 × 4,2 × 12 × 2 = 5,04 MB.

A tabela a seguir explica a geometria do disco com detalhes.

Banco de dados	ContentDB 1, 2, 3, 4	ContentDB 5, 6	ContentDB 7, 8	ContentDB 9, 10	Perfil	Social	Metadados
Tamanho do banco de dados	61,4 GB	39 GB	32,3 GB	33,7 GB	27,7 GB	3,7 GB	0,14 GB
Configuração de RAID	0	0	0	0	0	0	0
Número de eixos para o MDF	1	1	1	1	6	1	1
Número de eixos para o LDF	um eixo físico compartilhado por todos os bancos de dados

Combinação de testes

Observações importantes:

• Os testes utilizam somente o modelo de uso em horário nobre de um típico portal de computação social. Nós não consideramos as alterações cíclicas no tráfego gerado pelo usuário observadas em ciclos de dia/noite. Trabalhos de timer, como a Sincronização de Perfis e o Rastreamento de Pesquisas de Pessoas, que exigem recurso significativos, foram testados independentemente com a mesma carga de trabalho para determinar os seus efeitos.

• Os testes se concentram mais nas operações sociais, como os feeds de notícias, as marcações sociais e a leitura dos perfis dos usuários. Eles contém uma quantidade pequena do tráfego típico de colaboração; no entanto, não é esse o foco. Esses resultados devem ajudar a projetar um portal separado dedicado aos Meus Sites e aos recursos sociais.

• A combinação de testes não inclui o tráfego do Rastreamento do Conteúdo de Pesquisa. No entanto, isso foi considerado em nossos testes, modificando a definição de Zona Verde para 40% de utilização da CPU do SQL Server, em vez dos 50% padrão para permitir que o rastreamento de pesquisa utilizasse 10% da CPU. Similarmente, usamos 80% da CPU do SQL Server como critério para o RPS máximo.

• Além da combinação de testes listada na tabela a seguir, também adicionamos oito RPS para cada servidor Web front-end para o tráfego do Outlook Social Connector. Ativamos a filtragem de segurança. O Serviço de Token de Segurança apresentou sinais significativos de estresse conforme nos aproximávamos de cerca de 8 RPS do tráfego do Outlook Social Connector em um único servidor Web front-end ao obter as atividades dos colegas. Essa era uma função do conjunto de dados, da carga de trabalho de teste e do hardware que usamos no laboratório para os testes. Você poderá observar um comportamento totalmente diferente. Para evitar estresse adicional no Serviço de Token de Segurança, decidimos adicionar o tráfego do Outlook Social Connector como uma função do número de servidores Web front-end em cada iteração. Portanto, para 1x1x1, temos 8 RPS de tráfego do Outlook Social Connector, enquanto para 2x1x1, temos 16 RPS de tráfego do Outlook Social Connector e assim por diante.

A combinação geral de testes é apresentada na tabela a seguir.

Teste	Leitura/gravação	Porcentagem de combinação
Adicionar um colega.	Gravação	2,11
Criar uma classificação em uma URL, escrever uma anotação ou marcar uma URL.	Gravação	3,22
Listar documentos de operações.	Leitura/gravação	2,36
Fazer com que os links publicados modelem as chamadas de clientes para PublishedLinksService.asmx.	Leitura	6,92
Obter RSS feeds de listas.	Leitura	3,72
Visualizar todos os itens de bibliotecas de documentos e listas em Meu Site.	Leitura	1,07
Visualizar uma postagem de blog.	Leitura	0,04
Visualizar diversas páginas de Meu Site (meu conteúdo, colegas, feeds de notícias, meu perfil, o perfil de outra pessoa, o navegador da organização, associações, etiquetas, anotações).	Leitura	3,87
Sincronizar arquivos compartilhados do OneNote.	Leitura	10,0
Editar a minha página de perfil ou mensagem de status, atualizar foto.	Gravação	2,31
Office Web Apps: abrir e navegar pelos arquivos (PowerPoint, Word e Excel).	Leitura	0,13
Sincronizar listas com o Outlook.	Leitura	48,16
Carregar um documento.	Gravação	0,09
Carregar páginas, bibliotecas de documentos e pastas do banco de dados de conteúdo.	Leitura	15,93
Realizar a coautoria de documentos.	Leitura/gravação	0,17

A tabela a seguir descreve a combinação de testes do cenário adicional do Outlook Social Connector que gera 8 RPS por servidor Web front-end.

Sincronizar automaticamente os meus colegas.	Leitura	4%
Sincronizar automaticamente os feeds de notícias dos meus colegas.	Leitura	96%

Resultados e análise

Comparação de todas as iterações

Conforme mencionamos anteriormente , começamos com uma configuração mínima de farm, que consistia em um servidor Web front-end, um servidor de aplicativos e um computador baseado no SQL Server. Após várias iterações, finalmente chegamos a um farm com oito servidores Web front-end, um servidor de aplicativos e dois computadores do SQL Server. Para cada uma dessas iterações, realizamos testes de etapas de cargas para determinar a Zona Verde e a Zona Máxima. Na tabela a seguir, você verá uma comparação dessas características de desempenho de Zona Verde e Zona Máxima nas diferentes iterações.

A tabela e os gráficos a seguir apresentam um resumo para comparação e análise.

Resultados da Zona Verde

As características de desempenho da Zona Verde nas topologias são resumidas na tabela a seguir.

Topologia	1x1x1	2x1x1	3x1x1	5x1x1	8x1x1	8x1x2
RPS da Zona Verde	137,25	278,08	440,72	683,07	793,67	873,4
Latência do percentil 75 da Zona Verde	0,12	0,16	0,14	0,16	0,31	0,32
CPU do servidor Web front-end da Zona Verde	47,84	46,88	48,68	46,13	31,79	36,90
CPU do servidor de aplicativos da Zona Verde	9,45	18,88	26,91	35,58	48,73	47,20
CPU do SQL Server da Zona Verde	5,45	10,61	16,46	24,73	30,03	32,40 (17,9 para o banco de dados de conteúdo e 14,5 para o banco de dados de serviços)

O gráfico a seguir mostra as variações na utilização da CPU plotadas no RPS e oferecidas por diversas topologias para obter os resultados da Zona Verde.

Conforme foi ilustrado no gráfico anterior:

• O RPS aumentou a taxa de transferência conforme adicionávamos mais computadores às topologias.

• Esta claro que a CPU do servidor Web front-end foi o principal fator que levou a topologia até o limite da Zona Verde até 5x1x1. Em 8x1x1, a CPU do servidor de aplicativos atingiu o limite da Zona Verde antes que os servidores Web front-end pudessem alcançar os limites da Zona Verde.

• Durante o teste, a CPU do SQL Server permaneceu em um território de grande integridade.

Resultados da Zona Máxima

A tabela a seguir apresenta resumo dos resultados nas topologias para a Zona Máxima.

	1x1x1	2x1x1	3x1x1	5x1x1	8x1x1	8x1x2
RPS da Zona Máxima	203,28	450,75	615,00	971,13	1.655	1.877
Latência da Zona Máxima	0,22	0,23	0,22	0,22	0,31	0,32
CPU do servidor Web front-end da Zona Máxima	75,13	78,17	70,00	67,02	67	71,6
CPU do servidor de aplicativos da Zona Máxima	12,97	27,07	28,40	48,28	67,1	73,4
CPU do SQL Server da Zona Máxima	7,64	16,06	21,00	38,38	79,5	74,9 (45,9 para o banco de dados de conteúdo e 29 para o banco de dados de serviços)

O gráfico a seguir mostra as variações na utilização da CPU plotadas no RPS e oferecidas por diversas topologias para obter os resultados da Zona Máxima.

Conforme foi ilustrado no gráfico anterior:

• O RPS aumentou a taxa de transferência conforme adicionávamos mais computadores às topologias.

• Está claro que a CPU do servidor Web front-end era o afunilamento até a topologia 5x1x1. Em 8x1x1, a CPU do SQL Server se tornou o afunilamento.

• Inicialmente, a utilização da CPU do servidor de aplicativos era maior do que a utilização da CPU do SQL Server. No entanto, aparentemente a taxa de crescimento da utilização da CPU do SQL Server é maior do que a taxa de crescimento da utilização da CPU do servidor de aplicativos. Com níveis mais altos de taxa de transferência, a utilização da CPU do SQL Server ultrapassou a utilização da CPU do servidor de aplicativos e se tornou o afunilamento.

Zona Verde versus Zona Máxima

Os gráficos a seguir comparam a taxa de transferência e as latências da Zona Verde e da Zona Máxima de diferentes topologias.

Conforme foi ilustrado no gráfico anterior:

• As latências não variam muito com a taxa de transferência ou com as topologias. Nos nossos testes, todas as latências estavam abaixo de 0,5 segundo, o que é bastante aceitável.

• O aumento da taxa de transferência é quase linear.

E/S de disco

A tabela e o gráfico a seguir apresentam a E/S de disco observada em cada banco de dados de diferentes topologias. Não observamos a E/S de disco como afunilamento e, ao observar a tendência, não registramos dados para topologias posteriores.

	1x1x1 Zona Máxima	2x1x1 Zona Máxima	3x1x1 Zona Máxima	5x1x1 Zona Máxima
Leituras/segundo (banco de dados de conteúdo)	21,33	20,80	24,24	22,42
Leituras/segundo (banco de dados de perfis)	14,97	17,20	19,82	13,50
Leituras/segundo (banco de dados social)	1,81	1,83	2,10	2,01
Gravações/segundo (banco de dados de conteúdo)	50,12	76,24	80,02	99,16
Gravações/segundo (banco de dados de perfis)	9,01	24,31	23,35	38,29
Gravações/segundo (banco de dados social)	4,12	9,47	10,63	19,45

Efeito do rastreamento da Pesquisa de Pessoas

Queríamos medir o efeito do rastreamento da Pesquisa de Pessoas na taxa de transferência oferecida por uma configuração e pelas latências do usuário final. Para esse teste, utilizamos os resultados fornecidos por uma configuração de 8x1x1 como linha de base e iniciamos o rastreamento incremental da Pesquisa de Pessoas. O rastreamento incremental indexou 49.375 itens em 53 minutos.

Uma comparação das características de desempenho exibidas pela configuração 8x1x1 com e sem o rastreamento incremental da Pesquisa de Pessoas é apresentada na tabela a seguir.

	Resultados da Zona Verde de 8x1x1 da linha de base	Resultados da Zona Verde de 8x1x1 com rastreamento da Pesquisa de Pessoas
Taxa de transferência (RPS)	1024,00	1026,00
CPU de servidor Web front-end (%)	39,84	41,6
CPU do servidor de aplicativos (%)	41,40	43,1
CPU do SQL Server para conteúdo/serviços (%)	36,63	39,5
CPU do servidor do rastreamento (%)	0,52	34,6
CPU do SQL Server para Pesquisa (%)	3,62	14,8

Conforme descrito nessa tabela:

• O RPS permaneceu praticamente o mesmo. Como não houve afunilamento de recursos na Zona Verde de 8x1x1, não há motivos para que o RPS seja afetado.

• A utilização da CPU do servidor Web front-end Web e do SQL Server de conteúdo/serviços melhorou ligeiramente.

• A CPU do servidor do Rastreamento e do SQL Server aumentou de 0,5% para 34,6% e de 3,6% para 14,8%.

Análise

Escala do servidor de aplicativos

O servidor de aplicativos não foi um afunilamento em nenhuma das configurações. Além disso, ao analisar a utilização da CPU do servidor de aplicativos para diferentes cargas de VSTS em qualquer configuração, você observará que ela aumenta e estabiliza. Um exemplo ideal dessa situação pode ser observada na configuração 8x1x1, conforme é apresentado na tabela a seguir.

Carga do VSTS	416	616	816	1.016	1.216	1.416	1.616
Utilização da CPU do servidor de aplicativos (%)	37,6	49,4	57,9	61,9	67,1	65,3	63,10

Isso é esperado. No caso de um portal social, a maioria das operações exigem que você trabalhe com o serviço de Perfil de Usuário do SharePoint Server. A maioria das operações requer a busca de perfil de um usuário do banco de dados de Perfis provisionado quando o serviço Perfil de Usuário é criado.

Para evitar frequentes viagens de ida e volta no SQL Server, o servidor de aplicativos do serviço de Perfil de Usuário mantém um cache de perfis de usuário. Inicialmente, conforme o ambiente de testes se aquece, o cache fica vazio e o servidor de aplicativos responde a solicitações e entrada do servidor Web front-end buscando perfis de usuário constantemente do SQL Server. Esses perfis são armazenados em cache e, em seguida, todas as solicitações do servidor Web front-end podem ser respondidas pelo servidor de aplicativos sem causar uma viagem de ida e volta no SQL Server. Basta buscar o perfil no cache.

Como o número de perfis de usuários usados no teste era limitado, observamos o servidor de aplicativos armazenar todos esses perfis em cache. Depois disso, ele apresentou um aumento na utilização. Quando todos os perfis foram armazenados em cache, restou uma operação estável de pesquisas de cache. Portanto, observamos uma estabilização da utilização da CPU.

Tráfego e filtragem de segurança do Outlook Social Connector

O Outlook Social Connector é um suplemento incluído com o Office 2010 que exibe as atividades dos seus colegas do SharePoint no Outlook. Esse complemento também está disponível para download gratuito para o Microsoft Office 2007 e o Microsoft Office 2003.

O Outlook Social Connector verifica o SharePoint Server uma vez por hora para obter as atividades dos usuários que estão listados como colega de um usuário específico. Ele armazena essas atividades em cache a cada hora. Nas verificações seguintes, o Outlook Social Connector simplesmente busca as atividades novas desde a última verificação do SharePoint Server. Portanto, ele segue um padrão de tráfego muito previsível. Para uma implantação de 100.000 do Outlook Social Connector e do SharePoint Server, pressupondo que todos os usuários o utilizem o dia inteiro, o Outlook Social Connector gera 100.000 solicitações por hora, o que resulta em 27,77 RPS.

Exibir as atividades dos colegas pode causar a divulgação de informações. Por exemplo, uma URL marcada por um colega pode ser uma informação confidencial ao qual outro usuário não tem acesso. Nesse caso, o usuário poderá descobrir sobre a existência desse conteúdo confidencial visualizando-o pelo Outlook Social Connector. Para evitar essa divulgação de informações, o SharePoint Server filtra todas as atividades e exibe somente as URLs às quais um usuário tem acesso nos feeds de atividade. Chamamos isso de filtragem de segurança. Por padrão, a filtragem de segurança é ativada. No entanto, ela pode ser desativada por um administrador do SharePoint Server.

Nem todas as atividades exigem filtragem de segurança. Entre 16 tipos de atividade suportadas pelo SharePoint Server 2010, somente quatro atividades (marcação, comentários no Bloco de Anotações, classificações e alterações nas associações da lista de distribuição (DL)) exigem filtragem de segurança. Além disso, como o Outlook Social Connector solicita somente um delta das atividades ocorridas após a última sincronização, o número de atividades por usuário que exigiriam filtragem de segurança é razoavelmente baixo.

Todas as solicitações do Outlook Social Connector que exigem filtragem de segurança resultam em uma chamada do Windows Communication Foundation (WCF) para o servidor de aplicativos do Serviço de Pesquisa. Para obter o token de autenticação para realizar a chamada, uma chamada do WCF é primeiro realizada para o Serviço de Token de Segurança.

Descobrimos que, se o Outlook Social Connector ultrapassasse oito RPS por servidor Web front-end, o Serviço de Token de Segurança sofreria estresse. O estresse no Serviço de Token de Segurança pode não ocorrer com todos os usuários, pois ele é afetado pelo número total de usuários e a quantidade total de marcações sociais ocorridas nas atividades dos colegas de um usuário. No conjunto de dados que criamos e com os usuários que utilizamos, nós provavelmente tínhamos uma quantidade suficiente de atividades que exigiam filtragem de segurança para presenciar esse cenário. Portanto, aumentamos o tráfego do Outlook Social Connector de acordo com a função do número de servidores Web front-end disponíveis. Para a configuração 1x1x1, nós gerados 8 RPS de tráfego do Outlook Social Connector. No entanto, para uma configuração 2x1x1, nós geramos 16 RPS de tráfego do Outlook Social Connector e assim por diante.

Isso significa que, para o conjunto de dados, combinação de testes e hardware utilizados em nossos testes, poderíamos oferecer suporte para cerca de 8 × 60 × 60, ou seja, 28.800 solicitações por hora. Considerando como o Outlook Social Connector funciona, isso significa que poderíamos oferecer suporte para 28.800 usando o Outlook Social Connector em um servidor Web front-end com a filtragem de segurança ativada. Similarmente, poderíamos oferecer suporte para 28.800 × 3, que seriam 86.400 funcionários usando o Outlook Social Connector em três servidores Web front-end com a filtragem de segurança ativada.

Isso deve ajudar a criar uma estimativa o hardware necessário para oferecer suporte para o tráfego do Outlook Social Connector, mas observe que os resultados que observamos são específicos do conjunto de dados, combinação de testes e hardware usados nos testes. Além disso, lembre-se que você tem a opção de desativar a filtragem de segurança usando o Windows PowerShell 2,0 ou alterando a frequência das sincronizações do Outlook Social Connector com o SharePoint Server. Ambas as opções afetam os requisitos de hardware significativamente.

Resultados das iterações

Os resultados a seguir estão organizados com base na abordagem de dimensionamento descrita em Visão geral, anteriormente neste artigo.

Topologia 1x1x1

Esta seção descreve os resultados de testes obtidos com um servidor Web, um servidor de aplicativos e um servidor de banco de dados.

Resumo dos resultados

• Além da combinação de testes apresentada anteriormente neste artigo, esse farm tinha um tráfego de 8 RPS do Outlook Social Connector solicitando eventos de feed de um usuário.

• Em um farm com um servidor Web front-end, um servidor de aplicativos e um computador de SQL Server, o servidor Web front-end era claramente o afunilamento. Conforme apresentamos na tabela a seguir, a CPU do servidor Web front-end atingiu uma utilização de cerca de 90% quando o farm foi sujeitado a 238 RPS ao usar a combinação transacional descrita anteriormente neste documento.

• Essa configuração forneceu um RPS de Zona verde de 137,25, com uma latência de 75% de 0,12 segundos e a utilização da CPU do servidor Web front-end em cerca de 47,8%. Isso indica que esse farm pode fornecer com êxito um RPS de cerca de 137,25. O RPS da Zona Máxima fornecido por esse farm foi de 203,2 com latências de 0,22 segundos e a utilização da CPU do servidor Web front-end em cerca de 85%.

• Como o servidor Web front-end era o afunilamento, adicionamos outro servidor desse tipo ao farm na iteração seguinte.

Contadores e gráficos de desempenho

Diversos contadores de desempenho capturados durante o teste do farm 1x1x1, em diferentes etapas de carga do VSTS, são apresentados na tabela a seguir.

Carga do VSTS	52	77	102	127	152	177
RPS	99,8	147	188	218	238	243
CPU do servidor Web front-end	33,9	50	71,8	81,1	90,8	89
CPU do servidor de aplicativos	7,92	11,7	13,5	14,1	13,9	13,3
CPU do SQL Server	4,7	6,48	7,99	8,21	8,41	8,88
Percentil 75 [segundos]	0,13	0,16	0,17	0,25	0,3	0,45
Percentil 95 [segundos]	0,29	0,47	0,41	0,55	0,55	0,77

Topologia 2x1x1

Esta seção descreve os resultados de testes obtidos com dois servidores Web, um servidor de aplicativos e um servidor de banco de dados.

Resumo dos resultados

• Além da combinação de testes apresentada anteriormente neste artigo, esse farm tinha um tráfego de 16 RPS do Outlook Social Connector solicitando eventos de feed de um usuário.

• Em um farm com dois servidores Web front-end, um servidor de aplicativos e um computador SQL Server, os servidores Web front-end eram o afunilamento. Conforme apresentamos nestes dados, a CPU do servidor Web front-end atingiu uma utilização de cerca de 89% quando o farm foi sujeitado a 520 RPS ao usar a combinação transacional descrita anteriormente neste documento.

• Essa configuração forneceu um RPS de Zona verde de 278, com uma latência de 75% de 0,16 segundos e a utilização da CPU do servidor Web front-end em cerca de 47%. Isso indica que esse farm pode fornecer com êxito um RPS de cerca de 278 com a combinação de testes e o hardware utilizado nesses testes. O RPS da Zona Máxima fornecido por esse farm foi de 450 com latências de 0,23 segundos e a utilização da CPU do servidor Web front-end em cerca de 78%.

• Como a CPU do servidor Web front-end era o afunilamento dessa iteração, aliviamos esse afunilamento adicionando outro servidor Web front-end na iteração seguinte.

Contadores e gráficos de desempenho

Diversos contadores de desempenho capturados durante o teste do farm 2x1x1, em diferentes etapas de carga do VSTS, são apresentados na tabela e no gráfico a seguir.

Carga do VSTS	104	154	204	254	304	354
RPS	190	278	390	455	500	520
CPU do servidor Web front-end	36	50,9	71,9	86,9	87,1	89,5
CPU do servidor de aplicativos	16	24,9	28,3	26,5	26,5	24,9
CPU do SQL Server	8,06	10,6	14,2	16,4	17,9	18,9
Percentil 75 [segundos]	0,16	0,22	0,22	0,33	0,42	0,53
Percentil 95 [segundos]	0,42	0,64	0,51	0,69	0,73	0,89

Topologia 3x1x1

Esta seção descreve os resultados de testes obtidos com três servidores Web, um servidor de aplicativos e um servidor de banco de dados.

Resumo dos resultados

• Além da combinação de testes apresentada anteriormente neste artigo, esse farm tinha um tráfego de 24 RPS do Outlook Social Connector solicitando eventos de feed de um usuário.

• Em um farm com três servidores Web front-end, um servidor de aplicativos e um computador de SQL Server, os servidores Web front-end eram no afunilamento. Conforme apresentamos nestes dados, a CPU do servidor Web front-end atingiu uma utilização de cerca de 76% quando o farm foi sujeitado a 629 RPS ao usar a combinação transacional descrita anteriormente neste documento.

• Essa configuração forneceu um RPS de Zona verde de 440, com uma latência de 75% de 0,14 segundos e a utilização da CPU do servidor Web front-end em cerca de 48%. Isso indica que esse farm pode fornecer um RPS de cerca de 440 com a combinação de testes e o hardware utilizado nesses testes. O RPS da Zona Máxima fornecido por esse farm foi de 615 com latências de 0,22 segundos e a utilização da CPU do servidor Web front-end em cerca de 70%.

• Como a CPU do servidor Web front-end era o afunilamento dessa iteração, decidimos adicionar mais servidores Web front-end. Considerando o delta entre as iterações anteriores após a inclusão de um servidor Web front-end, decidimos adicionar dois servidores desse tipo. Com isso, esperávamos descobrir o servidor de aplicativos ou o computador do SQL Server como o afunilamento.

Contadores e gráficos de desempenho

Diversos contadores de desempenho capturados durante o teste do farm 3x1x1, em diferentes etapas de carga do VSTS, são apresentados na tabela e no gráfico a seguir.

Carga do VSTS	156	231	306	381	456	531
RPS	264	393	532	624	634	629
CPU do servidor Web front-end	30,5	46,3	62,55	72,95	75,4	76
CPU do servidor de aplicativos	22,7	35,6	34,2	32,5	32,5	29,4
CPU do SQL Server	10,4	14,8	20,8	22,5	22,8	22,4
Percentil 75 [segundos]	0,17	0,26	0,27	0,28	0,31	0,40
Percentil 95 [segundos]	0,63	1,08	0,76	0,68	0,88	0,98

Topologia 5x1x1

Esta seção descreve os resultados de testes obtidos com cinco servidores Web, um servidor de aplicativos e um servidor de banco de dados.

Resumo dos resultados

• Além da combinação de testes apresentada anteriormente neste artigo, esse farm tinha um tráfego de 40 RPS do Outlook Social Connector solicitando eventos de feed de um usuário.

• Em um farm com cinco servidores Web front-end, um servidor de aplicativos e um computador do SQL Server, observamos um aumento significativo na utilização da CPU do SQL Server e do servidor de aplicativos, mas a CPU do servidor Web front-end permanecia como o afunilamento. Conforme apresentamos nestes dados, a CPU do servidor Web front-end atingiu uma utilização de cerca de 88% quando o farm foi sujeitado a 1315 RPS ao usar a combinação transacional descrita anteriormente neste documento.

• Essa configuração forneceu um RPS de Zona verde de 683, com uma latência de 75% de 0,16 segundos e a utilização da CPU do servidor Web front-end em cerca de 46%. Isso indica que esse farm pode fornecer com êxito um RPS de cerca de 683 com a combinação de testes e o hardware utilizado nesses testes. O RPS da Zona Máxima fornecido por esse farm foi de 971 com latências de 0,22 segundos e a utilização da CPU do servidor Web front-end em cerca de 68%.

• Observando a tendência, decidimos adicionar três servidores Web front-end e testar a configuração 8x1x1. Esperamos que, com essa configuração, o servidor de aplicativos ou o SQL Server se torne o afunilamento.

Contadores e gráficos de desempenho

Diversos contadores de desempenho capturados durante o teste do farm 5x1x1, em diferentes etapas de carga de usuário, são apresentados aqui. Como não observamos um efeito significativo da carga do VSTS ou alterações de configuração de latência, paramos de registrar esses dados.

Carga do VSTS	260	385	510	635	760	885
RPS	359	560	901	1.188	1.281	1.315
CPU do servidor Web front-end	20,5	34	56,2	77,5	86,1	88
CPU do servidor de aplicativos	40,2	50,6	66,9	71,3	66,3	58,7
CPU do SQL Server	13,9	20,3	34,9	53,6	58,4	64

Topologia 8x1x1

Esta seção descreve os resultados de testes obtidos com oito servidores Web, um servidor de aplicativos e um servidor de banco de dados.

Resumo dos resultados

• Além da combinação de testes apresentada anteriormente neste artigo, esse farm tinha um tráfego de 64 RPS do Outlook Social Connector solicitando eventos de feed de um usuário.

• Em um farm com oito servidores Web front-end, um servidor de aplicativos e um computador de SQL Server, a CPU do SQL Server finalmente se tornou o afunilamento. Conforme apresentamos nestes dados, a CPU do SQL Server atingiu uma utilização de cerca de 80% quando o farm foi sujeitado a 1664 RPS ao usar a combinação transacional descrita anteriormente neste documento.

• Essa configuração forneceu um RPS de Zona verde de 793, com uma latência de 75% de 0,31 segundos e a utilização da CPU do SQL Server em cerca de 30%. No entanto, a utilização da CPU do servidor de aplicativos era de cerca de 48%. Isso indica que esse farm pode fornecer com êxito um RPS de cerca de 793 com a combinação de testes e o hardware utilizado nos testes. O RPS da Zona Máxima fornecido por esse farm foi de 1655 com latências de 0,31 segundos e a utilização da CPU do SQL Server em cerca de 80%.

• Como a CPU do SQL Server era o afunilamento dessa iteração, aliviamos o afunilamento separando o banco de dados de conteúdo e o banco de dados de serviços em duas instâncias do SQL Server na iteração seguinte.

Contadores e gráficos de desempenho

Diversos contadores de desempenho capturados durante o teste do farm 8x1x1, em diferentes etapas de carga do VSTS, são apresentados na tabela e no gráfico a seguir.

Carga do VSTS	416	616	816	1.016	1.216	1.416	1.616
RPS	664	1.101	1.359	1.530	1.655	1.664	1.617,00
CPU do servidor Web front-end	26,7	44,4	54,7	61,5	67	65,9	65,10
CPU do servidor de aplicativos	37,6	49,4	57,9	61,9	67,1	65,3	63,10
CPU do SQL Server	23,2	42	57,9	69,5	79,5	80,8	77,30

Topologia 8x1x2

Esta seção descreve os resultados de testes obtidos com oito servidores Web, um servidor de aplicativos e dois servidores de banco de dados.

Resumo dos resultados

• Além da combinação de testes apresentada anteriormente neste artigo, esse farm tinha um tráfego de 64 RPS do Outlook Social Connector solicitando eventos de feed de um usuário.

• Em um farm com oito servidores Web front-end, um servidor de aplicativos e dois computadores do SQL Server, poderíamos levar essa configuração ao seu extremo. O servidor Web front-end e o servidor de aplicativos eram afunilamentos, enquanto a utilização de CPU combinada do SQL Server também estava acima de 70%. O farm apresentou um RPS de 1.817 em sua carga máxima.

• Essa foi a última iteração testada. No entanto, está claro que, caso você precise ampliar mais a sua configuração, a próxima etapa seria usar dois computadores para executar as tarefas do servidor de aplicativos. Isso permitiria que você incluísse uma quantidade ainda maior de servidores Web front-end e, assim, reduzisse a carga em cada um deles.

Contadores e gráficos de desempenho

Diversos contadores de desempenho capturados durante o teste do farm 8x1x2, em diferentes etapas de carga do VSTS, são apresentados na tabela e no gráfico a seguir.

Carga do VSTS	466	666	866	1.066	1.266	1.416
RPS	466,00	873,40	1.431,00	1.703,00	1.766,00	1.817,00
CPU do servidor Web front-end	19,90	36,90	57,60	68,00	71,40	71,60
CPU do servidor de aplicativos	29,80	47,20	63,50	71,40	71,90	73,40
CPU total do SQL Server	19,61	32,40	55,20	63,60	68,50	74,90
CPU de conteúdo do SQL Server	9,93	17,90	31,90	40,10	42,30	45,90
CPU de serviços do SQL Server	9,68	14,50	23,30	23,50	26,20	29,00

Sobre os autores

Gaurav Doshi é gerente de programas da Microsoft

Wenyu Cai é engenheiro de software em teste da Microsoft

See Also

Other Resources

Centro de Recursos: Gerenciamento da capacidade do SharePoint Server 2010