Planear a arquitetura de pesquisa empresarial no SharePoint Server
APLICA-SE A:
2013 2016 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, iremos ajudá-lo a planear uma arquitetura de pesquisa empresarial pequena, média, grande ou de grande dimensão.
Está familiarizado com os componentes do sistema de pesquisa no SharePoint Server e como 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:
Passo 2: Qual o tamanho da arquitetura de pesquisa 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.
Passo 2: Qual o tamanho da arquitetura de pesquisa 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. Existem arquiteturas de pesquisa de exemplo que aconselhamos a utilizar como base para planear o seu próprio farm. A amostra de arquitetura de pesquisa escolhida depende de quanto conteúdo precisa ser pesquisável:
| Volume de conteúdos (SharePoint 2016) | Amostra de arquitetura de pesquisa | Volume de conteúdos (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 estas arquiteturas de pesquisa de exemplo utilizem máquinas virtuais, pode utilizar servidores físicos e máquinas virtuais de acordo com a estratégia da solução geral do SharePoint Server da sua arquitetura de pesquisa.
Farm pequeno de pesquisa
Estimámos que esta arquitetura de pesquisa pode pesquisar 50 documentos por segundo e servir na ordem de 10 consultas por segundo. Se tiver até 20 milhões de itens num farm do SharePoint Server 2016, o pequeno farm de pesquisa será provavelmente o farm mais adequado para si. Com uma taxa de pesquisa de 50 documentos por segundo, a pesquisa demora 110 horas a pesquisar 20 milhões de itens na primeira pesquisa completa.
Farm médio de pesquisa
Estimamos que esta arquitetura de pesquisa pode pesquisar 100 documentos por segundo e servir na ordem de 10 consultas por segundo. Se tiver entre 20 e 80 milhões de itens num farm do SharePoint Server 2016, o farm de pesquisa média será provavelmente o farm mais adequado para si. Com uma taxa de pesquisa de 200 documentos por segundo, a pesquisa demora 280 horas a pesquisar 80 milhões de itens na primeira pesquisa completa.
Farm grande de pesquisa
Estimamos que esta arquitetura de pesquisa pode pesquisar 200 documentos por segundo e servir na ordem de 10 consultas por segundo. Se tiver entre 80 e 200 milhões de itens num farm do SharePoint Server 2016, o farm de pesquisa grande será provavelmente o farm mais adequado para si. Com uma taxa de pesquisa de 200 documentos por segundo, a pesquisa demora 280 horas a pesquisar 200 milhões de itens na primeira pesquisa completa.
Farm de pesquisa extra grande
A Microsoft testou esta arquitetura de pesquisa e mediu que pode pesquisar 300 a 500 documentos por segundo e servir na ordem de 10 consultas por segundo. Apenas o SharePoint Server 2016 suporta esta arquitetura de pesquisa de tamanho. Se 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 pesquisa de 500 documentos por segundo, a pesquisa demora cerca de 300 horas a pesquisar 500 milhões de itens na primeira pesquisa completa.
Criar um farm de pesquisa deste tamanho requer que planeie e ajuste cuidadosamente o farm para obter o desempenho pretendido. Poderá considerar vantajoso procurar orientações especializadas. Também é importante planear como criar cópias de segurança e restaurar um farm de pesquisa deste tamanho e como recuperar o farm se o seu datacenter tiver uma falha grave. Recomendamos que pratique a cópia de segurança, o restauro e a 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 estiver a utilizar uma das arquiteturas que estimámos para si, estará a executar a 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 a 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, por exemplo, alterar a arquitetura de pesquisa de exemplo médio para utilizar servidores físicos, verá que tem dois componentes de processamento de conteúdos no Anfitrião E. A solução é retirar um dos componentes de processamento de conteúdos. Isto funciona porque a pesquisa, o processamento de conteúdos e o processamento de análise dependem da quantidade de recursos disponíveis e não do número de componentes de processamento de conteúdos.
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
Certifique-se de que cada servidor anfitrião tem espaço em disco suficiente para a instalação base do sistema operativo Windows Server e para os ficheiros 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 operativo Windows Server e para os ficheiros do programa 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 planear bases de dados SQL, veja Planeamento e configuração da capacidade do SQL Server e armazenamento (SharePoint Server).
O armazenamento mínimo que o banco de dados de relatórios da análise requer pode variar. Isto deve-se ao facto de a quantidade de armazenamento depender da forma como os utilizadores 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 | Núcleos de CPU de 1,8 GHz 8x2,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.
2Com o SharePoint Server 2013, a quantidade mínima de recursos necessários é 500 GB de armazenamento, 16 GB de RAM e quatro núcleos de CPU.
3Com o SharePoint Server 2016, também pode utilizar 250 GB de armazenamento, 16 GB de RAM e quatro núcleos de CPU, mas, em seguida, cada componente de índice só pode conter 10 milhões de itens e o farm de pesquisa só suporta o 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 | Núcleos de CPU de 1,8 GHz 8x2,3 | 1 Gbps |
| O servidor do aplicativo que tem um componente de índice. | A, B, C, D | 500 GB2,3 | 32 GB2,3 | Núcleos de CPU de 1,8 GHz 8x2,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.
2Com o SharePoint Server 2013, a quantidade mínima de recursos necessários é 500 GB de armazenamento, 16 GB de RAM e quatro núcleos de CPU.
3Com o SharePoint Server 2016, também pode utilizar 250 GB de armazenamento, 16 GB de RAM e quatro núcleos de CPU, mas, em seguida, cada componente de índice só pode conter 10 milhões de itens e o farm de pesquisa só suporta o 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 | Núcleos de CPU de 1,8 GHz 8x2, 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 | Núcleos de CPU de 1,8 GHz 8x2, 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.
2Com o SharePoint Server 2013, a quantidade mínima de recursos necessários é 500 GB de armazenamento, 16 GB de RAM e quatro núcleos de CPU.
3Com o SharePoint Server 2016, também pode utilizar 250 GB de armazenamento, 16 GB de RAM e quatro núcleos de CPU, mas, em seguida, cada componente de índice só pode conter 10 milhões de itens e o farm de pesquisa só suporta o 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. 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 aplicações com 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 aplicações com componentes de processamento de pesquisa, de pesquisa ou de pesquisa | AA-AF | 100 GB | 8 GB | 4 núcleos de CPU de 1,8 GHz | 1 Gbps |
| Servidores de aplicações com 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 bases de dados com bases de dados de pesquisa | IA-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
Pode definir uma localização personalizada para dados de componentes de pesquisa ao instalar o SharePoint Server num anfitrião. Qualquer componente de pesquisa no host que precisar armazenar dados, irá armazená-los nesse local. Para alterar esta localização mais tarde, tem de reinstalar o SharePoint Server nesse anfitrião.
Escolher o armazenamento
Para obter uma descrição geral das arquiteturas de armazenamento e dos tipos de disco, veja Planeamento e configuração da capacidade do SQL Server e armazenamento (SharePoint Server). Os servidores que alojam os componentes de processamento de índices ou análises, ou bases de dados de pesquisa, necessitam de armazenamento que possa manter baixa latência, ao mesmo tempo que fornecem operações de E/S suficientes 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 descrição geral dos testes no SharePoint, veja Testes de desempenho do 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. Pode utilizar a ferramenta DiskSpd para executar estes testes. Veja DiskSpd: Uma Ferramenta de Desempenho de Armazenamento Robusta.
Configurar o ambiente de teste
Não precisa de 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 ficheiro de teste 256 GiBytes com o comando
diskspd -c256G testfile. Este comando cria um ficheiro de tamanho GiBytes de 256 com o nome "testfile". Também pode criar um ficheiro com outro tamanho ao seguir 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 deve utilizar 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. Neste caso, utilize um ficheiro de teste muito grande que contenha dados reais, em vez de gerar um ficheiro de teste sintético com 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 o conteúdo que representa bem o conteúdo de produção. Se escolher conteúdos que só estão presentes para fins de teste, certifique-se de que tem diferentes tipos de itens e não apenas um item que tenha duplicado muitas vezes. Isto deve-se ao facto de o processador de consultas passar algum tempo a detetar itens duplicados, o que afetará o desempenho da pesquisa e os 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. Em alternativa, recolha 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 recolhe medidas de desempenho de pesquisa nos Relatórios de Estado de Funcionamento da Pesquisa e nos Relatórios de Estado de Funcionamento da 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. Em alternativa, se os seus utilizadores estiverem mais ativos do que o previsto, sugerimos que aumente a quantidade de espaço de armazenamento da base de dados de análise.