Pianificare l'architettura di ricerca a livello aziendale in SharePoint Server 2016

 

**Si applica a:**SharePoint Server 2016

**Ultima modifica dell'argomento:**2017-09-08

Riepilogo: informazioni sulla pianificazione di un'architettura per la ricerca di contenuti nell'organizzazione.

Prima di configurare un'architettura di ricerca di contenuti nell'organizzazione, è necessario pianificare attentamente alcuni aspetti. Di seguito viene illustrata in dettaglio la procedura consigliata per pianificare un'architettura di piccole, medie, grandi dimensioni o di dimensioni molto grandi per la ricerca di contenuti nell'organizzazione.

Se è necessario acquisire familiarità con i componenti del sistema di ricerca in SharePoint Server e le relative modalità di interazione, vedere 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 continuare, in modo da iniziare a conoscere l'architettura, i componenti, i database e la topologia di ricerca. Durante la pianificazione di un’architettura, componenti, database e topologia di ricerca, tenere presenti i seguenti suggerimenti:

1. Passaggio 1: Quantità di contenuto disponibile

2. Passaggio 2: Correlazione tra quantità di contenuto e dimensioni dell'architettura di ricerca

3. Passaggio 3: Requisiti hardware da conoscere

   • Scegliere se usare server fisici o virtuali

   • Scegliere le risorse hardware per i server host

   • Pianificazione delle prestazioni di archiviazione

   • Scegliere come supportare la disponibilità elevata per l'architettura di ricerca

4. Passaggio 4: Verifica del corretto funzionamento dell'architettura di ricerca

   • Testare il sottosistema di I/O di archiviazione

   • Testare le prestazioni della ricerca

Passaggio 1: Quantità di contenuto disponibile

Il volume del contenuto incluso nell'indice di ricerca incide sulle risorse necessarie per ospitare la farm. Stabilire approssimativamente il numero di elementi, ad esempio documenti, pagine Web, voci di elenco di SharePoint e immagini, che si intende rendere disponibili per la ricerca. Tenere presente che ogni voce in un elenco di SharePoint conta 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 triplicherà nei 12 mesi successivi, pianificare 36.000 elementi che supportano la ricerca.

Passaggio 2: Correlazione tra quantità di contenuto e dimensioni dell'architettura di ricerca

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. Sono disponibili alcune architetture di ricerca di esempio che si consiglia di usare come base per pianificare una farm. La scelta dell'architettura di ricerca di esempio dipende dalla quantità di contenuto da rendere disponibile per la ricerca:

Volume del contenuto (SharePoint 2016)	Architettura di ricerca di esempio	Volume del 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 supportata

Anche se queste architetture di ricerca di esempio usano macchine virtuali, è possibile usare sia server fisici che macchine virtuali a seconda della strategia della soluzione SharePoint Server complessiva 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 si dispone di un massimo di 20 milioni di elementi una farm di SharePoint Server 2016, la farm di ricerca di piccole dimensioni risulterà 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 si dispone di un numero di elementi tra 20 e 80 milioni in una farm di SharePoint Server 2016, la farm di ricerca di medie dimensioni risulterà 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 si dispone tra 80 e 200 milioni di elementi in una farm di SharePoint Server 2016, la grande farm di ricerca sarà probabilmente la più adatta alle proprie esigenze. 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 l'architettura di ricerca con queste 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 il ripristino di una farm di ricerca di queste dimensioni e come recuperare la farm se il datacenter contiene un'interruzione principale. 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 se usare server fisici o virtuali

• Scegliere le risorse hardware per i server host

  • Risorse di archiviazione generale

  • Requisiti hardware minimi per la farm di ricerca di piccole dimensioni

  • Requisiti hardware minimi per la farm di ricerca di medie dimensioni

  • Requisiti hardware minimi per la farm di ricerca di grandi dimensioni

  • Requisiti hardware minimi per la farm di ricerca di dimensioni molto grandi

• Pianificazione delle prestazioni di archiviazione

  • Scegliere l'archiviazione

    • Requisiti di input/output al secondo per i componenti di ricerca

    • Requisiti di input/output al secondo per i database di ricerca

• Scegliere come supportare la disponibilità elevata per l'architettura di ricerca

Scegliere se usare server fisici o virtuali

Se si sta utilizzando una delle architetture calcolate per l’utente, l'architettura di ricerca verrà eseguita su macchine virtuali. Si noti che, anche se è più semplice gestire un ambiente virtuale, il livello di prestazioni può talvolta 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. Sono disponibili indicazioni utili in Panoramica della virtualizzazione e delle architetture per le farm in SharePoint 2013.

È anche possibile eseguire l’architettura di ricerca in server fisici. Nelle architetture di farm di esempio è sufficiente spostare i componenti di ricerca dalle macchine virtuali al server host e quindi rimuovere le macchine virtuali. Ogni server fisico può ospitare fino a quattro componenti di indicizzazione, ma solo uno di ciascun tipo degli altri componenti di ricerca. Se ad esempio si interviene sull'architettura di ricerca di esempio di medie dimensioni per usare server fisici, vi sono due componenti di elaborazione del contenuto nell'host E. La soluzione è rimuovere uno dei componenti di elaborazione del contenuto, poiché la ricerca per indicizzazione, l’elaborazione di contenuti e l’elaborazione di analisi non dipende dal numero di componenti di elaborazione del contenuto, bensì dalla quantità di risorse disponibili.

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

Verificare 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 di spazio su disco 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 dell'archiviazione e della capacità di SQL Server (SharePoint Server).

