Estimar os requisitos de desempenho e capacidade para a Pesquisa do SharePoint Server 2010

 

Aplica-se a: SharePoint Server 2010

Tópico modificado em: 2016-11-30

Resumo: este artigo apresenta informações de planejamento de capacidade para diferentes implantações de pesquisa do Microsoft SharePoint Server 2010, incluindo farms pequenos, médios e grandes do SharePoint Server 2010.

Este artigo apresenta informações de planejamento de capacidade para implantações de pesquisa do SharePoint Server 2010 em ambiente de colaboração. Ele inclui as seguintes informações para três exemplos de configurações do farm de pesquisa:

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

• A carga de trabalho usada para geração de dados, incluindo o número e a classe de usuários, além das características de uso do farm

• Conjunto de dados do farm de teste, incluindo conteúdo e tamanho do banco de dados

• Os dados de integridade e de desempenho específicos do ambiente testado

Este artigo também inclui dados e recomendações de testes comuns sobre como determinar o hardware, a topologia e a configuração necessária para implantar um ambiente semelhante, e como otimizar o ambiente para características de capacidade e desempenho apropriadas.

A pesquisa do SharePoint Server 2010 oferece um conjunto mais completo de recursos e um modelo de topologia mais flexível do que as versões anteriores. Para aproveitar esta arquitetura para proporcionar recursos e funcionalidades mais avançados aos usuários, considere com cuidado seus efeitos na capacidade e no desempenho do farm.

Depois de ler este documento, você vai compreender como fazer o seguinte:

• Definir metas de desempenho e capacidade para o ambiente.

• Planejar o hardware necessário para oferecer suporte ao número e tipo de usuários, e aos recursos que pretende implantar.

• Criar a topologia física e lógica para perfeita confiabilidade e eficiência.

• Testar, validar e dimensionar o ambiente para atingir as metas de desempenho e capacidade.

• Monitorar o ambiente para obter os principais indicadores.

Antes de ler este artigo, você deve estar familiarizado com:

• Capacity management and sizing for SharePoint Server 2010

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

• Disponibilidade

• Redundância

• Conteúdo específico do banco de dados

Visão geral do planejamento

Os cenários deste artigo descrevem farms de teste pequenos, médios e grandes, com hipóteses que o ajudam a começar o planejamento da capacidade correta para o farm. Os tamanhos do farm são valores aproximados baseados nas seguintes hipóteses:

• Os repositórios rastreados são basicamente conteúdo do SharePoint Server.

• A grande maioria das consultas dos usuários pode ser encontrada nos mesmos 33% do índice. Isto é, a maioria dos usuários consulta os mesmos termos.

• As configurações de metadados padrão são usadas, garantindo que o banco de dados de propriedades não cresça a taxas elevadas.

• Nos farms médios e grandes, existem destinos de rastreamento dedicados (servidores Web front-end) para proporcionar conteúdo aos componentes de rastreamento desses farms de pesquisa.

• As medidas feitas nesses farms podem variar de acordo com as condições de rede e do ambiente, e possuem uma margem de erro de até 10%.

Escolhendo um cenário

Para escolher o cenário certo, considere as seguintes perguntas:

• Tamanho total   Quanto conteúdo deve ser pesquisado? O número total de itens deve incluir todos os objetos, inclusive documentos, páginas da Web, itens de lista e pessoas.

• Disponibilidade   Quais são os requisitos de disponibilidade? Os clientes precisam de uma solução de pesquisa capaz de sobreviver em caso de falha de um servidor?

• Atualização do conteúdo   Qual o nível de atualização dos resultados de pesquisa? Quanto tempo depois que um usuário alterar o conteúdo você deseja que as pesquisas incluam o conteúdo atualizado nos resultados? Com que frequência você espera que o conteúdo seja alterado?

• Taxa de transferência   Quantas pessoas estarão pesquisando um conteúdo ao mesmo tempo? Isso inclui as pessoas que digitam na caixa de pesquisa, as consultas ocultas como Web Parts que pesquisam dados automaticamente ou os Conectores Sociais do Microsoft Outlook 2010 que solicitam feeds de atividades com URLs que precisam de filtragem de segurança do sistema de pesquisa.

Com base nas respostas a essas perguntas, escolha um dos seguintes cenários:

• Farm pequeno   Inclui um único aplicativo de serviço de Pesquisa que compartilha os mesmos recursos em um único farm do SharePoint Server. Típico para pequenas implantações, a quantidade de conteúdo fornecida para pesquisa é limitada (menos de 10 milhões de itens). Dependendo das metas de atualização desejadas, os rastreamentos incrementais poderão ocorrer durante o horário comercial.

• Farm médio   Inclui um ou mais aplicativos de serviço de Pesquisa em um farm dedicado, que oferece serviços de pesquisa a outros farms. A quantidade de conteúdo fornecida para pesquisa é moderada (até 40 milhões de itens) e, para atender às metas de atualização, os rastreamentos incrementais podem ocorrer durante o horário comercial.

• Farm grande   Inclui um ou mais aplicativos de serviço de Pesquisa em um farm dedicado, que oferece serviços de pesquisa a outros farms. A quantidade de conteúdo fornecida para pesquisa é grande (até 100 milhões de itens) e, para atender às metas de atualização, os rastreamentos incrementais podem ocorrer durante o horário comercial.

Ciclo de vida da pesquisa

Esses três cenários permitem estimar a capacidade em um estágio antecipado do farm. Os farms passam pelos seguintes estágios do ciclo de vida da pesquisa durante o rastreamento do conteúdo:

• Aquisição do índice   Esse é o primeiro estágio da população de dados. A duração desse estágio depende do tamanho das fontes de conteúdo. Ele é caracterizado pelo seguinte:

  • Rastreamentos completos (possivelmente simultâneos) do conteúdo.

  • Monitoramento rigoroso do sistema de rastreamento para assegurar que os hosts rastreados não gerem afunilamento durante o rastreamento.

  • Mesclagens mestras frequentes que, para cada componente de consulta, são acionadas quando é alterado um determinado volume de índice.

• Manutenção do índice   Esse é o estágio mais comum do farm. Ele é caracterizado pelo seguinte:

  • Há rastreamentos incrementais de todo o conteúdo.

  • Para os rastreamentos de conteúdo do SharePoint Server, a maioria das alterações encontradas durante o rastreamento é de segurança.

  • Mesclagens mestras não frequentes que, para cada componente de consulta, são acionadas quando é alterado um determinado volume de índice.

• Limpeza do índice   Esse estágio ocorre quando uma alteração de conteúdo retira o farm do estágio de manutenção do índice — por exemplo, quando um banco de dados de conteúdo ou site é movido de um aplicativo de serviço de Pesquisa para outro. Esse estágio é acionado quando acontece uma das seguintes situações:

  • Um host que está fornecendo conteúdo não é encontrado pelo rastreador de pesquisa durante um longo período de tempo.

  • Uma fonte de conteúdo ou um endereço inicial é excluído do aplicativo de serviço de Pesquisa.

Cenários

Esta seção descreve as configurações que foram usadas para os cenários de farm pequeno, médio e grande. Ela também inclui a carga de trabalho, o conjunto de dados, os dados de desempenho e os dados de teste relacionados a cada ambiente.

Farm pequeno

Como o farm é pequeno, várias funções devem ser realizadas por alguns dos servidores. É recomendável combinar um componente de consulta a um servidor Web front-end para evitar colocar os componentes de rastreamento e os de consulta no mesmo servidor. Esta configuração usa três servidores de aplicativos e um servidor de banco de dados, conforme mostrado a seguir:

• Como os servidores de consulta redundantes são geralmente sugeridos para a pesquisa corporativa, dois servidores de aplicativos foram usados para os componentes de consulta, considerando a seguinte configuração:

  • Um servidor de aplicativos também hospeda o Centro de Pesquisa. Essa configuração poderá ser omitida se o farm pequeno for usado como farm de serviço, e os Centros de Pesquisa são criados nos farms de conteúdo filho que usam o aplicativo de serviço de Pesquisa a partir desse farm de serviço pai.

  • A configuração de consulta preferencial para menos de 10 milhões de itens é ter apenas uma partição de índice. Cada servidor então tem um componente de consulta principal da partição de índice. Essa configuração de componente de consulta ativo/ativo permite a falha de um dos componentes de consulta, pois ainda mantém sua capacidade de atender às consultas por meio do componente de consulta restante. Se houver falha de um componente de consulta, a pesquisa enviará as consultas (round robin) ao próximo componente de consulta disponível.

• Um servidor de aplicativos usado para rastreamento e administração. Isso significa que a Administração Central, o componente de administração de pesquisa e um componente de rastreamento são criados neste servidor.

• Um único servidor de banco de dados para oferecer suporte ao farm. O servidor de banco de dados deve ter um número dedicado de operações de entrada/saída por segundo (IOPS) para os bancos de dados de rastreamento, propriedades e administração (por exemplo, usar matrizes de armazenamento diferentes).

Especificações

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

Topologia

Hardware

Servidores Web

Servidor Web	Servidor Web front-end/Consulta (1)
Processador	1px4c com 3 GHz
RAM	16 GB
Sistema operacional	Windows Server 2008 R2 de 64 bits
Armazenamento	2x450GB 15K SAS: RAID1:OS 2x450GB 15K SAS: RAID1:DATA1 2x450GB 15K SAS: RAID1:DATA2
Número de placas de interface de rede (NICs)	2
Velocidade da NIC	1 gigabit
Autenticação	NTLM
Tipo de balanceador de carga	Nenhum
Versão do software	SharePoint Server 2010 (versão de pré-lançamento)
Serviços em execução no local	Todos os serviços (incluindo o Serviço de Configurações do Site e Consulta de Pesquisa)

Servidores de aplicativos

Servidor	Consulta (1)	Rastreamento/Administração (1)
Processador	1px4c com 3 GHz	1px4c com 3 GHz
RAM	16 GB	16 GB
Sistema operacional	Windows Server 2008 R2 de 64 bits	Windows Server 2008 R2 de 64 bits
Armazenamento	2x450GB 15K SAS:RAID1: OS 2x450GB 15K SAS:RAID1: DATA1 2x450GB 15K SAS:RAID1: DATA2	2x450GB 15K SAS: RAID1: OS 2x450GB 15K SAS: RAID1: TEMP 2x450GB 15K SAS: RAID0: DATA
Número de NICs	1	1
Velocidade da NIC	1 gigabit	1 gigabit
Autenticação	NTLM	NTLM
Tipo de balanceador de carga	nenhum	nenhum
Versão do software	SharePoint Server 2010 (versão de pré-lançamento)	SharePoint Server 2010 (versão de pré-lançamento)
Serviços em execução no local	Pesquisa do SharePoint Server; Serviço de Configurações do Site e Consulta de Pesquisa	Pesquisa do SharePoint Server

Servidores de banco de dados

Banco de dados	Compartilhado (1)
Processador	2px4c com 3 GHz
RAM	16 GB
Sistema operacional	Windows Server 2008 R2 de 64 bits
Armazenamento	2x450GB 15K SAS: RAID1: OS 2x450GB 15K SAS: RAID0: DATA 2x450GB 15K SAS: RAID0: LOGS Observação Por causa do número reduzido de unidades, a melhor prática de segregar os bancos de dados em diferentes canais de E/S não foi aplicada.
Número de NICs	2
Velocidade da NIC	1 gigabit
Autenticação	NTLM
Versão do software	Microsoft SQL Server 2008 Enterprise

Carga de trabalho

Esta seção descreve a carga de trabalho usada para a geração de dados, incluindo o número de usuários e as características de uso do farm.

Características da carga de trabalho	Valor
Descrição de alto nível da carga de trabalho	Farms de pesquisa
Média de consultas por minuto	6
Média de usuários simultâneos	1
Número total de consultas por dia	8.640

Conjunto de dados

Esta seção descreve o conjunto de dados do farm de teste, incluindo o conteúdo e o tamanho do banco de dados, os índices de pesquisa e as fontes de dados externas.

Objeto	Valor
Tamanho do índice de pesquisa (número de itens)	9 milhões
Tamanho do banco de dados de rastreamento	52 GB
Tamanho do arquivo de log do banco de dados de rastreamento	11 GB
Tamanho do banco de dados de propriedades	68 GB
Tamanho do arquivo de log do banco de dados de propriedades	1 GB
Tamanho do banco de dados de administração de pesquisa	2 GB
Tamanho das partições do índice ativo	38.4 GB (total de 76.8 GB, pois o índice é espelhado)
Número total de bancos de dados de pesquisa	3
Outros bancos de dados	SharePoint_Config; SharePoint_AdminContent; State_Service; Bdc_Service_db; WSS_UsageApplication; WSS_Content

Dados de integridade e desempenho

Esta seção mostra os dados de integridade e desempenho específicos do ambiente de teste.

Dados de desempenho da consulta

As seguintes medidas foram feitas com 9 milhões de itens no índice. As colunas mostram as medidas que foram feitas durante o teste específico, e os resultados estão na parte inferior da tabela a seguir. As medidas estão descritas conforme mostrado abaixo:

• Latência da consulta   Estas medidas foram feitas durante um teste de latência da consulta, em que uma ferramenta de teste enviou um conjunto de consultas padrão, como um usuário, e depois avaliou a latência resultante. Nenhum rastreamento ocorreu durante o teste.

