Estimar a capacidade e o desempenho para metadados gerenciados corporativos no SharePoint Server 2010

 

Aplica-se a: SharePoint Server 2010

Tópico modificado em: 2016-11-30

Este artigo fornece recomendações relacionadas ao dimensionamento e à otimização do desempenho do serviço de metadados gerenciados no Microsoft SharePoint Server 2010. Também fornece práticas recomendadas sobre como configurar o serviço e estruturar os bancos de dados de aplicativos de serviço para possibilitar o máximo de desempenho.

As informações aqui contidas podem ajudá-lo a compreender os limites testados de capacidade e desempenho do serviço de metadados gerenciados. Use-as para determinar se a sua implantação planejada está dentro desses limites aceitáveis.

Neste artigo:

• Características do farm de teste

• Resultados do teste e recomendações

Para obter informações gerais sobre o gerenciamento da capacidade e como fazer planejamentos para o SharePoint Server 2010, consulte Capacity management and sizing for SharePoint Server 2010.

Características do farm de teste

Conjunto de dados

Os testes foram primeiramente executados com base no banco de dados de linha de base, que simula um típico conjunto de dados de cliente. Em seguida, uma única variável foi alterada, e os mesmos testes foram novamente executados para determinar o efeito da alteração dessa variável sobre o desempenho. Na maioria dos casos, as variáveis foram testadas independentemente. Porém, em outros, algumas variáveis importantes foram testadas de forma combinada.

Conjunto de dados de linha de base

O conjunto de dados de linha de base contém os dados apresentados na tabela a seguir.

Dados	Detalhe
Grupos de conjuntos de termos	100
Conjuntos de termos	1.000 (10 por grupo)
Termos gerenciados (não incluem palavras-chave corporativas)	20.000 (20 por conjunto de termos)
Palavras-chave corporativas	80.000
Total de termos (inclui termos gerenciados e palavras-chave corporativas)	100.000
Rótulos	100.000 (1 por termo)
Comprimento do rótulo do termo	250 caracteres por rótulo

O número de termos no conjunto de dados de linha de base está ilustrado no gráfico a seguir.

Nesses testes, a proporção entre palavras-chave e termos gerenciados é sempre de 4:1 em todos os conjuntos de dados.

Carga de trabalho

Várias características básicas do serviço de metadados gerenciados podem acabar afetando o desempenho do serviço. Essas características incluem:

• Características dos dados no serviço

  • Comprimento do rótulo do termo

  • Número de termos por repositório de termos

  • Número de rótulos de termo por repositório de termos

• Características da carga no serviço

  • Combinação de leitura/gravação

• Tamanho do cache do repositório de termos

• Número de aplicativos de serviço por servidor de banco de dados

• Desempenho dos trabalhos de timer do serviço (Hub do Tipo de Conteúdo, Assinante de Tipo de Conteúdo, Atualização de dados do site de Metadados Corporativos, Agendador de Atualização de Taxonomia)

Os resultados específicos dos testes de capacidade e desempenho apresentados neste artigo podem ser diferentes dos resultados de testes em ambientes reais e têm como objetivo proporcionar um ponto de partida para o design de um ambiente apropriadamente dimensionado. Concluído o design do sistema inicial, teste a configuração para determinar se o sistema oferecerá suporte para a estratégia que você utilizou como base para configurar o serviço de dados gerenciados no seu ambiente.

Cenários de teste

Os seguintes testes foram usados para cada cenário de teste:

• Criar um termo (teste de gravação)

  Esse teste cria um termo em um conjunto de termos existente.

• Obter sugestões (teste somente leitura)

  Esse teste procura termos que começam com uma única cadeia de caracteres, que é utilizada na recuperação de sugestões do campo de palavras-chave.

• Obter correspondências (teste somente leitura)

  Esse teste procura termos que correspondem a uma cadeia fornecida, como na correspondência de valores do campo de palavras-chave ou do campo de metadados.

