Planejar arquitetura de pesquisa corporativa no SharePoint Server
APLICA-SE A:
2013 2019 Subscription Edition 
SharePoint no Microsoft 365
Antes de configurar sua arquitetura de pesquisa de empresa, existem alguns itens que requerem um planejamento atento. Passo a passo, ajudaremos você a planejar uma arquitetura de pesquisa empresarial pequena, média, grande ou extra de grande tamanho.
Você está familiarizado com os componentes do sistema de pesquisa no SharePoint Server e como eles interagem? Ao ler Visão geral da arquitetura de pesquisa no SharePoint Server e Arquiteturas de pesquisa do SharePoint Server 2016 (ou Arquiteturas de pesquisa do SharePoint Server 2013) antes de começar, você se familiarizará com a arquitetura de pesquisa, os componentes de pesquisa, os bancos de dados de pesquisa e a topologia de pesquisa. Ao planejar uma arquitetura de pesquisa, veja algumas sugestões sobre o que considerar:
Etapa 2: Qual arquitetura de pesquisa de tamanho para quanto conteúdo?
Etapa 4: Como verificar se minha arquitetura de pesquisa está tendo um bom desempenho?
Etapa 1: Quanto conteúdo tenho?
O volume de conteúdo que você possui em seu índice de pesquisa afeta os recursos de que você precisa para hospedar o farm. Formule aproximadamente o número de itens que você planeja tornar pesquisáveis. Eis alguns exemplos de itens: documentos, páginas da Web, entradas de listas do SharePoint, além de imagens. Lembre-se de que cada entrada em uma lista do SharePoint é contada como um item.
Depois de estabelecer um número, multiplique-o pelo que você acredita que seja o crescimento esperado desse conteúdo ao longo dos próximos 12 meses.
Por exemplo, você está começando com 12.000 itens indexados, e espera que o volume desse conteúdo triplique nos próximos 12 meses. Você deverá planejar para 36.000 itens pesquisáveis.
Etapa 2: Qual arquitetura de pesquisa de tamanho para quanto conteúdo?
Nem sempre é fácil avaliar o quanto grande ou pequena deve ser sua arquitetura de pesquisa. O tamanho da arquitetura de pesquisa depende de volume do conteúdo, taxa de rastreamento, taxa de transferência de consulta e nível de alta disponibilidade requerido. Há arquiteturas de pesquisa de exemplo que aconselhamos usar como base para planejar seu próprio farm. A amostra de arquitetura de pesquisa escolhida depende de quanto conteúdo precisa ser pesquisável:
| Volume de conteúdo (SharePoint 2016) | Amostra de arquitetura de pesquisa | Volume de conteúdo (SharePoint 2013) |
|---|---|---|
| 0 a 20 milhões de itens | Farm pequeno de pesquisa | 0-10 milhões de itens |
| 0 a 80 milhões de itens | Farm médio de pesquisa | 0 a 40 milhões de itens |
| 0 a 200 milhões de itens | Farm grande de pesquisa | 0 a 100 milhões de itens |
| 0 a 500 milhões de itens | Farm de pesquisa extra grande | Sem suporte |
Embora essas arquiteturas de pesquisa de exemplo usem máquinas virtuais, você pode usar servidores físicos e máquinas virtuais de acordo com a estratégia da solução geral do SharePoint Server de sua arquitetura de pesquisa.
Farm pequeno de pesquisa
Estimamos que essa arquitetura de pesquisa pode rastrear 50 documentos por segundo e servir na ordem de 10 consultas por segundo. Se você tiver até 20 milhões de itens em um farm do SharePoint Server 2016, o pequeno farm de pesquisa provavelmente será o farm mais adequado para você. Com uma taxa de rastreamento de 50 documentos por segundo, a pesquisa leva 110 horas para rastrear 20 milhões de itens no primeiro rastreamento completo.
Farm médio de pesquisa
Estimamos que essa arquitetura de pesquisa pode rastrear 100 documentos por segundo e servir na ordem de 10 consultas por segundo. Se você tiver entre 20 e 80 milhões de itens em um farm do SharePoint Server 2016, o farm de pesquisa média provavelmente será o farm mais adequado para você. Com uma taxa de rastreamento de 200 documentos por segundo, a pesquisa leva 280 horas para rastrear 80 milhões de itens no primeiro rastreamento completo.
Farm grande de pesquisa
Estimamos que essa arquitetura de pesquisa possa rastrear 200 documentos por segundo e servir na ordem de 10 consultas por segundo. Se você tiver entre 80 e 200 milhões de itens em um farm do SharePoint Server 2016, o grande farm de pesquisa provavelmente será o farm mais adequado para você. Com uma taxa de rastreamento de 200 documentos por segundo, a pesquisa leva 280 horas para rastrear 200 milhões de itens no primeiro rastreamento completo.
Farm de pesquisa extra grande
A Microsoft testou essa arquitetura de pesquisa e mediu que ela pode rastrear de 300 a 500 documentos por segundo e servir na ordem de 10 consultas por segundo. Somente o SharePoint Server 2016 dá suporte a essa arquitetura de pesquisa de tamanho. Se você tiver até 500 milhões de itens, um farm semelhante ao farm de pesquisa extra grande é um bom ponto de partida. Com uma taxa de rastreamento de 500 documentos por segundo, leva cerca de 300 horas para rastrear 500 milhões de itens no primeiro rastreamento completo.
A criação de um farm de pesquisa desse tamanho exige que você planeje e ajuste cuidadosamente o farm para obter o desempenho desejado. Você pode achar vantajoso buscar orientações de especialistas. Também é importante planejar como fazer backup e restaurar um farm de pesquisa desse tamanho e como recuperar o farm se o data center tiver uma grande interrupção. Recomendamos que você pratique backup, restauração e recuperação.
Etapa 3: De quais requisitos de hardware devo estar ciente?
Agora que você determinou o volume de seu conteúdo e escolheu uma amostra de arquitetura de pesquisa, a primeira etapa é planejar o hardware necessário, como descrito nesta seção:
Escolher executar os servidores fisicamente ou virtualmente
Se você estiver usando uma das arquiteturas que estimamos para você, você executará sua arquitetura de pesquisa em máquinas virtuais. Note também que embora um ambiente virtual seja mais fácil de gerenciar, o nível de seu desempenho pode, algumas vezes, ser um pouco inferior que de um ambiente físico. Um servidor físico pode hospedar mais componentes de pesquisa no mesmo servidor que um servidor virtual. Você encontrará uma orientação útil em Overview of farm virtualization and architectures for SharePoint 2013.
Também é possível executar sua arquitetura de pesquisa em servidores físicos. Nos exemplos de arquitetura de farm, simplesmente mova os componentes de pesquisa das máquinas virtuais para o servidor host e remova as máquinas virtuais. Cada servidor físico pode hospedar até quatro componentes de índice, mas apenas um de cada tipo dos outros componentes de pesquisa. Se você, por exemplo, alterar a arquitetura de pesquisa de exemplo médio para usar servidores físicos, descobrirá que tem dois componentes de processamento de conteúdo no Host E. A solução é tirar um dos componentes de processamento de conteúdo. Isso funciona porque o rastreamento, o processamento de conteúdo e o processamento de análise dependem da quantidade de recursos disponíveis, não do número de componentes de processamento de conteúdo.
Escolher recursos de hardware para os servidores de host
Cada componente de pesquisa e banco de dados de pesquisa requer uma quantidade mínima de recursos de hardware do servidor de host para ser bem executado. Porém, quanto mais recursos de hardware você tiver, melhor será o desempenho da arquitetura de pesquisa. Portanto, é uma boa ideia ter mais do que a quantidade mínima de recursos de hardware. Os recursos que cada componente de pesquisa requer depende da carga de trabalho, em grande parte determinada pela taxa de rastreamento, taxa de consulta e número de itens indexados.
Por exemplo, ao hospedar máquinas virtuais no Windows Server 2008 R2 Service Pack 1 (SP1), você não pode usar mais de quatro núcleos da CPU por máquina virtual. Com o Windows Server 2012 ou mais recente, você usa oito ou mais núcleos da CPU por máquina virtual. Então, pode expandir com mais núcleos da CPU para cada máquina virtual, ao invés de aumentar com mais máquinas virtuais. Configure os servidores ou as máquinas virtuais que hospedam os mesmos componentes de pesquisa com os mesmos recursos de hardware. Usaremos o componente de índice como um exemplo. Quando você hospeda partições do índice nas máquinas virtuais, a máquina virtual com o desempenho mais fraco determina o desempenho da arquitetura de pesquisa geral.
Armazenamento geral
Verifique se cada servidor host tem espaço em disco suficiente para a instalação base do sistema operacional Windows Server e para os arquivos do programa do SharePoint Server. O servidor de host também precisa de espaço livre no disco rígido para fazer diagnósticos, como log, depuração e criação de despejos da memória para as operações diárias e para o arquivo de página. Normalmente, 80 GB de espaço em disco são suficientes para o sistema operacional Windows Server e para os arquivos do programa do SharePoint Server.
Adicione armazenamento para o espaço de log do SQL para cada servidor do banco de dados. Se você não definir o servidor do banco de dados para fazer backup dos bancos de dados com frequência, o espaço de log do SQL usará muito armazenamento. Para obter mais informações sobre como planejar bancos de dados SQL, consulte Armazenamento e SQL Server planejamento e configuração de capacidade (SharePoint Server) .
O armazenamento mínimo que o banco de dados de relatórios da análise requer pode variar. Isso ocorre porque a quantidade de armazenamento depende de como os usuários interagem com o SharePoint Server. Quando os usuários interagem com frequência, em geral há mais eventos a armazenar. Verifique a quantidade de armazenamento que sua arquitetura de pesquisa atual usa para o banco de dados de análise e atribua pelo menos essa quantidade para sua topologia reconstruída.
Recursos mínimos de hardware para o farm pequeno de pesquisa
Esta tabela mostra a quantidade mínima de recursos de hardware que cada servidor de aplicativos e de bancos de dados precisa.
| Servidor | No host | Armazenamento | RAM | Processador1 | Largura de banda da rede |
|---|---|---|---|---|---|
| O servidor do aplicativo que tem processamento de consulta e componentes de índice. | A, B | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8x núcleos de CPU2,3 | 1 Gbps |
| O servidor do aplicativo que tem rastreamento, administração da pesquisa, análise e componentes de processamento do conteúdo. | A, B | 200 GB | 8 GB | 4 núcleos de CPU de 1,8 GHz | 1 Gbps |
| O servidor do banco de dados que tem todos os bancos de dados de pesquisa. | C, D | 100 GB | 16 GB | 4 núcleos de CPU de 1,8 GHz | 1 Gbps |
1O número de núcleos da CPU é especificado aqui, mas não o número de threads da CPU.
2 Com o SharePoint Server 2013, a quantidade mínima de recursos necessária é de 500 GB de armazenamento, 16 GB de RAM e quatro núcleos de CPU.
3 Com o SharePoint Server 2016, você também pode usar 250 GB de armazenamento, 16 GB de RAM e quatro núcleos de CPU, mas cada componente de índice só pode conter 10 milhões de itens e o farm de pesquisa só dá suporte ao mesmo volume de conteúdo que um farm de pesquisa do SharePoint Server 2013.
Recursos mínimos de hardware para o farm médio de pesquisa
Esta tabela mostra a quantidade mínima de recursos de hardware que cada servidor de aplicativos e de bancos de dados precisa.
| Servidor | No host | Armazenamento | RAM | Processador1 | Largura de banda da rede |
|---|---|---|---|---|---|
| O servidor do aplicativo que tem processamento de consulta e componentes de índice. | A, B, C, D | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8x núcleos de CPU2,3 | 1 Gbps |
| O servidor do aplicativo que tem um componente de índice. | A, B, C, D | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8x núcleos de CPU2,3 | 1 Gbps |
| O servidor do aplicativo que tem componentes de processamento da análise e do conteúdo. | E, F | 300 GB | 8 GB | 4 núcleos de CPU de 1,8 GHz | 1 Gbps |
| O servidor do aplicativo que tem rastreamento, administração da pesquisa e componentes de processamento do conteúdo. | E, F | 100 GB | 8 GB | 4 núcleos de CPU de 1,8 GHz | 1 Gbps |
| O servidor do banco de dados que tem todos os bancos de dados de pesquisa. | G, H | 400 GB | 16 GB | 4 núcleos de CPU de 1,8 GHz | 1 Gbps |
1O número de núcleos da CPU é especificado aqui, mas não o número de threads da CPU.
2 Com o SharePoint Server 2013, a quantidade mínima de recursos necessária é de 500 GB de armazenamento, 16 GB de RAM e quatro núcleos de CPU.
3 Com o SharePoint Server 2016, você também pode usar 250 GB de armazenamento, 16 GB de RAM e quatro núcleos de CPU, mas cada componente de índice só pode conter 10 milhões de itens e o farm de pesquisa só dá suporte ao mesmo volume de conteúdo que um farm de pesquisa do SharePoint Server 2013.
Recursos mínimos de hardware para o farm grande de pesquisa
Esta tabela mostra a quantidade mínima de recursos de hardware que cada servidor de aplicativos e de bancos de dados precisa.
| Servidor | No host | Armazenamento | RAM | Processador1 | Largura de banda da rede |
|---|---|---|---|---|---|
| O servidor do aplicativo que tem processamento de consulta e componentes de índice. | A, B, C, D, E, G, H | 500 GB2, 3 | 32 GB2, 3 | 1,8 GHz 8x núcleos de CPU2, 3 | 1 Gbps |
| O servidor do aplicativo que tem um componente de índice. | A, B, C, D, E, F, G, H, I, J | 500 GB2, 3 | 32 GB2, 3 | 1,8 GHz 8x núcleos de CPU2, 3 | 1 Gbps |
| Os servidores do aplicativo que têm componentes de processamento da análise e do conteúdo | K, L, M, N | 300 GB | 8 GB | 4 núcleos de CPU de 1,8 GHz | 1 Gbps |
| Os servidores do aplicativo que têm rastreamento e componentes de administração da pesquisa | K, L | 100 GB | 8 GB | 4 núcleos de CPU de 1,8 GHz | 1 Gbps |
| O servidor do banco de dados que tem bancos de dados de pesquisa | O, P, Q, R | 500 GB | 16 GB | 4 núcleos de CPU de 1,8 GHz | 1 Gbps |
1O número de núcleos da CPU é especificado aqui, mas não o número de threads da CPU.
2 Com o SharePoint Server 2013, a quantidade mínima de recursos necessária é de 500 GB de armazenamento, 16 GB de RAM e quatro núcleos de CPU.
3 Com o SharePoint Server 2016, você também pode usar 250 GB de armazenamento, 16 GB de RAM e quatro núcleos de CPU, mas cada componente de índice só pode conter 10 milhões de itens e o farm de pesquisa só dá suporte ao mesmo volume de conteúdo que um farm de pesquisa do SharePoint Server 2013.
Recursos de hardware mínimos para o farm de pesquisa extra grande
Esta tabela mostra a quantidade mínima de recursos de hardware que cada servidor de aplicativos e de bancos de dados precisa. Você só pode criar este farm de exemplo com o SharePoint Server 2016.
| Servidor | No host | Armazenamento | RAM | Processador1 | Largura de banda de rede |
|---|---|---|---|---|---|
| Servidor de aplicativo que tem componentes de índice. | A-X | 500 GB | 32 GB | Núcleos de CPU de 1,8 GHz 8x | 1 Gbps |
| O servidor do aplicativo que tem processamento de consulta e componentes de índice. | Y, Z | 500 GB | 32 GB | Núcleos de CPU de 1,8 GHz 8x | 1 Gbps |
| Servidores de aplicativo que têm componentes de rastreamento, administração de pesquisa ou processamento de conteúdo | AA-AF | 100 GB | 8 GB | 4 núcleos de CPU de 1,8 GHz | 1 Gbps |
| Servidores de aplicativo que têm componentes de processamento de análise | AG, AH | 800 GB | 8 GB | 4 núcleos de CPU de 1,8 GHz | 1 Gbps |
| Servidores de banco de dados que têm bancos de dados de pesquisa | AI-AL | 500 GB | 16 GB | 4 núcleos de CPU de 1,8 GHz | 1 Gbps |
1O número de núcleos da CPU é especificado aqui, mas não o número de threads da CPU.
Planejar o desempenho do armazenamento
A velocidade do armazenamento afeta o desempenho da pesquisa. Verifique se o armazenamento de que você dispõe é rápido o bastante para lidar com o tráfego dos componentes e bancos de dados de pesquisa. A velocidade do disco é medida em operações de E/S por segundo (IOPS).
O modo pelo qual você decide distribuir os dados dos componentes de pesquisa e do sistema operacional em todo o seu armazenamento tem um impacto sobre o desempenho de pesquisa. É uma boa ideia:
Dividir os arquivos do sistema operacional do Windows Server, arquivos de programa do SharePoint Server e logs de diagnóstico em três volumes de armazenamento separados ou partições com desempenho normal.
Armazenar os dados de componentes de pesquisa em um volume ou partição de armazenamento distinto com alto desempenho.
Observação
Você pode definir um local personalizado para dados de componente de pesquisa ao instalar o SharePoint Server em um host. Qualquer componente de pesquisa no host que precisar armazenar dados, irá armazená-los nesse local. Para alterar esse local mais tarde, você precisa reinstalar o SharePoint Server nesse host.
Escolher o armazenamento
Para obter uma visão geral das arquiteturas de armazenamento e tipos de disco, consulte Armazenamento e SQL Server planejamento e configuração de capacidade (SharePoint Server). Os servidores que hospedam os componentes de processamento de índice ou análise, ou bancos de dados de pesquisa, exigem armazenamento que possa manter baixa latência, fornecendo operações suficientes de E/S por segundo (IOPS). As tabelas seguintes mostram quantas IOPS são requeridas por cada um desses componentes e bancos de dados de pesquisa.
Se você implantar um armazenamento compartilhado como SAN/NAS, a carga de pico do disco de um componente de pesquisa geralmente coincidirá com a carga de pico do disco de outro componente de pesquisa. Para obter o número da pesquisa IOPS requerido no armazenamento compartilhado, é preciso adicionar o requisito de IOPS de cada um desses componentes.
Pesquisar os requisitos de IOPS do componente
| Nome do componente | Detalhes do componente | Requisitos de IOPS | Uso do volume/partição de armazenamento separado |
|---|---|---|---|
| Componente do índice | Usa o armazenamento ao mesclar o índice, ao lidar e responder a consultas. | 300 IOPS para 64 KB de leituras aleatórias. 100 IOPS para 256 KB de gravações aleatórias. 200 MB/s para leituras sequenciais. 200 MB/s para gravações sequenciais. |
Sim |
| Componente de análise | Analisa os dados localmente, no processamento em massa. | Não | Sim |
| Componente de rastreamento | Armazena o conteúdo baixado localmente, antes de enviar para um componente de processamento do conteúdo. O armazenamento é limitado pela largura de banda da rede. | Não | Sim |
Pesquisar requisitos de IOPS do banco de dados
| Nome do banco de dados | Requisitos de IOPS | Carga típica no subsistema de E/S. |
|---|---|---|
| Banco de dados de rastreamento | IOPS médio a alto | 10 IOPS por taxa de rastreamento de 1 documento por segundo (DPS). |
| Banco de dados de links | IOPS médio | 10 IOPS por 1 milhão de itens no índice da pesquisa. |
| Banco de dados de Administração de Pesquisa | IOPS baixo | Não aplicável. |
| Banco de Dados de Relatório de Análise | IOPS médio | Não aplicável. |
Escolher como sua arquitetura de pesquisa oferece suporte à alta disponibilidade
Se você não estiver familiarizado com as estratégias de alta disponibilidade, eis um artigo para começar: Crie uma arquitetura e uma estratégia de alta disponibilidade para o SharePoint Server. Sua arquitetura de pesquisa oferece suporte a alta disponibilidade quando você hospeda componentes e bancos de dados de pesquisa em domínios de falha separado. Todas as amostras de arquitetura de pesquisa hospedam componentes de pesquisa redundantes em servidores independentes.
Para cada servidor host redundante em sua arquitetura de pesquisa, prepare-se para instalar:
Rede redundante
Fontes de alimentação redundantes com fiação independente ou um no-break (UPS).
Etapa 4: Como verificar se minha arquitetura de pesquisa está tendo um bom desempenho?
Antes de implantar sua arquitetura de pesquisa em um ambiente de produção, você precisará verificar se ela tem um bom desempenho. Eis uma lista de verificação sobre o que fazer:
Teste se os componentes do índice utilizam um subsistema de E/S de armazenamento que tenha IOPS suficiente. Confira Testar o subsistema de E/S de armazenamento.
Implante a arquitetura de pesquisa em um ambiente piloto. Certifique-se de que o ambiente piloto seja representativo do ambiente de produção.
Teste o desempenho de pesquisa do ambiente piloto. Confira Testar o desempenho de pesquisa
Para obter uma visão geral dos testes no SharePoint, confira Teste de desempenho para SharePoint Server 2013.
Testar o subsistema de E/S de armazenamento
Para testar o subsistema de E/S de armazenamento, execute as operações de disco mais importantes e meça o IOPS. Você pode usar a ferramenta DiskSpd para executar esses testes. Consulte DiskSpd: Uma ferramenta de desempenho de armazenamento robusta.
Configurar o ambiente de teste
Você não precisa configurar toda a arquitetura de pesquisa ou instalar o SharePoint Server. Basta configurar um ambiente de teste que produza uma carga de trabalho realista para o subsistema de E/S de armazenamento.
Consideremos o caso do armazenamento local. Por exemplo, se o host A no farm médio de pesquisa usa um disco local, você precisa instalar as duas máquinas virtuais e executar os testes de operação de disco em ambas as máquinas virtuais ao mesmo tempo.
Você precisa de uma configuração diferente para o armazenamento compartilhado. Se, por exemplo, a carga de trabalho de todos os componentes de índice no farm médio de pesquisa, mais outras cargas de trabalho não relacionadas, compartilham o mesmo armazenamento, você precisa:
Instalar as oito máquinas virtuais nos hosts A, B, C e D, e configurar as fontes das cargas de trabalho não relacionadas.
Certificar-se de que a carga de trabalho não relacionada seja aplicada ao armazenamento compartilhado ao mesmo tempo em que você executa testes de operação de disco simultâneos em todas as máquinas virtuais nos hosts A, B, C e D.
Criar um arquivo de teste
Crie um arquivo de teste 256 GiBytes usando o comando
diskspd -c256G testfile. Esse comando cria um arquivo de tamanho GiBytes de 256 chamado "testfile". Você também pode criar um arquivo com outro tamanho seguindo a sintaxe:diskspd -c<size>[K|M|G|b] <filename>Salvar o arquivo de teste no dispositivo de armazenamento a ser testado. Por exemplo, no disco rídigo do Host A no farm médio.
Reiniciar o servidor. Isso garantirá que o cache não distorça os resultados do teste.
Executar testes
É uma boa ideia medir:
O desempenho de acessos aleatórios de tamanho médio (veja o número de teste um e dois abaixo).
Taxa de transferência de leitura e gravação para transferências grandes (veja o número de teste três e quatro abaixo).
A tabela abaixo mostra os comandos DiskSpd que você deve usar para executar cada teste. Todos os comandos presumem que o "arquivo de teste" exista no diretório atual. Cada teste é executado por 300 segundos.
| Número do teste | Escopo | Comando |
|---|---|---|
| 1 | Leitura de 64 KB [IOPS] | diskspd -t4 -b64K -o25 -r -d300 testfile |
| 2 | Gravação de 256 KB [IOPS] | diskspd -t4 -b256K -o25 -r -w100 -d300 testfile |
| 3 | Leitura de 100 MB [MB/s] | diskspd -t1 -o1 -b100M -r -d300 testfile |
| 4 | Gravação de 100 MB [MB/s] | diskspd -t1 -o1 -b100M -r -w100 -d300 testfile |
Resultados de exemplo do armazenamento de disco local
Os resultados de amostra na tabela abaixo mostram uma implantação na qual pelo menos 50 por cento da capacidade do susistema de disco estava em uso antes de adicionar o arquivo de teste.
O controlador do disco e os eixos do disco influenciam fortemente esses resultados.
Se você testar em discos vazios, obterá resultados elevados, pois o arquivo de teste estará nas faixas mais ideais em todos os eixos (traços curtos). Isso pode aumentar o desempenho em até duas ou três vezes. Você obterá resultados altos irreais se testar um disco rígido que otimize acessos em espaço de armazenamento não inicializado, ou armazenamento contendo todos os zeros, por exemplo, arquivos VHD/VHDX dinâmicos. Nesse caso, use um arquivo de teste muito grande que contém dados reais, em vez de gerar um arquivo de teste sintético usando comandos DiskSpd.
| Layout de disco | Teste 1 | Teste 2 | Teste 3 | Teste 4 | |
| IOPS mínimo recomendfado durante operações comuns | 300 | 100 | 200 | 200 | |
| 4x 1 TB 7200 RPM NLSAS em RAID5 no controlador Dell H710 RAID (tamanho da listra de 64 kB, tamanho de bloco de 64 kB) | 1181 | 206 | 284 | 296 | |
| 8x 1TB 7200 RPM NLSAS em RAID5 no controlador Dell H710 RAID (tamanho da listra de 64 kB, tamanho de bloco de 64 kB) | 2082 | 337 | 610 | 645 | |
| 16x 1TB 7200 RPM NLSAS em RAID5 no controlador Dell H710 RAID (tamanho da listra de 64 kB, tamanho de bloco de 64 kB) | 3763 | 595 | 1173 | 1181 | |
| 16x 1TB 7200 RPM NLSAS em RAID50 (2x8) no controlador Dell H710 RAID (tamanho da listra de 64 kB, tamanho de bloco de 64 kB) | 3613 | 545 | 1139 | 1164 | |
| 16x 1TB 7200 RPM NLSAS em RAID10 no controlador Dell H710 RAID (tamanho da listra de 256 kB, tamanho de bloco de 64 kB) | 4030 | 1146 | 970 | 775 | |
| 4x SmartStorage Optimus 800GB SSDs em RAID5 no controlador Dell H710 RAID (tamanho da listra de 64 kB, tamanho de bloco de 64 kB) | 32385 | 3781 | 1714 | 1319 | |
| 4x SmartStorage Optimus 800GB SSDs em RAID0 no controlador Dell H710 RAID (tamanho da listra de 256 kB, tamanho do bloco de 64 kB) | 31747 | 7149 | 1643 | 1798 |
Testar o desempenho de pesquisa
Eis uma lista de verificação sobre o que fazer para testar sua arquitetura de pesquisa:
Escolher conteúdo no qual executar testes
Escolha bem o conteúdo que representa seu conteúdo de produção. Se você escolher o conteúdo que está lá apenas para fins de teste, verifique se você tem diferentes tipos de itens, não apenas um item que você duplicado muitas vezes. O motivo para isso é que o processador de consulta gastará tempo detectando itens duplicados, o que afetará o desempenho da pesquisa e seus resultados não serão representativos de um ambiente de produção.
Configure uma ou mais fontes de conteúdo para rastrear o conteúdo. Verifique se você tem a conta de usuário requerida e acesso à rede.
Escolher termos e frases para testar o desempenho da consulta
O número de resultados obtidos para uma consulta é chamado de recall.
Para testar o desempenho da consulta, você primeiro precisará criar um conjunto de termos e frases para usar como consultas. Como alternativa, colete consultas de uma instalação existente. Certifique-se de que o conjunto contenha termos e frases que tenham baixo recall e alto recall, e de que os termos e frases sejam relevantes para seu ambiente.
Exemplos
Se você pesquisar um número de produto em um catálogo de produtos, é provável que só haja um número para um produto. Portanto, você obterá seus resultados da pesquisa rapidamente. Isso é recall baixo.
Se você pesquisar um termo comum como "apresentação" na intranet de uma emprea, é provável que obternha muitos resultados, e pode levar mais tempo para obtê-los. Isso é recall alto.
Se, por exemplo, seu conteúdo for relacionado a recursos humanos, use termos de pesquisa relacionados a essa área.
Medir o desempenho de pesquisa
O SharePoint Server coleta medidas de desempenho de pesquisa nos Relatórios de Integridade de Rastreamento e Relatórios de Integridade de Consulta. Você pode encontrar esses relatórios em Administração Central, em Administração da Pesquisa.
É uma boa ideia medir cada desempenho de pesquisa primeiro com uma carga sintética, depois com um pequeno conjunto de usuários reais e conteúdo real. Ao usar usuários reais e conteúdo real, é possível observar como a arquitetura de pesquisa está se saindo em termos de desempenho. Se o seu conteúdo aumentar mais rápido do que você pretendia, pode ser útil considerar o uso do tamanho seguinte de arquitetura de pesquisa. Ou, se seus usuários estiverem mais ativos do que o previsto, sugerimos que você aumente a quantidade de espaço de armazenamento do banco de dados de análise.