• Taxa de transferência da consulta   Estas medidas foram feitas durante um teste de taxa de transferência da consulta, em que uma ferramenta de teste enviou um conjunto padrão de consultas efetuadas no farm, como um número crescente de usuários simultâneos (até 80), e depois avaliou a latência e a taxa de transferência resultante. Nenhum rastreamento ocorreu durante o teste.

	Métrica de scorecard	Latência da consulta	Taxa de transferência da consulta
Métricas da CPU	Média da CPU do SQL Server	3,4%	12%
	Média da CPU do servidor Web front-end	8%	51%
	Média da CPU do servidor de consulta	13,3%	95%
Confiabilidade	Taxa de falha	0	0
	Falhas do servidor Web front-end	0	0
	Falhas do servidor de aplicativos	0	0
SQL Server	Taxa de acertos do cache (SQL Server)	99,97%	100%
	Bloqueios do SQL Server: tempo médio de espera (ms)	0,071	0,038
	Bloqueios do SQL Server: tempo de espera de bloqueio (ms)	0,035	0,019
	Bloqueios do SQL Server: número de Deadlocks/s	0	0
	Travas do SQL Server: tempo médio de espera (ms)	31	0,017
	Compilações do SQL Server/s	14,9	10,2
	Estatísticas do SQL Server: recompilações do SQL Server/s	0,087	0,05
	Comprimento médio da fila de disco (SQL Server)	0,011	0,01
	Comprimento da fila de disco: gravações (SQL Server)	0,01	0,008
	Leituras de disco/s (SQL Server)	0,894	0,05
	Gravações de disco/s (SQL Server)	45	106
Servidor de aplicativos	Comprimento médio da fila de disco (servidor de consulta)	0,013	0,001
	Comprimento da fila de disco: gravações (servidor de consulta)	0	0,001
	Leituras de disco/s (servidor de consulta)	11,75	0,06
	Gravações de disco/s (servidor de consulta)	4	5,714
	Média de memória usada (servidor de consulta)	8,73%	9%
	Máximo de memória usada (servidor de consulta)	8,75%	9%
Servidor Web front-end	Solicitações ASP.NET em fila (média de todos os servidores Web front-end)	0	0
	Média de memória usada (servidor Web front-end)	9,67%	95%
	Máximo de memória usada (servidor Web front-end)	9,74%	100%
Resultados do teste	Número de êxitos	1.757	13.608
	Número de erros	0	0
	Latência da IU de consulta (75 percentil)	0,331 s	3,68 s
	Latência da IU de consulta (95 percentil)	0,424 s	3,93 s
	Taxa de transferência da consulta	3,29 solicitações/s	22,4 solicitações/s

Dados de desempenho do rastreamento

As seguintes medidas foram feitas durante os rastreamentos completos iniciais e sequenciais da fonte de conteúdo especificada. O tamanho da fonte de conteúdo aparece em milhões de itens. As colunas mostram as medidas que foram feitas durante o rastreamento específico, e os resultados estão na parte inferior da tabela.

	Métrica de scorecard	Conteúdo do SharePoint (4M)	Compartilhamento de arquivos (1M)	HTTP (não SharePoint) (1M)
Métricas da CPU	Média da CPU do SQL Server	5,4%	11,7%	23%
	Média da CPU do indexador	41,6%	69%	71%
Confiabilidade	Taxa de falha	0	0	0
	Falhas do servidor Web front-end	0	0	0
	Falhas do servidor de aplicativos	0	0	0
SQL Server	Taxa de acertos do cache (SQL Server)	n/a	n/a	n/a
	Bloqueios do SQL Server: tempo médio de espera (ms)	436	51,76	84,73
	Bloqueios do SQL Server: tempo de espera de bloqueio (ms)	n/a	n/a	n/a
	Bloqueios do SQL Server: número de deadlocks/s	n/a	n/a	n/a
	Travas do SQL Server: tempo médio de espera (ms)	1,05	1,64	3,53
	Compilações do SQL Server/s	n/a	n/a	n/a
	Estatísticas do SQL Server: recompilações do SQL Server/s	n/a	n/a	n/a
	Comprimento médio da fila de disco (SQL Server)	27,124	6,85	45
	Comprimento da fila de disco: gravações (SQL Server)	17,6	6,7	21,57
Servidor de aplicativos	Comprimento médio da fila de disco (servidor de rastreamento)	0,008	0,032	0,02
	Comprimento da fila de disco: gravações (servidor de rastreamento)	0,006	0,025	0,012
	Média de memória usada (servidor de rastreamento)	14,16%	10,4%	11,5%
	Máximo de memória usada (servidor de rastreamento)	19,2%	11,13%	12,78%
Servidor Web front-end	Solicitações ASP.NET em fila (média de todos os servidores Web front-end)	0	0	0
	Média de memória usada (servidor Web front-end)	n/a	n/a	n/a
	Máximo de memória usada (servidor Web front-end)	n/a	n/a	n/a
Resultados do teste	Número de êxitos	3.934.881	1.247.838	996.982
	Número de erros	9.645	302	2
	Velocidade de rastreamento do portal (itens/s)	46,32	120,436	138,316
	Velocidade de rastreamento da ancoragem (itens/s)	5.197	3.466,219	2.192,982
	Velocidade total de rastreamento (itens/s)	45,91	116,392	130,086

Dados de teste

Esta seção apresenta dados de teste que ilustram o desempenho do farm. Consulte a seção Otimizações mais adiante neste artigo para saber como melhorar o desempenho do farm.

Latência da consulta

O seguinte gráfico mostra os percentis de latência da consulta referentes a este farm à medida que a carga de usuário aumenta (coletados durante o teste de taxa de transferência da consulta). Um percentil de consulta de 95% significa que 95% das latências de consulta que foram avaliadas estavam abaixo desse valor.

Você vê neste gráfico que com um índice menor este farm é capaz de manter a latência da consulta inferior a 1 segundo, mesmo quando mais usuários simultâneos (20) estão fazendo consultas neste farm.

Taxa de transferência da consulta

O seguinte gráfico mostra a taxa de transferência da consulta referente a este farm à medida que a carga de usuário aumenta (coletada durante o teste de taxa de transferência da consulta).

Considerando os dois gráficos anteriores, você vê que se adicionar uma carga de usuário além dos cerca de 20 usuários simultâneos, este farm não obterá nenhuma taxa de transferência adicional da consulta, e a latência aumentará.

Taxa de rastreamento

O seguinte gráfico mostra a taxa de rastreamento deste farm durante o estágio de aquisição do índice do ciclo de vida da pesquisa. Os valores representam um rastreamento completo, em itens rastreados por segundo.

A sobrecarga extra envolvida para realizar com eficiência um rastreamento completo na fonte de conteúdo do site do SharePoint resulta em uma taxa geral de rastreamento menor neste farm.

Consideração geral

Este farm estava no limite da sua capacidade de RAM para os servidores de consulta. Como os processos do servidor Web front-end (que também consomem RAM) estavam em um dos servidores de consulta, isso pode afetar a latência nas consultas executadas nesse servidor.

As próximas etapas para melhorar o desempenho deste farm podem ser estas:

• Mover os processos do servidor Web front-end para seu próprio servidor Web front-end (isto é, adicionar outro servidor Web front-end para redundância).

• Adicionar mais RAM a ambos servidores de consulta. É recomendável ter RAM suficiente no servidor de consulta para 33% da partição de índice do componente de consulta ativo mais 3 GB para o sistema operacional e outros processos.

• Adicionar matrizes de armazenamento para poder segregar os bancos de dados no servidor de banco de dados.

Farm médio

A configuração do farm médio usa um servidor Web, seis servidores de aplicativos e dois servidores de banco de dados, conforme mostrado a seguir:

• Um servidor Web foi usado nesta configuração de teste para hospedar o Centro de Pesquisa. Este servidor Web poderá ser omitido se as pesquisas sempre forem feitas de um farm filho usando um proxy de aplicativo de serviço de Pesquisa (instalado no farm filho). Do contrário, você pode adicionar outro servidor Web a este farm para redundância.

• Dois servidores de aplicativos são usados para rastreamento e administração. Isso quer dizer o seguinte:

  • A Administração Central e o componente de administração de pesquisa são criados em um dos servidores de aplicativos.

  • Cada servidor tem dois componentes de rastreamento. Cada componente de rastreamento é anexado a um banco de dados de rastreamento diferente para redundância.

• Os quatro servidores de aplicativos restantes são usados para consulta. Para até 40 milhões de itens, a configuração padrão é ter quatro partições de índice. A funcionalidade de consulta redundante é obtida organizando os componentes de consulta de forma que cada servidor tenha um componente de consulta ativo de uma das partições de índice e um componente de consulta de failover de uma partição de índice diferente. Entretanto, este farm de exemplo mostra o que fazer se você realmente pretende ter mais de 40 milhões de itens. Comece com oito partições de índice (cada uma com seus próprios componentes de consulta ativos e de failover) nos quatro servidores de aplicativos, assim você minimiza o reparticionamento de índice. Supõe-se que cada servidor atenda às seguintes diretrizes para permitir quatro componentes no mesmo servidor de aplicativos:

  • RAM e IOPS suficientes estão disponíveis.

  • Cada servidor tem mais de seis núcleos de CPU para oferecer suporte ao processamento, conforme mostrado a seguir:

    • Quatro núcleos de CPU para os dois componentes de consulta ativos.

    • Dois núcleos de CPU para os dois componentes de consulta de failover.

• Dois servidores de banco de dados dão suporte ao farm. Um servidor de banco de dados é usado para os dois bancos de dados de rastreamento. O outro servidor é usado para os bancos de dados de propriedades e pesquisa, além de ser usado para os outros bancos de dados do SharePoint. Os servidores de banco de dados devem ter um número dedicado de IOPS para cada banco de dados de rastreamento, propriedades e administração de pesquisa (por exemplo, usar matrizes de armazenamento diferentes).

Especificações

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

Topologia

Hardware

Servidor Web

Servidor Web	Servidor Web front-end (1)
Processador	2px4c com 2.33 GHz
RAM	8 GB
Sistema operacional	Windows Server 2008 R2 de 64 bits
Armazenamento	2x148GB 15K SAS: RAID1: OS
Número de NICs	2
Velocidade da NIC	1 gigabit
Autenticação	NTLM
Tipo de balanceador de carga	Nenhum
Versão do software	Microsoft SharePoint Server (versão de pré-lançamento)
Serviços em execução no local	Todos os serviços

Servidores de aplicativos

Há seis servidores de aplicativos no farm. Quatro servidores são usados para atender às consultas e dois servidores são usados para rastreamento.

Servidor (contagem)	Consulta (4)	Rastreamento (1), Rastreamento/Admin (1)
Processador	2px4c com 2.33 GHz	2px4c com 2.33 GHz
RAM	32 GB	8 GB
Sistema operacional	Windows Server 2008 R2 de 64 bits	Windows Server 2008 R2 de 64 bits
Armazenamento	2x148 GB 15K SAS: RAID1: OS 4x300GB 15K SAS:RAID10:Data	2x148 GB 15K SAS:RAID1: OS/Data
Número de NICs	2	2
Velocidade da NIC	1 gigabit	1 gigabit
Autenticação	NTLM	NTLM
Tipo de balanceador de carga	Nenhum	Nenhum
Versão do software	SharePoint Server 2010 (versão de pré-lançamento)	SharePoint Server 2010 (versão de pré-lançamento)
Serviços em execução no local	Pesquisa do SharePoint Server; Serviço de Configurações do Site e Consulta de Pesquisa	Pesquisa do SharePoint Server

Servidores de banco de dados

Há dois servidores de banco de dados. O primeiro servidor inclui o banco de dados de pesquisa, de propriedades e outros bancos de dados do SharePoint Server. O segundo servidor inclui os dois bancos de dados de rastreamento. Observe que os volumes de armazenamento criados otimizaram o hardware existente que estava disponível para o teste.

Servidor de banco de dados	Bancos de dados de Administração de Pesquisa; Propriedades; do SharePoint	Bancos de dados de rastreamento
Processador	2px4c com 3.2 GHz	4px2c com 2.19 GHz
RAM	32 GB	16 GB
Sistema operacional	Windows Server 2008 R2 de 64 bits	Windows Server 2008 R2 de 64 bits
Armazenamento	2x148GB 15K SAS :RAID1: SO 2x148GB 15K SAS :RAID1: Log TEMP 2x450GB 15K SAS :RAID1: BD TEMP 6x450GB 15K SAS :RAID10: BD de propriedades 2x450GB 15K SAS :RAID1: BDs de admin de pesquisa, do SharePoint 2x450GB 15K SAS :RAID1: Logs	2x148GB 15K SAS :RAID1: SO 2x148GB 15K SAS :RAID1: Log TEMP 2x300GB 15K SAS :RAID1: BD TEMP 6x146GB 15K SAS :RAID10: BD1 de rastreamento 6x146GB 15K SAS :RAID10: BD2 de rastreamento 2x300GB 15K SAS :RAID1: Log BD de rastreamento1 2x300GB 15K SAS :RAID1: Log BD de rastreamento2
Número de NICs	2	2
Velocidade da NIC	1 gigabit	1 gigabit
Autenticação	NTLM	NTLM
Versão do software	SQL Server 2008 Enterprise	SQL Server 2008 Enterprise

Carga de trabalho

Esta seção descreve a carga de trabalho usada para a geração de dados, incluindo o número de usuários e as características de uso do farm.

Características da carga de trabalho	Valor
Descrição de alto nível da carga de trabalho	Farms de pesquisa
Média de consultas por minuto	12
Média de usuários simultâneos	1
Número total de consultas por dia	17.280
Trabalhos de timer	Monitoramento da Integridade da Pesquisa – Eventos de Rastreamento; Relatório do Log de Rastreamento; Trabalho de Análise da Integridade; Pesquisar e Processar