• Obter termos secundários em um conjunto de termos usando paginação (teste somente leitura)

  Esse teste recupera termos secundários em um conjunto de termos usando paginação.

• Validar um termo (teste somente leitura)

  Esse teste valida um único termo, como na validação de valores do campo de palavras-chave ou do campo de metadados.

Combinação de testes

A maioria dos testes (com exceção dos testes dos efeitos de operações de gravação) usou a mesma combinação de operações de leitura e gravação, apresentada na tabela a seguir.

Teste	Porcentagem de combinação
Criar um termo	0,125%
Obter sugestões	72,875%
Obter correspondências	11%
Obter termos secundários em um conjunto de termos usando paginação	5%
Validar um termo	11%

"Obter sugestões" é a operação de usuário final usada com mais frequência. É por isso que o seu peso é expressivo na combinação de testes.

Hardware, configurações e topologia

O farm de teste é um farm de três servidores que possui um servidor único à parte para o servidor Web, o servidor de aplicativos e o computador de banco de dados.

Servidor Web e servidor de aplicativos

O servidor Web e o servidor de aplicativos usaram um hardware idêntico e foram configurados conforme apresentado na tabela a seguir.

Componente	Configuração do servidor Web e do servidor de aplicativos
Processadores	Dois com núcleo quádruplo, 2,33 GHz cada um
RAM	8 GB
Sistema operacional	Windows Server 2008, 64 bits
Tamanho da unidade do sistema	300 GB
Número de adaptadores de rede	Dois
Velocidade do adaptador de rede	1 gigabit por segundo
Autenticação	Básica do Windows
Versão do software	SharePoint Server 2010 Observação O resultado pode variar dependendo da versão utilizada.
Serviços executados localmente	Administração Central Email de entrada do Microsoft SharePoint Foundation Aplicativo Web do Microsoft SharePoint Foundation Serviço de Timer de Fluxo de Trabalho do Microsoft SharePoint Foundation Microsoft SharePoint Foundation

Servidor de banco de dados

O servidor de banco de dados foi configurado como mostra a tabela a seguir.

Componente	Configuração do servidor de banco de dados
Processadores	Quatro com núcleo quádruplo, 3,19 GHz cada um
RAM	16 GB
Sistema operacional	Windows Server 2008, 64 bits
Armazenamento	15 discos de 300 GB, 15.000 RPM cada um
Número de adaptadores de rede	Dois
Velocidade do adaptador de rede	1 gigabit por segundo
Autenticação	Windows NTLM
Versão do software	Microsoft SQL Server 2008

Resultados do teste e recomendações

Esta seção descreve os resultados do teste e dá recomendações para as seguintes características:

• Características de dados

• Características de carga

• Desempenho dos trabalhos de timer

Características de dados

Efeito do comprimento do rótulo do termo

Esses testes foram realizados no repositório de termos de linha de base usando primeiramente um comprimento de rótulo de termo de 5 caracteres e depois novamente usando um comprimento de rótulo de termo de 250 caracteres. Neste último teste, as operações de gravação representam uma porcentagem muito maior do total do que a combinação das operações de leitura e gravação que usamos para a maioria dos outros testes.

Teste	Porcentagem de combinação
Criar um termo	5%
Obter sugestões	70%
Obter correspondências	10%
Obter termos secundários em um conjunto de termos usando paginação	5%
Validar um termo	10%

Os resultados de RPS (solicitações por segundo) para diferentes comprimentos de rótulos de termos são apresentados no gráfico a seguir. Esses dados sugerem que o comprimento de rótulo dos termos tem um efeito insignificante sobre a média de RPS para ambas as cargas.

O uso da CPU e o uso da memória estão ilustrados nos seguintes gráficos.

Como mostram os resultados, o efeito do comprimento de rótulo dos termos no uso da CPU e da memória para o servidor Web e o servidor de aplicativos é insignificante. No entanto, a carga no servidor de banco de dados aumenta à medida que o comprimento de rótulo dos termos termo também aumenta.

