Estimar requisitos de desempenho e capacidade para ambientes sociais (SharePoint Server 2013)
APLICA-SE A:
2013 
2019 Subscription Edition SharePoint no Microsoft 365
Para criar um plano de desempenho e capacidade para uma intranet empresarial Meu Site e uma solução de portal de computação social, este artigo contém informações sobre as seguintes áreas:
Especificações de ambiente de laboratório, como hardware, topologia de farm e configuração de farm
A carga de trabalho e o conjunto de dados do farm de teste usado para gerar a carga de teste
Testar resultados e análises que demonstram e explicam tendências na taxa de transferência, latência e demanda de hardware sob carga em pontos de escala específicos.
Use as informações neste artigo para entender os seguintes conceitos:
Características do cenário em cargas normais e de pico
Como as tendências de desempenho mudam quando os servidores farm são dimensionados
Como estimar um ponto de partida apropriado para sua arquitetura planejada
Fatores importantes a serem considerados quando você planeja os recursos que seu farm precisará para manter níveis aceitáveis de desempenho sob carga máxima
Introdução a este ambiente
As empresas geralmente usam o SharePoint Server 2013 para publicar Meu Site e portais de computação social que autenticaram o acesso dos usuários em um site de intranet. Este artigo contém dados de capacidade e desempenho para ajudar a planejar o número de computadores a serem usados e os tipos de computadores necessários para publicar Meu Site e portais de computação social no SharePoint Server 2013.
Diretrizes adicionais explicam como dimensionar servidores em uma solução de portal de computação social do SharePoint Server 2013. O planejamento de capacidade informa as decisões sobre o hardware a ser adquirido e as configurações de sistema que otimizam sua solução.
Como as fazendas individuais do SharePoint Server 2013 são exclusivas, cada farm tem requisitos diferentes que dependem de hardware, comportamento do usuário, configuração de recursos instalados e muitos outros fatores. Portanto, complemente esta orientação com testes adicionais em seu próprio hardware e ambiente. Se o design e a carga de trabalho planejados se parecem com o ambiente descrito neste artigo, você pode usar este artigo para descrever conclusões sobre como dimensionar seu ambiente.
Os resultados do teste neste artigo foram produzidos em um laboratório de teste, usando uma carga de trabalho, conjunto de dados e arquitetura para simular um ambiente de produção em condições altamente controladas. Embora o design dos testes necessite de muito cuidado, as características de desempenho de um laboratório de teste nunca são as mesmas como o comportamento de um ambiente de produção. Estes resultados de testes não representam o desempenho e a capacidade característicos de um farm de produção. Em vez disso, eles demonstram tendências observadas nas demandas de taxa de transferência, latência e hardware. Use a análise dos dados observados para ajudá-lo a planejar a capacidade e a gerenciar seu próprio farm.
Este artigo inclui o seguinte:
Especificações, que incluem hardware, topologia e configuração
A carga de trabalho, que inclui uma análise da demanda sobre o farm, o número de usuários e características de uso
O conjunto de dados, como tamanhos de bancos de dados e tipos de conteúdo
Resultados de testes e análises para dimensionar servidores Web
Antes de ler este artigo, leia os artigos a seguir para garantir que você entenda os principais conceitos por trás do gerenciamento de capacidade no SharePoint Server 2013.
Estes artigos fornecem as seguintes informações:
A abordagem recomendada para gerenciamento de capacidade
Como fazer uso eficaz das informações neste artigo
Glossário
A lista a seguir contém as definições dos principais termos deste artigo:
RPS: Solicitações por segundo. RPS é o número de solicitações que um farm ou servidor recebe em um segundo. É uma medição comum da carga do servidor e do farm.
Importante
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 um navegador carrega uma página. 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: A Zona Verde representa um conjunto definido de características de carga em condições operacionais normais, até cargas de pico diárias esperadas. Um farm que opera nesta faixa deve estar apto a manter tempos de resposta e latência que estejam dentro de parâmetros aceitáveis.
Este é o estado no qual o servidor pode manter os seguintes conjuntos de critérios:
A latência do lado do servidor para pelo menos 75% das solicitações é inferior a 0,5 segundos.
Todos os servidores mantêm uma utilização média de CPU inferior a 50%.
A taxa de falha é menor que 0,1%.
Zona Vermelha (Max): A Zona Vermelha representa um conjunto definido de características de carga em condições de operação de pico. Na Zona Vermelha, o farm apresenta uma demanda de recursos transitórios muito alta, e só pode ser sustentado por períodos limitados, até a ocorrência de falhas e outros problemas de desempenho e confiabilidade.
Este é o estado no qual o servidor pode manter os seguintes conjuntos de critérios por uma duração limitada
A latência do lado do servidor para pelo menos 75% das solicitações é menor que 1 segundo.
A utilização média da CPU do servidor de banco de dados é inferior a 80%.
A taxa de falha é menor que 0,1%.
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 em seu ambiente na ordem específica que seguimos para escalar nosso ambiente de laboratório de teste. Essa abordagem permitirá que você identifique a melhor configuração para a sua carga de trabalho.
Dividimos os ciclos de teste de desempenho em três categorias de carga de trabalho. O parâmetro primário que determinou o limite de categoria foi o número de perfis de usuário, que foi definido em testes de perfil de usuário de 10K, 100 mil e 500 mil. Outro parâmetro foi o número de usuários ativos, que estavam realizando ações relacionadas ao conjunto social de recursos. Com o número de usuários com um perfil e um número de usuários ativos, fizemos testes para simular o uso do aplicativo que seria semelhante a implantações reais. A tabela a seguir mostra o conjunto de dados inicial e o número de usuários ativos.
Conjunto de Dados Inicial
| Entidade | % dos usuários com esse recurso | Pequenos (usuários de 10 mil) | Médio (100 mil usuários) | Grandes (500 mil usuários) |
|---|---|---|---|---|
| Número de perfis de usuário para usuários |
100% |
10K |
100 mil |
500 mil |
| Número de Meus Sites provisionados |
100% |
10K |
100 mil |
500 mil |
| Número de perfis de usuário que têm fotos de usuário |
50% |
5K |
50 mil |
250 mil |
| Número de perfis de usuário que têm postagens |
10% |
1K |
10K |
50 mil |
| Número de equipes |
1,860 |
18,600 |
93K |
|
| Número de usuários ativos por dia |
10% |
1K |
10K |
50 mil |
| Número de usuários ativos por hora |
5% |
500 |
5K |
25 mil |
Os testes se concentraram nos seguintes cenários principais:
Acesso à página do Feed de Notícias e outras ações
Página de perfil
Acesso à página do feed do site e outras ações
Sincronização do Feed de Atividades do Conector Social do Outlook
Acesso à página do OneDrive
Uso do cliente do OneDrive
Para simular um cenário de implantação realista, todos os testes foram executados em um banco de dados que já tinha dados. O conjunto de dados era um modelo de uma organização de árvores com uma média de 4 a 6 usuários por equipe e 3 a 4 níveis de profundidade. Para gerar esses números, analisamos o tráfego de um site social interno. A tabela a seguir descreve o conjunto de parâmetros que usamos para criar o conjunto de dados inicial.
Modelo de dados para banco de dados inicial
| Descrição da entidade de dados | Número |
|---|---|
| Número médio de usuários na equipe |
5 |
| Número médio de níveis por organização |
4 |
| Número de equipes por 1.000 usuários |
186 |
| Número médio de colegas que um usuário segue |
50 |
| Número de propriedades do Perfil de Usuário |
93 |
A tabela a seguir descreve o conjunto de parâmetros em termos de ações que resultariam na população de dados:
Características de uso
| Parâmetro | Número ou porcentagem |
|---|---|
| Percentual de usuários com 1 a 3 postagens |
10% |
| Número médio de postagens por usuário |
2 |
| Número médio de respostas por postagem |
2 |
| Percentual de postagens que são curtidas |
15% |
| Percentual de postagens com links |
5% |
| Percentual de postagens com marcas |
12% |
| Percentual de postagens com menções de usuário |
8% |
| Percentual de postagens com imagem anexada |
5% |
Para criar cada um de nossos testes de escala, aplicamos o seguinte mix de ações ao conjunto de dados anterior e ao número de usuários ativos:
Ações de LEITURA do Usuário
| Ação do usuário | % do usuário que está tomando essa ação | Cenário | Recurso ou URL |
|---|---|---|---|
| Navegar até a página inicial do Meu Site |
12% |
News feed |
Página do Newsfeed (http://my/default.aspx) |
| Navegue até a página de perfil público do usuário |
8% |
Perfil |
Página de perfil (http://my/person.aspx?accountname=<alias>) |
| Navegue até a página de perfil privado do usuário |
4% |
Perfil |
Página perfil (http://my/person.aspx) |
| Sincronização automática do feed de atividades |
32% |
Conector Social do Outlook |
none |
| Navegue até a página Pessoas estou seguindo |
3% |
Seguir Pessoas Lista |
http://my/MyPeople.aspx |
| Navegue até a biblioteca de documentos padrão |
6% |
OneDrive |
https://msft-my.spoppe.com/personal/<usuário>/Documentos |
| Navegar até a página de documentos seguidos |
3% |
OneDrive |
https://msft-my.spoppe.com/personal/<user>/Social/FollowedContent.aspx |
| Navegar até a página de documentos seguidos |
3% |
OneDrive |
https://msft-my.spoppe.com/personal/<user>/Social/FollowedContent.aspx |
| Navegue até a página de feed do site |
8% |
Feed do Site |
Página feed do site (https://< domain>/teams/<site>/newsfeed.aspx_ |
| Exibir todas as respostas em um thread |
1% |
News feed |
Página do Newsfeed (http://my/default.aspx) |
| Exibir feed de Todos |
3% |
News feed |
Página do Newsfeed (http://my/default.aspx) |
| Exibir mais postagens no feed de notícias |
2% |
News feed |
Página do Newsfeed (http://my/default.aspx) |
| Exibir a @mentions página |
1% |
News feed |
Página do Newsfeed (http://my/default.aspx) |
| Exibir o feed de notícias (Mobile) |
1% |
Dispositivo móvel |
Chamada rest (transferência de estado representacional móvel) |
| Exibir o feed de notícias categorizado |
3% |
Dispositivo móvel |
Chamada REST móvel |
Ações WRITE do usuário
| Ação do usuário | Porcentagem | Cenário | Recurso ou URL |
|---|---|---|---|
| Criar postagem raiz no feed |
0.5% |
News feed |
Página do Newsfeed (http://my/default.aspx) |
| Como uma postagem no feed |
0.3% |
News feed |
Página do Newsfeed (http://my/default.aspx) |
| Responder a uma postagem no feed |
0.7% |
News feed |
Página do Newsfeed (http://my/default.aspx) |
| Criar post no feed com @mention |
0.1% |
News feed |
Página do Newsfeed (http://my/default.aspx) |
| Criar postagem raiz no feed do site |
0.5% |
Feed do Site |
Página do feed do site (https://< domain>/teams/<site>/newsfeed.aspx) |
| Criar post no feed do site com @mention |
0.5% |
Feed do Site |
Página do feed do site (https://< domain>/teams/<site>/newsfeed.aspx) |
| Responder a uma postagem no feed do site |
0.15% |
Feed do Site |
Página do feed do site (https://< domain>/teams/<site>/newsfeed.aspx) |
| Criar post no feed do site com uma marca |
0.05% |
Feed do Site |
Página do feed do site (https://< domain>/teams/<site>/newsfeed.aspx) |
Ações de cliente do OneDrive
| Ação do usuário** | Porcentagem | Cenário | Recurso ou URL |
|---|---|---|---|
| Sincronização inicial do OneDrive |
0.2% |
OneDrive |
Sincronização Inicial |
| Sincronização incremental do OneDrive – baixar um arquivo |
0.88% |
OneDrive |
Sincronização Incremental |
| Sincronização incremental do OneDrive – sem alterações |
8.1% |
OneDrive |
Sincronização Incremental |
Metodologia de teste
Começamos com uma configuração mínima do farm do SharePoint Server 2013 para recursos sociais. Aplicamos uma carga social característica ao farm de teste e aumentamos a carga até observarmos níveis de capacidade normal e máxima do servidor. Analisamos gargalos em cada um desses níveis de carga e adicionamos computadores da função sobrecarregada para dimensionar a configuração do farm. Essa adição aliviou os gargalos em cada caso e forneceu uma exibição das características de escalabilidade do servidor para um conjunto de dados específico. Repetimos esse processo de expansão para três tamanhos de implantação para fornecer resumos representativos das características e diretrizes de escalabilidade de um farm do SharePoint Server 2013 para planejamento de capacidade.
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.
Importante
Os servidores Web al e os servidores de aplicativo no laboratório de teste foram virtualizados usando hosts Hyper-V. Servidores de bancos de dados não foram virtualizados. O hardware do host físico e o hardware virtual da máquina virtual são detalhados separadamente nas seções a seguir.
Hardware
A tabela a seguir lista as especificações de hardware para os computadores usados no teste. Os servidores Web front-end que foram adicionados ao farm de servidores durante várias iterações do teste também cumpriram essas especificações.
Hosts Hyper-V
O farm inclui um total de três hosts Hyper-V configurados de forma idêntica e cada host executa de uma a quatro máquinas virtuais.
| Hardware do host | Valor |
|---|---|
| Processador(s) |
2 Processadores Quad-core 2.27 GHz |
| RAM |
64 GB |
| Sistema Operacional |
Windows Server 2008 R2 SP1 |
| Número de adaptadores de rede |
2 |
| Velocidade do adaptador de rede |
1 Gigabit |
Servidores Web virtuais e servidores de aplicativos
O farm tem de um a oito servidores Web virtuais. Um servidor virtual dedicado adicional executa o serviço de cache distribuído.
Observação
Em um ambiente de produção, servidores dedicados que executam o Serviço de Cache Distribuído normalmente são implantados em uma configuração altamente disponível. Para fins de teste, usamos um único servidor dedicado para o cache distribuído porque a alta disponibilidade não é um fator essencial.
| Hardware de VM | Servidores da Web |
|---|---|
| Processadores |
4 processadores virtuais |
| RAM |
12 GB |
| Sistema operacional |
Windows Server 2008 R2 SP1 |
| Tamanho da unidade do SharePoint |
100 GB |
| Número de adaptadores de rede |
2 |
| Velocidade do adaptador de rede |
1 Gigabit |
| Autenticação |
Windows NTLM |
| Tipo de balanceador de carga |
IP grande F5 |
| Serviços executados localmente |
Microsoft SharePoint Foundation Web Application, Microsoft SharePoint Foundation Incoming E-Mail, Microsoft SharePoint Foundation Workflow Timer Service, Managed Metadata Web Service, User Profile Service |
| Hardware de VM | Cache |
|---|---|
| Processadores |
4 processadores virtuais |
| RAM |
12 GB |
| Sistema operacional |
Windows Server 2008 R2 SP1 |
| Tamanho da unidade do SharePoint |
100 GB |
| Número de adaptadores de rede |
2 |
| Velocidade do adaptador de rede |
1 Gigabit |
| Autenticação |
Windows NTLM |
| Serviços em execução no local |
Cache Distribuído, Serviço de Temporizador de Fluxo de Trabalho do Microsoft SharePoint Foundation |
| Hardware de VM | Pesquisar componente de consulta |
|---|---|
| Processadores |
4 processadores virtuais |
| RAM |
12 GB |
| Sistema operacional |
Windows Server 2008 R2 SP1 |
| Número de adaptadores de rede |
2 |
| Velocidade do adaptador de rede |
1 Gigabit |
| Autenticação |
Windows NTLM |
| Serviços em execução no local |
Microsoft SharePoint Foundation Web Application, Microsoft SharePoint Foundation Incoming E-Mail, Microsoft SharePoint Foundation Workflow Timer Service, Search Query and Site Settings Service, SharePoint Server Search |
| Hardware de máquina virtual | Componente de índice de pesquisa |
|---|---|
| Processadores |
4 processadores virtuais |
| RAM |
12 GB |
| Sistema operacional |
Windows Server 2008 R2 SP1 |
| Número de adaptadores de rede |
2 |
| Velocidade do adaptador de rede |
1 Gigabit |
| Autenticação |
Windows NTLM |
| Serviços em execução no local |
Microsoft SharePoint Foundation Web Application, Microsoft SharePoint Foundation Incoming E-Mail, Microsoft SharePoint Foundation Workflow Timer Service, SharePoint Server Search |
Servidores de banco de dados
Um servidor de banco de dados físico executa a instância padrão SQL Server que tem os bancos de dados do SharePoint. Este artigo não acompanha o banco de dados de registro em log.
Observação
Se você ativar o relatório de uso, recomendamos que armazene o banco de dados de registro em log em um LUN (número de unidade lógica) separado. Talvez as implementações grandes e algumas implementações médias necessitem de um servidor de banco de dados de registro em log dedicado para acomodar a demanda no processador gerada por um alto volume de log de eventos. >Nesse ambiente de laboratório, o registro em log foi restrito e o banco de dados de registro em log foi armazenado em uma instância separada de SQL Server.
Servidor de Banco de Dados – Instância Padrão
| Processadores |
2 processadores Quad-core 3.3 GHz |
| RAM |
32 GB |
| Sistema operacional |
Windows Server 2008 R2 SP1 |
| Armazenamento e geometria |
DAS (armazenamento de conexão direta) Matriz interna com disco de 6 x 300 GB 15krpm Matriz externa com disco de 15 x 450 GB 15krpm 50 x dados de conteúdo (RAID10 externo, 2x3 eixos de 300 GB cada) 50 x logs de conteúdo (RAID10 interno, 2x2 spindle 300 GB cada) 1 x dados temporários (RAID10 interno, 2x2 eixos de 300 GB cada) 1 x log temporário (RAID10 interno, 2x2 eixos de 300 GB cada) |
| Número de adaptadores de rede |
1 |
| Velocidade do adaptador de rede |
1 Gigabit |
| Autenticação |
Windows NTLM |
| Versão do software |
SQL Server 2008 R2 |
Topologia
A tabela a seguir mostra a topologia deste ambiente de laboratório:
Topologia do ambiente de laboratório
| Role | Implantação pequena (10 mil usuários) | Implantação média (100 mil usuários) | Implantação grande (500 mil usuários) |
|---|---|---|---|
| Servidor Web |
2-4 |
4-8 |
8 |
| Cache |
1 |
1-2 |
3 |
| SQL Server |
1 |
1-2 |
2 |
Processo de Teste
Importante
Os testes só modelam o uso normal da hora de negócios em um portal de computação social típico. Não consideramos as alterações cíclicas no tráfego gerado pelo usuário que os ciclos dia/noite produzem. Testamos trabalhos de Temporizador, como Sincronização de Perfil e Pessoas Rastreamento de Pesquisa, que exigem recursos significativos, independentemente com a mesma carga de trabalho de teste para determinar seu efeito. > Os testes se concentram em operações sociais, como feeds de notícias, marcação social e leitura de perfis de pessoas. O mix de teste inclui uma pequena quantidade de tráfego de colaboração típico para simular melhor um ambiente de produção. Esperamos que esses resultados ajudem a criar um portal separado dedicado a Meus Sites e recursos sociais. > O mix de teste não inclui o tráfego do Rastreamento de Conteúdo de Pesquisa. >
Realizamos testes em implantações pequenas, médias e grandes para os recursos sociais. Para configurar o hardware do servidor, começamos em configurações mínimas para o menor tamanho e preenchemos o banco de dados de teste com o conjunto de dados, conforme descrito na seção Abordagem de dimensionamento .
Usamos o VSTS (Visual Studio Team System) para simular uma carga de trabalho e aplicar uma carga social característica, conduzindo uma pequena carga contra o servidor no início. Aumentamos uniformemente essa carga lentamente e registramos métricas de desempenho em todas as funções do servidor até observarmos o RPS máximo. Isso foi reconhecível como o estado em que um aumento da carga aplicada no farm não resultou em aumento na saída de RPS entregue devido a restrições de gargalo do servidor.
A partir dessas métricas registradas, definimos estados de zona verde e zona vermelha, que representam os estados normais e totalmente carregados do servidor de VM em uma determinada configuração de computador. Em seguida, aplicamos uma carga constante em níveis de zona verde e zona vermelha para analisar métricas de desempenho de estado estável nessas cargas. Isso forneceu uma representação de integridade e desempenho do servidor de VM nessas principais condições de carga para cada configuração de topologia.
Depois que entendemos as características de carga verde e vermelha e a curva de dimensionamento para cada topologia, identificamos o gargalo de dimensionamento que limitava o RPS. No caso da carga de trabalho social, essa era normalmente a CPU do servidor Web para pequenos conjuntos de dados. Para conjuntos de dados maiores, também observamos a pressão de memória nos nós do Cache Distribuído. Adicionamos servidores virtuais da função sobrecarregada à configuração para remover os gargalos em cada caso e continuar o processo de expansão. Em seguida, repetimos a análise das tendências de desempenho e sua conformidade com definições de zona verde e vermelha em cada tamanho de configuração até alcançarmos requisitos para um tamanho de implantação específico.
Depois que entendemos cada tamanho de implantação, reconfiguramos o farm de teste para a menor configuração do próximo tamanho maior, preenchemos o conjunto de dados conforme descrito na seção Abordagem de dimensionamento e repetimos o ciclo de processo de análise/expansão e medimos as características de expansão de cada tamanho do conjunto de dados.
Resultados e análise
Esta seção mostra os resultados medidos para os três tamanhos de implantação. Especificamente, ele mostra como o dimensionamento do farm de servidores adicionando servidores Web afeta RPS de zona verde e vermelha, latência e uso médio da CPU.
As seguintes tendências foram consistentes em todos os três tamanhos de implantação:
O RPS da zona vermelha e verde aumenta linearmente com o número de servidores Web virtuais.
O principal gargalo em todas as configurações testadas foi a CPU do servidor Web.
Na zona vermelha, a latência aumenta ligeiramente à medida que adicionamos servidores Web e aumentamos a carga. Isso é causado pela pressão adicional sobre SQL Server e o serviço cache distribuído (que está em execução em todos os servidores Web no farm de testes).
Além disso, o uso médio da CPU em computadores SQL Server e cache distribuído aumenta à medida que o número de servidores Web aumenta. Isso é causado por uma carga de cache adicional no SQL Server e no serviço cache distribuído.
A latência da zona verde permanece bastante plana à medida que o número de servidores Web aumenta. Isso ocorre porque os servidores Web não são sobrecarregados em níveis de carga de zona verde.
Resultados de pequena escala
O gráfico a seguir mostra como o aumento do número de servidores Web afeta o RPS para zonas verde e vermelha.
O gráfico a seguir mostra como o aumento do número de servidores Web afeta a latência para níveis de carga de zona verde e vermelha.
O gráfico a seguir mostra como o aumento do número de servidores Web afeta o uso médio da CPU para níveis de carga de zona verde e vermelha.
Resultados em escala média
O gráfico a seguir mostra como o aumento do número de servidores Web afeta o RPS para zonas verde e vermelha.
O gráfico a seguir mostra como o aumento do número de servidores Web afeta a latência para níveis de carga de zona verde e vermelha.
O gráfico a seguir mostra como o aumento do número de servidores Web afeta o uso médio da CPU para níveis de carga de zona verde e vermelha.
Resultados em grande escala
O gráfico a seguir mostra como o aumento do número de servidores Web afeta o RPS para zonas verde e vermelha.
O gráfico a seguir mostra como o aumento do número de servidores Web afeta a latência para níveis de carga de zona verde e vermelha.
O gráfico a seguir mostra como o aumento do número de servidores Web afeta o uso médio da CPU para níveis de carga de zona verde e vermelha.
À medida que o número de servidores Web aumenta, os seguintes eventos ocorrem:
O uso médio da CPU aumenta para nós SQL Server e cache distribuído devido à carga adicional sobre esses recursos compartilhados.
O uso médio da CPU do servidor Web na zona vermelha diminui ligeiramente devido ao gargalo que muda ligeiramente para computadores SQL Server e cache distribuído.
O uso médio da CPU do servidor Web na zona verde permanece constante porque os servidores são mantidos em níveis de carga recomendados.
Recomendações
Uma implantação social bem-sucedida do SharePoint Server 2013 medida pelo desempenho depende dos seguintes fatores:
O número de usuários ativos que você deseja dar suporte
O mix de transações esperado de operações de leitura e gravação
Como a carga é distribuída entre os servidores farm
O número esperado de usuários ativos é um fator-chave para determinar o número de servidores que você deve planejar ter na topologia. O número de usuários ativos também determina a composição da hospedagem dos vários serviços necessários para serem habilitados para o cenário social entre os servidores.
Embora nossos testes tenham usado um conjunto de dados típico e aplicado a complexidade de carga que você pode esperar em uma implantação de cliente no mundo real, cada implantação é exclusiva. Seu esforço de planejamento de capacidade deve considerar características de uso esperadas, configuração de recursos e disponibilidade de recursos de hardware. Alguns fatores que podem afetar ou alterar os números de capacidade de forma significativa são os seguintes:
Um padrão de aumento do uso de email pode aumentar a carga gerada pelo Outlook Social Connector.
Um aumento significativo no percentual de ações de gravação (por exemplo, um aumento na marcação ou @mention) no mix de transações pode aumentar a carga no servidor de banco de dados.
Você pode adicionar ou remover servidores Web para equilibrar a carga da CPU entre servidores Web, SQL Server e nós de Cache Distribuído.
Siga cuidadosamente as diretrizes de configuração padrão do SharePoint Server 2013 para obter um desempenho ideal. Considerações que importam especificamente para transações sociais são as seguintes:
Separar discos físicos para o DB de Perfil – Devido ao uso de disco pesado que as transações sociais podem ter no Perfil DB, recomendamos manter o Perfil DB em seu próprio conjunto de discos físicos no servidor que executa SQL Server.
Requisitos de memória para o aplicativo de serviço Perfil de Usuário – O aplicativo de serviço perfil de usuário está localizado em servidores Web front-end e depende muito do cache na memória. Verifique se os servidores Web front-end têm RAM suficiente para armazenar em cache muitas solicitações de dados. A RAM recomendada mínima é de 12 GB por servidor Web front-end.
Requisitos de memória para servidores de Cache Distribuído: recursos sociais, microblogging em particular, dependem fortemente do armazenamento em Cache Distribuído suficiente e robusto. Situações de memória baixa nesses computadores podem degradar a capacidade do farm do SharePoint enquanto esse cache está sendo repovoado. Portanto, recomendamos configurar servidores que hospedam o Cache Distribuído para usar pelo menos 12 GB de RAM e dimensionados conforme necessário com base no número total de usuários na implantação.
A implantação social do SharePoint Server 2013 torna obrigatório provisionar um site pessoal para cada usuário que deseja usar recursos sociais. Planeje o crescimento da criação de coleções de sites pessoais no nível do banco de dados de conteúdo . Para obter mais informações sobre como escalar coleções de sites pessoais, confira Limites e limites de software para o SharePoint 2013.
Confira também
Conceitos
Planejamento de desempenho no SharePoint Server 2013