Conjunto de dados

Esta seção descreve o conjunto de dados do farm de teste, incluindo o conteúdo e o tamanho do banco de dados, os índices de pesquisa e as fontes de dados externas.

Objeto	Valor
Tamanho do índice de pesquisa (número de itens)	46 milhões
Tamanho do banco de dados de rastreamento	356 GB
Tamanho do arquivo de log do banco de dados de rastreamento	85 GB
Tamanho do banco de dados de propriedades	304 GB
Tamanho do arquivo de log do banco de dados de propriedades	9 GB
Tamanho do banco de dados de administração de pesquisa	5 GB
Tamanho das partições do índice ativo	316 GB (79 GB por componente ativo).
Número total de bancos de dados	4
Outros bancos de dados	SharePoint_Config; SharePoint_AdminContent; State_Service; Bdc_Service_db; WSS_UsageApplication; WSS_Content

Dados de integridade e desempenho

Esta seção mostra os dados de integridade e desempenho específicos do ambiente de teste.

Dados de desempenho da consulta

As seguintes medidas foram feitas com 46 milhões de itens no índice de pesquisa. As colunas mostram as medidas que foram feitas durante o teste específico, e os resultados estão na parte inferior da tabela. As medidas estão descritas conforme mostrado abaixo:

• Latência da consulta   Estas medidas foram feitas durante um teste de latência da consulta, em que uma ferramenta de teste enviou um conjunto padrão de consultas, como um usuário, e depois avaliou a latência resultante. Nenhum rastreamento ocorreu durante o teste.

• Taxa de transferência da consulta   Estas medidas foram feitas durante um teste de taxa de transferência da consulta, em que uma ferramenta de teste enviou um conjunto padrão de consultas efetuadas no farm, como um número crescente de usuários simultâneos (até 80), e depois avaliou a latência e a taxa de transferência resultante. Nenhum rastreamento ocorreu durante o teste.

	Métrica de scorecard	Latência da consulta	Taxa de transferência da consulta
Métricas da CPU	Média da CPU do SQL Server (servidor de banco de dados de propriedades)	5%	98%
	Média da CPU do servidor Web front-end	3%	33%
	Média da CPU do servidor de consulta	3%	47%
Confiabilidade	Taxa de falha	0,07%	0%
	Falhas do servidor Web front-end	0	0
	Falhas do servidor de aplicativos	0	0
SQL Server (servidor de banco de dados de propriedades)	Taxa de acertos do cache (SQL Server)	100%	99,9%
	Bloqueios do SQL Server: tempo médio de espera (ms)	0,000	0,159
	Bloqueios do SQL Server: tempo de espera de bloqueio (ms)	0,000	0,080
	Bloqueios do SQL Server: número de deadlocks/s	0	0
	Travas do SQL Server: tempo médio de espera (ms)	0,041	1,626
	Compilações do SQL Server/s	9,776	93,361
	Estatísticas do SQL Server: recompilações do SQL Server/s	0,059	0,071
	Proporção leitura/gravação (E/S por banco de dados)	0,01	0,81
	Comprimento médio da fila de disco (SQL Server)	0,001	0,037
	Comprimento da fila de disco: gravações (SQL Server)	0,000	0,003
	Leituras de disco/s (SQL Server)	0,057	14,139
	Gravações de disco/s (SQL Server)	4,554	17,515
Servidor de aplicativos	Comprimento médio da fila de disco (servidor de consulta)	0,000	0,001
	Comprimento da fila de disco: gravações (servidor de consulta)	0,000	0,001
	Leituras de disco/s (servidor de consulta)	0,043	0,266
	Gravações de disco/s (servidor de consulta)	4,132	5,564
	Média de memória usada (servidor de consulta)	9%	10%
	Máximo de memória usada (servidor de consulta)	9%	10%
Servidor Web front-end	Solicitações ASP.NET em fila (média de todos os servidores Web front-end)	0	0
	Média de memória usada (servidor Web front-end)	47%	48%
	Máximo de memória usada (servidor Web front-end)	47%	49%
Resultados do teste	Número de êxitos	1.398	14.406
	Número de erros	1	0
	Latência da IU de consulta (75 percentil)	0,47 s	2,57 s
	Latência da IU de consulta (95 percentil)	0,65 s	3,85 s
	Taxa de transferência da consulta	2,38 solicitações/s	27,05 solicitações/s

Dados de desempenho do rastreamento

As seguintes medidas foram feitas durante os rastreamentos completos iniciais da fonte de conteúdo especificada. O tamanho da fonte de conteúdo aparece em milhões de itens. As colunas mostram as medidas que foram feitas durante o rastreamento específico, e os resultados estão na parte inferior da tabela.

	Métrica de scorecard	Conteúdo do SharePoint (3,5 milhões)	Compartilhamento de arquivos (1 milhão)	HTTP (não SharePoint) (1 milhão)
Métricas da CPU	Média da CPU do SQL Server (servidor de banco de dados de rastreamento, servidor de banco de dados de propriedades)	11%, 19%	22%, 7%	23%, 5%
	Máximo da CPU do SQL Server (servidor de banco de dados de rastreamento, servidor de banco de dados de propriedades)	96%, 100%	86%, 45%	79%, 28%
	Média da CPU do indexador	41,6%	69%	71%
Confiabilidade	Taxa de falha	0,2%	0,02%	0%
	Falhas do servidor Web front-end	0	0	0
	Falhas do servidor de aplicativos	0	0	0
SQL Server (servidor de banco de dados de rastreamento, servidor de banco de dados de propriedades)	Taxa de acertos do cache (SQL Server)	99,5%, 99,8%	Não coletado	99,9%, 99,3%
	Bloqueios do SQL Server: tempo médio de espera [ms]	1.881,749, 1.106,314	1.617,980, 2,882	983,137, 0,904
	Bloqueios do SQL Server: tempo máximo de espera [ms]	69.919,500, 1.081.703	55.412,000, 304,500	24.000,500, 47
	Bloqueios do SQL Server: tempo médio de espera do bloqueio [ms]	339,658, 10.147,012	Não coletado	739,232, 0,136
	Bloqueios do SQL Server: tempo máximo de espera do bloqueio [ms]	598.106,544, 234.708.784	Não coletado	52.711,592, 23,511
	Bloqueios do SQL Server: número de deadlocks/s	0,001, 0	Não coletado	0,008, 0
	Travas do SQL Server: tempo médio de espera [ms]	2,288, 13,684	3,042, 13,516	2,469, 20,093
	Travas do SQL Server: tempo máximo de espera [ms]	2.636, 1.809	928, 858,5	242,929, 938,706
	Compilações do SQL Server/s: média	20,384, 5,449	Não coletado	76,157, 6,510
	Compilações do SQL Server/s: máximo	332,975, 88,992	Não coletado	295,076, 42,999
	Estatísticas do SQL Server: recompilações do SQL Server/s: média	0,560, 0,081	Não coletado	0,229, 0,125
	Estatísticas do SQL Server: recompilações do SQL Server/s: máximo	22,999, 88,492	Não coletado	17,999, 15,5
	Proporção leitura/gravação (E/S por banco de dados): máximo	2,15, 1,25	Não coletado	1,45, 0,364
	Comprimento médio da fila de disco (SQL Server)	66,765, 27,314	129,032, 20,665	182,110, 11,816
	Comprimento máximo da fila de disco (SQL Server)	4.201,185, 5.497,980	3.050,015, 762,542	1.833,765, 775,7
	Comprimento da fila de disco: gravações (SQL Server): média	58,023, 13,532	114,197, 19,9	175,621, 10,417
	Comprimento da fila de disco: gravações (SQL Server): máximo	1.005,691, 881,892	1.551,437, 761,891	1.018,642, 768,289
	Leituras de disco/s (SQL Server): média	245,945, 94,131	Não coletado	137,435, 154,103
	Leituras de disco/s (SQL Server): máximo	6.420,412, 6.450,870	Não coletado	3.863,283, 1.494,805
	Gravações de disco/s (SQL Server): média	458,144, 286,884	Não coletado	984,668, 278,175
	Gravações de disco/s (SQL Server): máximo	2.990,779, 5.164,949	Não coletado	2.666,285, 4.105,897
Servidor de aplicativos	Comprimento médio da fila de disco (servidor de rastreamento)	0,052	0,043	0,030
	Comprimento da fila de disco: gravações (servidor de rastreamento)	0,029	0,031	0,026
	Leituras de disco/s (servidor de rastreamento)	5,405	Não coletado	0,798
	Gravações de disco/s (servidor de rastreamento)	48,052	Não coletado	102,235
	Média de memória usada (servidor de rastreamento)	68%	45%	52%
	Máximo de memória usada (servidor de rastreamento)	76%	47%	59%
Servidor Web front-end	Solicitações ASP.NET em fila (média de todos os servidores Web front-end)	0	0	0
	Média de memória usada (servidor Web front-end)	n/a	n/a	n/a
	Máximo de memória usada (servidor Web front-end)	n/a	n/a	n/a
Resultados do teste	Número de êxitos	3.631.080	1.247.838	200.000
	Número de erros	7.930	304	0
	Velocidade de rastreamento do portal (itens/s)	82	148	81
	Velocidade de rastreamento da ancoragem (itens/s)	1.573	1.580	1.149
	Velocidade total de rastreamento (itens/s)	79	136	76

Dados de teste

Esta seção apresenta dados de teste que ilustram o desempenho do farm sob carga.

Latência da consulta

O seguinte gráfico mostra os percentis de latência da consulta referentes a este farm à medida que a carga de usuário aumenta (coletados durante o teste de taxa de transferência da consulta). Um percentil de consulta de 95% significa que 95% das latências de consulta que foram avaliadas estavam abaixo desse valor.

Você vê neste gráfico que com um índice menor este farm é capaz de manter a latência da consulta inferior a 1 segundo a 95 percentil, mesmo quando mais usuários simultâneos (22) estão fazendo consultas neste farm.

Taxa de transferência da consulta

O seguinte gráfico mostra a taxa de transferência da consulta referente a este farm à medida que a carga de usuário aumenta (coletada durante o teste de taxa de transferência da consulta).

Considerando tanto este gráfico quanto o gráfico anterior, você vê que, com 33 milhões de itens no índice, o farm é capaz de manter a latência inferior a 1 segundo a 75 percentil com cerca de 30 usuários simultâneos. Ainda é possível acomodar mais carga de usuário simultâneo, mas a latência da consulta vai aumentar além da marca inferior a 1 segundo.

Porém, com 46 milhões de itens no índice, não é possível acomodar nenhuma carga de usuário adicional, e a latência da consulta vai aumentar.

Taxa de rastreamento

O seguinte gráfico mostra a taxa de rastreamento deste farm durante o estágio de aquisição do índice do ciclo de vida da pesquisa. Os valores representam um rastreamento completo, em itens rastreados por segundo.

A sobrecarga extra envolvida para rastrear com eficiência uma fonte de conteúdo do site do SharePoint resulta em uma taxa geral de rastreamento menor neste farm.

Consideração geral

Este farm estava no limite da sua capacidade de RAM para os servidores de consulta.

As próximas etapas para melhorar o desempenho deste farm podem ser estas:

• Adicionar mais RAM a ambos servidores de consulta. É recomendável ter RAM suficiente no servidor de consulta para 33% da partição de índice do componente de consulta ativo mais 3 GB para o sistema operacional e outros processos.

• Adicionar mais RAM ao servidor de banco de dados que hospeda o banco de dados de propriedades. Nesta configuração, as tabelas de chaves tinham cerca de 92 GB (incluindo os índices), o que sugere um requisito de 30 GB de RAM. No entanto, o servidor de banco de dados tinha apenas 32 GB de RAM para atender ao banco de dados de propriedades, ao banco de dados de administração de pesquisa e a outros bancos de dados do SharePoint Server.

• Adicionar matrizes de armazenamento para poder segregar os bancos de dados no servidor de banco de dados.

• Dimensionar para aumentar a taxa de transferência ou reduzir a latência da consulta, ou ambos.

Embora a velocidade de rastreamento seja alta neste farm com dois bancos de dados de rastreamento e quatro componentes de rastreamento, pode ser uma meta importante para o farm ter determinadas partes do índice mais atualizadas; ou seja, algum conteúdo precisa ser rastreado com muita frequência. A adição de outro banco de dados de rastreamento dedicado aos hosts na fonte de conteúdo desejada (com regras de distribuição de host) e a associação de dois componentes de rastreamento extras ao banco de dados podem contribuir para a meta de atualização do índice.

Farm grande

A configuração esperada usa um servidor Web, 13 servidores de aplicativos e três servidores de banco de dados, conforme mostrado a seguir:

• Um servidor Web é usado para hospedar um Centro de Pesquisa. Esse servidor Web poderá ser omitido se as pesquisas sempre forem feitas de um farm de conteúdo usando um proxy de aplicativo de serviço de Pesquisa (instalado no farm de conteúdo).

• Três servidores de aplicativos são usados para rastreamento e administração. Isso quer dizer que:

  • A Administração Central e o componente de administração de pesquisa são criados em um dos servidores de aplicativos.

  • Cada servidor tem dois componentes de rastreamento. Cada componente de rastreamento é anexado a um banco de dados de rastreamento separado.

• Os dez servidores de aplicativos restantes são usados para consulta. A configuração preferencial é ter 10 partições de índice. Cada servidor então tem um componente de consulta principal de uma das partições de índice, além de um componente de consulta de failover de uma partição de índice diferente.