Conclusões e recomendações: comprimento de rótulo dos termos

O comprimento de rótulo dos termos não tem um efeito significativo sobre o desempenho do sistema.

Termos por repositório de termos

Esses testes foram realizados no repositório de termos de linha de base e, em seguida, esse repositório foi dimensionado para até 1 milhão de termos por meio de um aumento proporcional no número de palavras-chave e termos gerenciados.

Quando o conjunto de termos de palavras-chave foi removido do repositório de termos para teste, a diferença não foi significativa entre o desempenho de um repositório com 100.000 termos, de um repositório com 500.000 termos e de um repositório com 1 milhão de termos, como mostram os dois gráficos a seguir.

Quando o sistema está submetido à carga de teste especificada, o tempo necessário para criar uma palavra-chave aumenta significativamente conforme o número de palavras-chave passa de 16.000 para 800.000. Essa tendência pode ser vista no próximo gráfico.

Conclusões e recomendações: termos por repositório de termos

O número de termos em um repositório de termos não afeta significativamente o desempenho do sistema quando muitos poucos usuários criam palavras-chave ou quando o número dessas palavras-chave é pequeno.

O conjunto de termos de palavras-chave é armazenado em uma lista simples, ao contrário dos outros conjuntos de termos, que possuem uma estrutura mais complexa. Quanto mais essa lista simples crescer, maior será o tempo necessário para verificar se já existe uma palavra-chave com o mesmo nome. Portanto, o processo para criar uma palavra-chave é mais demorado em um conjunto de termos de palavras-chave muito grande.

O administrador do repositório de termos deve limitar o tamanho do conjunto de termos de palavras-chave para impedir problemas de latência quando os usuários criarem termos de palavras-chave. Uma abordagem é mover frequentemente as palavras-chave para um conjunto de termos regulares, o que pode aumentar o desempenho e contribuir para uma organização melhor dos dados de termos.

Qualquer conjunto de termos contendo mais de 150.000 termos em uma lista simples está sujeito a problemas de latência e desempenho. Uma alternativa é usar um conjunto de termos gerenciados, que em geral possui uma coleção estruturada de termos. Para obter mais informações sobre conjuntos de termos, consulte Visão geral dos metadados gerenciados.

Erros comuns

Conforme o número total de termos no repositório se aproxima de 500.000, os usuários podem perceber várias exceções ao tentarem acessar esse repositório de termos. Verificando o log ULS (Serviço de Log Unificado), o administrador do farm pode localizar a exceção e determinar se ela se aplica ao cliente ou ao servidor.

TimeoutException

Quando o erro TimeoutException ocorre, você pode modificar o valor de tempo limite no arquivo client.config ou no arquivo web.config do serviço de metadados gerenciados. O arquivo client.config está localizado na pasta %PROGRAMFILES%\Microsoft Office Servers\14.0\WebClients\Metadata, enquanto o arquivo web.config está localizado na pasta %PROGRAMFILES%\Microsoft Office Servers\14.0\WebServices\Metadata. Há quatro valores de tempo limite:

• receiveTimeout Um valor de tempo limite que especifica o intervalo de tempo fornecido para que uma operação de recepção seja concluída.

• sendTimeout Um valor de tempo limite que especifica o intervalo de tempo fornecido para que uma operação de envio seja concluída.

• openTimeout Um valor de tempo limite que especifica o intervalo de tempo fornecido para que uma operação de abertura seja concluída.

• closeTimeout Um valor de tempo limite que especifica o intervalo de tempo fornecido para que uma operação de fechamento seja concluída.

Esses valores de tempo limite são definidos na seção customBinding. É possível aumentar qualquer um deles com base na operação específica que está atingindo o tempo limite. Por exemplo, se o tempo limite ocorre quando mensagens são recebidas, apenas é necessário aumentar o valor de ReceiveTimeout.