Le risorse di archiviazione minime richieste dal database di report di analisi possono variare, poiché la quantità di spazio di archiviazione dipende dalla modalità di interazione degli utenti con SharePoint Server. Se gli utenti interagiscono frequentemente, in genere sono presenti più eventi da archiviare. Controllare la quantità di spazio di archiviazione usato dall'architettura di ricerca corrente per il database di analisi e assegnare almeno la stessa quantità alla 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	Spazio di archiviazione	RAM	Processor1	Larghezza di banda di rete
Server applicazioni con componenti di elaborazione delle query e di indicizzazione.	A, B	500 GB2,3	32 GB2,3	8 core di CPU a 1,8 GHz2,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.

2Con SharePoint Server 2013 la quantità minima di risorse è 500 GB di RAM, 16 GB di RAM e quattro core CPU.

3Con SharePoint Server 2016 è inoltre possibile utilizzare 500 GB di spazio di archiviazione, 16 GB di RAM e quattro core CPU, ma quindi ogni componente di indicizzazione può contenere solo 10 milioni di elementi e la farm di ricerca supporta solo un volume di contenuto come 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	Spazio di archiviazione	RAM	Processor1	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	8 core di CPU a 1,8 GHz2,3	1 Gbps
Server applicazioni con un componente di indicizzazione.	A, B, C, D	500 GB2,3	32 GB2,3	8 core di CPU a 1,8 GHz2,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.

2Con SharePoint Server 2013 la quantità minima di risorse è 500 GB di RAM, 16 GB di RAM e quattro core CPU.

3Con SharePoint Server 2016 è inoltre possibile utilizzare 500 GB di spazio di archiviazione, 16 GB di RAM e quattro core CPU, ma quindi ogni componente di indicizzazione può contenere solo 10 milioni di elementi e la farm di ricerca supporta solo un volume di contenuto come 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	Spazio di archiviazione	RAM	Processor1	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	8 core di CPU a 1,8 GHz2, 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	8 core di CPU a 1,8 GHz2, 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.

2Con SharePoint Server 2013 la quantità minima di risorse è 500 GB di RAM, 16 GB di RAM e quattro core CPU.

3Con SharePoint Server 2016 è inoltre possibile utilizzare 500 GB di spazio di archiviazione, 16 GB di RAM e quattro core CPU, ma quindi ogni componente di indicizzazione può contenere solo 10 milioni di elementi e la farm di ricerca supporta solo un volume di contenuto come 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 creare solo la farm di esempio con SharePoint Server 2016.

Server	Nell'host	Spazio di archiviazione	RAM	Processor1	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.

Poiché la modalità di distribuzione dei dati dal componenti di ricerca e dal sistema operativo sul sistema di archiviazione incide sulle prestazioni della ricerca, può essere opportuno:

• 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 cambiare questo percorso in un secondo momento, è necessario reinstallare SharePoint Server sull'host.

Scegliere l'archiviazione

Per una panoramica delle architetture di archiviazione e sui tipi di dischi, vedere Pianificazione e configurazione dell'archiviazione e della capacità di SQL Server (SharePoint Server). I server che ospitano i componenti di indicizzazione, analisi, elaborazione delle ricerche o i database di ricerca richiedono supporti di archiviazione in grado di mantenere una latenza bassa, assicurando comunque un numero sufficiente di operazioni di input/output al secondo. 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, vedere l'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:

1. Risorse di rete ridondanti

2. 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:

1. 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.

2. Distribuire l'architettura di ricerca in un ambiente pilota, assicurandosi che sia rappresentativo dell'ambiente di produzione.

3. Testare le prestazioni di ricerca dell'ambiente pilota. Vedere Testare le prestazioni della ricerca

Per una panoramica di test generale in SharePoint, vedere Esecuzione dei test delle prestazioni di 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. Per eseguire questi test è possibile usare lo strumento SQLIO. Vedere Strumento di benchmark SQLIO dei sottosistemi di dischi.

Configurare l'ambiente di testing

Non è necessario configurare l'intera infrastruttura 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.

Nel caso dell'archiviazione locale, ad esempio, se l'host A nella farm di ricerca di medie dimensioni usa un disco locale, è necessario installare le due macchine virtuali ed eseguire i test di funzionamento dei dischi su 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:

1. Installare le otto macchine virtuali nell'host A, B, C e D e configurare le origini dei carichi di lavoro non correlati.

2. 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

1. Creare un file di test da 1 GB mediante il comando sqlio.exe -t32 -s1 -b256 1g. Questo comando crea un file di test denominato "1g".

2. Salvare il file di test sul dispositivo di archiviazione che si desidera testare, ad esempio sul disco rigido dell'host A nella farm di medie dimensioni.

3. Concatenare il file di test a un file di test di dimensioni sufficienti, ad esempio 256 GB, mediante il comando copy 1g+1g+1g+...+1g testfile.

4. Riavviare il server per assicurare che i risultati del test non siano distorti dalla memorizzazione nella cache.

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).

Nella tabella seguente sono riportati i comandi SQLIO da 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]	sqlio.exe -kR -t4 -o25 -b64 -frandom -s300 testfile
2	256 KB in scrittura [input/output al secondo]	sqlio.exe -kW -t4 -o25 -b256 -frandom -s300 testfile
3	100 MB in lettura [MB/s]	sqlio.exe -kR -t1 -o1 -b100000 -frandom -s300 testfile
4	100 MB in scrittura [MB/s]	sqlio.exe -kW -t1 -o1 -b100000 -frandom -s300 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 contenente dati reali anziché generare un file di test sintetico mediante comandi SQLIO.

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:

1. Scegliere il contenuto su cui eseguire i test

2. Scegliere i termini e le frasi da usare per testare le prestazioni delle query

3. Misurare le prestazioni della 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 le query di 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 di stato della ricerca per indicizzazione e nei report di stato 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. Se gli utenti svolgono maggiori attività del previsto, è consigliabile incrementare la quantità di spazio di archiviazione del database di analisi.