• Quatro servidores de banco de dados dão suporte ao farm. Um servidor é usado para os bancos de dados de propriedades e administração de pesquisa. Um segundo servidor é usado para um banco de dados de propriedades. Um terceiro servidor é usado para dois bancos de dados de rastreamento. O quarto servidor é usado para um banco de dados de rastreamento e os outros bancos de dados do SharePoint. Os servidores de banco de dados devem ter um número dedicado de IOPS para cada banco de dados de rastreamento, propriedades e administração de pesquisa (por exemplo, usar matrizes de armazenamento diferentes).

Especificações

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

Topologia

Esta seção descreve a topologia do ambiente de teste.

Hardware

Esta seção descreve o hardware usado para o teste.

Servidores Web

Servidor Web	Servidor Web front-end (1)
Processador	2px4c com 2.33 GHz
RAM	8 GB
Sistema operacional	Windows Server 2008 R2 de 64 bits
Armazenamento	2x148GB 15K SAS: RAID1: OS
Número de NICs	2
Velocidade da NIC	1 gigabit
Autenticação	NTLM
Tipo de balanceador de carga	nenhum
Versão do software	SharePoint Server 2010 (versão de pré-lançamento)
Serviços em execução no local	Todos os serviços

Servidores de aplicativos

Há 13 servidores de aplicativos no farm. Dez servidores são usados para atender às consultas e três servidores são usados para rastreamento.

Servidor (contagem)	Consulta (10)	Rastreamento (2), Rastreamento/Administração (1)
Processador	2px4c com 2.5 GHz	2px4c com 2.5 GHz
RAM	32 GB	32 GB
Sistema operacional	Windows Server 2008 R2 de 64 bits	Windows Server 2008 R2 de 64 bits
Armazenamento	2x148GB 15K SAS: RAID1: SO 4x300GB 15K SAS:RAID10: Dados	2x148GB 15K SAS:RAID1: SO/Dados
Número de NICs	2	2
Velocidade da NIC	1 gigabit	1 gigabit
Autenticação	NTLM	NTLM
Tipo de balanceador de carga	Nenhum	Nenhum
Versão do software	SharePoint Server 2010 (versão de pré-lançamento)	SharePoint Server 2010 (versão de pré-lançamento)
Serviços em execução no local	Pesquisa do SharePoint Server; Serviço de Configurações do Site e Consulta de Pesquisa	Pesquisa do SharePoint Server

Servidores de banco de dados

Há quatro servidores de banco de dados. O primeiro servidor inclui os bancos de dados de administração de pesquisa e propriedades; o segundo servidor inclui um banco de dados de propriedades; o terceiro inclui dois bancos de dados de rastreamento; o quarto inclui um banco de dados de rastreamento e um banco de dados do SharePoint. Observe que os volumes de armazenamento criados otimizaram o hardware existente disponível para o teste.

Servidor de banco de dados	Bancos de dados de Administração de Pesquisa, Propriedades e do SharePoint	Bancos de dados de rastreamento
Processador	2px4c com 3.2 GHz	4px2c com 2.19 GHz
RAM	32 GB	16 GB
Sistema operacional	Windows Server 2008 R2 de 64 bits	Windows Server 2008 R2 de 64 bits
Armazenamento	2x148GB 15K SAS :RAID1: SO 2x148GB 15K SAS :RAID1: Log TEMP 2x450GB 15K SAS :RAID1: BD TEMP 6x450GB 15K SAS :RAID10: BD de propriedades 2x450GB 15K SAS :RAID1: BDs de admin de pesquisa, do SharePoint 2x450GB 15K SAS :RAID1: Logs	2x148GB 15K SAS :RAID1: SO 2x148GB 15K SAS :RAID1: Log TEMP 2x300GB 15K SAS :RAID1: BD TEMP 6x146GB 15K SAS :RAID10: BD1 de rastreamento 6x146GB 15K SAS :RAID10: BD2 de rastreamento 2x300GB 15K SAS :RAID1: Log BD de rastreamento1 2x300GB 15K SAS :RAID1: Log BD de rastreamento2
Número de NICs	2	2
Velocidade da NIC	1 gigabit	1 gigabit
Autenticação	NTLM	NTLM
Versão do software	SQL Server 2008 Enterprise	SQL Server 2008 Enterprise

Dados de desempenho da consulta

As seguintes medidas foram feitas com 103 milhões de itens no índice. As colunas mostram as medidas feitas durante o teste específico, e os resultados estão na parte inferior da tabela. As medidas feitas estão descritas conforme mostrado abaixo:

• Latência da Consulta   Estas medidas foram feitas durante um teste de latência da consulta, em que uma ferramenta de teste enviou um conjunto padrão de consultas como um usuário e avaliou a latência resultante. Nenhum rastreamento ocorreu durante o teste.

• Taxa de Transferência da Consulta   Estas medidas foram feitas durante um teste de taxa de transferência da consulta, em que uma ferramenta de teste enviou um conjunto padrão de consultas efetuadas no farm como um número crescente de usuários simultâneos (até 120) e avaliou a latência e a taxa de transferência resultante. Nenhum rastreamento ocorreu durante o teste.

	Métrica de scorecard	Taxa de transferência da consulta
Métricas da CPU	Média da CPU do SQL Server (servidor de banco de dados de propriedades)	34%
	Média da CPU do servidor Web front-end	45%
	Média da CPU do servidor de consulta	20%
Confiabilidade	Taxa de falha	0%
	Falhas do servidor Web front-end	0
	Falhas do servidor de aplicativos	0
SQL Server (servidor de banco de dados de propriedades)	Taxa de acertos do cache (SQL Server)	100%
	Bloqueios do SQL Server: tempo médio de espera (ms)	0
	Bloqueios do SQL Server: tempo de espera de bloqueio (ms)	0
	Bloqueios do SQL Server: número de deadlocks/s	0
	Travas do SQL Server: tempo médio de espera (ms)	1,401
	Compilações do SQL Server/s	73,349
	Estatísticas do SQL Server: recompilações do SQL Server/s	0,006
	Proporção leitura/gravação (E/S por banco de dados)	0,81
	Comprimento médio da fila de disco (SQL Server)	0,037
	Comprimento da fila de disco: gravações (SQL Server)	0,003
	Leituras de disco/s (SQL Server)	9,88
	Gravações de disco/s (SQL Server)	354,1
Servidor de aplicativos	Comprimento médio da fila de disco (servidor de consulta)	0,002
	Comprimento da fila de disco: gravações (servidor de consulta)	0,002
	Leituras de disco/s (servidor de consulta)	0,035
	Gravações de disco/s (servidor de consulta)	6,575
	Média de memória usada (servidor de consulta)	6,548%
	Máximo de memória usada (servidor de consulta)	6,601%
Servidor Web front-end	Solicitações ASP.NET em fila (média de todos os servidores Web front-end)	0
	Média de memória usada (servidor Web front-end)	18,081%
	Máximo de memória usada (servidor Web front-end)	19,983%
Resultados do teste	Número de êxitos	10.925
	Número de erros	0
	Latência da IU de consulta (75 percentil)	3,431 s
	Latência da IU de consulta (95 percentil)	3,512 s
	Taxa de transferência da consulta	36,42 solicitações/s

Dados de desempenho do rastreamento

As seguintes medidas foram feitas durante os rastreamentos completos iniciais e sequenciais da fonte de conteúdo especificada. O tamanho do conteúdo aparece em milhões de itens. As colunas mostram as medidas que foram feitas durante o rastreamento específico, e os resultados estão na parte inferior da tabela.

	Métrica de scorecard	Conteúdo do SharePoint (3,5 milhões)	Compartilhamento de arquivos (1 milhão)
Métricas da CPU	Média da CPU do SQL Server (servidor de banco de dados de rastreamento, servidor de banco de dados de propriedades)	15,74%, N/A	24%, 6,6%
	Máximo da CPU do SQL Server (servidor de banco de dados de rastreamento, servidor de banco de dados de propriedades)	100%, N/A%	100%, 45%
	Média da CPU do indexador	44%	49%
Confiabilidade	Taxa de falha	0,0%	0,00%
	Falhas do servidor Web front-end	0	0
	Falhas do servidor de aplicativos	0	0
SQL Server (servidor de banco de dados de rastreamento, servidor de banco de dados de propriedades)	Taxa de acertos do cache (SQL Server)	99,8%, N/A%	99,797%, 99,49%
	Bloqueios do SQL Server: tempo médio de espera [ms]	734,916, N/A	1.165, 5,866
	Bloqueios do SQL Server: tempo máximo de espera [ms]	15.335, N/A	28.683, 210,5
	Bloqueios do SQL Server: tempo médio de espera do bloqueio [ms]	108,98, N/A	847,72, 5,325
	Bloqueios do SQL Server: tempo máximo de espera do bloqueio [ms]	17.236,96, N/A	124.353, 12.920
	Bloqueios do SQL Server: número de deadlocks/s	0, N/A	0,012, 0
	Travas do SQL Server: tempo médio de espera [ms]	1,4, N/A	2,233, 40,6
	Travas do SQL Server: tempo máximo de espera [ms]	1.606, N/A	917,8, 1.895
	Compilações do SQL Server/s: média	24,28, N/A	72,7, 11,39
	Compilações do SQL Server/s: máximo	416, N/A	460, 76,62
	Estatísticas do SQL Server: recompilações do SQL Server/s: média	0,560, N/A	0,295, 0,099
	Estatísticas do SQL Server: recompilações do SQL Server/s: máximo	0,24, N/A	17,50, 17,393
	Proporção leitura/gravação (E/S por banco de dados): máximo	20,3, N/A	1,18/0,214
	Comprimento médio da fila de disco (SQL Server)	90,113, N/A	138,64, 27,478
	Comprimento máximo da fila de disco (SQL Server)	3.179, N/A	2.783,543, 847,574
	Comprimento da fila de disco: gravações (SQL Server): média	86,93, N/A	130.853, 26,086
	Comprimento da fila de disco: gravações (SQL Server): máximo	1.882, N/A	2.781,197, 884,801
	Leituras de disco/s (SQL Server): média	99, N/A	147,462, 159,159
	Leituras de disco/s (SQL Server): máximo	3.772, N/A	2.403,336, 896,462
	Gravações de disco/s (SQL Server): média	373, N/A	475,886, 539,497
	Gravações de disco/s (SQL Server): máximo	18.522, N/A	2.031,888, 4.174,271
Servidor de aplicativos	Comprimento médio da fila de disco (servidor de rastreamento)	0,075	0,063
	Comprimento da fila de disco: gravações (servidor de rastreamento)	0,046	0,053
	Leituras de disco/s (servidor de rastreamento)	1,958	1,693
	Gravações de disco/s (servidor de rastreamento)	62,33	101,093
	Média de memória usada (servidor de rastreamento)	59%	56,38%
	Máximo de memória usada (servidor de rastreamento)	70%	58,93%
Servidor Web front-end	Solicitações ASP.NET em fila (média de todos os servidores Web front-end)	N/A	N/A
	Média de memória usada (servidor Web front-end)	N/A	N/A
	Máximo de memória usada (servidor Web front-end)	N/A	N/A
Resultados do teste	Número de êxitos	1.909.739	1.247.838
	Número de erros	9.361	331
	Velocidade de rastreamento do portal (itens/s)	70,3	131,44
	Velocidade de rastreamento da ancoragem (itens/s)	764	525,84
	Velocidade total de rastreamento (itens/s)	64	105

Recomendações e solução de problemas

As seções a seguir apresentam recomendações sobre como determinar o hardware, a topologia e a configuração necessária para implantar ambientes similares a estes cenários e como otimizar o ambiente para as características apropriadas de capacidade e desempenho.

Recomendações

Esta seção descreve ações específicas que você pode executar para otimizar o ambiente para as características apropriadas de capacidade e desempenho.

Recomendações de hardware

Para obter informações específicas sobre os requisitos gerais mínimos e recomendados do sistema, consulte Requisitos de hardware e software (SharePoint Server 2010). Observe que os requisitos dos servidores usados para pesquisa substituem os requisitos gerais do sistema. Use as seguintes diretrizes recomendadas de RAM, processador e IOPS para atender às metas de desempenho.

Dimensionamento da pesquisa

Esta seção explica o sistema de pesquisa, incluindo os requisitos e as diretrizes de dimensionamento, por componente.

O SharePoint Server 2010 pode ser implantado e configurado de inúmeras maneiras. Dessa forma, não há uma maneira simples de estimar quantos usuários ou itens poderão ter suporte em um determinado número de servidores. Portanto, realize testes em seu próprio ambiente antes de implantar o SharePoint Server 2010 em um ambiente de produção.

Sistema de consulta de pesquisa

Esta seção mostra os componentes do sistema de consulta de pesquisa referentes a determinado aplicativo de serviço de Pesquisa. Os requisitos de dimensionamento de cada componente aparecem na lista da tabela Detalhes da escala, após o diagrama a seguir.

Descrições dos objetos

A lista a seguir define os objetos do sistema de consulta de pesquisa que estão no diagrama anterior:

• Proxy de pesquisa   É o proxy do aplicativo de serviço de Pesquisa que está instalado em qualquer farm que consome pesquisa deste aplicativo de serviço de Pesquisa. Ele é executado no contexto dos aplicativos Web associados ao proxy do aplicativo de serviço de Pesquisa.