Para obter mais informações sobre valores de tempo limite, consulte <customBinding> (https://go.microsoft.com/fwlink/?linkid=214213&clcid=0x416).

ThreadAbortException

Quando erros ThreadAbortException ocorrem, você pode aumentar o valor de tempo limite de execução no arquivo web.config referente ao aplicativo Web específico. O arquivo web.config está localizado na pasta %inetpub%\wwwroot\wss\VirtualDirectories\<Número da Porta do Aplicativo>. Por exemplo, se a solicitação estiver relacionada a TaxonomyInternalService em um aplicativo Web, primeiro identifique o arquivo web.config do aplicativo Web e depois adicione o seguinte código ao nó de configuração.

  <location path="_vti_bin/TaxonomyInternalService.json">
    <system.web>
      <httpRuntime executionTimeout="3600" />
    </system.web>
  </location>

Rótulos de termos por repositório de termos

Esse teste foi realizado em um repositório de termos de linha de base que possuía 100.000 termos. Durante o teste, o número de rótulos aumentou para cada termo, como mostra o gráfico a seguir.

A média de RPS só diminui um pouco à medida que o número de rótulos aumenta. O uso da CPU e da memória no servidor Web, no servidor de aplicativos e no servidor de banco de dados aumenta só um pouco, como mostram os gráficos a seguir.

Conclusões e recomendações: rótulos de termos por repositório de termos

O número de rótulos não tem efeito significativo sobre o desempenho do sistema quando o número médio de rótulos por termo é menor que quatro.

Resumo: características de dados

Esta seção analisa os resultados do teste para três características diferentes dos dados no repositório de termos: o comprimento de rótulo dos termos, o número de termos por repositório e o número de rótulos de termos por repositório de termos. As tendências reveladas por esse teste incluem:

• Aumentar o comprimento de rótulo dos termos para 250 não tem efeito significativo sobre o desempenho do repositório de termos.

• Aumentar para quatro o número médio de rótulos por termo não tem efeito significativo sobre o desempenho do repositório de termos.

• Aumentar o número de termo para 1 milhão não tem efeito significativo sobre o desempenho do repositório de termos.

• Quando o repositório de termos contém mais de 150.000 termos em um conjunto de termos que utiliza uma lista simples, talvez o processo de adicionar novos termos a esse repositório seja demorado.

Características de carga

Impacto das alterações na combinação de leitura/gravação

Esses testes foram realizados com o uso da combinação de testes de operações de leitura/gravação de linha de base, com o teste "Criar item de taxonomia" figurando como o item modificado. A tabela a seguir mostra as operações específicas que foram usadas na combinação de testes de linha de base, juntamente com as suas porcentagens associadas.

Teste	Porcentagem de carga
Obter sugestões	73%
Criar item de taxonomia	0%
Obter correspondências	11%
Obter termos secundários paginados em um conjunto de termos	5%
Validar um termo	11%

Para cada teste sucessivo, o número de termos criados aumentou. A tabela a seguir mostra os três testes que foram realizados, identificando a média de termos criados por minuto e depois calculando a média de RPS.

Média de termos criados/minuto	Média de RPS
0	182
8,4	157
20	139

Como mostra o gráfico a seguir, o valor de RPS diminui à medida que o número médio de termos criados por minuto aumenta.

O uso da CPU e o uso da memória estão ilustrados nos dois gráficos a seguir.

Conclusões e recomendações: impacto das alterações na combinação de leitura/gravação

A expectativa é de que o desempenho do repositório de termos diminua à medida que a porcentagem de operações de gravação aumenta. Isso porque esse tipo de operação mantém bloqueios mais exclusivos sobre os dados, o que atrasa a execução das operações de leitura. Com base nos dados de teste, o número de RPS não diminui significativamente até a quantidade de termos criados atingir uma média de 20 por minuto. No entanto, uma taxa média de 20 termos criados por minuto é razoavelmente alta e não costuma ocorrer com frequência, especialmente em um conjunto de termos desenvolvido. O desempenho poderá melhorar se um conjunto de termos for transformado em somente leitura, pois isso eliminará as operações de gravação.

Cache do repositório de termos

O cache do repositório de termos existe em todos os servidores Web de um farm. Ele pode conter grupos de conjuntos de termos, conjuntos de termos e termos. Esses testes foram realizados para mostrar como a área ocupada de memória do objeto de cache muda à medida que o número de termos aumenta. Há outros fatores que afetam o tamanho do cache, entre eles descrições de termos, o número de rótulos e propriedades personalizadas. Para simplificar o teste, cada termo no repositório de termos de linha de base possui apenas um rótulo com 250 caracteres, sem nenhuma descrição ou propriedade personalizada.

O gráfico a seguir mostra como a área ocupada de memória muda à medida que o número de termos no cache aumenta.

Conclusões e recomendações: cache do repositório de termos

O uso de memória no servidor Web aumenta de maneira linear à medida que o número de termos no cache aumenta. Isso permite estimar o tamanho do cache quando o número de termos é conhecido. Com base nos dados do teste, o uso de memória não será um problema de desempenho para a maioria dos sistemas.

Aplicativos de serviço consumidos por um farm

Esse teste mostra a diferença de desempenho entre um e dois aplicativos de serviços de metadados gerenciados que possuem bancos de dados hospedados no mesmo servidor de banco de dados.

Como mostra o gráfico a seguir, no mesmo nível de carga, o número de RPS diminui quando um aplicativo de serviço adicional é acrescentado. A expectativa é de que o número de RPS diminua quando aplicativos de serviço adicionais forem acrescentados.

A latência da maioria das operações não é afetada significativamente quando aplicativos de serviço adicionais são acrescentados. Porém, ao contrário das outras operações, a operação "Obter sugestões" interage com todos os aplicativos de serviço disponíveis e, portanto, como mostra o gráfico a seguir, a latência dessa operação fica mais alta à medida que o número de aplicativos de serviço aumenta. A expectativa é de que essa tendência continue conforme o número de aplicativos de serviço aumentar.

Como mostram os gráficos a seguir, o uso de CPU no servidor de banco de dados aumenta significativamente quando existem dois aplicativos de serviço com bancos de dados residentes no mesmo servidor. Por outro lado, o uso de memória não aumenta significativamente.

Conclusões e recomendações: aplicativos de serviço consumidos por um farm

Se você precisar manter mais de um aplicativo de serviço de metadados gerenciados, certifique-se de que a latência para operações de sugestão de palavras-chave permaneça dentro de níveis aceitáveis. Lembre-se de que a latência de rede também contribui para a latência efetiva total. Recomendamos que os aplicativos de serviço de metadados gerenciados sejam consolidados dentro do limite máximo possível.

Se um único computador SQL Server for usado para hospedar todos os aplicativos de serviço, será necessário que o servidor tenha recursos suficientes de CPU e memória para favorecer metas de desempenho aceitáveis.

Desempenho dos trabalhos de timer

Esta seção mostra as características de desempenho de dois trabalhos de timer no serviço de metadados gerenciados: o trabalho de timer Assinante de Tipo de Conteúdo e o trabalho de timer Agendador de Atualização de Taxonomia. Ambos enumeram os conjuntos de sites em um determinado aplicativo Web, podendo ser executados por longos períodos e consumir um número significativo de recursos de sistema em um farm grande.

Trabalho de timer Assinante de Tipo de Conteúdo

O trabalho de timer Assinante de Tipo de Conteúdo distribui os tipos de conteúdo publicados a todos os conjuntos de sites apropriados de um aplicativo Web. O tempo geral necessário para a execução desse trabalho de timer depende de vários fatores, como o número de tipos de conteúdo que precisam ser distribuídos, o número e os tipos de campos no tipo de conteúdo e o número de conjuntos de sites. Esse teste mostra como os seguintes fatores de dimensionamento afetam o tempo geral para a distribuição de um tipo de conteúdo:

• O número de conjuntos de sites em um aplicativo Web

• O número de tipos de conteúdo

O primeiro teste foi realizado por meio da publicação de 10 tipos de conteúdo e da sua respectiva distribuição a um número diferente de conjuntos de sites. Como mostra o gráfico a seguir, a relação entre o tempo de distribuição de tipos de conteúdo e o número de conjuntos de sites é quase linear.

Nesse teste, um tipo de conteúdo foi publicado em 1.000 conjuntos de sites e, em seguida, dez tipos de conteúdo foram publicados em 1.000 conjuntos de sites. O tempo de distribuição para dez tipos de conteúdo é cerca de 10 vezes maior que o tempo de distribuição para um tipo de conteúdo, o que mostra novamente um aumento quase linear.

Conclusões e recomendações: trabalho de timer Assinante de Tipo de Conteúdo

Os resultados do teste mostram que o tempo médio de distribuição de um único tipo de conteúdo em um conjunto de sites é quase uma constante. Portanto, é seguro executar esse trabalho de timer em uma ampla coleção de conjuntos de sites. Você pode usar o tempo médio de distribuição para estimar qual será o tempo necessário para a execução do trabalho de timer, com base no número de conjuntos de sites e no número de tipos de conteúdo a serem distribuídos. Se esses números forem extremamente altos, talvez você calcule que serão necessárias várias horas ou até mesmo dias para a execução desse trabalho de timer. Mesmo assim, ele pode ser pausado e retomado, e a publicação de tipos de conteúdo não é uma atividade frequente.

Observe que o tempo necessário para a execução desse trabalho de timer pode aumentar significativamente quando ocorre um empilhamento de tipo de conteúdo durante o processo, especialmente no caso em que muitas listas estão envolvidas. Para obter mais informações sobre o empilhamento de tipos de conteúdo, consulte a seção sobre conexões de metadados gerenciados no tópico Sobre o aplicativo de serviço de metadados.

Trabalho de timer Agendador de Atualização de Taxonomia

O trabalho de timer Agendador de Atualização de Taxonomia mantém a lista oculta de taxonomias de cada conjunto de sites de um aplicativo Web em sincronia com o repositório de termos. O tempo geral necessário para a execução desse trabalho de timer depende do número de itens que precisam ser atualizados e do número de conjuntos de sites que contêm itens atualizados. Esse teste mostra como o tamanho da lista oculta e o número de conjuntos de sites no aplicativo Web afetam o tempo médio de atualização de um único item para um conjunto de sites.

O gráfico a seguir mostra a relação entre o número de conjuntos de sites e o tempo médio necessário para atualizar um termo em um conjunto de sites.

Como mostra o gráfico a seguir, o tempo médio para atualizar um termo em um conjunto de sites aumenta um pouco à medida que o tamanho da lista oculta fica maior.

Conclusões e recomendações: trabalho de timer Agendador de Atualização de Taxonomia

Um aumento no número de conjuntos de sites não tem efeitos significativos sobre o tempo médio necessário para atualizar um termo em um conjunto de sites. Portanto, é seguro executar esse trabalho de timer em um aplicativo Web que possui vários conjuntos de sites. Você pode estimar o tempo de execução geral do trabalho de timer multiplicando o tempo médio necessário para atualizar um termo em um conjunto de sites pelo número de conjuntos de sites e pelo número médio de termos atualizados em cada um desses conjuntos. Também existe a opção de pausar e retomar esse trabalho de timer.

O tamanho da lista oculta de taxonomias aumenta com o passar do tempo, à medida que uma quantidade cada vez maior de termos é utilizada pelo conjunto de sites. Portanto, nesse cenário, é possível que a execução do trabalho de timer seja mais demorada.