Pianificare l'architettura di ricerca aziendale in SharePoint Server
SI APPLICA A:
2013 2016 2019 Subscription Edition 
SharePoint in Microsoft 365
Prima di configurare un'architettura di ricerca di contenuti nell'organizzazione, è necessario pianificare attentamente alcuni aspetti. Passo dopo passo, ti aiuteremo a pianificare un'architettura di ricerca aziendale di piccole, medie, grandi o grandi dimensioni.
Si ha familiarità con i componenti del sistema di ricerca in SharePoint Server e con come interagiscono? Leggendo Panoramica dell'architettura di ricerca in SharePoint Server e architetture di ricerca per SharePoint Server 2016 (o Architetture di ricerca per SharePoint Server 2013) prima di iniziare, si acquisirà familiarità con l'architettura di ricerca, i componenti di ricerca, i database di ricerca e la topologia di ricerca. Quando si pianifica un'architettura di ricerca, ecco alcuni suggerimenti su cosa considerare:
Passaggio 2: Quale architettura di ricerca delle dimensioni per la quantità di contenuto?
Passaggio 4: Verifica del corretto funzionamento dell'architettura di ricerca
Passaggio 1: Quantità di contenuto disponibile
Il volume di contenuto incluso nell'indice di ricerca influisce sulle risorse necessarie per ospitare la farm. Elaborare approssimativamente il numero di elementi che si prevede di rendere ricercabile. Ecco alcuni esempi di elementi: documenti, pagine Web, voci di elenco di SharePoint e immagini. Tenere presente che ogni voce di un elenco di SharePoint viene conteggiata come un elemento.
Dopo avere definito un valore, moltiplicarlo per un valore corrispondente alla crescita prevista per tale contenuto nei 12 mesi successivi.
Ad esempio, se si inizia con 12.000 elementi indicizzati e si prevede che il volume di tale contenuto triplica nei prossimi 12 mesi. È consigliabile pianificare 36.000 elementi ricercabili.
Passaggio 2: Quale architettura di ricerca delle dimensioni per la quantità di contenuto?
Pianificare le dimensioni di un'architettura di ricerca è un'operazione tutt'altro che semplice. Dipende infatti dal volume del contenuto, dalla frequenza di ricerca per indicizzazione, dalla velocità effettiva delle query e dal livello di disponibilità richiesto. Esistono architetture di ricerca di esempio che è consigliabile usare come base per pianificare la propria farm. La scelta dell'architettura di ricerca di esempio dipende dalla quantità di contenuto da rendere disponibile per la ricerca:
| Volume di contenuto (SharePoint 2016) | Architettura di ricerca di esempio | Volume di contenuto (SharePoint 2013) |
|---|---|---|
| 0-20 milioni di elementi | Farm di ricerca di piccole dimensioni | 0-10 milioni di elementi |
| 0-80 milioni di elementi | Farm di ricerca di medie dimensioni | 0-40 milioni di elementi |
| 0-200 milioni di elementi | Farm di ricerca di grandi dimensioni | 0-100 milioni di elementi |
| 0-500 milioni di elementi | Farm di ricerca di dimensioni molto grandi | Non supportato |
Anche se queste architetture di ricerca di esempio usano macchine virtuali, è possibile usare sia server fisici che macchine virtuali in base alla strategia della soluzione complessiva di SharePoint Server dell'architettura di ricerca.
Farm di ricerca di piccole dimensioni
È stato calcolato che questa architettura di ricerca è in grado di eseguire la ricerca per indicizzazione di 50 documenti al secondo e di gestire 10 query al secondo. Se in una farm di SharePoint Server 2016 sono presenti fino a 20 milioni di elementi, la farm di ricerca di piccole dimensioni sarà probabilmente la farm più adatta. Con una frequenza di ricerca per indicizzazione di 50 documenti al secondo, la prima ricerca per indicizzazione completa su 20 milioni di elementi richiede circa 110 ore.
Farm di ricerca di medie dimensioni
È stato calcolato che questa architettura di ricerca è in grado di eseguire la ricerca per indicizzazione di 100 documenti al secondo e di gestire 10 query al secondo. Se in una farm di SharePoint Server 2016 sono presenti da 20 a 80 milioni di elementi, la farm di ricerca media sarà probabilmente la farm più adatta. Con una frequenza di ricerca per indicizzazione di 200 documenti al secondo, la prima ricerca per indicizzazione completa su 80 milioni di elementi richiede circa 280 ore.
Farm di ricerca di grandi dimensioni
Abbiamo calcolato che questa architettura di ricerca è in grado di eseguire la ricerca per indicizzazione di 200 documenti al secondo nell'ordine di 10 query al secondo. Se in una farm di SharePoint Server 2016 sono presenti tra 80 e 200 milioni di elementi, la farm di ricerca di grandi dimensioni sarà probabilmente la farm più adatta. Con una frequenza di ricerca per indicizzazione di 200 documenti al secondo, la prima ricerca per indicizzazione completa su 200 milioni di elementi richiede circa 280 ore.
Farm di ricerca di dimensioni molto grandi
Microsoft ha testato questa architettura di ricerca e calcolato che è in grado di eseguire la ricerca per indicizzazione di un numero di documenti da 300 a 500 al secondo e di gestire 10 query al secondo. Solo SharePoint Server 2016 supporta questa architettura di ricerca di dimensioni. Se si dispone fino a 500 milioni di elementi, una farm simile a una farm di ricerca extra large è un buon punto di partenza. Con una frequenza di ricerca per indicizzazione di 500 documenti al secondo, la prima ricerca per indicizzazione completa su 500 milioni di elementi richiede circa 300 ore.
Per creare una farm di ricerca di questa dimensione è necessario pianificare attentamente e ricercare manualmente la farm per ottenere le prestazioni desiderate. Può risultare vantaggioso per richiedere assistenza. È anche importante pianificare come eseguire il backup e ripristinare una farm di ricerca di queste dimensioni e come ripristinare la farm se il data center presenta un'interruzione importante. Si consiglia di praticare operazioni di backup, ripristino e recupero.
Passaggio 3: Requisiti hardware da conoscere
Dopo avere determinato il volume del contenuto e avere scelto un'architettura di ricerca di esempio, il passo successivo consiste nel pianificare l'hardware necessario, come descritto in questa sezione:
Scegliere come supportare la disponibilità elevata per l'architettura di ricerca
Scegliere se usare server fisici o virtuali
Se si usa una delle architetture stimate, l'architettura di ricerca verrà eseguita nelle macchine virtuali. Si noti inoltre che sebbene un ambiente virtuale sia più facile da gestire, il livello di prestazioni a volte può essere leggermente inferiore rispetto a un ambiente fisico. Un server fisico può ospitare più componenti di ricerca nello stesso server rispetto a un server virtuale. In Overview of farm virtualization and architectures for SharePoint 2013 sono disponibili informazioni utili.
È anche possibile eseguire l'architettura di ricerca nei server fisici. Nelle architetture di farm di esempio, è sufficiente spostare i componenti di ricerca dalle macchine virtuali al server host e rimuovere le macchine virtuali. Ogni server fisico può ospitare un massimo di quattro componenti di indicizzazione, ma solo uno di ogni altro tipo di componente di ricerca. Se ad esempio si modifica l'architettura di ricerca di esempio media per usare i server fisici, si noterà che sono presenti due componenti di elaborazione del contenuto nell'host E. La soluzione consiste nell'eliminare uno dei componenti di elaborazione del contenuto. Ciò funziona perché la ricerca per indicizzazione, l'elaborazione del contenuto e l'elaborazione dell'analisi dipendono dalla quantità di risorse disponibili, non dal numero di componenti di elaborazione del contenuto.
Scegliere le risorse hardware per i server host
Ogni componente e database di ricerca richiede una quantità minima di risorse hardware del server host per funzionare correttamente. Tuttavia, maggiore è il numero di risorse hardware presenti, migliori saranno le prestazioni dell'architettura di ricerca. È consigliabile pertanto implementare risorse hardware superiori alla quantità minima richiesta. Le risorse richieste da ogni componente di ricerca dipendono dal carico di lavoro, a sua volta determinato principalmente dalla frequenza della ricerca per indicizzazione, dalla frequenza delle query e dal numero di elementi indicizzati.
Se ad esempio si ospitano macchine virtuali in Windows Server 2008 R2 Service Pack 1 (SP1), non è possibile usare più di quattro core di CPU per macchina virtuale. Con Windows Server 2012 o versioni successive, si usano otto o più core di CPU per macchina virtuale. È quindi possibile implementare la scalabilità orizzontale con più core di CPU per ogni macchina virtuale anziché implementare la scalabilità verticale con più macchine virtuali. Configurare i server o le macchine virtuali che ospitano gli stessi componenti di ricerca con le stesse risorse hardware. Usare il componente di indicizzazione come esempio. Se si ospitano partizioni di indice in macchine virtuali, la macchina virtuale con le prestazioni inferiori determina le prestazioni dell'intera architettura di ricerca.
Risorse di archiviazione generale
Assicurarsi che ogni server host disponga di spazio su disco sufficiente per l'installazione di base del sistema operativo Windows Server e per i file di programma di SharePoint Server. Il server host necessita anche di spazio su disco disponibile per le operazioni di diagnostica quali la registrazione, il debug e la creazione di dump della memoria, per le operazioni quotidiane e per il file di paging. In genere, 80 GB di spazio su disco sono sufficienti per il sistema operativo Windows Server e per i file di programma di SharePoint Server.
Aggiungere spazio di archiviazione per i log SQL per ogni server di database. Se non si imposta il server di database in modo da eseguire spesso il backup dei database, i log SQL usano una quantità elevata di spazio di archiviazione. Per altre informazioni su come pianificare i database SQL, vedere Pianificazione e configurazione della capacità di Archiviazione e SQL Server (SharePoint Server) .
L'archiviazione minima richiesta dal database di report di analisi può variare. Ciò è dovuto al fatto che la quantità di spazio di archiviazione dipende dal modo in cui gli utenti interagiscono con SharePoint Server. Quando gli utenti interagiscono frequentemente, in genere sono presenti più eventi da archiviare. Controllare la quantità di spazio di archiviazione usata dall'architettura di ricerca corrente per il database di analisi e assegnare almeno questa quantità per la topologia riprogettata.
Requisiti hardware minimi per la farm di ricerca di piccole dimensioni
Questa tabella indica la quantità minima di risorse hardware necessaria per ogni server applicazioni o server di database.
| Server | Nell'host | Archiviazione | RAM | Processore1 | Larghezza di banda di rete |
|---|---|---|---|---|---|
| Server applicazioni con componenti di elaborazione delle query e di indicizzazione. | A, B | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8 core CPU2,3 | 1 Gbps |
| Server applicazioni con componenti di ricerca per indicizzazione, amministrazione delle ricerche, analisi ed elaborazione del contenuto. | A, B | 200 GB | 8 GB | 4 core di CPU a 1,8 GHz | 1 Gbps |
| Server di database con tutti i database di ricerca. | C, D | 100 GB | 16 GB | 4 core di CPU a 1,8 GHz | 1 Gbps |
1Il numero specificato fa riferimento ai core, non ai thread della CPU.
numero araboCon SharePoint Server 2013 la quantità minima di risorse necessarie è di 500 GB di spazio di archiviazione, 16 GB di RAM e quattro core CPU.
3Con SharePoint Server 2016 è anche possibile usare 250 GB di spazio di archiviazione, 16 GB di RAM e quattro core CPU, ma ogni componente di indice può contenere solo 10 milioni di elementi e la farm di ricerca supporta solo lo stesso volume di contenuto di una farm di ricerca di SharePoint Server 2013.
Requisiti hardware minimi per la farm di ricerca di medie dimensioni
Questa tabella indica la quantità minima di risorse hardware necessaria per ogni server applicazioni o server di database.
| Server | Nell'host | Archiviazione | RAM | Processore1 | Larghezza di banda di rete |
|---|---|---|---|---|---|
| Server applicazioni con componenti di elaborazione delle query e di indicizzazione. | A, B, C, D | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8 core CPU2,3 | 1 Gbps |
| Server applicazioni con un componente di indicizzazione. | A, B, C, D | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8 core CPU2,3 | 1 Gbps |
| Server applicazioni con componenti di analisi e di elaborazione del contenuto | E, F | 300 GB | 8 GB | 4 core di CPU a 1,8 GHz | 1 Gbps |
| Server applicazioni con componenti di ricerca per indicizzazione, amministrazione delle ricerche ed elaborazione del contenuto. | E, F | 100 GB | 8 GB | 4 core di CPU a 1,8 GHz | 1 Gbps |
| Server di database con tutti i database di ricerca. | G, H | 400 GB | 16 GB | 4 core di CPU a 1,8 GHz | 1 Gbps |
1Il numero specificato fa riferimento ai core, non ai thread della CPU.
numero araboCon SharePoint Server 2013 la quantità minima di risorse necessarie è di 500 GB di spazio di archiviazione, 16 GB di RAM e quattro core CPU.
3Con SharePoint Server 2016 è anche possibile usare 250 GB di spazio di archiviazione, 16 GB di RAM e quattro core CPU, ma ogni componente di indice può contenere solo 10 milioni di elementi e la farm di ricerca supporta solo lo stesso volume di contenuto di una farm di ricerca di SharePoint Server 2013.
Requisiti hardware minimi per la farm di ricerca di grandi dimensioni
Questa tabella indica la quantità minima di risorse hardware necessaria per ogni server applicazioni o server di database.
| Server | Nell'host | Archiviazione | RAM | Processore1 | Larghezza di banda di rete |
|---|---|---|---|---|---|
| Server applicazioni con componenti di elaborazione delle query e di indicizzazione. | A, B, C, D, E, G, H | 500 GB2, 3 | 32 GB2, 3 | 1,8 GHz 8 core CPU2, 3 | 1 Gbps |
| Server applicazioni con un componente di indicizzazione. | A, B, C, D, E, F, G, H, I, J | 500 GB2, 3 | 32 GB2, 3 | 1,8 GHz 8 core CPU2, 3 | 1 Gbps |
| Più server applicazioni con componenti di analisi e di elaborazione del contenuto. | K, L, M, N | 300 GB | 8 GB | 4 core di CPU a 1,8 GHz | 1 Gbps |
| Più server applicazioni con componenti di ricerca per indicizzazione e amministrazione delle ricerche. | K, L | 100 GB | 8 GB | 4 core di CPU a 1,8 GHz | 1 Gbps |
| Server di database con database di ricerca. | O, P, Q, R | 500 GB | 16 GB | 4 core di CPU a 1,8 GHz | 1 Gbps |
1Il numero specificato fa riferimento ai core, non ai thread della CPU.
numero araboCon SharePoint Server 2013 la quantità minima di risorse necessarie è di 500 GB di spazio di archiviazione, 16 GB di RAM e quattro core CPU.
3Con SharePoint Server 2016 è anche possibile usare 250 GB di spazio di archiviazione, 16 GB di RAM e quattro core CPU, ma ogni componente di indice può contenere solo 10 milioni di elementi e la farm di ricerca supporta solo lo stesso volume di contenuto di una farm di ricerca di SharePoint Server 2013.
Requisiti hardware minimi per la farm di ricerca di dimensioni molto grandi
Questa tabella indica la quantità minima di risorse hardware necessaria per ogni server applicazioni o server di database. È possibile compilare questa farm di esempio solo con SharePoint Server 2016.
| Server | Nell'host | Archiviazione | RAM | Processore1 | Larghezza di banda di rete |
|---|---|---|---|---|---|
| Server applicazioni con componenti di indicizzazione. | A-X | 500 GB | 32 GB | 8 core di CPU a 1,8 GHz | 1 Gb/s |
| Server applicazioni con componenti di elaborazione delle query e di indicizzazione. | Y, Z | 500 GB | 32 GB | 8 core di CPU a 1,8 GHz | 1 Gb/s |
| Server applicazioni con componenti di ricerca per indicizzazione, amministrazione delle ricerche o elaborazione del contenuto | AA-AF | 100 GB | 8 GB | 4 core di CPU a 1,8 GHz | 1 Gbps |
| Server applicazioni con componenti di analisi e di elaborazione | AG, AH | 800 GB | 8 GB | 4 core di CPU a 1,8 GHz | 1 Gbps |
| Server di database con database di ricerca | AI-AL | 500 GB | 16 GB | 4 core di CPU a 1,8 GHz | 1 Gbps |
1Il numero specificato fa riferimento ai core, non ai thread della CPU.
Pianificazione delle prestazioni di archiviazione
La velocità di archiviazione incide sulle prestazioni di ricerca. Assicurarsi che la velocità di archiviazione sia sufficiente per gestire il traffico dei componenti e database di ricerca. La velocità del disco è misurata in operazioni di input/output al secondo.
Il modo in cui si decide di distribuire i dati dai componenti di ricerca e dal sistema operativo nell'archiviazione ha un impatto sulle prestazioni di ricerca. È consigliabile:
Suddividere i file del sistema operativo Windows Server, i file di programma di SharePoint Server e i log di diagnostica su tre volumi di archiviazione o partizioni di memoria separate con prestazioni normali.
Archiviare i dati dei componenti di ricerca su un altro volume di archiviazione o su un'altra partizione con prestazioni elevate.
Nota
È possibile impostare un percorso personalizzato per i dati dei componenti di ricerca quando si installa SharePoint Server in un host. Tutti i componenti di ricerca presenti nell'host che devono archiviare dati usano questo percorso. Per modificare questo percorso in un secondo momento, è necessario reinstallare SharePoint Server in tale host.
Scegliere l'archiviazione
Per una panoramica delle architetture di archiviazione e dei tipi di disco, vedere Pianificazione e configurazione della capacità di Archiviazione e SQL Server (SharePoint Server). I server che ospitano i componenti di elaborazione dell'indice o dell'analisi o i database di ricerca richiedono spazio di archiviazione in grado di mantenere una bassa latenza, fornendo al tempo stesso operazioni di I/O al secondo sufficienti. Nelle tabelle seguenti è indicato il numero di operazioni di input/output al secondo richiesto da ognuno di questi componenti e database di ricerca.
Se si distribuisce un sistema di archiviazione condiviso come SAN/NAS, il carico massimo del disco di un componente di ricerca coincide generalmente con quello di un altro componente di ricerca. Per ottenere il numero di operazioni di input/output al secondo richiesto dalla ricerca dal sistema di archiviazione condivisa, è necessario sommare il requisito di operazioni di input/output al secondo di ognuno di questi componenti.
Requisiti di input/output al secondo per i componenti di ricerca
| Nome componente | Dettagli componente | Requisiti di input/output al secondo | Uso di volume di archiviazione//partizione di memoria separata |
|---|---|---|---|
| Componente di indicizzazione | Usa l'archiviazione durante l'unione dell'indice e durante la gestione e la risposta alle query. | 300 operazioni di input/output al secondo per letture casuali a 64 KB. 100 operazioni di input/output al secondo per scritture casuali a 256 KB. 200 MB/s per letture sequenziali. 200 MB/s per scritture sequenziali. |
Sì |
| Componente di analisi | Analizza i dati in locale, con elaborazione bulk. | No | Sì |
| Componente di ricerca per indicizzazione | Archivia localmente il contenuto scaricato, prima di inviarlo a un componente di elaborazione del contenuto. L'archiviazione è limitata dalla larghezza di banda della rete. | No | Sì |
Requisiti di input/output al secondo per i database di ricerca
| Nome database | Requisiti di input/output al secondo | Carico tipico sul sottosistema I/O. |
|---|---|---|
| Database di ricerca per indicizzazione | Numero medio-alto di operazioni di input/output al secondo | 10 operazioni di input/output al secondo per una frequenza di ricerca per indicizzazione di un documento al secondo. |
| Database dei collegamenti | Numero medio di operazioni di input/output al secondo | 10 operazioni di input/output al secondo per un milione di elementi nell'indice di ricerca. |
| Database di amministrazione della ricerca | Numero ridotto di operazioni di input/output al secondo | Non applicabile. |
| Database di report di analisi | Numero medio di operazioni di input/output al secondo | Non applicabile. |
Scelta della modalità di supporto della disponibilità elevata per l'architettura di ricerca
Se non si ha familiarità con le strategie di disponibilità elevata, ecco un articolo introduttivo: Creare un'architettura e una strategia a disponibilità elevata per SharePoint Server. L'architettura di ricerca supporta la disponibilità elevata quando vengono ospitati componenti e database di ricerca ridondanti su domini separati. Tutte le architetture di ricerca di esempio ospitano componenti di ricerca ridondanti su server indipendenti.
Per ogni server host ridondante nell'architettura di ricerca, è consigliabile pianificare l'installazione di quanto segue:
Risorse di rete ridondanti
Alimentatori ridondanti con cablaggio indipendente o gruppo di continuità (UPS).
Passaggio 4: Verifica del corretto funzionamento dell'architettura di ricerca
Prima di distribuire l'architettura di ricerca in un ambiente di produzione, è necessario verificare che funzioni correttamente. Ecco un elenco delle operazioni da eseguire:
Verificare che i componenti di indicizzazione usino un sottosistema di I/O di archiviazione con prestazioni sufficienti di input/output al secondo. Vedere Testare il sottosistema di I/O di archiviazione.
Distribuire l'architettura di ricerca in un ambiente pilota. Assicurarsi che l'ambiente pilota sia rappresentativo dell'ambiente di produzione.
Testare le prestazioni di ricerca dell'ambiente pilota. Vedere Testare le prestazioni della ricerca
Per una panoramica dei test in generale in SharePoint , vedere Test delle prestazioni per SharePoint Server 2013.
Testare il sottosistema di I/O di archiviazione
Per testare il sottosistema di I/O di archiviazione, eseguire le operazioni su disco più importanti e misurare le prestazioni di input/output al secondo. È possibile usare lo strumento DiskSpd per eseguire questi test. Vedere DiskSpd: uno strumento affidabile per le prestazioni di archiviazione.
Configurare l'ambiente di testing
Non è necessario configurare l'intera architettura di ricerca o installare SharePoint Server. È sufficiente configurare un ambiente di testing che produca un carico di lavoro realistico per il sottosistema di I/O di archiviazione.
Si consideri il caso dell'archiviazione locale. Ad esempio, se l'host A nella farm di ricerca media usa un disco locale, è necessario installare le due macchine virtuali ed eseguire i test delle operazioni su disco in entrambe le macchine virtuali contemporaneamente.
Per l'archiviazione condivisa è necessaria una diversa configurazione. Se ad esempio il carico di lavoro di tutti i componenti di indicizzazione nella farm di ricerca di media dimensioni e altri carichi di lavoro non correlati usano lo stesso spazio di archiviazione, è necessario:
Installare le otto macchine virtuali nell'host A, B, C e D e configurare le origini dei carichi di lavoro non correlati.
Assicurarsi che il carico di lavoro non correlato venga applicato all'archiviazione condivisa quando si eseguono i test simultanei delle operazioni su disco su tutte le macchine virtuali negli host A, B, C e D.
Creare un file di test
Creare un file di test da 256 GiByte usando il comando
diskspd -c256G testfile. Questo comando crea un file di dimensioni di 256 GiByte denominato "testfile". È anche possibile creare un file con un'altra dimensione seguendo la sintassi:diskspd -c<size>[K|M|G|b] <filename>Salvare il file di test nel dispositivo di archiviazione da testare. Ad esempio: nel disco rigido dell'host A nella farm media.
Riavviare il server. In questo modo, la memorizzazione nella cache non altera i risultati del test.
Eseguire i test
È consigliabile misurare:
Le prestazioni di accessi casuali di medie dimensioni (vedere i test numero 1 e 2 di seguito).
La velocità effettiva in lettura e scrittura per trasferimenti di grandi dimensioni (vedere i test numero 3 e 4 di seguito).
La tabella seguente mostra i comandi DiskSpd che è necessario usare per eseguire ogni test. Tutti i comandi presuppongono che il "testfile" sia presente nella directory corrente. Ogni test viene eseguito per 300 secondi.
| Numero del test | Ambito | Comando |
|---|---|---|
| 1 | 64 KB in lettura [input/output al secondo] | diskspd -t4 -b64K -o25 -r -d300 testfile |
| 2 | 256 KB in scrittura [input/output al secondo] | diskspd -t4 -b256K -o25 -r -w100 -d300 testfile |
| 3 | 100 MB in lettura [MB/s] | diskspd -t1 -o1 -b100M -r -d300 testfile |
| 4 | 100 MB in scrittura [MB/s] | diskspd -t1 -o1 -b100M -r -w100 -d300 testfile |
Risultati di esempio per l'archiviazione su disco locale
I risultati di esempio nella tabella che segue mostrano una distribuzione in cui almeno il 50% della capacità del sottosistema di dischi era in uso prima dell'aggiunta del file di test.
Questi risultati sono fortemente influenzati dal controller e dagli spindle del disco.
Se si esegue il test su dischi vuoti, si otterranno risultati elevati perché il file di test si troverà nella posizione ottimale su tutti gli spindle (tragitto breve). Questo può incrementare le prestazioni fino a due o tre volte. I risultati saranno irrealisticamente elevati se si testa un disco rigido che ottimizza gli accessi su uno spazio di archiviazione non inizializzato o uno spazio di archiviazione che contiene tutti zero, ad esempio i file VHD/VHDX dinamici. In questo caso, usare un file di test di grandi dimensioni che contiene dati reali, anziché generare un file di test sintetico usando i comandi DiskSpd.
| Layout del disco | Test 1 | Test 2 | Test 3 | Test 4 | |
| Numero minimo di operazioni di input/output al secondo consigliato durante operazioni normali | 300 | 100 | 200 | 200 | |
| 4 unità NL-SAS da 1 TB a 7200 RPM in RAID5 su controller RAID Dell H710 (dimensione stripe 64 kB, dimensione blocco 64 kB) | 1181 | 206 | 284 | 296 | |
| 8 unità NL-SAS da 1 TB a 7200 RPM in RAID5 su controller RAID Dell H710 (dimensione stripe 64 kB, dimensione blocco 64 kB) | 2082 | 337 | 610 | 645 | |
| 16 unità NL-SAS da 1 TB a 7200 RPM in RAID5 su controller RAID Dell H710 (dimensione stripe 64 kB, dimensione blocco 64 kB) | 3763 | 595 | 1173 | 1181 | |
| 16 unità NL-SAS da 1 TB a 7200 RPM in RAID50 (2x8) su controller RAID Dell H710 (dimensione stripe 64 kB, dimensione blocco 64 kB) | 3613 | 545 | 1139 | 1164 | |
| 16 unità NL-SAS da 1 TB a 7200 RPM in RAID10 su controller RAID Dell H710 (dimensione stripe 256 kB, dimensione blocco 64 kB) | 4030 | 1146 | 970 | 775 | |
| 4 unità SSD SmartStorage Optimus da 800 GB in RAID5 su controller RAID Dell H710 (dimensione stripe 64 kB, dimensione blocco 64 kB) | 32385 | 3781 | 1714 | 1319 | |
| 4 unità SSD SmartStorage Optimus da 800 GB in RAID0 su controller RAID Dell H710 (dimensione stripe 256 kB, dimensione blocco 64 kB) | 31747 | 7149 | 1643 | 1798 |
Testare le prestazioni della ricerca
Ecco un elenco di controllo della procedura da eseguire per testare l'architettura di ricerca:
Scegliere il contenuto su cui eseguire i test
Il contenuto scelto deve rappresentare correttamente il contenuto di produzione. Se si sceglie un contenuto specifico per i test, assicurarsi che siano inclusi diversi tipi di elementi, non solo uno elemento duplicato più volte. In questo caso, infatti, il processore di query impiegherà molto tempo per rilevare gli elementi duplicati, con conseguente ripercussione sulle prestazioni della ricerca, e i risultati non saranno rappresentativi di un ambiente di produzione.
Configurare una o più origini di contenuto per la ricerca per indicizzazione. Verificare di disporre dell'account utente e dell'accesso di rete richiesti.
Scegliere i termini e le frasi da usare per testare le prestazioni delle query
Il numero di risultati ottenuti per una query è denominato richiamo.
Per testare le prestazioni delle query, è necessario innanzitutto creare un set di termini e frasi da usare come query. In alternativa, raccogliere query da un'installazione esistente. Assicurarsi che il set contenga termini e frasi con richiamo basso e alto e che i termini e le frasi siano pertinenti per l'ambiente.
Esempi
Se si cerca un numero di prodotto in un catalogo di prodotti, è probabile che esista un solo numero per un determinato prodotto. I risultati della ricerca verranno quindi visualizzati rapidamente. Il richiamo in questo caso è basso.
Se si cerca un termine comune come "presentazione" su una Intranet aziendale, è probabile che si ottengano molti risultati e che il tempo per la loro visualizzazione risulti più lungo. In questo caso il richiamo è alto.
Se ad esempio il contenuto è correlato alle risorse umane, usare termini di ricerca specifici di tale ambito.
Misurare le prestazioni della ricerca
SharePoint Server raccoglie le misurazioni delle prestazioni di ricerca nei report sull'integrità della ricerca per indicizzazione e nei report sull'integrità delle query. Questi report sono disponibili in Amministrazione ricerca in Amministrazione centrale.
È consigliabile misurare le prestazioni di ricerca prima con un carico sintetico e quindi con un set limitato di utenti e contenuti attivi. Quando si usano utenti e contenuti attivi, è possibile osservare le prestazioni dell'architettura di ricerca. Se il contenuto aumenta più velocemente del previsto, può essere preferibile usare l'architettura di ricerca di dimensioni appena superiori. In alternativa, se gli utenti sono più attivi del previsto, è consigliabile aumentare la quantità di spazio di archiviazione del database di analisi.