• Serviço de Configurações do Site e Consulta de Pesquisa   Também conhecido como o processador de consultas. Ao receber a consulta de uma conexão proxy do aplicativo de serviço de Pesquisa, o processador de consultas faz o seguinte:

  • Envia a consulta a um componente de consulta ativo para cada partição de índice (ou ao banco de dados de propriedades, ou ambos, dependendo da consulta)

  • Recupera as Melhores Opções e remove duplicatas para obter o conjunto de resultados

  • Realiza a filtragem de segurança dos resultados com base nos descritores de segurança no banco de dados de administração de pesquisa

  • Recupera os metadados do conjunto de resultados final do banco de dados de propriedades

  • Envia os resultados da consulta de volta ao proxy

• Partição de índice   É um grupo lógico de componentes de consulta que representa um subconjunto de índice de texto completo. A soma das partições de índice compõe o índice de texto completo. Porém, observe que os componentes de consulta incluem o subconjunto real do índice. Uma partição de índice está associada a um banco de dados de propriedades.

• Componente de consulta de pesquisa   Um componente de consulta inclui todo o índice de texto completo, ou parte dele. Quando um processador de consultas faz uma consulta, o componente de consulta determina os melhores resultados de seu índice e retorna esses itens. É possível criar um componente de consulta como uma das seguintes opções:

  • Ativo, o que significa que ele vai responder às consultas por padrão. A adição de vários componentes de consulta ativos à mesma partição de índice aumenta a taxa de transferência.

  • Failover, o que significa que ele só vai responder às consultas se todos os componentes ativos da mesma partição de índice tiverem falhado.

• Banco de dados de administração de pesquisa   Criado ao mesmo tempo que o aplicativo de serviço de Pesquisa, o banco de dados de administração de pesquisa inclui os dados de todo o aplicativo de serviço de Pesquisa usados para consultas como Melhores Opções e descritores de segurança, além das configurações de aplicativo que são usadas para administração.

• Banco de dados de propriedades   Um banco de dados de propriedades inclui os metadados (título, autor, campos relacionados) referentes aos itens no índice. O banco de dados de propriedades é usado para consultas baseadas em propriedades, além de recuperar os metadados necessários para exibir os resultados finais. Se houver várias partições de índice, elas poderão ser mapeadas para bancos de dados de propriedades diferentes.

Detalhes da escala

Objeto	Considerações da escala	RAM	IOPS (leitura/gravação)
Proxy de pesquisa	Faz o dimensionamento com os servidores Web front-end aos quais está associado.	N/A	N/A
Serviço de Configurações do Site e Consulta de Pesquisa	Esse serviço, que é instalado na página Serviços no Servidor na Administração Central, deve ser iniciado em cada servidor com um componente de consulta. É possível movê-lo para um servidor separado (ou par, para alta disponibilidade) para evitar o uso da RAM nos servidores que incluem os componentes de consulta. Se também for utilizado um filtro de segurança personalizado, ele poderá afetar os recursos de CPU e RAM.	Usa a RAM (cache de processos) para armazenar em cache os descritores de segurança do índice.	N/A
Partição de índice	O aumento do número de partições de índice reduz o número de itens na partição de índice, e isso reduz a RAM e o espaço em disco necessários no servidor de consulta que hospeda o componente de consulta atribuído à partição de índice.	N/A	N/A
Componente de consulta	Cada componente de consulta ativo no servidor consome memória enquanto atende às consultas. Cada componente de consulta ativo é criado ou modificado como parte da topologia de um aplicativo de serviço de Pesquisa. Ambos componentes ativo e de failover consomem E/S durante o rastreamento. Os servidores podem ser dedicados aos componentes de consulta (por exemplo, dois ativos e dois de failover no mesmo servidor), considerando que os requisitos de RAM e E/S sejam seguidos. Quando possível, dedique pelo menos dois núcleos de CPU por componente ativo por servidor, e pelo menos um núcleo de CPU por componente de failover por servidor.	Para cada componente de consulta ativo em um servidor de aplicativos, 33% de seu índice deve estar na RAM (cache do sistema operacional).	São necessários 2 mil componentes de consulta por par (ativo/failover) em um servidor específico. O componente de consulta precisa de E/S para: Carregar o índice na RAM para as consultas Gravar fragmentos do índice que são recebidos de cada componente de rastreamento Mesclar fragmentos do índice em seu índice, por exemplo, durante uma mesclagem mestra
Banco de dados de administração de pesquisa	Para cada consulta, as Melhores Opções e os descritores de segurança são carregados do banco de dados de administração de pesquisa. Verifique se o servidor de banco de dados tem RAM suficiente para realizar essa operação no cache. Quando possível, evite colocar esses itens em um servidor com banco de dados de rastreamento, pois o banco de dados de rastreamento tende a reiniciar o cache de seu servidor de banco de dados.	Verifique se o servidor de banco de dados tem RAM suficiente para manter a tabela crítica (MSSSecurityDescriptors) na RAM.	700
Banco de dados de propriedades	Para cada consulta, são recuperados metadados do banco de dados de propriedades para os resultados dos documentos, assim você pode adicionar RAM ao servidor de banco de dados para melhorar o desempenho. Se houver várias partições de índice, você poderá particionar o banco de dados de propriedades e passar para um servidor de banco de dados diferente para reduzir os requisitos de RAM e E/S.	Verifique se o servidor de banco de dados tem RAM suficiente para manter 33% das tabelas críticas (MSSDocSDIDs + MSSDocProps + MSSDocresults) no cache.	2 mil 30% de leitura, 70% de gravação

Sistema de rastreamento de pesquisa

Esta seção mostra os componentes do sistema de rastreamento de pesquisa. Os requisitos de dimensionamento de cada componente aparecem na tabela após o diagrama.

Descrições dos objetos

Esta seção define os objetos do sistema de rastreamento de pesquisa no diagrama anterior:

• Componente de administração   É usado quando um rastreamento é iniciado e também quando uma tarefa de administração é realizada no sistema de rastreamento.

• Componente de rastreamento   Rastreia, propaga os arquivos de fragmentos do índice resultantes para os componentes de consulta e adiciona informações sobre o local e o cronograma de rastreamento das fontes de conteúdo ao banco de dados de rastreamento associado.

• Banco de dados de administração de pesquisa   Criado ao mesmo tempo que o aplicativo de serviço de Pesquisa, armazena os descritores de segurança descobertos durante o rastreamento e também as configurações de aplicativo usadas para administração.

• Banco de dados de rastreamento   Inclui dados relacionados ao local das fontes de conteúdo, cronogramas de rastreamento e outras informações específicas às operações de rastreamento. Pode ser dedicado a hosts específicos através da criação de regras de distribuição de host. Um banco de dados de rastreamento armazena somente dados. O componente de rastreamento associado a determinado banco de dados de rastreamento realiza o rastreamento.

• Sistema de consulta de pesquisa

Detalhes da escala

Objeto	Considerações da escala	RAM	IOPS (opcionalmente, % de leitura/gravação)
Componente de administração	O único componente de administração não é escalonável. Por padrão, ele está localizado em um servidor que hospeda um componente de rastreamento (e a Administração Central, em farms menores).	Mínimo	Mínimo
Componente de rastreamento	Os componentes de rastreamento usam largura de banda massiva da CPU. O ideal é que um componente de rastreamento utilize quatro núcleos de CPU. A RAM não é crítica. Em farms maiores, dedicar servidores para hospedar componentes de rastreamento minimiza o efeito do rastreador sobre outros componentes (principalmente se usar componentes de rastreamento associados a bancos de dados de rastreamento diferentes, se desejar redundância).	Moderado. Observe que ao rastrear documentos do leste asiático, os requisitos de RAM aumentam por causa dos separadores de palavras.	300-400
Banco de dados de administração de pesquisa	Consulte Sistema de consulta de pesquisa acima. Quando possível, evite colocar esses itens em um servidor com banco de dados de rastreamento, pois o banco de dados de rastreamento tende a reiniciar o cache de seu servidor de banco de dados.	Consulte Sistema de consulta de pesquisa acima.	700
Banco de dados de rastreamento	Os bancos de dados de rastreamento usam largura de banda massiva de E/S. A RAM não é crítica. Um banco de dados de rastreamento precisa de 3.500 IOPS para as atividades de rastreamento; ele consome até 6 mil IOPS, com base na largura de banda disponível.	Moderado	3.500 – 7 mil 73% de leitura, 27% de gravação

Calcular dimensionamento de armazenamento

Calcule os fatores a seguir para ajudar a estimar os requisitos de armazenamento. Os fatores de dimensionamento são baseados em um sistema interno pré-implantação com um índice que inclui basicamente conteúdo do SharePoint (o tamanho dos bancos de dados de conteúdo é de 13,3 terabytes). Em geral, a pesquisa do SharePoint exigia aproximadamente 20% do espaço em disco no banco de dados de conteúdo. Conforme já mencionado, realize testes em seu próprio ambiente antes de implantar o SharePoint Server 2010 em um ambiente de produção.

Avisos:

• O total usado para derivar esses números era basicamente conteúdo do SharePoint (inglês), portanto, se o seu conteúdo for diferente (por exemplo, consistir principalmente em compartilhamentos de arquivos ou sites HTTP não pertencentes ao SharePoint), será necessário permitir uma maior variação.

• Mesmo que o conteúdo seja basicamente do SharePoint, ainda será possível variar os coeficientes nas seguintes circunstâncias:

  • Se você tiver repositórios grandes de documentos, os coeficientes serão significativamente maiores.

  • Se o conteúdo for basicamente de imagens, poderá ser possível reduzir os coeficientes.

  • Conteúdo em outro idioma pode afetar os coeficientes.

1. Calcular o fator de dimensionamento do banco de dados de conteúdo (ContentDBSum)

Determine a soma dos bancos de dados de conteúdo do SharePoint que serão rastreados. Esse é o valor ContentDBSum que será usado como a correlação nos próximos cálculos de armazenamento.

2. Calcular os tamanhos relacionados ao índice (TotalIndexSize e QueryComponentIndexSize)

Determine o tamanho do índice total (que está localizado nos componentes de consulta e é usado para as consultas de texto completo):

Multiplique ContentDBSum por 0,035. Esse é o TotalIndexSize antes de você particionar e reservar espaço para mesclagens e reparticionamento.

Em seguida, determine o número de partições de índice que você vai ter com base no seu cenário. Uma diretriz geral é que a partição de índice deve ter entre 5 e 10 milhões de itens. Após determinar o número de partições de índice, você poderá calcular o tamanho do armazenamento de componentes de consulta.

• Divida TotalIndexSize por (número de partições de índice). Esse é o QueryComponentIndexSize, usado para calcular os seguintes tamanhos:

  • Para a RAM, multiplique QueryComponentIndexSize por 0,33. Esse é o mínimo de RAM necessário para esse componente de consulta, se estiver ativo.

    • Se o componente for de failover, ele não vai precisar de RAM até se tornar ativo.

    • Para um servidor, ter vários componentes de consulta ativos no mesmo servidor significa que você precisa somar a RAM de cada componente de consulta ativo para chegar à RAM necessária para o servidor.

  • Para o armazenamento em disco, use QueryComponentIndexSize das seguintes maneiras para estimar os requisitos de disco, dependendo se você vai reparticionar o índice (ou seja, você espera que o índice cresça além do limite de 10 milhões por partição):

    • Multiplique QueryComponentIndexSize por 3 para calcular o armazenamento em disco de um único componente de consulta e liberar espaço para a mesclagem do índice.

    • Multiplique QueryComponentIndexSize por 4 para calcular o armazenamento em disco de um único componente de consulta e liberar espaço para o reparticionamento do índice.

Para um servidor, ter vários componentes de consulta no mesmo servidor significa que você tem que organizar o armazenamento de cada componente de consulta de acordo com os requisitos de IOPS na seção "Detalhes da escala", da seção "Sistema de consulta de pesquisa" já mencionadas neste artigo.

3. Calcular os tamanhos de banco de dados de propriedades

Determine o tamanho dos bancos de dados de propriedades da seguinte maneira:

• Multiplique ContentDBSum por 0,015. Esse é o TotalPropertyDBSize antes do particionamento.

• Multiplique ContentDBSum por 0,0031. Esse é o TotalPropertyDBLogSize antes do particionamento. Supõe-se que você usa o modelo de recuperação simples para os bancos de dados SQL Server.

• Multiplique ContentDBSum por 0,00034. Esse é o TempDBSize do banco de dados de propriedades. Como a recomendação é ter 33% das tabelas de chaves no banco de dados de propriedades na RAM, o uso de um banco de dados temporário não fica pesado.

Em seguida, determine o número de bancos de dados de propriedades que você vai ter com base no seu cenário. Uma diretriz geral é que o banco de dados de propriedades tenha até 50 milhões de itens, considerando que não haja nenhum problema de desempenho da consulta e que você tenha um número limitado de propriedades gerenciadas (a configuração padrão).

• Divida TotalPropertyDBSize por (número de bancos de dados de propriedades). Esse é o PropertyDatabaseSize.

• Divida TotalPropertyDBLogSize por (número de bancos de dados de propriedades). Esse é o PropertyDatabaseLogSize.

• Para a RAM, multiplique PropertyDatabaseSize por 0,33. Essa é a quantidade mínima de RAM recomendada para este banco de dados de propriedades.

Para um servidor de banco de dados, ter vários bancos de dados de propriedades no mesmo servidor significa que você tem que organizar o armazenamento e a RAM de cada banco de dados de propriedades de acordo com os requisitos de IOPS e RAM na seção "Detalhes da escala", da seção "Sistema de consulta de pesquisa" já mencionadas neste artigo.

4. Calcular os tamanhos de banco de dados de rastreamento

Em seguida, determine o tamanho necessário para o banco de dados de rastreamento da seguinte maneira:

• Multiplique ContentDBSum por 0,046. Esse é o TotalCrawlDBSize antes do particionamento.

• Multiplique ContentDBSum por 0,011. Esse é o TotalCrawlDBLogSize antes do particionamento. Supõe-se que você usa o modelo de recuperação simples para os bancos de dados SQL Server.

• Multiplique ContentDBSum por 0,0011. Esse é o TempDBSize do banco de dados de rastreamento. Como o sistema de rastreamento de pesquisa afeta o desempenho do banco de dados temporário, não é recomendável localizar outros bancos de dados nos servidores que hospedam o banco de dados de rastreamento ou os bancos de dados que podem ser afetados por este uso.

Em seguida, determine o número de bancos de dados de rastreamento que você vai ter com base no seu cenário. Uma diretriz geral é que o banco de dados de rastreamento tenha até 25 milhões de itens, considerando que não haja problemas de desempenho do rastreamento.

• Divida TotalCrawlDBSize por (número de bancos de dados de rastreamento). Esse é o CrawlDatabaseSize.

• Divida TotalCrawlDBLogSize por (número de bancos de dados de rastreamento). Esse é o CrawlDatabaseLogSize.

Para um servidor de banco de dados, ter vários bancos de dados de rastreamento no mesmo servidor significa que você precisa organizar o armazenamento de cada banco de dados de rastreamento, de acordo com os requisitos de IOPS na seção "Detalhes da escala", da seção "Sistema de rastreamento de pesquisa" já mencionadas neste artigo. Para a RAM, é recomendável ter no mínimo 16 GB nos servidores de banco de dados que estão dedicados aos bancos de dados de rastreamento.

5. Calcular o tamanho do banco de dados de administração de pesquisa

Determine o tamanho do banco de dados de administração de pesquisa (considerando a autenticação do Windows) da seguinte maneira:

• Multiplique número de itens no índice (em milhões) por 0,3. Esse é o SearchAdminDBSize.

• Para a RAM, multiplique SearchAdminDBSize por 0,33. Essa é a quantidade mínima de RAM recomendada para este banco de dados de administração de pesquisa.

Para um servidor de banco de dados, ter vários bancos de dados no mesmo servidor significa que você tem que organizar o armazenamento e a RAM de cada banco de dados, de acordo com os requisitos de IOPS e RAM na seção "Detalhes da escala", da seção "Sistema de consulta de pesquisa" já mencionadas neste artigo.

Opcional: calcular o tamanho do backup

Para determinar o espaço em disco necessário para fazer backup de um aplicativo de serviço de Pesquisa, faça o seguinte cálculo:

• TotalCrawlDBSize + TotalPropertyDBSize + TotalIndexSize + SearchAdminDBSize = tamanho básico do backup.

Esse tamanho básico do backup é um ponto de partida. Ele também pode ser afetado pelo seguinte:

• Tamanho do índice adicional incluído no TotalIndexSize para qualquer rastreamento que tenha ocorrido desde a última mesclagem mestra.

• Com o passar do tempo, o crescimento devido a itens, consultas e descritores de segurança adicionais.

Além disso, você pode querer manter vários backups de períodos diferentes e também reservar espaço para o próximo backup.

Exercício de dimensionamento

Usando os fatores de dimensionamento já mencionados, veja a seguir um exercício de dimensionamento para um farm de 100 milhões de itens que vai atender às consultas principalmente de conteúdo do SharePoint. Aplicando o cenário de farm grande, você considera o seguinte:

• Dez partições de índice lógicas são necessárias para acomodar os 100 milhões de itens.

• Para atender às consultas, são precisos 10 componentes de consulta ativos, um por partição de índice.

• A redundância de consulta é importante, portanto, você tem 10 componentes de consulta de failover, um por partição de índice (localizados em um servidor diferente do componente ativo).

Para determinar as necessidades de armazenamento e RAM, siga as etapas abaixo:

1. Em um farm de conteúdo do SharePoint com vários bancos de dados de conteúdo, adicione os bancos de dados de conteúdo que deseja rastrear para chegar a 20 terabytes.

2. Usando o coeficiente de índice acima, multiplique 20 terabytes por 0,035 (Coeficiente de Índice) para obter 716,8 GB. Esse é o TotalIndexSize. Caso tenha apenas uma partição, esse será o tamanho do índice inativo.

3. Divida TotalIndexSize pelo número de partições: 716,8 GB / 71,68 GB. Esse é o tamanho do índice necessário por componente de consulta (QueryComponentIndexSize), com uma partição de índice. O tamanho é o mesmo para os componentes de consulta ativos ou de failover.

4. Multiplique TotalIndexSize por 4, se pretende reparticionar; do contrário, multiplique por 3 para dar suporte às mesclagens mestras. 71,68 GB * 4 = 286,72 GB. Você deve ter 286,72 GB disponíveis no disco do servidor de consulta para oferecer suporte a um componente de consulta. Caso tenha dois componentes de consulta no mesmo servidor de aplicativos (como na topologia ativo/failover recomendada no cenário de farm grande), você deverá ter o seguinte layout de unidade de disco:

   1. Unidade do sistema operacional (tamanho padrão).

   2. Sistema de armazenamento extra 1: Componente de Consulta1_Compartilhamento (tamanho= no mínimo 300 GB), usado para o componente de consulta ativo da Partição de índice 1.

   3. Sistema de armazenamento extra 2: Componente de Consulta2_Compartilhamento (tamanho = no mínimo 300 GB), usado para o componente de consulta de failover (espelho) da Partição de índice 2.

Limites de software

A tabela a seguir mostra os limites de software impostos para oferecer suporte a uma experiência aceitável de pesquisa.

Objeto	Limite	Observações adicionais
Aplicativo de Serviço de Pesquisa do SharePoint	Máximo recomendado de 20 por farm. Máximo absoluto de um total de 256 aplicativos de serviço.	É possível implantar vários aplicativos de serviço de Pesquisa no mesmo farm, pois você pode atribuir componentes de pesquisa e bancos de dados a servidores separados.
Documentos indexados	Máximo geral recomendado de 10 milhões de itens por partição de índice e 100 milhões de itens por aplicativo de serviço de Pesquisa.	A pesquisa do SharePoint dá suporte a partições de índice, em que cada uma tem um subconjunto do índice de pesquisa inteiro. O máximo recomendado é de 10 milhões de itens em uma partição específica. O número máximo total de itens recomendado, incluindo pessoas, itens de lista, documentos e páginas da Web, é de 100 milhões.
Partições de índice	Máximo recomendado de 20 por aplicativo de serviço de Pesquisa	Esta partição de índice é um subconjunto lógico do índice do aplicativo de serviço de Pesquisa. O limite recomendado é de 20. O aumento do número de partições de índice reduz o número de itens na partição de índice, o que reduz a RAM e o espaço em disco necessários no servidor de consulta que hospeda o componente de consulta atribuído à partição de índice. No entanto, isso pode afetar a relevância, pois o número de itens na partição de índice é reduzido. O limite rígido de partições de índice é de 128.
Banco de dados de propriedades	O limite recomendado é de 10 por aplicativo de serviço de Pesquisa	O banco de dados de propriedades armazena os metadados de itens em cada partição de índice associada a ele. Uma partição de índice só pode ser associada a um repositório de propriedades. O limite recomendado é de 10 por aplicativo de serviço de Pesquisa, com um limite rígido de 255 (o mesmo que as partições de índice).
Bancos de dados de rastreamento	O limite é de 32 bancos de dados de rastreamento por aplicativo	O banco de dados de rastreamento armazena dados de rastreamento (incluindo tempo e status) sobre todos os itens que foram rastreados. O limite recomendado é de 25 milhões de itens por banco de dados de rastreamento, ou um total de quatro bancos de dados para um aplicativo de serviço de Pesquisa.
Componentes de rastreamento	O limite recomendado por aplicativo é um total de 16 componentes de rastreamento, com dois por banco de dados de rastreamento e dois por servidor, presumindo-se que o servidor tenha, pelo menos, oito processadores (núcleos).	O número total de componentes de rastreamento por servidor deve ser inferior a 128/(total de componentes de consulta) para minimizar a degradação de E/S de propagação. Se o limite recomendado for excedido, isso poderá não aumentar o desempenho de rastreamento. Na verdade, o desempenho de rastreamento poderá diminuir com base nos recursos disponíveis no servidor de rastreamento, banco de dados e host de conteúdo.
Componentes de consulta	O limite recomendado por aplicativo é de 128, com 64/(total de componentes de rastreamento) por servidor.	O número total de componentes de consulta é limitado pela capacidade dos componentes de rastreamento de copiar arquivos. O número máximo de componentes de consulta por servidor é limitado pela capacidade dos componentes de consulta de absorver arquivos propagados dos componentes de rastreamento.
Rastreamentos simultâneos	O limite recomendado é de 20 rastreamentos por aplicativo de serviço de Pesquisa	Este é o número de rastreamentos em andamento ao mesmo tempo. Os rastreamentos são tarefas de pesquisa extremamente caras que podem afetar a carga do banco de dados e de outros aplicativos. Se você exceder 20 rastreamentos simultâneos, poderá causar degradação na taxa de rastreamento geral.
Fontes de conteúdo	Limite recomendado de 50 fontes de conteúdo por aplicativo de Pesquisa.	O limite recomendado pode ser excedido até o limite rígido de 500 por aplicativo de serviço de Pesquisa. No entanto, devem ser usados menos endereços iniciais, e o limite de rastreamento simultâneo precisa ser seguido.
Endereços iniciais	Limite recomendado de 100 endereços iniciais por fonte de conteúdo.	O limite recomendado pode ser excedido até o limite rígido de 500 por fonte de conteúdo. No entanto, devem ser usadas menos fontes de conteúdo. A melhor abordagem quando há muitos endereços iniciais é colocá-los em uma página HTML como links e, em seguida, rastrear a página com o rastreador HTTP, seguindo os links.
Regras de rastreamento	Limite recomendado de 100 por aplicativo de serviço de Pesquisa	É possível exceder a recomendação; porém, a exibição das regras de rastreamento na administração de pesquisa será prejudicada.
Logs de rastreamento	Limite recomendado de 100 milhões por aplicativo	Esse é o número de entradas de log individuais no log de rastreamento. Ele seguirá o limite de documentos indexados.
Propriedades de metadados reconhecidas por item	O limite rígido é de 10.000.	Esse é o número de propriedades de metadados que, quando um item é rastreado, podem ser determinadas (e potencialmente mapeadas e usadas para consultas).
Propriedades rastreadas	500.000 por aplicativo de serviço de Pesquisa	Estas são propriedades descobertas durante um rastreamento.
Propriedades gerenciadas	100.000 por aplicativo de serviço de Pesquisa	Estas são propriedades utilizadas pelo sistema de pesquisa em consultas. Propriedades rastreadas são mapeadas para propriedades gerenciadas. É recomendável um máximo de 100 mapeamentos por propriedade gerenciada. Se esse limite for excedido, isso poderá diminuir a velocidade do rastreamento e o desempenho da consulta.
Escopos	Limite recomendado de 200 por site.	Esse é o limite recomendado por site. Se esse limite for excedido, isso poderá prejudicar a eficiência do rastreamento, além de afetar a latência do navegador do usuário final se os escopos forem adicionados ao grupo de exibição. Além disso, a exibição dos escopos na administração de pesquisa é prejudicada à medida que o número de escopos ultrapassa o limite recomendado.
Grupos de exibição	25 por site	Eles são utilizados para uma exibição agrupada de escopos por meio da interface do usuário. Se esse limite for excedido, a experiência do escopo de administração de pesquisa vai começar a ser prejudicada.
Regras de escopo	O limite recomendado é de 100 regras de escopo por escopo e um total de 600 por aplicativo de serviço de Pesquisa.	Se esse limite for excedido, vai prejudicar a atualização e atrasar os resultados potenciais das consultas com escopo.
Palavras-chave	Limite recomendado de 200 por conjunto de sites	O limite recomendado pode ser excedido até o limite máximo (imposto pelo ASP.NET) de 5.000 por conjunto de sites, com cinco Melhores Opções por palavra-chave. A exibição de palavras-chave na interface do usuário de administração de site será prejudicada. Para modificar o limite imposto pelo ASP.NET, edite os arquivos Web.config e Client.config (MaxItemsInObjectGraph).
Páginas autoritativas	Limite recomendado de uma página autoritativa de nível superior, e do menor número possível de páginas de segundo e terceiro nível, ao atingir a relevância desejada.	O limite rígido é de 200 por nível de relevância por aplicativo de serviço de Pesquisa, mas a adição de páginas pode não proporcionar a relevância desejada. Adicione o site principal ao primeiro nível de relevância. Adicione sites principais subsequentes como o segundo ou terceiro nível de relevância, um de cada vez, avaliando a relevância após cada adição para garantir que o efeito de relevância desejado seja obtido.
Alertas	Limite recomendado de 1.000.000 por aplicativo de serviço de Pesquisa	Esse é o limite testado.
Remoção dos resultados	100 URLS em uma operação	Esse é o número máximo recomendado de URLs que devem ser removidas do sistema em uma operação.

Otimizações

As seções a seguir abordam métodos para melhorar o desempenho do farm.

Vários fatores podem afetar o desempenho. Esses fatores incluem o número de usuários; o tipo, a complexidade e a frequência de operações de usuário; o número de postbacks em uma operação e o desempenho das conexões de dados. Cada um desses fatores pode ter um efeito significativo na taxa de transferência do farm. Considere cada um com cuidado na hora de planejar a implantação.

A capacidade e o desempenho de um sistema de pesquisa depende altamente de sua topologia. É possível dimensionar aumentando a capacidade dos computadores de servidor existentes ou adicionando servidores à topologia.

Otimizações no sistema de consulta de pesquisa

Em geral, as otimizações na consulta de pesquisa seguem um dos cenários abaixo:

• Os usuários estão reclamando da latência da consulta, portanto, tenho que diminuir essa latência.

• Estão ocorrendo muito mais solicitações de pesquisa do que o planejado, e o desempenho começou a ser prejudicado, portanto, tenho que aumentar a taxa de transferência da consulta.

O dimensionamento do subsistema de consulta sempre envolve a criação de mais componentes de consulta. Se você tem excesso de capacidade (RAM, E/S e CPU) em um servidor de consulta existente, poderá dimensionar criando mais componentes de consulta nesse servidor, aumentando a RAM, CPU ou E/S, caso chegar a um afunilamento. Do contrário, você poderá criar mais componentes de consulta (ou mover os componentes existentes) em um novo servidor para fazer o dimensionamento.

A seção a seguir mostra várias maneiras de adicionar recursos de consulta ao sistema de consulta de pesquisa.

Como reduzir a latência da consulta

Adicionando componentes de consulta para reduzir a latência

O gráfico a seguir ilustra o efeito da adição de componentes de consulta ativos a servidores diferentes sem alterar o tamanho do índice.

Adicione mais componentes de consulta ativos para manter a latência da consulta inferior a um segundo à medida que aumenta a carga de usuário no sistema (medida em consultas de usuário simultâneas).

Adicionando processadores de consultas (Serviço de Configurações do Site e Consulta) para reduzir a latência

O gráfico a seguir ilustra o efeito da adição de serviços de processadores de consultas ativos a servidores diferentes sem alterar nenhuma outra parte do sistema de consulta.

Inicie outras instâncias ativas do Serviço de Configurações do Site e Consulta em servidores diferentes para manter a latência da consulta inferior a um segundo à medida que aumenta a carga de usuário no sistema (medida em consultas de usuário simultâneas).

Dimensionar para aumentar a taxa de transferência da consulta

Adicionando componentes de consulta para aumentar a taxa de transferência da consulta

O gráfico a seguir ilustra o efeito da adição de componentes de consulta ativos a servidores diferentes sem alterar o tamanho do índice.

Adicione mais componentes de consulta ativos para aumentar a taxa de transferência da consulta à medida que aumenta a carga de usuário no sistema (medida em consultas de usuário simultâneas).

Adicionando processadores de consultas (Serviço de Configurações do Site e Consulta) para aumentar a taxa de transferência da consulta

O gráfico a seguir ilustra o efeito da adição de serviços de processadores de consultas ativos a servidores diferentes sem alterar nenhuma outra parte do sistema de consulta.

Consideração: inicie outras instâncias ativas do Serviço de Configurações do Site e Consulta em servidores diferentes para aumentar a taxa de transferência à medida que aumenta a carga de usuário no sistema (medida em consultas de usuário simultâneas).

Otimizações no sistema de rastreamento de pesquisa

Em geral, você realiza otimizações no rastreamento de pesquisa quando os usuários reclamam dos resultados que deveriam aparecer, mas não aparecem, ou que aparecem, mas estão obsoletos.

Quando você tenta rastrear o endereço inicial da fonte de conteúdo dentro das metas de atualização, pode encontrar os seguintes problemas de desempenho do rastreamento:

• A taxa de rastreamento está baixa devido aos afunilamentos de IOPS no subsistema de rastreamento de pesquisa.

• A taxa de rastreamento está baixa devido à falta de threads de CPU no subsistema de rastreamento de pesquisa.

• A taxa de rastreamento está baixa devido à lenta capacidade de resposta do repositório.

Cada um desses problemas pressupõe que a taxa de rastreamento esteja baixa. Consulte Use search administration reports (SharePoint Server 2010) (considerando as fases do ciclo de vida do software) para estabelecer uma linha de base para a taxa de rastreamento comum para o sistema com o passar do tempo. Quando essa linha de base regredir, as subseções a seguir vão mostrar as várias maneiras de resolver esses problemas de desempenho do rastreamento.

Afunilamento de IOPS do rastreamento

Após determinar um banco de dados de rastreamento ou de propriedades como um afunilamento, você terá que dimensionar o sistema de rastreamento para resolver essa questão seguindo as resoluções apropriadas. A tabela abaixo mostra como a adição de IOPS (outro banco de dados de rastreamento) gera uma melhor taxa de rastreamento (até a adição de mais componentes o tornar novamente um afunilamento).

Consideração: verifique sempre se o banco de dados de rastreamento não é um afunilamento. Se os IOPS do banco de dados de rastreamento já estiverem afunilados, não vai ser útil adicionar componentes de rastreamento nem reduzir o número de threads.

Topologia (componente de rastreamento/ banco de dados de rastreamento)	Percentual da CPU	RAM: % de taxa de acertos do cache do buffer	Latência de leitura	Latência de gravação	Velocidade do rastreamento (docs/s)
2/1 banco de dados	19,5	99,6	142 ms	73 ms	50
4/2 banco de dados	8,502	99,55	45 ms	75 ms	~75
6/2 banco de dados	22	99,92	55 ms	1050 ms	~75

Afunilamento do thread da CPU de rastreamento

Caso tenha um grande número de hosts e nenhum outro afunilamento de rastreamento, dimensione o sistema de rastreamento seguindo as resoluções apropriadas. O rastreador pode acomodar um máximo de 256 threads por aplicativo de serviço de Pesquisa. É recomendável ter um processador de núcleo quádruplo para aproveitar todo o benefício do número máximo de threads. Quando já estiver determinado de forma conclusiva que o repositório está atendendo aos dados rápido o suficiente (consulte a seção "Afunilamento do rastreamento no repositório" mais adiante neste artigo), a taxa de transferência do rastreamento poderá ser aumentada solicitando os dados mais rapidamente do repositório através do aumento do número de threads do rastreador. Veja a seguir três maneiras de fazer isso:

1. Altere o nível de desempenho do indexador para Parcialmente Reduzido ou Máximo usando o seguinte cmdlet do Windows PowerShell:

   • Get-SPEnterpriseSearchService | Set-SPEnterpriseSearchService –PerformanceLevel “Maximum”

     O valor Máximo é usado quando você utiliza um processador com menos de quatro núcleos.

2. Use as regras de impacto do rastreador para aumentar o número de threads por host. Leve em consideração de que há suporte para um máximo de 256 threads, e a atribuição de um grande número de threads a poucos hosts pode resultar na recuperação mais lenta dos dados de outros repositórios.

3. Se houver um grande número de hosts, a solução ideal será adicionar outro componente de rastreamento à um indexador separado para rastrear os hosts que deverão ser indexados mais rapidamente.

A maneira ideal de aumentar diretamente a taxa de transferência de rastreamento é adicionar outro indexador, se o subsistema de pesquisa não estiver afunilado nos IOPS e o repositório estiver fornecendo conteúdo rapidamente.

Afunilamento do rastreamento no repositório

Algumas vezes, quando um aplicativo Web do SharePoint com vários conjuntos de sites aninhados ou compartilhamentos de arquivos remotos está sendo rastreado, o rastreador de pesquisa pode ser afunilado no repositório. É possível identificar um afunilamento no repositório quando ocorrem as duas condições a seguir:

• A utilização da CPU está baixa (menos de 20%) nos servidores de rastreamento.

• Há um grande número de threads (quase todos no pior caso) em espera na rede.

  O afunilamento é identificado pelo contador de desempenho Gatherer do OSS Search/Threads Acessando a Rede.

Essa situação mostra que os threads estão bloqueados enquanto aguardam pelos dados do repositório. Em um ambiente com várias fontes de conteúdo, pode ser útil identificar o host que tem a capacidade de resposta lenta pausando todos os outros rastreamentos e, na sequência, realizando um rastreamento por meio da fonte de conteúdo que tem o host suspeito como um de seu endereço inicial.

Quando o host problemático for identificado, você vai precisar investigar a causa do tempo de resposta lento. Para o conteúdo do SharePoint em particular, consulte o artigo Capacity management and sizing for SharePoint Server 2010.

É possível melhorar significativamente a taxa de transferência do rastreamento ajustando o desempenho dos repositórios de dados rastreados.

Solucionando problemas de desempenho e escala

Saber qual é a carga do farm é crucial para solucionar problemas de desempenho. A seção a seguir utiliza os dados de um farm online com 60 milhões de itens para mostrar as várias métricas do sistema em diferentes fases do ciclo de vida da pesquisa.

Exemplos de desempenho durante o ciclo de vida da pesquisa

Métrica	Aquisição do índice	Manutenção do índice	Limpeza do índice
CPU do SQL Server (em %) Banco de dados de propriedades/banco de dados de rastreamento	14,8/19,13	35/55	11/63
Expectativa de vida da página do SQL Server Banco de dados de propriedades/banco de dados de rastreamento	60.548/5.913	83.366/5.373	33.927/2.806
Média de gravação em disco do SQL Server em segundos Banco de dados de propriedades/banco de dados de rastreamento	9 ms/48 ms MÁX: 466 ms/1.277 ms	12 ms/28 ms	20 ms/49 ms MÁX: 253 ms/1156 ms
Média de leitura de disco do SQL Server em segundos Banco de dados de propriedades/banco de dados de rastreamento	8 ms/43 ms MÁX: 1.362 ms/2.688 ms	11 ms/24 ms	24 ms/29 ms MÁX: 2 039 ms/2 142 ms
CPU do Rastreador (em %) Servidor de indexação 1 (2 componentes de rastreamento)/servidor de indexação 2 (2 componentes de rastreamento)	18/11	25,76/21,62	8,34/7,49 Máximo de picos a 99%
Gravações de Disco/s Servidor de indexação 1 (2 componentes de rastreamento)/servidor de indexação 2 (2 componentes de rastreamento)	64,32/42,35	93,31/92,45	99,81/110,98
Leituras de Disco/s Servidor de indexação 1 (2 componentes de rastreamento)/servidor de indexação 2 (2 componentes de rastreamento)	0,23/0,20	4,92/2,03	1,38/1,97
Média de gravação em disco em segundos Servidor de indexação 1 (2 componentes de rastreamento)/servidor de indexação 2 (2 componentes de rastreamento)	11 ms/11 ms	1 ms/2 ms	5 ms/4 ms MÁX: 1.962 ms/3.235 ms
Média de leitura de disco em segundos Servidor de indexação 1 (2 componentes de rastreamento)/servidor de indexação 2 (2 componentes de rastreamento)	1 ms/2 ms	12 ms/11 ms	10 ms/16 ms MÁX: 2.366 ms/5.206 ms

Solucionando problemas de desempenho da consulta

A pesquisa do SharePoint tem um pipeline de consulta instrumentado e relatórios de administração associados que podem ajudá-lo a solucionar problemas de desempenho da consulta baseados no servidor. Para mais informações, consulte Use search administration reports (SharePoint Server 2010). Esta seção mostra os relatórios e os utiliza para um melhor entendimento de como solucionar problemas no servidor. Além disso, esta seção inclui as ferramentas e diretrizes disponíveis para ajudar a resolver os problemas de desempenho baseados no cliente (navegador).

Problemas de consulta baseados no servidor

É possível segregar os problemas de consulta baseados no servidor nos dois níveis a seguir:

• Problemas de desempenho no front-end de pesquisa

• Problemas de desempenho no back-end de pesquisa

As duas subseções a seguir apresentam os detalhes para a solução de problemas de cada um. Observe que estas são diretrizes de alto nível.

Problemas de desempenho no front-end

A primeira etapa da solução de problemas de desempenho no front-end deve ser examinar o relatório de administração de pesquisa Latência Geral da Consulta. Veja a seguir um exemplo de relatório:

Nesse relatório, o desempenho do front-end está representado pela seguinte série de dados:

• Renderização de Servidor: esse valor representa, no minuto especificado, o tempo médio gasto por consulta nas várias Web Parts de Pesquisa no servidor Web front-end.

• Modelo de Objeto: esse valor representa, no minuto especificado, o tempo médio gasto na comunicação entre o servidor Web front-end e o back-end de pesquisa.

Solucionando problemas de renderização do servidor

Os problemas de renderização do servidor podem ser afetados por qualquer coisa que ocorra no servidor Web front-end que está atendendo à página de resultados da pesquisa. Em geral, você deseja saber quanto tempo está sendo gasto na recuperação das várias Web Parts para saber onde a latência extra está sendo adicionada. Habilite o Painel do Desenvolvedor na página de resultados da pesquisa para ver o relatório detalhado da latência. Veja a seguir alguns dos problemas comuns manifestados como excesso de latência na renderização do sistema:

• Problemas de plataforma, como:

  • Pesquisas lentas do Active Directory

  • Lentidão no SQL Server

  • Solicitações lentas feitas ao Aplicativo de Perfil de Usuário nas consultas por pessoas no SharePoint Server 2010 ou em todas as consultas no FAST Search Server 2010 for SharePoint

  • Solicitações lentas de busca pelas preferências do usuário

  • Chamadas lentas para obter o token do usuário do serviço de token de segurança

• Problemas de code-behind, como páginas de resultados da pesquisa modificadas (por exemplo, results.aspx e peopleresults.aspx) que passaram por check-in, mas não foram publicadas.

Solucionando problemas do modelo de objeto

Os problemas do modelo de objeto podem ser afetados pelo seguinte:

• Problemas com a camada do Windows Communication Foundation (WCF), como:

  • Tempos limite e threadabortexception nas chamadas do WCF na implantação.

  • Comunicação lenta entre o servidor Web front-end e o servidor de aplicativos. Isso pode ocorrer por causa de problemas com o IPsec ou conexões de rede lentas.

• Problemas com a comunicação entre os farms de conteúdo e serviço (se configurados).

Problemas de desempenho no back-end

A primeira etapa da solução de problemas de desempenho no back-end deve ser examinar o relatório de administração de pesquisa Latência da Consulta do Back-end do SharePoint. Veja a seguir um exemplo de relatório:

Nesse relatório, o desempenho do back-end está representado pela seguinte série de dados (cada uma é a média de tempo gasto por consulta, no minuto especificado), agrupada por componente funcional:

• Componente de Consulta:

  • Consulta de Texto Completo: o tempo médio gasto na consulta de resultados no índice de texto completo.

• Banco de dados de propriedades:

  • Recuperação de Vários Resultados: o tempo médio gasto na recuperação de metadados de documentos, como título ou autor, que devem aparecer nos resultados da consulta.

  • Consulta do Repositório de Propriedades: o tempo médio gasto na pesquisa de consultas baseadas em propriedades no banco de dados de propriedades.

• Banco de dados de Administração de Pesquisa:

  • Melhores Opções: o tempo médio gasto para determinar se as Melhores Opções estarão disponíveis para os termos da consulta.

  • Resultados de Alta Confiabilidade: o tempo médio gasto na recuperação dos resultados de alta confiabilidade para as consultas.

• Processador de Consultas:

  • Filtragem de Segurança: o tempo médio gasto na remoção de itens aos quais o usuário não tem acesso.

  • Remoção de Duplicatas: o tempo médio gasto na remoção de duplicatas.

  • Preenchimento de Resultados: o tempo médio gasto na criação da tabela da memória que vai ser transmitida ao modelo de objeto.

Solucionando problemas de desempenho do componente de consulta

Os componentes de consulta fazem uso intensivo de recursos, principalmente quando o componente é ativo, ou seja, estão respondendo às solicitações de consulta. A solução de problemas de desempenho do componente de consulta é uma das áreas de pesquisa mais complicadas. Veja a seguir as áreas gerais que devem ser consideradas:

• O evento de componente de consulta com uso mais intensivo de recursos é a mesclagem mestra, em que os índices de sombra são mesclados com o índice mestre. Esse evento ocorre independentemente para cada componente de consulta. Um exemplo do efeito pode ser visto no relatório Latência da Consulta do Back-end do SharePoint, mencionado anteriormente neste artigo, nos horários anteriores às 13:30. Se esse evento estiver afetando a latência da consulta, será possível definir períodos de blecaute nos quais uma mesclagem mestra não será permitida, a menos que a porcentagem da alteração exceda o limite definido.

• Valores altos sustentados no ambiente indicam que você pode fazer o seguinte:

  • Examine o tamanho do índice de cada componente no servidor. Verifique se há RAM suficiente no servidor para permitir cerca de 33% da soma dos tamanhos dos índices a serem armazenados em cache.

  • Examine o canal de E/S do componente de consulta no servidor. Verifique se não há nenhum afunilamento de E/S.

  • Se a E/S e a RAM não forem a causa do problema de desempenho, reparticione os componentes de consulta (adicionando partições de índice), dimensionando novos servidores com componentes de consulta adicionais.

Solucionando problemas no banco de dados de propriedades

Examine a integridade do SQL Server utilizando os conceitos em Planejamento e configuração de armazenamento e capacidade do SQL Server (SharePoint Server 2010). Se estiver executando consultas personalizadas, talvez tenha que consultar as dicas para orientá-lo no plano de consulta correto.

Solucionando problemas no banco de dados de administração de pesquisa

Examine a integridade do SQL Server utilizando os conceitos em Planejamento e configuração de armazenamento e capacidade do SQL Server (SharePoint Server 2010).

Solucionando problemas de desempenho do processador de consultas

A solução de problemas do processador de consultas depende de qual das seguintes áreas do processador de consultas está afetando a latência da consulta:

• Filtragem de segurança:

  • Para declarações do Windows, examine a conexão do Active Directory do servidor que está hospedando o processador de consultas.

  • Para todos os casos, o tamanho do cache utilizado pelo processador de consultas poderá ser aumentado se houver uma correlação entre um grande número de viagens de ida e volta do SQL Server (determinado pelo SQL Server Profiler). Mais de 25% das consultas não devem precisar de uma chamada do SQL Server para recuperar os descritores de segurança do banco de dados de administração de pesquisa. Se precisarem, ajuste o tamanho do cache do processador de consultas.

• Remoção de duplicatas:

  • Observe se você está rastreando o mesmo conteúdo em vários locais. Desabilite a detecção de duplicatas no Centro de Pesquisa.

• Recuperação de vários resultados:

  • Examine a integridade do SQL Server utilizando os conceitos em Planejamento e configuração de armazenamento e capacidade do SQL Server (SharePoint Server 2010).

Problemas de consulta baseados no navegador

Os usuários podem ficar satisfeitos ou irritados com a velocidade dos resultados da pesquisa. O tempo de carregamento da página é um dos fatores importantes da satisfação dos usuários com a experiência de pesquisa. O foco maior em relação ao tempo de carregamento da página está no servidor, especificamente no tempo que leva para o servidor retornar os resultados. A renderização do lado do cliente, porém, pode ser uma parte significativa do tempo de carregamento da página e é importante levar em consideração.

A experiência de pesquisa do usuário foi desenvolvida para fornecer respostas em menos de um segundo como o tempo total de carregamento da página. Desse tempo, a renderização do cliente em geral leva menos de 280 milissegundos, dependendo do navegador e da medida da renderização. Essa experiência agrada os usuários com resultados muito rápidos.

As personalizações feitas na experiência dos resultados podem facilmente prejudicar o desempenho da renderização. Os administradores e desenvolvedores de pesquisa devem estar atentos à medida do tempo de renderização após cada modificação para garantir que o desempenho não sofra nenhuma redução significativa. Cada adição feita à página, desde uma nova Web Part até um novo estilo de Folha de Estilos em Cascata, aumenta o tempo da renderização no navegador e atrasa os resultados dos seus usuários. O tempo de atraso, porém, pode variar bastante, dependendo se você segue ou não as práticas recomendadas na hora de personalizar a página.

Veja a seguir algumas diretrizes gerais:

• Personalizações básicas de identidade visual e estilo feitas à página não devem acrescentar mais de 25 ms aproximadamente ao tempo de carregamento da página. Marque o tempo de carregamento da página antes e depois de implementar as personalizações para observar a alteração.

• Os usuários normalmente observam uma alteração (se está mais rápido ou mais lento) em um incremento de 20%. Lembre-se disso quando fizer alterações. Vinte por cento do tempo de renderização padrão é apenas 50 ms. (Fonte: Designing and Engineering Time)

• Folhas de estilos em cascata e JScript são as causas mais comuns e maiores de desempenho com alta renderização. Se você personalizou folhas de estilos em cascata e JScript, restrinja seu uso a um arquivo cada.

• O JScript pode ser carregado sob demanda após a renderização da página para proporcionar resultados visíveis ao usuário mais rapidamente. Os detalhes sobre como fazer isso estão mostrados no artigo que trata das considerações de desempenho.

• Quanto mais personalizações forem adicionadas à página, mais lento será o seu carregamento. Considere se a funcionalidade e o estilo adicionados compensam o atraso extra dos resultados para os usuários.

Além dessas diretrizes, há ótimas informações na Internet sobre como reduzir o tempo de carregamento da página e sobre o efeito de páginas lentas na experiência do usuário.

Solucionando problemas de desempenho do rastreamento

A pesquisa do SharePoint pode sofrer afunilamentos no subsistema de rastreamento à medida que o sistema passa pelas fases de aquisição, manutenção e exclusão do índice. Para solucionar problemas de desempenho do rastreamento de maneira eficaz, use os Relatórios de Monitoramento da Integridade da Pesquisa na seção "Afunilamentos comuns e suas causas" mais adiante neste artigo para isolar os problemas de rastreamento.

Solucionando problemas durante a fase de aquisição do índice

O primeiro local para identificar problemas de rastreamento é o relatório de integridade Taxa de Rastreamento por Fonte de Conteúdo. Conforme mostrado mais adiante neste artigo, o relatório apresenta uma visão geral da taxa de rastreamento de cada uma das fontes de conteúdo no sistema. Em geral, a taxa de rastreamento deve ser superior a 15 documentos/s para uma fonte de conteúdo de pessoas, e superior a 35 documentos/s para todos os outros tipos de fontes de conteúdo.

Quando é identificada uma fonte de conteúdo com taxa de rastreamento inferior a ideal, é recomendável executar as seguintes etapas:

1. Pause todos os outros rastreamentos, exceto a fonte de conteúdo que está sendo investigada. A taxa de rastreamento sobe além da meta especificada de 15 a 35 documentos/s?

2. Se a etapa anterior não ajudar, verifique se o repositório que está sendo rastreado está respondendo corretamente e não é a causa da lentidão. Consulte a seção "Afunilamento do rastreamento no repositório", já mencionada neste artigo.

3. Se o repositório não for o afunilamento, identifique o afunilamento no servidor de rastreamento ou no servidor de banco de dados e faça as otimizações necessárias. Você encontra orientação nas seções "Afunilamento de IOPS do rastreamento" e "Afunilamento do thread da CPU de rastreamento", já mencionadas neste artigo.

Solucionando problemas durante a fase de manutenção do índice

A meta principal na fase de manutenção do índice é mantê-lo o mais atualizado possível. Veja a seguir dois dos principais indicadores:

• Atualização do índice: Os rastreamentos estão sendo concluídos dentro do tempo orçado e de acordo com as diretrizes de TI em relação à atualização do índice?

• Velocidade do rastreamento incremental: Se a meta de atualização do índice não for atendida, verifique se as velocidades do rastreamento incremental são de 10 documentos/s para fontes de conteúdo de pessoas e de 35 documentos/s para todas as outras fontes de conteúdo. Se as velocidades do rastreamento incremental não forem ideais, realize uma análise de afunilamento no repositório rastreado e no subsistema de rastreamento, conforme descrito anteriormente.

Afunilamentos comuns e suas causas

Durante o teste de desempenho, vários afunilamentos comuns diferentes foram revelados. Um afunilamento é uma condição em que a capacidade de um elemento específico de um farm é alcançada. Isso causa uma estabilização ou uma diminuição na produtividade do farm.

A tabela a seguir lista alguns afunilamentos comuns e descreve suas causas e possíveis soluções.

Afunilamento	Sintoma (contador de desempenho)	Solução
RAM do Banco de Dados	Banco de dados de propriedades, Banco de dados de administração de pesquisa exibem: Gerenciador de buffer do SQL Server/ expectativa de vida da página < 300(s) (deve ser > 1000 (s)) Gerenciador de buffer do SQL Server/ taxa de acertos do cache do buffer < 96% (deve ser > 98%)	Adicione memória ao servidor de banco de dados. Desfragmente o banco de dados de propriedades, se a regra de desfragmentação semanal tiver sido desabilitada. Verifique se você está usando a edição do SQL Server 2008 Enterprise para habilitar a compactação de página. Mova o banco de dados para um servidor separado e adicione vários bancos de dados de propriedades, se forem necessários.
IOPS do servidor de banco de dados	Um banco de dados de propriedades ou de rastreamento exibe o seguinte: Média de leitura de disco em segundos e Média de gravação em disco em segundos ~50 ms ou > 50 ms	Verifique se o servidor de banco de dados tem RAM suficiente para manter 33% das tabelas críticas (MSSDocSDIDs + MSSDocProps + MSSDocresults) no cache. Aumente o número dedicado de IOPS no banco de dados fazendo o seguinte: Use matrizes de armazenamento diferentes Otimize a configuração de armazenamento; por exemplo, adicionando fusos (unidades de disco) à matriz de armazenamento. Execute a Pesquisa do Analisador de Integridade do SharePoint - Um ou mais bancos de dados de propriedades têm regra de índices fragmentados, se tiver sido desabilitada. Execute a Pesquisa do Analisador de Integridade do SharePoint - Um ou mais bancos de dados de rastreamento têm regra de índices fragmentados. Verifique se você está usando a edição do SQL Server 2008 Enterprise para habilitar a compactação de página. Mova o banco de dados para um servidor separado, adicionando vários bancos de dados de propriedades ou de rastreamento, ou ambos, se forem necessários.
IOPS do componente de consulta	O disco lógico usado para um índice do componente de consulta exibe o seguinte: Média de leitura de disco em segundos e Média de gravação em disco em segundos ~30 ms ou > 30 ms por um período de tempo sustentado (ou seja, grande parte do dia; não apenas durante uma mesclagem do índice).	Verifique se cada servidor de aplicativos tem RAM suficiente para manter 33% do índice de cada componente de consulta ativo (nesse servidor) no cache (cache do sistema operacional). Aumente o número dedicado de IOPS da unidade que é usada para o índice do componente de consulta fazendo o seguinte: Use matrizes de armazenamento diferentes para componentes diferentes. Otimize a configuração de armazenamento; por exemplo, adicionando fusos (unidades de disco) à matriz de armazenamento.

Sobre o autor

Brion Stone é gerente sênior de programa para a Pesquisa do SharePoint Server na Microsoft.