Calcolare i requisiti di prestazioni e capacità per il servizio di ricerca di SharePoint Server 2010

 

Si applica a: SharePoint Server 2010

Ultima modifica dell'argomento: 2016-11-30

Riepilogo: in questo articolo vengono fornite informazioni sulla pianificazione della capacità per diverse distribuzioni del servizio di ricerca di Microsoft SharePoint Server 2010, incluse le farm di SharePoint Server 2010 di piccole, medie e grandi dimensioni.

In questo articolo vengono fornite informazioni sulla pianificazione della capacità per distribuzioni di ambienti di collaborazione del servizio di ricerca di SharePoint Server 2010. Sono incluse le informazioni seguenti per tre configurazioni di farm di ricerca di esempio:

• Specifiche dell'ambiente di testing, ad esempio hardware, topologia della farm e configurazione

• Carico di lavoro utilizzato per la generazione dei dati, inclusi il numero e la classe degli utenti e le caratteristiche di utilizzo della farm

• Set di dati di farm di testing, inclusi contenuto e dimensioni di database

• Dati relativi all'integrità e alle prestazioni specifici dell'ambiente testato

In questo articolo inoltre sono contenuti dati relativi a test comuni e suggerimenti per determinare l'hardware, la topologia e la configurazione necessari per la distribuzione di un ambiente simile, nonché per ottimizzare l'ambiente per caratteristiche di capacità e prestazioni appropriate.

Nel servizio di ricerca di SharePoint Server 2010 sono disponibili un insieme di caratteristiche più esteso e un modello di topologia più flessibile rispetto alle versioni precedenti. Prima di utilizzare questa architettura per offrire agli utenti caratteristiche e funzionalità più potenti, è necessario valutare attentamente il relativo effetto sulla capacità e le prestazioni della farm.

Con la lettura di questo documento sarà possibile acquisire familiarità con le operazioni seguenti:

• Definire obiettivi di prestazioni e capacità per l'ambiente.

• Pianificare l'hardware necessario per supportare il numero e il tipo di utenti, nonché le caratteristiche che si intende distribuire.

• Progettare la topologia fisica e logica per un'affidabilità e un'efficienza ottimali.

• Testare, convalidare e adattare l'ambiente per raggiungere gli obiettivi di prestazioni e capacità.

• Monitorare l'ambiente in base a indicatori chiave.

Prima di leggere questo articolo, è consigliabile acquisire familiarità con quanto segue:

• Capacity management and sizing for SharePoint Server 2010

• Gestione della capacità di SharePoint Server 2010: Limiti software statici e configurabili

• Disponibilità

• Ridondanza

• Contenuto specifico di database

Panoramica della pianificazione

Negli scenari illustrati in questo articolo vengono descritte farm di testing di piccole medie e grandi dimensioni, con presupposti che consentono di iniziare la pianificazione della capacità appropriata per la farm. Queste dimensioni di farm sono approssimazioni basate sui presupposti seguenti:

• Gli archivi sottoposti a ricerca per indicizzazione sono costituiti principalmente da contenuto di SharePoint Server.

• La maggior parte delle query utente è concentrata nello stesso 33% dell'indice e pertanto la maggioranza degli utenti esegue query per gli stessi termini.

• Vengono utilizzate le impostazioni di metadati predefinite, in modo da evitare che il database delle proprietà aumenti rapidamente.

• Nelle farm di medie e grandi dimensioni sono presenti destinazioni dedicate della ricerca per indicizzazione (server Web front-end) che forniscono il contenuto ai componenti di ricerca per indicizzazione di queste farm di ricerca.

• Le misurazioni effettuate in queste farm possono variare a seconda delle condizioni ambientali e di rete, con un margine di errore massimo del 10%.

Scelta di uno scenario

Per scegliere lo scenario appropriato, valutare gli aspetti seguenti:

• Dimensioni del corpo dei dati Valutare la quantità di contenuto che deve supportare la ricerca. Nel numero totale di elementi devono essere contenuti tutti gli oggetti, inclusi documenti, pagine Web, elementi di elenco e utenti.

• Disponibilità Valutare i requisiti di disponibilità e se i clienti necessitano di una soluzione di ricerca in grado di ovviare agli errori di un server specifico.

• Livello di aggiornamento del contenuto Valutare il livello di aggiornamento desiderato per i risultati. Determinare dopo quanto tempo dalla modifica del contenuto da parte di un utente si desidera che venga fornito il contenuto aggiornato nei risultati delle ricerche e con quale frequenza si prevede che venga modificato il contenuto.

• Velocità effettiva Valutare quanti utenti effettueranno ricerche simultanee nel contenuto. In questa valutazione devono essere inclusi gli utenti che digitano testo in una casella query, le query nascoste come le web part che ricercano automaticamente i dati, nonché le istanze di Microsoft Outlook 2010 Social Connector che effettuano richieste di feed attività contenenti URL che necessitano della limitazione per motivi di sicurezza dal sistema di ricerca.

Sulla base di queste valutazioni, scegliere uno degli scenari seguenti:

• Farm di piccole dimensioni Include una singola applicazione del servizio di ricerca che condivide alcune risorse in una singola farm di SharePoint Server. Per le distribuzioni ridotte, la quantità di contenuto in cui consentire la ricerca è limitata (meno di 10 milioni di elementi). A seconda degli obiettivi di livello di aggiornamento desiderati, possono verificarsi ricerche per indicizzazione incrementali durante gli orari di ufficio.

• Farm di medie dimensioni Include una o più applicazioni del servizio di ricerca in una farm dedicata, che offre servizi di ricerca ad altre farm. La quantità di contenuto in cui consentire la ricerca è moderata (fino a 40 milioni di elementi) e per soddisfare gli obiettivi di livello di aggiornamento desiderati è probabile che si verifichino ricerche per indicizzazione incrementali durante gli orari di ufficio.

• Farm di grandi dimensioni Include una o più applicazioni del servizio di ricerca in una farm dedicata, che offre servizi di ricerca ad altre farm. La quantità di contenuto in cui consentire la ricerca è elevata (fino a 100 milioni di elementi) e per soddisfare gli obiettivi di livello di aggiornamento desiderati è probabile che si verifichino ricerche per indicizzazione incrementali durante gli orari di ufficio.

Ciclo di vita della ricerca

Questi tre scenari consentono di calcolare la capacità in una fase iniziale della farm. Man mano che viene eseguita la ricerca per indicizzazione del contenuto, le farm attraversano le fasi seguenti del ciclo di vita della ricerca:

• Acquisizione dell'indice Questa è la prima fase dell'inserimento dei dati. La durata di questa fase dipende dalle dimensioni delle origini di contenuto. È caratterizzata da quanto segue:

  • Ricerche per indicizzazione complete del contenuto (possibilmente simultanee).

  • Stretto monitoraggio del sistema di ricerca per indicizzazione per verificare che gli host sottoposti a ricerca per indicizzazione non costituiscano un collo di bottiglia.

  • Frequenti unioni dell'indice master che per ogni componente di query vengono attivate dopo che è stata modificata una determinata quantità di indice.

• Gestione dell'indice Questa è la fase più comune di una farm. È caratterizzata da quanto segue:

  • Ricerche per indicizzazione incrementali di tutto il contenuto.

  • Per le ricerche per indicizzazione del contenuto di SharePoint Server, la maggior parte delle modifiche rilevate durante la ricerca per indicizzazione è costituita da modifiche di sicurezza.

  • Le unioni dell'indice master sono poco frequenti e per ogni componente di query vengono attivate dopo che è stata modificata una determinata quantità di indice.

• Pulizia dell'indice Questa fase si verifica quando una modifica del contenuto comporta l'interruzione della fase di gestione dell'indice per la farm, ad esempio quando un sito o un database del contenuto viene spostato da un'applicazione del servizio di ricerca a un'altra. Questa fase viene attivata quando si verifica una delle condizioni seguenti:

  • Per un periodo di tempo esteso non è possibile per il crawler di ricerca trovare un host che fornisce contenuto.

  • Da un'applicazione del servizio di ricerca viene eliminata un'origine di contenuto o un indirizzo iniziale.

Scenari

In questa sezione vengono descritte le configurazioni che sono state utilizzate per gli scenari con farm di piccole, medie e grandi dimensioni. Sono inclusi inoltre il carico di lavoro, il set di dati, i dati sulle prestazioni e i dati dei test per ogni ambiente.

Farm di piccole dimensioni

Poiché la farm è di piccole dimensioni, alcuni dei server devono eseguire più ruoli. È consigliabile combinare un componente di query con un server Web front-end per evitare di posizionare i componenti della ricerca per indicizzazione e i componenti di query nello stesso server. In questa configurazione vengono utilizzati tre server applicazioni e un server di database, come indicato di seguito:

• Poiché viene generalmente suggerito l'utilizzo di server di query ridondanti per la ricerca di contenuti nell'organizzazione, sono stati utilizzati due server applicazioni per i componenti di query, sulla base della configurazione seguente:

  • Un server applicazioni ospita anche il Centro ricerche. Questa configurazione può essere omessa se la farm di piccole dimensioni viene utilizzata come farm di servizi e i Centri ricerche vengono creati in farm del contenuto figlio che utilizzano l'applicazione del servizio di ricerca di questa farm di servizi padre.

  • La configurazione di query preferita per meno di 10 milioni di elementi prevede l'utilizzo di una partizione di indice. Ogni server pertanto dispone di un componente di query principale della partizione di indice. Questa configurazione del componente di query attivo/attivo supporta l'errore di uno dei componenti di query, conservando la capacità di elaborare le query del componente di query restante. In caso di errore di un componente di query, il servizio di ricerca invia le query (round-robin) al componente di query disponibile successivo.

• Un server applicazioni utilizzato per la ricerca per indicizzazione e per l'amministrazione. In questo server pertanto vengono creati Amministrazione centrale, il componente di amministrazione della ricerca e un componente di ricerca per indicizzazione.

• Un singolo server di database per supportare la farm. Il server di database deve disporre di un numero dedicato di operazioni di input/output al secondo (IOPS) per i database di ricerca per indicizzazione, proprietà e amministrazione, ad esempio l'utilizzo di diversi array di archiviazione.

Specifiche

In questa sezione sono contenute informazioni dettagliate sull'hardware, il software, la topologia e la configurazione dell'ambiente di testing.

Topologia

Hardware

Server Web

Server Web	Server Web front-end/Query (1)
Processore	1px4c a 3 GHz
RAM	16 GB
Sistema operativo	Windows Server 2008 R2 a 64 bit
Spazio di archiviazione	2x450 GB 15 K SAS: RAID1: sistema operativo 2x450 GB 15 K SAS: RAID1: dati1 2x450 GB 15 K SAS: RAID1: dati2
Numero di schede di interfaccia di rete	2
Velocità schede di interfaccia di rete	1 gigabit
Autenticazione	NTLM
Tipo di servizio di bilanciamento del carico	Nessuno
Versione software	SharePoint Server 2010 (versione non definitiva)
Servizi in esecuzione localmente	Tutti i servizi (tra cui il Servizio query di ricerca e impostazioni sito)

Server applicazioni

Server	Query (1)	Ricerca per indicizzazione/Amministrazione (1)
Processore	1px4c a 3 GHz	1px4c a 3 GHz
RAM	16 GB	16 GB
Sistema operativo	Windows Server 2008 R2 a 64 bit	Windows Server 2008 R2 a 64 bit
Spazio di archiviazione	2x450 GB 15 K SAS:RAID1: sistema operativo 2x450 GB 15 K SAS:RAID1: dati1 2x450 GB 15 K SAS:RAID1: dati2	2x450 GB 15 K SAS: RAID1: sistema operativo 2x450 GB 15 K SAS: RAID1: temp 2x450 GB 15 K SAS: RAID0: dati
Numero di schede di interfaccia di rete	1	1
Velocità schede di interfaccia di rete	1 gigabit	1 gigabit
Autenticazione	NTLM	NTLM
Tipo di servizio di bilanciamento del carico	Nessuno	Nessuno
Versione software	SharePoint Server 2010 (versione non definitiva)	SharePoint Server 2010 (versione non definitiva)
Servizi in esecuzione localmente	Servizio di ricerca di SharePoint Server, Servizio query di ricerca e impostazioni sito	Servizio di ricerca di SharePoint Server

Server di database

Database	Condivisione (1)
Processore	2px4c a 3 GHz
RAM	16 GB
Sistema operativo	Windows Server 2008 R2 a 64 bit
Spazio di archiviazione	2x450 GB 15 K SAS: RAID1: sistema operativo 2x450 GB 15 K SAS: RAID0: dati 2x450 GB 15 K SAS: RAID0: registri Nota A causa del ridotto numero di unità, la procedura consigliata di separazione dei database in canali di I/O diversi non è stata applicabile.
Numero di schede di interfaccia di rete	2
Velocità schede di interfaccia di rete	1 gigabit
Autenticazione	NTLM
Versione software	Microsoft SQL Server 2008 Enterprise

Carico di lavoro

In questa sezione viene descritto il carico di lavoro utilizzato per la generazione di dati, inclusi il numero di utenti e le caratteristiche di utilizzo delle farm.

Caratteristiche del carico di lavoro	Valore
Descrizione generale del carico di lavoro	Farm di ricerca
Media di query al minuto	6
Media di utenti simultanei	1
Numero totale di query al giorno	8.640

Set di dati

In questa sezione viene descritto il set di dati della farm di testing, inclusi il contenuto e le dimensioni di database, gli indici di ricerca e le origini dati esterne.

Oggetto	Valore
Dimensione degli indici di ricerca (numero di elementi)	9 milioni
Dimensione del database di ricerca per indicizzazione	52 GB
Dimensione del file di registro del database di ricerca per indicizzazione	11 GB
Dimensione del database delle proprietà	68 GB
Dimensione del file di registro del database delle proprietà	1 GB
Dimensione del database di amministrazione della ricerca	2 GB
Dimensione delle partizioni di indice attive	38,4 GB (76,8 GB totali, poiché l'indice è con mirroring)
Numero totale di database di ricerca	3
Altri database	SharePoint_Config; SharePoint_AdminContent; State_Service; Bdc_Service_db; WSS_UsageApplication; WSS_Content

Dati relativi all'integrità e alle prestazioni

In questa sezione vengono forniti dati relativi all'integrità e alle prestazioni specifici dell'ambiente di testing.

Dati relativi alle prestazioni delle query

Le misurazioni riportate di seguito sono state effettuate su 9 milioni di elementi nell'indice. Nelle colonne vengono elencate le misurazioni che sono state effettuate nel corso del test specifico e i risultati sono riportati alla fine della tabella successiva. Le misurazioni sono le seguenti:

• Latenza delle query Queste misurazioni sono state effettuate durante un test di latenza delle query, in cui uno strumento di test ha inviato un insieme di query standard come utente singolo e quindi ha misurato la latenza risultante. Non erano in corso ricerche per indicizzazione durante il test.

• Velocità effettiva delle query Queste misurazioni sono state effettuate durante un test sulla velocità effettiva delle query, in cui uno strumento di test ha inviato un insieme standard di query per la farm, come numero in aumento di utenti simultanei (massimo 80), e quindi ha misurato la latenza e la velocità effettiva risultanti. Non erano in corso ricerche per indicizzazione durante il test.

	Metrica scorecard	Latenza query	Velocità effettiva query
Metriche CPU	CPU SQL Server media	3,4%	12%
	CPU server Web front-end media	8%	51%
	CPU server di query media	13,3%	95%
Affidabilità	Frequenza errori	0	0
	Arresti anomali server Web front-end	0	0
	Arresti anomali server applicazioni	0	0
SQL Server	Rapporti riscontri cache (SQL Server)	99,97%	100%
	Blocchi di SQL Server: tempo medio di attesa (ms)	0,071	0,038
	Blocchi di SQL Server: tempo di attesa blocchi (ms)	0,035	0,019
	Blocchi di SQL Server: deadlock/sec	0	0
	Latch di SQL Server: tempo medio di attesa (ms)	31	0,017
	Compilazioni SQL Server/sec	14,9	10,2
	Statistiche di SQL Server: ricompilazioni SQL Server/sec	0,087	0,05
	Lunghezza coda disco media (SQL Server)	0,011	0,01
	Lunghezza coda disco: scritture (SQL Server)	0,01	0,008
	Letture disco/sec (SQL Server)	0,894	0,05
	Scritture disco/sec (SQL Server)	45	106
Server applicazioni	Lunghezza coda disco media (server di query)	0,013	0,001
	Lunghezza coda disco: scritture (server di query)	0	0,001
	Letture disco/sec (server di query)	11,75	0,06
	Scritture disco/sec (server di query)	4	5,714
	Memoria media utilizzata (server di query)	8,73%	9%
	Memoria massima utilizzata (server di query)	8,75%	9%
Server Web front-end	Richieste ASP.NET in coda (media di tutti i server Web front-end)	0	0
	Memoria media utilizzata (server Web front-end)	9,67%	95%
	Memoria massima utilizzata (server Web front-end)	9,74%	100%
Risultati dei test	Numero di esiti positivi	1.757	13.608
	Numero di errori	0	0
	Latenza interfaccia utente query (75° percentile)	0,331 sec	3,68 sec
	Latenza interfaccia utente query (95° percentile)	0,424 sec	3,93 sec
	Velocità effettiva query	3,29 richieste/sec	22,4 richieste/sec

Dati sulle prestazioni della ricerca per indicizzazione

Le misurazioni seguenti sono state effettuate durante ricerche per indicizzazione complete iniziali sequenziali dell'origine di contenuto specifica. La dimensione dell'origine di contenuto è di milioni di elementi. Nelle colonne vengono fornite le misurazioni che sono state effettuate durante la ricerca per indicizzazione specifica e i risultati sono riportati alla fine della tabella.

	Metrica scorecard	Contenuto di SharePoint (4 M)	Condivisione file (1 M)	HTTP (non SharePoint) (1 M)
Metriche CPU	CPU SQL Server media	5,4%	11,7%	23%
	CPU indicizzatore media	41,6%	69%	71%
Affidabilità	Frequenza errori	0	0	0
	Arresti anomali server Web front-end	0	0	0
	Arresti anomali server applicazioni	0	0	0
SQL Server	Rapporti riscontri cache (SQL Server)	n/d	n/d	n/d
	Blocchi di SQL Server: tempo medio di attesa (ms)	436	51,76	84,73
	Blocchi di SQL Server: tempo di attesa blocchi (ms)	n/d	n/d	n/d
	Blocchi di SQL Server: deadlock/sec	n/d	n/d	n/d
	Latch di SQL Server: tempo medio di attesa (ms)	1,05	1,64	3,53
	Compilazioni SQL Server/sec	n/d	n/d	n/d
	Statistiche di SQL Server: ricompilazioni SQL Server/sec	n/d	n/d	n/d
	Lunghezza coda disco media (SQL Server)	27,124	6,85	45
	Lunghezza coda disco: scritture (SQL Server)	17,6	6,7	21,57
Server applicazioni	Lunghezza coda disco media (server di ricerca per indicizzazione)	0,008	0,032	0,02
	Lunghezza coda disco: scritture (server di ricerca per indicizzazione)	0,006	0,025	0,012
	Memoria media utilizzata (server di ricerca per indicizzazione)	14,16%	10,4%	11,5%
	Memoria massima utilizzata (server di ricerca per indicizzazione)	19,2%	11,13%	12,78%
Server Web front-end	Richieste ASP.NET in coda (media di tutti i server Web front-end)	0	0	0
	Memoria media utilizzata (server Web front-end)	n/d	n/d	n/d
	Memoria massima utilizzata (server Web front-end)	n/d	n/d	n/d
Risultati dei test	Numero di esiti positivi	3.934.881	1.247.838	996.982
	Numero di errori	9.645	302	2
	Velocità ricerca per indicizzazione portale (elementi/sec)	46,32	120,436	138,316
	Velocità ricerca per indicizzazione di ancoraggio (elementi/sec)	5.197	3.466,219	2.192,982
	Velocità ricerca per indicizzazione totale (elementi/sec)	45,91	116,392	130,086

Dati di test

In questa sezione vengono forniti dati di test che illustrano le prestazioni della farm. Fare riferimento alla sezione Ottimizzazioni più avanti in questo articolo per informazioni su come migliorare le prestazioni della farm.

Latenza delle query

Nel grafico riportato di seguito vengono mostrati i percentili di latenze delle query della farm man mano che aumenta il carico utente (dati raccolti durante il test di velocità effettiva delle query). Un percentile di query del 95% indica che il 95% delle latenze delle query misurate è stato inferiore a tale valore.

Da questo grafico è possibile osservare come con un indice più piccolo la farm possa mantenere una latenza di query dell'ordine inferiore al secondo, anche in presenza di più utenti simultanei (20) che eseguono query nella farm.

Velocità effettiva delle query

Nel grafico riportato di seguito viene mostrata la velocità effettiva delle query della farm man mano che aumenta il carico utente (dati raccolti durante il test di velocità effettiva delle query).

Considerando i due grafici precedenti, è possibile osservare come superando il carico utente di circa 20 utenti simultanei, questa farm non otterrà un aumento della velocità effettiva delle query e si verificherà un aumento della latenza.

Velocità della ricerca per indicizzazione

Nel grafico riportato di seguito viene illustrata la velocità della ricerca per indicizzazione per la farm durante la fase di acquisizione dell'indice del ciclo di vita della ricerca. I valori rappresentano una ricerca per indicizzazione completa, in elementi sottoposti a ricerca per indicizzazione al secondo.

Il sovraccarico aggiuntivo per l'esecuzione di una ricerca per indicizzazione completa in un'origine di contenuto del sito di SharePoint determina una riduzione della velocità della ricerca per indicizzazione globale nella farm.

Area di intervento globale

Questa farm ha quasi raggiunto la capacità della RAM per i server di query. Poiché i processi dei server Web front-end (che utilizzano la RAM) sono stati eseguiti anche in uno dei server di query, si sarebbe verificato un aumento della latenza per le query eseguite nel server.

I passaggi successivi per migliorare le prestazioni di questa farm sarebbero i seguenti:

• Spostare i processi dei server Web front-end nei relativi server Web front-end, ovvero aggiungere un altro server Web front-end per la ridondanza.

• Aggiungere ulteriore RAM in entrambi i server di query. È consigliabile aggiungere sufficiente RAM nel server di query per il 33% della partizione di indice del componente di query attivo più 3 GB per il sistema operativo e altri processi.

• Aggiungere array di archiviazione in modo da poter separare i database nel server di database.

Farm di medie dimensioni

Nella configurazione di farm di medie dimensioni vengono utilizzati un server Web, sei server applicazioni e due server di database come indicato di seguito:

• In questa configurazione di test viene utilizzato un server Web per ospitare il Centro ricerche. Questo server Web può essere omesso se le ricerche vengono eseguite sempre a partire da una farm figlio utilizzando un proxy applicazione del servizio di ricerca (installato nella farm figlio). In caso contrario, probabilmente sarebbe necessario aggiungere un altro server Web alla farm per ridondanza.

• Vengono utilizzati due server applicazioni per la ricerca per indicizzazione e per l'amministrazione. Questo comporta quanto segue:

  • Amministrazione centrale e il componente di amministrazione di ricerca vengono creati in uno dei server applicazioni.

  • Ogni server dispone di due componenti di ricerca per indicizzazione, ognuno collegato per la ridondanza a un database di ricerca per indicizzazione diverso.

• I quattro server applicazioni restanti vengono utilizzati per le query. Per un massimo di 40 milioni di elementi la configurazione standard deve prevedere quattro partizioni di indice. La funzionalità di ridondanza delle query si ottiene distribuendo i componenti di query in modo che ogni server disponga di un componente di query attivo da una delle partizioni di indice e di un componente di query di failover da una partizione di indice diversa. In questa farm di esempio tuttavia viene mostrato come procedere per una pianificazione di oltre 40 milioni di elementi. Si inizia con otto partizioni di indice (ognuna con i propri componenti di query attivo e di failover) nei quattro server applicazioni in modo da ridurre al minimo il ripartizionamento dell'indice. Si presuppone che ogni server soddisfi le linee guida seguenti per consentire l'utilizzo di quattro componenti nello stesso server applicazioni:

  • Disponibilità di RAM e di operazioni di input/output al secondo (IOPS) sufficienti.

  • Più di sei CPU core in ogni server per supportare l'elaborazione come indicato di seguito:

    • Quattro CPU core per i due componenti di query attivi.

    • Due CPU core per i due componenti di query di failover.

• Due server di database supportano la farm. Un server di database viene utilizzato per i due database di ricerca per indicizzazione, l'altro per i database delle proprietà e di amministrazione della ricerca oltre che per gli altri database di SharePoint. I server di database devono disporre di un numero dedicato di operazioni di input/output al secondo (IOPS) per ogni database di ricerca per indicizzazione, delle proprietà e di amministrazione della ricerca. Utilizzare ad esempio array di archiviazione diversi.

Specifiche

In questa sezione sono contenute informazioni dettagliate sull'hardware, il software, la topologia e la configurazione dell'ambiente di testing.

Topologia

Hardware

Server Web

Server Web	Server Web front-end (1)
Processore	2px4c a 2,33 GHz
RAM	8 GB
Sistema operativo	Windows Server 2008 R2 a 64 bit
Spazio di archiviazione	2x148 GB 15 K SAS: RAID1: sistema operativo
Numero di schede di interfaccia di rete	2
Velocità schede di interfaccia di rete	1 gigabit
Autenticazione	NTLM
Tipo di servizio di bilanciamento del carico	Nessuno
Versione software	Microsoft SharePoint Server (versione non definitiva)
Servizi in esecuzione localmente	Tutti i servizi

Server applicazioni

Nella farm sono presenti sei server applicazioni, quattro vengono utilizzati per la gestione delle query e due per la ricerca per indicizzazione.

Server (conteggio)	Query (4)	Ricerca per indicizzazione (1), Ricerca per indicizzazione/Amministrazione (1)
Processore	2px4c a 2,33 GHz	2px4c a 2,33 GHz
RAM	32 GB	8 GB
Sistema operativo	Windows Server 2008 R2 a 64 bit	Windows Server 2008 R2 a 64 bit
Spazio di archiviazione	2x148 GB 15 K SAS: RAID1: sistema operativo 4x300 GB 15 K SAS:RAID10:dati	2x148 GB 15 K SAS:RAID1: sistema operativo/dati
Numero di schede di interfaccia di rete	2	2
Velocità schede di interfaccia di rete	1 gigabit	1 gigabit
Autenticazione	NTLM	NTLM
Tipo di servizio di bilanciamento del carico	Nessuno	Nessuno
Versione software	SharePoint Server 2010 (versione non definitiva)	SharePoint Server 2010 (versione non definitiva)
Servizi in esecuzione localmente	Servizio di ricerca di SharePoint Server, Servizio query di ricerca e impostazioni sito	Servizio di ricerca di SharePoint Server

Server di database

Sono presenti due server di database. Il primo contiene i database delle proprietà, di amministrazione della ricerca e altri database di SharePoint Server. Il secondo contiene i due database di ricerca per indicizzazione. Si noti che i volumi dello spazio di archiviazione creati hanno ottimizzato l'hardware esistente disponibile per il test.

Server di database	Database di amministrazione della ricerca, delle proprietà e di SharePoint	Database di ricerca per indicizzazione
Processore	2px4c a 3,2 GHz	4px2c a 2,19 GHz
RAM	32 GB	16 GB
Sistema operativo	Windows Server 2008 R2 a 64 bit	Windows Server 2008 R2 a 64 bit
Spazio di archiviazione	2x148 GB 15 K SAS: RAID1: sistema operativo 2x148 GB 15 K SAS :RAID1: registro temp 2x450 GB 15 K SAS :RAID1: db temp 6x450 GB 15 K SAS :RAID10: db proprietà 2x450 GB 15 K SAS :RAID1: db di amministrazione della ricerca e di SharePoint 2x450 GB 15 K SAS :RAID1: registri	2x148 GB 15 K SAS: RAID1: sistema operativo 2x148 GB 15 K SAS :RAID1: registro temp 2x300 GB 15 K SAS :RAID1: db temp 6x146 GB 15 K SAS :RAID10: db1 di ricerca per indicizzazione 6x146 GB 15 K SAS :RAID10: db2 di ricerca per indicizzazione 2x300 GB 15 K SAS :RAID1: registro1 db di ricerca per indicizzazione 2x300 GB 15 K SAS :RAID1:registro2 db di ricerca per indicizzazione
Numero di schede di interfaccia di rete	2	2
Velocità schede di interfaccia di rete	1 gigabit	1 gigabit
Autenticazione	NTLM	NTLM
Versione software	SQL Server 2008 Enterprise	SQL Server 2008 Enterprise

Carico di lavoro

In questa sezione viene descritto il carico di lavoro utilizzato per la generazione di dati, inclusi il numero di utenti e le caratteristiche di utilizzo delle farm.

Caratteristiche del carico di lavoro	Valore
Descrizione generale del carico di lavoro	Farm di ricerca
Media di query al minuto	12
Media di utenti simultanei	1
Numero totale di query al giorno	17.280
Processi timer	Monitoraggio dello stato della ricerca - Traccia eventi, Rapporto registro di ricerca per indicizzazione, Processo di analisi integrità; Ricerca ed elaborazione

Set di dati

In questa sezione viene descritto il set di dati della farm di testing, inclusi il contenuto e le dimensioni di database, gli indici di ricerca e le origini dati esterne.

Oggetto	Valore
Dimensione degli indici di ricerca (numero di elementi)	46 milioni
Dimensione del database di ricerca per indicizzazione	356 GB
Dimensione del file di registro del database di ricerca per indicizzazione	85 GB
Dimensione del database delle proprietà	304 GB
Dimensione del file di registro del database delle proprietà	9 GB
Dimensione del database di amministrazione della ricerca	5 GB
Dimensione delle partizioni di indice attive	316 GB (79 GB per componente attivo)
Numero totale di database	4
Altri database	SharePoint_Config; SharePoint_AdminContent; State_Service; Bdc_Service_db; WSS_UsageApplication; WSS_Content

Dati relativi all'integrità e alle prestazioni

In questa sezione vengono forniti dati relativi all'integrità e alle prestazioni specifici dell'ambiente di testing.

Dati relativi alle prestazioni delle query

Le misurazioni riportate di seguito sono state effettuate su 46 milioni di elementi nell'indice di ricerca. Nelle colonne vengono elencate le misurazioni che sono state effettuate nel corso del test specifico e i risultati sono riportati alla fine della tabella. Le misurazioni sono le seguenti:

• Latenza delle query Queste misurazioni sono state effettuate durante un test di latenza delle query, in cui uno strumento di test ha inviato un insieme di query standard come utente singolo e quindi ha misurato la latenza risultante. Non erano in corso ricerche per indicizzazione durante il test.

• Velocità effettiva delle query Queste misurazioni sono state effettuate durante un test sulla velocità effettiva delle query, in cui uno strumento di test ha inviato un insieme standard di query per la farm, come numero in aumento di utenti simultanei (massimo 80), e quindi ha misurato la latenza e la velocità effettiva risultanti. Non erano in corso ricerche per indicizzazione durante il test.

	Metrica scorecard	Latenza delle query	Velocità effettiva delle query
Metriche CPU	CPU SQL Server media (server di database delle proprietà)	5%	98%
	CPU server Web front-end media	3%	33%
	CPU server di query media	3%	47%
Affidabilità	Frequenza errori	0,07%	0%
	Arresti anomali server Web front-end	0	0
	Arresti anomali server applicazioni	0	0
SQL Server (server di database delle proprietà)	Rapporti riscontri cache (SQL Server)	100%	99,9%
	Blocchi di SQL Server: tempo medio di attesa (ms)	0,000	0,159
	Blocchi di SQL Server: tempo di attesa blocchi (ms)	0,000	0,080
	Blocchi di SQL Server: deadlock/sec	0	0
	Latch di SQL Server: tempo medio di attesa (ms)	0,041	1,626
	Compilazioni SQL Server/sec	9,776	93,361
	Statistiche di SQL Server: ricompilazioni SQL Server/sec	0,059	0,071
	Rapporto lettura/scrittura (IO per database)	0,01	0,81
	Lunghezza coda disco media (SQL Server)	0,001	0,037
	Lunghezza coda disco: scritture (SQL Server)	0,000	0,003
	Letture disco/sec (SQL Server)	0,057	14,139
	Scritture disco/sec (SQL Server)	4,554	17,515
Server applicazioni	Lunghezza coda disco media (server di query)	0,000	0,001
	Lunghezza coda disco: scritture (server di query)	0,000	0,001
	Letture disco/sec (server di query)	0,043	0,266
	Scritture disco/sec (server di query)	4,132	5,564
	Memoria media utilizzata (server di query)	9%	10%
	Memoria massima utilizzata (server di query)	9%	10%
Server Web front-end	Richieste ASP.NET in coda (media di tutti i server Web front-end)	0	0
	Memoria media utilizzata (server Web front-end)	47%	48%
	Memoria massima utilizzata (server Web front-end)	47%	49%
Risultati dei test	Numero di esiti positivi	1.398	14.406
	Numero di errori	1	0
	Latenza interfaccia utente query (75° percentile)	0,47 sec	2,57 sec
	Latenza interfaccia utente query (95° percentile)	0,65 sec	3,85 sec
	Velocità effettiva delle query	2,38 richieste/sec	27,05 richieste/sec

Dati sulle prestazioni della ricerca per indicizzazione

Le misurazioni seguenti sono state effettuate durante ricerche per indicizzazione iniziali complete dell'origine di contenuto specifica. La dimensione dell'origine di contenuto è di milioni di elementi. Nelle colonne vengono fornite le misurazioni che sono state effettuate durante la ricerca per indicizzazione specifica e i risultati sono riportati alla fine della tabella.

	Metrica scorecard	Contenuto di SharePoint (3,5 milioni)	Condivisione file (1 milione)	HTTP (non SharePoint) (1 milione)
Metriche CPU	CPU SQL Server media (server di database di ricerca per indicizzazione, server di database delle proprietà)	11%, 19%	22%, 7%	23%, 5%
	CPU SQL Server massima (server di database di ricerca per indicizzazione, server di database delle proprietà)	96%, 100%	86%, 45%	79%, 28%
	CPU indicizzatore media	41,6%	69%	71%
Affidabilità	Frequenza errori	0,2%	0,02%	0%
	Arresti anomali server Web front-end	0	0	0
	Arresti anomali server applicazioni	0	0	0
SQL Server (server di database di ricerca per indicizzazione, server di database delle proprietà)	Rapporti riscontri cache (SQL Server)	99,5%, 99,8%	Non raccolta	99,9%, 99,3%
	Blocchi di SQL Server: tempo medio di attesa [ms]	1.881,749, 1.106,314	1.617,980, 2,882	983,137, 0,904
	Blocchi di SQL Server: tempo massimo di attesa [ms]	69.919,500, 1.081.703	55.412,000, 304,500	24.000,500, 47
	Blocchi di SQL Server: tempo medio di attesa blocchi [ms]	339,658, 10.147,012	Non raccolta	739,232, 0,136
	Blocchi di SQL Server: tempo massimo di attesa blocchi [ms]	598.106,544, 234.708,784	Non raccolta	52.711,592, 23,511
	Blocchi di SQL Server: deadlock/sec	0,001, 0	Non raccolta	0,008, 0
	Latch di SQL Server: tempo medio di attesa [ms]	2,288, 13,684	3,042, 13,516	2,469, 20,093
	Latch di SQL Server: tempo massimo di attesa [ms]	2.636, 1.809	928, 858,5	242,929, 938,706
	Compilazioni SQL Server/sec: media	20,384, 5,449	Non raccolta	76,157, 6,510
	Compilazioni SQL Server/sec: valore massimo	332,975, 88,992	Non raccolta	295,076, 42,999
	Statistiche di SQL Server: ricompilazioni SQL Server/sec: media	0,560, 0,081	Non raccolta	0,229, 0,125
	Statistiche di SQL Server: ricompilazioni SQL Server/sec: valore massimo	22,999, 88,492	Non raccolta	17,999, 15,5
	Rapporto lettura/scrittura (IO per database): valore massimo	2,15, 1,25	Non raccolta	1,45, 0,364
	Lunghezza coda disco media (SQL Server)	66,765, 27,314	129,032, 20,665	182,110, 11,816
	Lunghezza coda disco massima (SQL Server)	4.201,185, 5.497,980	3.050,015, 762,542	1.833,765, 775,7
	Lunghezza coda disco: scritture (SQL Server): media	58,023, 13,532	114,197, 19,9	175,621, 10,417
	Lunghezza coda disco: scritture (SQL Server): valore massimo	1.005,691, 881,892	1.551,437, 761,891	1.018,642, 768,289
	Letture disco/sec (SQL Server): media	245,945, 94,131	Non raccolta	137,435, 154,103
	Letture disco/sec (SQL Server): valore massimo	6.420,412, 6.450,870	Non raccolta	3.863,283, 1.494,805
	Scritture disco/sec (SQL Server): media	458,144, 286,884	Non raccolta	984,668, 278,175
	Scritture disco/sec (SQL Server): valore massimo	2.990,779, 5.164,949	Non raccolta	2.666,285, 4.105,897
Server applicazioni	Lunghezza coda disco media (server di ricerca per indicizzazione)	0,052	0,043	0,030
	Lunghezza coda disco: scritture (server di ricerca per indicizzazione)	0,029	0,031	0,026
	Letture disco/sec (server di ricerca per indicizzazione)	5,405	Non raccolta	0,798
	Scritture disco/sec (server di ricerca per indicizzazione)	48,052	Non raccolta	102,235
	Memoria media utilizzata (server di ricerca per indicizzazione)	68%	45%	52%
	Memoria massima utilizzata (server di ricerca per indicizzazione)	76%	47%	59%
Server Web front-end	Richieste ASP.NET in coda (media di tutti i server Web front-end)	0	0	0
	Memoria media utilizzata (server Web front-end)	n/d	n/d	n/d
	Memoria massima utilizzata (server Web front-end)	n/d	n/d	n/d
Risultati dei test	Numero di esiti positivi	3.631.080	1.247.838	200.000
	Numero di errori	7.930	304	0
	Velocità ricerca per indicizzazione portale (elementi/sec)	82	148	81
	Velocità ricerca per indicizzazione di ancoraggio (elementi/sec)	1.573	1.580	1.149
	Velocità ricerca per indicizzazione totale (elementi/sec)	79	136	76

Dati di test

In questa sezione vengono forniti dati di test che illustrano le prestazioni della farm sotto carico.

Latenza delle query

Nel grafico riportato di seguito vengono mostrati i percentili di latenze delle query della farm man mano che aumenta il carico utente (dati raccolti durante il test di velocità effettiva delle query). Un percentile di query del 95% indica che il 95% delle latenze delle query misurate è stato inferiore a tale valore.

Da questo grafico è possibile osservare come con un indice più piccolo la farm possa mantenere una latenza di query dell'ordine inferiore al secondo al novantacinquesimo percentile, anche in presenza di più utenti simultanei (22) che eseguono query nella farm.

Velocità effettiva delle query

Nel grafico riportato di seguito viene mostrata la velocità effettiva delle query della farm man mano che aumenta il carico utente (dati raccolti durante il test di velocità effettiva delle query).

Considerando sia questo grafico che quello precedente, è possibile osservare che, con 33 milioni di elementi nell'indice, la farm può mantenere una latenza inferiore al secondo al settantacinquesimo percentile con circa 30 utenti simultanei. È ancora consentito ulteriore carico utente, ma la latenza delle query non sarà più limitata a un ordine inferiore al secondo.

Con 46 milioni di elementi nell'indice tuttavia non è consentito ulteriore carico utente e la latenza delle query aumenterà.

Velocità della ricerca per indicizzazione

Nel grafico riportato di seguito viene illustrata la velocità della ricerca per indicizzazione per la farm durante la fase di acquisizione dell'indice del ciclo di vita della ricerca. I valori rappresentano una ricerca per indicizzazione completa, in elementi sottoposti a ricerca per indicizzazione al secondo.

Il sovraccarico aggiuntivo per l'esecuzione di una ricerca per indicizzazione in un'origine di contenuto del sito di SharePoint determina una riduzione della velocità della ricerca per indicizzazione globale nella farm.

Area di intervento globale

Questa farm ha quasi raggiunto la capacità della RAM per i server di query.

I passaggi successivi per migliorare le prestazioni di questa farm sarebbero i seguenti:

• Aggiungere ulteriore RAM in entrambi i server di query. È consigliabile aggiungere sufficiente RAM nel server di query per il 33% della partizione di indice del componente di query attivo più 3 GB per il sistema operativo e altri processi.

• Aggiungere ulteriore RAM al server di database che ospita il database delle proprietà. In questa configurazione la dimensione delle tabelle chiave è di circa 92 GB, inclusi gli indici, il che indica un requisito di 30 GB di RAM. Il server di database tuttavia dispone solo di 32 GB di RAM per la gestione del database delle proprietà, del database di ricerca dell'amministrazione e di altri database di SharePoint Server.

• Aggiungere array di archiviazione in modo da poter separare i database nel server di database.

• Implementare la scalabilità orizzontale per aumentare la velocità effettiva, ridurre la latenza delle query o entrambe le soluzioni.

Benché la velocità della ricerca per indicizzazione sia elevata in questa farm con due database di ricerca per indicizzazione e quattro componenti di ricerca per indicizzazione, può essere un obiettivo importante per la farm disporre di alcune parti dell'indice più aggiornate, ovvero determinato contenuto che deve essere sottoposto a ricerca per indicizzazione molto frequentemente. L'aggiunta di un altro database di ricerca per indicizzazione dedicato agli host nell'origine di contenuto desiderata (con regole di distribuzione host) e l'associazione di due componenti di ricerca per indicizzazione aggiuntivi con il database garantisce il raggiungimento dell'obiettivo del livello di aggiornamento dell'indice.

Farm di grandi dimensioni

Nella configurazione prevista vengono utilizzati un server Web, 13 server applicazioni e tre server di database come indicato di seguito:

• Un server Web viene utilizzato per ospitare un Centro ricerche. Questo server Web può essere omesso se le ricerche vengono eseguite sempre a partire da una farm del contenuto utilizzando un proxy applicazione del servizio di ricerca (installato nella farm del contenuto).

• Vengono utilizzati tre server applicazioni per la ricerca per indicizzazione e per l'amministrazione. Questo comporta quanto segue:

  • Amministrazione centrale e il componente di amministrazione di ricerca vengono creati in uno dei server applicazioni.

  • Ogni server dispone di due componenti di ricerca per indicizzazione, ognuno collegato a un database di ricerca per indicizzazione diverso.

• I dieci server applicazioni restanti vengono utilizzati per le query. La configurazione preferita prevede dieci partizioni di indice. Ogni server dispone quindi di un componente di query principale di una delle partizioni di indice, oltre a un componente di query di failover di una partizione di indice diversa.

• Quattro server di database supportano la farm. Un server viene utilizzato per i database delle proprietà e di amministrazione della ricerca. Un secondo server viene utilizzato per un database delle proprietà. Un terzo server viene utilizzato per due database di ricerca per indicizzazione. Il quarto server viene utilizzato per un database di ricerca per indicizzazione e per gli altri database di SharePoint. I server di database devono disporre di un numero dedicato di operazioni di input/output al secondo (IOPS) per ogni database di ricerca per indicizzazione, delle proprietà e di amministrazione della ricerca, ad esempio l'utilizzo di diversi array di archiviazione.

Specifiche

In questa sezione sono contenute informazioni dettagliate sull'hardware, il software, la topologia e la configurazione dell'ambiente di testing.

Topologia

In questa sezione viene descritta la topologia dell'ambiente di testing.

Hardware

In questa sezione viene descritto l'hardware utilizzato per il testing.

Server Web

Server Web	Server Web front-end (1)
Processore	2px4c a 2,33 GHz
RAM	8 GB
Sistema operativo	Windows Server 2008 R2 a 64 bit
Spazio di archiviazione	2x148 GB 15 K SAS: RAID1: sistema operativo
Numero di schede di interfaccia di rete	2
Velocità schede di interfaccia di rete	1 gigabit
Autenticazione	NTLM
Tipo di servizio di bilanciamento del carico	Nessuno
Versione software	SharePoint Server 2010 (versione non definitiva)
Servizi in esecuzione localmente	Tutti i servizi

Server applicazioni

Nella farm sono presenti 13 server applicazioni, 10 vengono utilizzati per la gestione delle query e tre per la ricerca per indicizzazione.

Server (conteggio)	Query (10)	Ricerca per indicizzazione (2), Ricerca per indicizzazione/Amministrazione (1)
Processore	2px4c a 2,5 GHz	2px4c a 2,5 GHz
RAM	32 GB	32 GB
Sistema operativo	Windows Server 2008 R2 a 64 bit	Windows Server 2008 R2 a 64 bit
Spazio di archiviazione	2x148 GB 15 K SAS: RAID1: sistema operativo 4x300 GB 15 K SAS:RAID10:dati	2x148 GB 15 K SAS: RAID1: sistema operativo/dati
Numero di schede di interfaccia di rete	2	2
Velocità schede di interfaccia di rete	1 gigabit	1 gigabit
Autenticazione	NTLM	NTLM
Tipo di servizio di bilanciamento del carico	Nessuno	Nessuno
Versione software	SharePoint Server 2010 (versione non definitiva)	SharePoint Server 2010 (versione non definitiva)
Servizi in esecuzione localmente	Servizio di ricerca di SharePoint Server, Servizio query di ricerca e impostazioni sito	Servizio di ricerca di SharePoint Server

Server di database.

Sono presenti quattro server di database. Il primo server contiene i database delle proprietà e di amministrazione della ricerca, il secondo un database delle proprietà, il terzo due database di ricerca per indicizzazione e il quarto un database di ricerca per indicizzazione e un database di SharePoint. Si noti che i volumi dello spazio di archiviazione creati hanno ottimizzato l'hardware esistente disponibile per il test.

Server di database	Database di amministrazione della ricerca, delle proprietà e di SharePoint	Database di ricerca per indicizzazione
Processore	2px4c a 3,2 GHz	4px2c a 2,19 GHz
RAM	32 GB	16 GB
Sistema operativo	Windows Server 2008 R2 a 64 bit	Windows Server 2008 R2 a 64 bit
Spazio di archiviazione	2x148 GB 15 K SAS: RAID1: sistema operativo 2x148 GB 15 K SAS :RAID1: registro temp 2x450 GB 15 K SAS :RAID1: db temp 6x450 GB 15 K SAS :RAID10: db proprietà 2x450 GB 15 K SAS :RAID1: db di amministrazione della ricerca e di SharePoint 2x450 GB 15 K SAS :RAID1: registri	2x148 GB 15 K SAS: RAID1: sistema operativo 2x148 GB 15 K SAS :RAID1: registro temp 2x300 GB 15 K SAS :RAID1: db temp 6x146 GB 15 K SAS :RAID10: db1 di ricerca per indicizzazione 6x146 GB 15 K SAS :RAID10: db2 di ricerca per indicizzazione 2x300 GB 15 K SAS :RAID1: registro1 db di ricerca per indicizzazione 2x300 GB 15 K SAS :RAID1:registro2 db di ricerca per indicizzazione
Numero di schede di interfaccia di rete	2	2
Velocità schede di interfaccia di rete	1 gigabit	1 gigabit
Autenticazione	NTLM	NTLM
Versione software	SQL Server 2008 Enterprise	SQL Server 2008 Enterprise

Dati relativi alle prestazioni delle query

Le misurazioni riportate di seguito sono state effettuate su 103 milioni di elementi nell'indice. Nelle colonne vengono elencate le misurazioni che sono state effettuate nel corso del test specifico e i risultati sono riportati alla fine della tabella. Le misurazioni sono le seguenti:

• Latenza delle query Queste misurazioni sono state effettuate durante un test di latenza delle query, in cui uno strumento di test ha inviato un insieme di query standard come utente singolo e ha misurato la latenza risultante. Non erano in corso ricerche per indicizzazione durante il test.

• Velocità effettiva delle query Queste misurazioni sono state effettuate durante un test sulla velocità effettiva delle query, in cui uno strumento di test ha inviato un insieme standard di query per la farm, come numero in aumento di utenti simultanei (massimo 120), e ha misurato la latenza e la velocità effettiva risultanti. Non erano in corso ricerche per indicizzazione durante il test.

	Metrica scorecard	Velocità effettiva delle query
Metriche CPU	CPU SQL Server media (server di database delle proprietà)	34%
	CPU server Web front-end media	45%
	CPU server di query media	20%
Affidabilità	Frequenza errori	0%
	Arresti anomali server Web front-end	0
	Arresti anomali server applicazioni	0
SQL Server (server di database delle proprietà)	Rapporti riscontri cache (SQL Server)	100%
	Blocchi di SQL Server: tempo medio di attesa (ms)	0
	Blocchi di SQL Server: tempo di attesa blocchi (ms)	0
	Blocchi di SQL Server: deadlock/sec	0
	Latch di SQL Server: tempo medio di attesa (ms)	1,401
	Compilazioni SQL Server/sec	73,349
	Statistiche di SQL Server: ricompilazioni SQL Server/sec	0,006
	Rapporto lettura/scrittura (IO per database)	0,81
	Lunghezza coda disco media (SQL Server)	0,037
	Lunghezza coda disco: scritture (SQL Server)	0,003
	Letture disco/sec (SQL Server)	9,88
	Scritture disco/sec (SQL Server)	354,1
Server applicazioni	Lunghezza coda disco media (server di query)	0,002
	Lunghezza coda disco: scritture (server di query)	0,002
	Letture disco/sec (server di query)	0,035
	Scritture disco/sec (server di query)	6,575
	Memoria media utilizzata (server di query)	6,548%
	Memoria massima utilizzata (server di query)	6,601%
Server Web front-end	Richieste ASP.NET in coda (media di tutti i server Web front-end)	0
	Memoria media utilizzata (server Web front-end)	18,081%
	Memoria massima utilizzata (server Web front-end)	19,983%
Risultati dei test	Numero di esiti positivi	10.925
	Numero di errori	0
	Latenza interfaccia utente query (75° percentile)	3,431 sec
	Latenza interfaccia utente query (95° percentile)	3,512 sec
	Velocità effettiva delle query	36,42 richieste/sec

Dati sulle prestazioni della ricerca per indicizzazione

Le misurazioni seguenti sono state effettuate durante ricerche per indicizzazione complete iniziali sequenziali dell'origine di contenuto specifica. La dimensione del contenuto è di milioni di elementi. Nelle colonne vengono fornite le misurazioni che sono state effettuate durante la ricerca per indicizzazione specifica e i risultati sono riportati alla fine della tabella.

	Metrica scorecard	Contenuto di SharePoint (3,5 milioni)	Condivisione file (1 milione)
Metriche CPU	CPU SQL Server media (server di database di ricerca per indicizzazione, server di database delle proprietà)	15,74%, N/D	24%, 6,6%
	CPU SQL Server massima (server di database di ricerca per indicizzazione, server di database delle proprietà)	100%, N/D%	100%, 45%
	CPU indicizzatore media	44%	49%
Affidabilità	Frequenza errori	0,0%	0,00%
	Arresti anomali server Web front-end	0	0
	Arresti anomali server applicazioni	0	0
SQL Server (server di database di ricerca per indicizzazione, server di database delle proprietà)	Rapporti riscontri cache (SQL Server)	99,8%, N/D%	99,797%, 99,49%
	Blocchi di SQL Server: tempo medio di attesa [ms]	734,916, N/D	1.165, 5,866
	Blocchi di SQL Server: tempo massimo di attesa [ms]	15.335, N/D	28.683, 210,5
	Blocchi di SQL Server: tempo medio di attesa blocchi [ms]	108,98, N/D	847,72, 5,325
	Blocchi di SQL Server: tempo massimo di attesa blocchi [ms]	17.236,96, N/D	124.353, 12.920
	Blocchi di SQL Server: deadlock/sec	0, N/D	0,012, 0
	Latch di SQL Server: tempo medio di attesa [ms]	1,4, N/D	2,233, 40,6
	Latch di SQL Server: tempo massimo di attesa [ms]	1.606, N/D	917,8, 1.895
	Compilazioni SQL Server/sec: media	24,28, N/D	72,7, 11,39
	Compilazioni SQL Server/sec: valore massimo	416, N/D	460, 76,62
	Statistiche di SQL Server: ricompilazioni SQL Server/sec: media	0,560, N/D	0,295, 0,099
	Statistiche di SQL Server: ricompilazioni SQL Server/sec: valore massimo	0,24, N/D	17,50, 17,393
	Rapporto lettura/scrittura (IO per database): valore massimo	20,3, N/D	1,18/0,214
	Lunghezza coda disco media (SQL Server)	90,113, N/D	138,64, 27,478
	Lunghezza coda disco massima (SQL Server)	3.179, N/D	2.783,543, 847,574
	Lunghezza coda disco: scritture (SQL Server): media	86,93, N/D	130.853, 26,086
	Lunghezza coda disco: scritture (SQL Server): valore massimo	1.882, N/D	2.781,197, 884,801
	Letture disco/sec (SQL Server): media	99, N/D	147,462, 159,159
	Letture disco/sec (SQL Server): valore massimo	3.772, N/D	2.403,336, 896,462
	Scritture disco/sec (SQL Server): media	373, N/D	475,886, 539,497
	Scritture disco/sec (SQL Server): valore massimo	18.522, N/D	2.031,888, 4.174,271
Server applicazioni	Lunghezza coda disco media (server di ricerca per indicizzazione)	0,075	0,063
	Lunghezza coda disco: scritture (server di ricerca per indicizzazione)	0,046	0,053
	Letture disco/sec (server di ricerca per indicizzazione)	1,958	1,693
	Scritture disco/sec (server di ricerca per indicizzazione)	62,33	101,093
	Memoria media utilizzata (server di ricerca per indicizzazione)	59%	56,38%
	Memoria massima utilizzata (server di ricerca per indicizzazione)	70%	58,93%
Server Web front-end	Richieste ASP.NET in coda (media di tutti i server Web front-end)	N/D	N/D
	Memoria media utilizzata (server Web front-end)	N/D	N/D
	Memoria massima utilizzata (server Web front-end)	N/D	N/D
Risultati dei test	Numero di esiti positivi	1.909.739	1.247.838
	Numero di errori	9.361	331
	Velocità ricerca per indicizzazione portale (elementi/sec)	70,3	131,44
	Velocità ricerca per indicizzazione di ancoraggio (elementi/sec)	764	525,84
	Velocità ricerca per indicizzazione totale (elementi/sec)	64	105

Suggerimenti e risoluzione dei problemi

Nelle sezioni che seguono vengono forniti suggerimenti per la determinazione dell'hardware, della topologia e della configurazione necessari per distribuire ambienti simili a questi scenari, nonché per l'ottimizzazione dell'ambiente per caratteristiche di capacità e prestazioni appropriate.

Suggerimenti

In questa sezione vengono descritte azioni specifiche che possono essere eseguite per ottimizzare l'ambiente per caratteristiche di capacità e prestazioni appropriate.

Consigli per i componenti hardware

Per informazioni specifiche sui requisiti di sistema globali minimi e consigliati, vedere Requisiti hardware e software (SharePoint Server 2010). Si noti che i requisiti per i server utilizzati per il servizio di ricerca hanno la priorità sui requisiti di sistema globali. Utilizzare le linee guida consigliate seguenti per soddisfare gli obiettivi di prestazioni per RAM, processore e operazioni di input/output al secondo (IOPS).

Dimensioni del servizio di ricerca

In questa sezione viene descritto il sistema di ricerca, inclusi i requisiti e le linee guida per le dimensioni, per componente.

SharePoint Server 2010 può essere distribuito e configurato in molti modi diversi. Non esiste pertanto una soluzione semplice per calcolare il numero di utenti o di elementi che possono essere supportati da un determinato numero di server. È quindi necessario eseguire test nell'ambiente in uso prima di distribuire SharePoint Server 2010 in un ambiente di produzione.

Sistema delle query di ricerca

In questa sezione vengono mostrati i componenti del sistema delle query di ricerca per una specifica applicazione del servizio di ricerca. I requisiti di dimensioni per ogni componente sono elencati nella tabella con i dettagli relativi alla scalabilità dopo il diagramma seguente.

Descrizioni degli oggetti

Nell'elenco seguente vengono definiti gli oggetti del sistema delle query di ricerca presenti nel diagramma precedente:

• Proxy di ricerca Proxy di applicazione del servizio di ricerca installato in una farm che utilizza il servizio di ricerca di questa applicazione del servizio di ricerca. Viene eseguito nel contesto delle applicazioni Web associate al proxy di applicazione del servizio di ricerca.

• Servizio query di ricerca e impostazioni sito È conosciuto inoltre come sistema di elaborazione delle query. Quando riceve la query da una connessione proxy di applicazione del servizio di ricerca, un sistema di elaborazione delle query esegue le operazioni seguenti:

  • Invia la query a un componente di query attivo per ogni partizione di indice (oppure al database delle proprietà o a entrambi, a seconda della query)

  • Recupera gli elementi di maggiore rilevanza e rimuove i duplicati per ottenere i set di risultati

  • Applica la limitazione per motivi di protezione ai risultati in base ai descrittori di sicurezza nel database di amministrazione della ricerca

  • Recupera i metadati del set di risultati finale dal database delle proprietà

  • Invia i risultati delle query al proxy

• Partizione di indice Si tratta di un gruppo logico di componenti di query, che rappresenta un sottoinsieme dell'indice full-text. La somma delle partizioni di indice costituisce l'indice full-text. Si noti tuttavia che i componenti di query contengono il sottoinsieme effettivo dell'indice. Una partizione di indice è associata a un database delle proprietà.

• Componente di query di ricerca Un componente di query contiene tutto l'indice full-text o parte di esso. Quando viene interrogato tramite query da parte di un sistema di elaborazione delle query, il componente di query determina i risultati migliori dall'indice e restituisce tali elementi. È possibile creare un componente di query con le caratteristiche seguenti:

  • Componente attivo, ovvero un componente che risponderà alle query per impostazione predefinita. L'aggiunta di più componenti di query attivi per la stessa partizione di indice determina un aumento della velocità effettiva.

  • Componente di failover, ovvero un componente che risponderà alle query solo in caso di errore di tutti i componenti attivi della stessa partizione di indice.

• Database di amministrazione della ricerca Creato contemporaneamente all'applicazione del servizio di ricerca, il database di amministrazione della ricerca contiene i dati a livello dell'applicazione del servizio di ricerca utilizzati per query quali elementi di maggiore rilevanza e descrittori di sicurezza, oltre alle impostazioni delle applicazioni utilizzate per l'amministrazione.

• Database delle proprietà Un database delle proprietà contiene i metadati (titolo, autore e campi correlati) degli elementi dell'indice. Il database delle proprietà viene utilizzato per le query basate sulle proprietà oltre che per il recupero dei metadati necessari per la visualizzazione dei risultati finali. Se sono presenti più partizioni di indice, queste possono essere mappate a database delle proprietà diversi.

Dettagli relativi alla scalabilità

Oggetto	Considerazioni sulla scalabilità	RAM	IOPS (lettura/scrittura)
Proxy di ricerca	Viene adattato in base ai server Web front-end a cui è associato.	N/D	N/D
Servizio query di ricerca e impostazioni sito	Questo servizio, che viene installato nella pagina Servizi nel server in Amministrazione centrale, deve essere avviato in ogni server con un componente di query. Può essere spostato in un server separato (o in una coppia di server per una disponibilità elevata) per evitare di utilizzare la RAM nei server in cui sono contenuti i componenti di query. L'eventuale utilizzo di un trimmer di sicurezza personalizzato (le informazioni potrebbero essere in lingua inglese) può influire sulle risorse di CPU e RAM.	Utilizza la RAM (cache dei processi) per memorizzare nella cache i descrittori di sicurezza per l'indice.	N/D
Partizione di indice	L'aumento del numero di partizioni di indice comporta una riduzione del numero di elementi nella partizione di indice e di conseguenza una riduzione della RAM e dello spazio su disco necessari nel server di query che ospita il componente di query assegnato alla partizione di indice.	N/D	N/D
Componente di query	Ogni componente di query attivo in un server utilizza memoria quando gestisce le query. Ogni componente di query attivo viene creato o modificato nell'ambito della topologia di un'applicazione del servizio di ricerca. I componenti attivi e di failover utilizzano operazioni di I/O quando è in corso la ricerca per indicizzazione. I server possono essere dedicati a componenti di query (ad esempio due componenti attivi e due di failover nello stesso server), presupponendo che siano stati soddisfatti i requisiti di RAM e I/O. Se possibile, dedicare almeno due CPU core per componente attivo per server e almeno un CPU core per componente di failover per server.	Per ogni componente di query attivo in un server applicazioni, il 33% dell'indice deve essere nella RAM (cache del sistema operativo).	2 K necessari per coppia (attivo/failover) di componenti di query in un server specifico. Il componente di query necessita di I/O per: Caricare l'indice nella RAM per le query Scrivere frammenti di indice ricevuti da ogni componente di ricerca per indicizzazione Unire frammenti di indice nell'indice, ad esempio durante un'unione master
Database di amministrazione della ricerca	Per ogni query, gli elementi di maggiore rilevanza e i descrittori di sicurezza vengono caricati dal database di amministrazione della ricerca. Verificare che il server di database disponga di RAM sufficiente per la gestione dalla cache. Se possibile, evitare di utilizzare un server con un database di ricerca per indicizzazione, poiché questo tipo di database tende a reimpostare la cache del server di database.	Verificare che nel server di database sia presente RAM sufficiente per mantenere la tabella critica (MSSSecurityDescriptors) nella RAM.	700
Database delle proprietà	Per ogni query, i metadati vengono recuperati dal database delle proprietà per i risultati dei documenti, in modo da poter aggiungere RAM al server di database per migliorare le prestazioni. Se sono presenti più partizioni di indice, è possibile partizionare il database delle proprietà e passare a un altro server di database per ridurre i requisiti di RAM e I/O.	Verificare che il server di database disponga di RAM sufficiente per mantenere il 33% delle tabelle critiche (MSSDocSDIDs + MSSDocProps + MSSDocresults) nella cache.	2 K 30% lettura, 70% scrittura

Sistema di ricerca per indicizzazione

In questa sezione vengono illustrati i componenti del sistema di ricerca per indicizzazione. I requisiti di dimensioni di ogni componente sono riportati nella tabella dopo il diagramma.

Descrizioni degli oggetti

In questa sezione vengono definiti gli oggetti del sistema di ricerca per indicizzazione riportati nel diagramma precedente:

• Componente di amministrazione Un componente di amministrazione viene utilizzato quando viene avviata una ricerca per indicizzazione, nonché quando viene eseguita un'attività di amministrazione nel sistema di ricerca per indicizzazione.

• Componente di ricerca per indicizzazione Un componente di ricerca per indicizzazione elabora le ricerche per indicizzazione, propaga i file dei frammenti di indice risultanti nei componenti di query e aggiunge informazioni sulla posizione e sulla pianificazione della ricerca per indicizzazione per le origini di contenuto al database di ricerca per indicizzazione associato.

• Database di amministrazione della ricerca Il database di amministrazione della ricerca viene creato contemporaneamente all'applicazione del servizio di ricerca. In esso sono archiviati i descrittori di sicurezza rilevati durante la ricerca per indicizzazione e le impostazioni delle applicazioni utilizzate per l'amministrazione.

• Database di ricerca per indicizzazione Un database di ricerca per indicizzazione contiene dati correlati alla posizione delle origini di contenuto, alle pianificazioni della ricerca per indicizzazione e altre informazioni specifiche delle operazioni di ricerca per indicizzazione. Può essere dedicato a host specifici creando regole di distribuzione host. In un database di ricerca per indicizzazione vengono archiviati solo dati. La ricerca per indicizzazione viene eseguita dal componente di ricerca per indicizzazione associato al database di ricerca per indicizzazione specifico.

• Sistema delle query di ricerca.

Dettagli relativi alla scalabilità

Oggetto	Considerazioni sulla scalabilità	RAM	IOPS (facoltativamente, % lettura/scrittura)
Componente di amministrazione	Il singolo componente di amministrazione non è scalabile. Per impostazione predefinita, è contenuto in un server che ospita un componente di ricerca per indicizzazione (e Amministrazione centrale nelle farm di dimensioni inferiori).	Minima	Minime
Componente di ricerca per indicizzazione	I componenti di ricerca per indicizzazione utilizzano la larghezza di banda della CPU in modo esteso. In una situazione ottimale, un componente di ricerca per indicizzazione specifico può utilizzare quattro CPU core. La RAM non è altrettanto importante. In farm di dimensioni maggiori la dedica di server a componenti di ricerca per indicizzazione host comporta una riduzione dell'effetto del crawler su altri componenti, soprattutto se si utilizzano componenti di ricerca per indicizzazione associati a database di ricerca per indicizzazione diversi, qualora si desideri implementare la ridondanza.	Media. Si noti che quando viene eseguita la ricerca per indicizzazione di documenti dell'Asia orientale, i requisiti della RAM aumentano a causa dei word breaker.	300-400
Database di amministrazione della ricerca	Vedere la sezione relativa al sistema delle query di ricerca più indietro. Se possibile, evitare di utilizzare un server con un database di ricerca per indicizzazione, poiché questo tipo di database tende a reimpostare la cache del server di database.	Vedere la sezione relativa al sistema delle query di ricerca più indietro.	700
Database di ricerca per indicizzazione	I database di ricerca per indicizzazione utilizzano la larghezza di banda di I/O in modo esteso. La RAM non è altrettanto importante. Un database di ricerca per indicizzazione necessita di 3,5 K di IOPS per le attività di ricerca per indicizzazione. Utilizzerà al massimo 6 K di IOPS, in base alla larghezza di banda disponibile.	Media	3,5 - 7 K 73% lettura, 27% scrittura

Calcolare le dimensioni per lo spazio di archiviazione

Tenere conto dei fattori seguenti per valutare i requisiti per lo spazio di archiviazione. I fattori per le dimensioni sono basati su un sistema di pre-distribuzione interno con un indice che include principalmente contenuto di SharePoint (la dimensione dei database del contenuto è di 13,3 terabyte). Nell'insieme, il servizio di ricerca di SharePoint ha richiesto circa il 20% dello spazio su disco del database del contenuto. Come dichiarato precedentemente, è necessario eseguire i test nell'ambiente un uso prima di distribuire SharePoint Server 2010 in un ambiente di produzione.

Avvertenze:

• Poiché il corpo che è stato utilizzato per dedurre questi numeri è costituito principalmente da contenuto di SharePoint (in lingua inglese), se il contenuto in uso è diverso, ad esempio è costituito principalmente da condivisioni di file o da siti HTTP non di SharePoint, sarà necessario consentire ulteriori varianti.

• Anche se i dati sono costituiti principalmente da contenuto di SharePoint, è comunque possibile variare i coefficienti nelle circostanze seguenti:

  • Se si dispone di archivi di documenti estesi, i coefficienti saranno maggiori in modo significativo.

  • Se il contenuto è costituito principalmente da immagini, potrebbe essere possibile ridurre i coefficienti.

  • Il contenuto in una lingua diversa avrà effetto probabilmente sui coefficienti.

1. Calcolare il fattore di dimensionamento dei database del contenuto (ContentDBSum)

Determinare la somma dei database del contenuto di SharePoint che verranno sottoposti a ricerca per indicizzazione. Questo è il valore ContentDBSum che verrà utilizzato come correlazione nei successivi calcoli per lo spazio di archiviazione.

2. Calcolare le dimensioni correlate all'indice (TotalIndexSize e QueryComponentIndexSize)

Determinare la dimensione dell'indice totale (contenuto nei componenti di query e utilizzato per le query full-text):

Moltiplicare ContentDBSum per 0,035. Questo è il valore di TotalIndexSize ottenuto prima di eseguire il partizionamento e di riservare spazio per le unioni e il ripartizionamento.

Determinare quindi il numero di partizioni di indice in base a questo scenario. Come linea guida generale considerare che una partizione di indice dovrebbe disporre di un numero di elementi compreso tra 5 e 10 milioni. Dopo aver determinato il numero di partizioni di indice, è possibile calcolare la dimensione dello spazio di archiviazione del componente di query.

• Dividere TotalIndexSize per il (numero di partizioni di indice). Questo è il valore di QueryComponentIndexSize. Viene utilizzato per calcolare le dimensioni seguenti:

  • Per la RAM, moltiplicare QueryComponentIndexSize per 0,33. Questa è la RAM minima necessaria per questo componente di query, se attivo.

    • I componenti di failover non necessitano della RAM finché non diventano attivi.

    • Per un server specifico, in caso di più componenti di query attivi nello stesso server, è necessario sommare la RAM di ogni componente di query attivo per ottenere i requisiti di RAM per il server.

  • Per lo spazio di archiviazione su disco, utilizzare QueryComponentIndexSize come indicato di seguito per calcolare i requisiti del disco, qualora si intenda ripartizionare l'indice, ovvero si preveda un aumento dell'indice oltre il limite di 10 milioni per partizione:

    • Moltiplicare QueryComponentIndexSize per 3 per calcolare lo spazio di archiviazione su disco affinché un singolo componente di query disponga di spazio sufficiente per l'unione dell'indice.

    • Moltiplicare QueryComponentIndexSize per 4 per calcolare lo spazio di archiviazione su disco affinché un singolo componente di query disponga di spazio sufficiente per il ripartizionamento dell'indice.

Per un server specifico, in caso di più componenti di query presenti nello stesso server, è necessario definire lo spazio di archiviazione per ogni componente di query in base ai requisiti di operazioni di I/O al secondo (IOPS) indicati in "Dettagli relativi alla scalabilità" nella sezione "Sistema delle query di ricerca" più indietro in questo articolo.

3. Calcolare le dimensioni dei database delle proprietà

Determinare le dimensioni dei database delle proprietà come indicato di seguito:

• Moltiplicare ContentDBSum per 0,015. Questo è il valore di TotalPropertyDBSize prima del partizionamento.

• Moltiplicare ContentDBSum per 0,0031. Questo è il valore di TotalPropertyDBLogSize prima del partizionamento. Si presuppone che venga utilizzato il modello di recupero con registrazione minima per i database di SQL Server.

• Moltiplicare ContentDBSum per 0,00034. Questo è il valore di TempDBSize per il database delle proprietà. Poiché è consigliabile disporre del 33% delle tabelle chiave del database delle proprietà nella RAM, l'utilizzo del database temporaneo non è oneroso.

Determinare quindi il numero di database delle proprietà in base a questo scenario. Come linea guida generale, un database delle proprietà può contenere fino a 50 milioni di elementi, presupponendo che non vi siano problemi di prestazioni delle query e che sia presente un numero limitato di proprietà gestite (configurazione standard).

• Dividere TotalPropertyDBSize per il (numero di database delle proprietà). Questo è il valore di PropertyDatabaseSize.

• Dividere TotalPropertyDBLogSize per il (numero di database delle proprietà). Questo è il valore di PropertyDatabaseLogSize.

• Per la RAM, moltiplicare PropertyDatabaseSize per 0,33. Questa è la quantità minima di RAM consigliata per questo database delle proprietà.

Per un server di database specifico, in caso di più database delle proprietà presenti nello stesso server, è necessario definire lo spazio di archiviazione e la RAM per ogni database delle proprietà in base ai requisiti di operazioni di I/O al secondo (IOPS) e di RAM indicati in "Dettagli relativi alla scalabilità" nella sezione "Sistema delle query di ricerca" più indietro in questo articolo.

4. Calcolare le dimensioni dei database di ricerca per indicizzazione

Determinare quindi la dimensione necessaria per il database di ricerca per indicizzazione come indicato di seguito:

• Moltiplicare ContentDBSum per 0,046. Questo è il valore di TotalCrawlDBSize prima del partizionamento.

• Moltiplicare ContentDBSum per 0,011. Questo è il valore di TotalCrawlDBLogSize prima del partizionamento. Si presuppone che venga utilizzato il modello di recupero con registrazione minima per i database di SQL Server.

• Moltiplicare ContentDBSum per 0,0011. Questo è il valore di TempDBSize per i database di ricerca per indicizzazione. Poiché il sistema di ricerca per indicizzazione ha effetto sulle prestazioni del database temporaneo, non è consigliabile posizionare altri database nei server che ospitano il database o i database di ricerca per indicizzazione, che verrebbero penalizzati da questo utilizzo.

Determinare quindi il numero di database di ricerca per indicizzazione in base a questo scenario. Come linea guida generale, un database di ricerca per indicizzazione può contenere fino a 25 milioni di elementi, presupponendo che non vi siano problemi di prestazioni della ricerca per indicizzazione.

• Dividere TotalCrawlDBSize per il (numero di database di ricerca per indicizzazione). Questo è il valore di CrawlDatabaseSize.

• Dividere TotalCrawlDBLogSize per il (numero di database di ricerca per indicizzazione). Questo è il valore di CrawlDatabaseLogSize.

Per un server di database specifico, in caso di più database di ricerca per indicizzazione presenti nello stesso server, è necessario definire lo spazio di archiviazione per ogni database di ricerca per indicizzazione in base ai requisiti di operazioni di I/O al secondo (IOPS) indicati in "Dettagli relativi alla scalabilità" nella sezione "Sistema delle query di ricerca" più indietro in questo articolo. Per la RAM, è consigliabile pianificare almeno 16 GB nei server di database dedicati ai database di ricerca per indicizzazione.

5. Calcolare la dimensione del database di amministrazione della ricerca

Determinare la dimensione del database di amministrazione della ricerca (presupponendo che venga utilizzata l'autenticazione di Windows) come indicato di seguito:

• Moltiplicare il numero di elementi contenuti nell'indice (in milioni) per 0,3. Questo è il valore di SearchAdminDBSize.

• Per la RAM, moltiplicare SearchAdminDBSize per 0,33. Questa è la quantità minima di RAM consigliata per questo database di amministrazione della ricerca.

Per un server di database specifico, in caso di più database presenti nello stesso server, è necessario definire lo spazio di archiviazione e la RAM per ogni database in base ai requisiti di operazioni di I/O al secondo (IOPS) e di RAM indicati in "Dettagli relativi alla scalabilità" nella sezione "Sistema delle query di ricerca" più indietro in questo articolo.

Facoltativo: calcolare la dimensione per i backup

Per determinare lo spazio su disco necessario per il backup di un'applicazione del servizio di ricerca, eseguire il calcolo seguente:

• TotalCrawlDBSize + TotalPropertyDBSize + TotalIndexSize + SearchAdminDBSize = dimensione per il backup di base.

Questa dimensione per il backup di base è un punto di partenza. È determinata inoltre dai fattori seguenti:

• Dimensione aggiuntiva dell'indice inclusa in TotalIndexSize per le eventuali ricerche per indicizzazione eseguite dopo l'ultima unione master.

• Espansione nel tempo dovuta a ulteriori elementi, query e descrittori di sicurezza.

Sarà probabilmente necessario inoltre mantenere più backup di periodi diversi, oltre a riservare spazio per il backup successivo.

Esercizio di dimensionamento

Sulla base dei fattori di dimensionamento precedentemente menzionati, viene riportato di seguito un esercizio di dimensionamento per una farm con 100 milioni di elementi che gestirà query eseguite principalmente su contenuto di SharePoint. Utilizzando lo scenario relativo alla farm di grandi dimensioni, basarsi sui presupposti seguenti:

• Sono necessarie dieci partizioni di indice logiche per i 100 milioni di elementi.

• Per la gestione delle query, sono necessari 10 componenti di query attivi, uno per partizione di indice.

• La ridondanza delle query è importante e pertanto si dispone di 10 componenti di query di failover, uno per partizione di indice (posizionato in un server diverso rispetto al componente attivo).

Per determinare le esigenze di spazio di archiviazione e RAM, eseguire la procedura seguente:

1. In una farm di contenuto di SharePoint con più database del contenuto aggiungere i database del contenuto che si desidera sottoporre a ricerca per indicizzazione fino a raggiungere 20 terabyte.

2. Utilizzando il coefficiente di indice sopra indicato, moltiplicare 20 terabyte per 0.035 (coefficiente di indice) per ottenere 716,8 GB. Questo è il valore di TotalIndexSize. Se fosse stata presente una sola partizione, questa sarebbe stata la dimensione dell'indice a riposo.

3. Dividere TotalIndexSize per il numero di partizioni: 716,8 GB / 71,68 GB. Questa è la dimensione dell'indice necessaria per componente di query (QueryComponentIndexSize), con una partizione di indice. La dimensione è la stessa per i componenti di query attivi o di failover.

4. Moltiplicare TotalIndexSize per 4 se si prevede di eseguire il ripartizionamento, altrimenti moltiplicarlo per 3 per supportare le unioni master. 71,68 GB * 4 = 286,72 GB. Dovrebbero essere disponibili 286,72 GB nel disco del server di query per supportare un componente di query. Se sono presenti due componenti di query nello stesso server applicazioni (come nella topologia di componenti attivi/di failover consigliata nello scenario della farm di grandi dimensioni), il layout dell'unità disco sarà il seguente:

   1. Unità del sistema operativo (dimensione standard).

   2. Sistema di archiviazione aggiuntiva 1: Query Component1_Share (dimensione = almeno 300 GB), per il componente di query attivo dalla partizione di indice 1.

   3. Sistema di archiviazione aggiuntiva 2: Query Component2_Share (dimensione = almeno 300 GB), per il componente di query di failover (mirror) dalla partizione di indice 2.

Limiti software

Nella tabella riportata di seguito vengono illustrati i limiti software imposti per ottenere risultati accettabili dalla funzionalità di ricerca.

Oggetto	Limite	Note aggiuntive
Applicazione del servizio di ricerca di SharePoint	È consigliato un massimo di 20 per farm. Il massimo assoluto è di 256 applicazioni di servizio totali.	È possibile distribuire più applicazioni del servizio di ricerca nella stessa farm, poiché i componenti e i database di ricerca possono essere assegnati a server separati.
Documenti indicizzati	Valore totale massimo consigliato di 10 milioni di elementi per partizione di indice e di 100 milioni di elementi per applicazione del servizio di ricerca.	Il servizio di ricerca di SharePoint supporta le partizioni di indice, ognuna delle quali contiene un sottoinsieme dell'intero indice della ricerca. Il numero massimo consigliato è 10 milioni di elementi per una partizione specifica. Il numero massimo totale consigliato è di 100 milioni di elementi, inclusi utenti, elementi di elenco, documenti e pagine Web.
Partizioni di indice	Numero massimo consigliato di 20 per applicazione del servizio di ricerca.	Questa partizione di indice è un sottoinsieme logico dell'indice dell'applicazione del servizio di ricerca. Il limite consigliato è 20. L'aumento del numero di partizioni di indice comporta una riduzione del numero di elementi nella partizione di indice e di conseguenza una riduzione della RAM e dello spazio su disco necessari nel server di query che ospita il componente di query assegnato alla partizione di indice. Questo può tuttavia influire sulla pertinenza poiché il numero di elementi nella partizione di indice viene ridotto. Il limite rigido delle partizioni di indice è 128.
Database delle proprietà	Il limite consigliato è 10 per applicazione del servizio di ricerca.	Nel database delle proprietà vengono archiviati i metadati relativi agli elementi di ogni partizione di indice associata. Una partizione di indice può essere associata solo a un archivio delle proprietà. Il limite consigliato è 10 per applicazione del servizio di ricerca, con un limite rigido di 255, come per le partizioni di indice.
Database di ricerca per indicizzazione	Il limite è 32 database di ricerca per indicizzazione per applicazione.	Nel database di ricerca per indicizzazione vengono archiviati i dati di ricerca per indicizzazione (inclusi l'ora e lo stato) relativi a tutti gli elementi sottoposti a tale ricerca. Il limite consigliato è 25 milioni di elementi per database di ricerca per indicizzazione oppure quattro database totali per un'applicazione del servizio d ricerca.
Componenti di ricerca per indicizzazione	Il limite consigliato per applicazione è 16 componenti di ricerca per indicizzazione in totale, con due componenti per database di ricerca per indicizzazione e due per server, presupponendo che il server disponga di almeno otto processori (core).	Il numero totale di componenti di ricerca per indicizzazione per server deve essere inferiore a 128/(componenti di query totali) per ridurre al minimo gli effetti negativi sull'I/O di propagazione. Superando il limite consigliato non si ottiene automaticamente un miglioramento delle prestazioni in fase di ricerca per indicizzazione. Tali prestazioni potrebbero anzi peggiorare a seconda delle risorse disponibili nel server di ricerca per indicizzazione, nel database e nell'host del contenuto.
Componenti di query	Il limite consigliato per applicazione è 128, con 64/(componenti di ricerca per indicizzazione totali) per server.	Il numero totale di componenti di query dipende dalla capacità dei componenti di ricerca per indicizzazione di copiare file. Il numero massimo di componenti di query per server dipende dalla capacità dei componenti di query di assorbire i file propagati dai componenti di ricerca per indicizzazione.
Ricerche per indicizzazione simultanee	Il limite consigliato è 20 ricerche per indicizzazione per applicazione del servizio di ricerca.	Questo è il numero di ricerche per indicizzazione in esecuzione contemporaneamente. Le ricerche per indicizzazione sono attività di ricerca che utilizzano molte risorse e che possono influire sul carico dei database, oltre al carico delle applicazioni. Se si supera il limite di 20 ricerche per indicizzazione simultanee, esiste il rischio che la velocità della ricerca per indicizzazione possa rallentare.
Origini di contenuto	Il limite consigliato è 50 origini di contenuto per applicazione del servizio di ricerca.	Il limite consigliato può essere superato fino al limite rigido di 500 per applicazione del servizio di ricerca. È tuttavia consigliabile utilizzare meno indirizzi iniziali e deve essere seguito il limite relativo alle ricerche per indicizzazione simultanee.
Indirizzi iniziali	Il limite consigliato è 100 indirizzi iniziali per origine di contenuto.	Il limite consigliato può essere superato fino al limite rigido di 500 per origine di contenuto. È tuttavia consigliabile utilizzare un numero inferiore di origini di contenuto. Un approccio ottimale in caso di numerosi indirizzi iniziali consiste nell'inserirli in una pagina HTML come collegamenti e quindi fare in modo che il crawler HTTP esegua la ricerca per indicizzazione della pagina visitando i collegamenti.
Regole di ricerca per indicizzazione	Il limite consigliato è 100 per applicazione del servizio di ricerca.	Tale limite può essere superato, ma diminuirà la qualità della visualizzazione delle regole di ricerca per indicizzazione nell'amministrazione della ricerca.
Registri di ricerca per indicizzazione	Il limite consigliato è 100 milioni per applicazione.	Si tratta del numero di singole voci del registro di ricerca per indicizzazione. Segue il limite relativo ai documenti indicizzati.
Proprietà di metadati riconosciute per elemento	Il limite rigido è 10.000.	Questo è il numero di proprietà dei metadati che è possibile determinare e potenzialmente mappare e utilizzare per le query quando un elemento viene sottoposto a ricerca per indicizzazione.
Proprietà sottoposte a ricerca per indicizzazione	500.000 per applicazione del servizio di ricerca.	Queste sono le proprietà rilevate durante una ricerca per indicizzazione.
Proprietà gestite	100.000 per applicazione del servizio di ricerca.	Queste sono le proprietà utilizzate dal sistema di ricerca nelle query. Le proprietà sottoposte a ricerca per indicizzazione sono mappate alle proprietà gestite. È consigliabile un massimo di 100 mapping per proprietà gestita. Superando tale limite, può diminuire la velocità della ricerca per indicizzazione e possono ridursi le prestazioni delle query.
Ambiti	Il limite consigliato è 200 per sito.	Questo è un limite consigliato per sito. Superandolo, la ricerca per indicizzazione può risultare meno efficiente e, in caso di aggiunta di ambiti al gruppo di visualizzazione, aumenterà inoltre la latenza del browser dell'utente finale. Peggiorerà infine la qualità della visualizzazione degli ambiti nell'amministrazione della ricerca man mano che il numero degli ambiti supera il limite consigliato.
Gruppi di visualizzazione	25 per sito.	Vengono utilizzati per una visualizzazione raggruppata degli ambiti tramite l'interfaccia utente. Se viene superato questo limite, si verifica un peggioramento del funzionamento degli ambiti nell'amministrazione della ricerca.
Regole di ambito	Il limite consigliato è di 100 regole per ambito e di un totale di 600 regole per applicazione del servizio di ricerca.	Superando tale limite, peggiora il livello di aggiornamento e i possibili risultati delle query con ambito vengono restituiti con ritardo.
Parole chiave	Il limite consigliato è 200 per raccolta siti.	Il limite consigliato può essere superato fino al limite massimo (imposto da ASP.NET) di 5.000 per raccolta siti con cinque elementi di maggiore rilevanza per parola chiave. Se si supera tale limite, diminuirà la qualità della visualizzazione delle parole chiave nell'interfaccia utente di amministrazione dei siti. Il limite imposto da ASP.NET può essere modificato intervenendo sui file Web.config e Client.config (MaxItemsInObjectGraph).
Pagine rilevanti	Il limite consigliato è una pagina rilevante principale e il minor numero possibile di pagine rilevanti di secondo e terzo livello, per ottenere il livello di pertinenza desiderato.	Il limite rigido è 200 per livello di pertinenza per applicazione del servizio di ricerca, ma aggiungendo pagine esiste il rischio di non ottenere la pertinenza desiderata. Aggiungere il sito chiave al primo livello di pertinenza. Aggiungere siti chiave successivi al secondo o al terzo livello di pertinenza, uno per volta, e valutare la pertinenza dopo ogni aggiunta per essere certi di raggiungere l'effetto desiderato.
Avvisi	Il limite consigliato è 1.000.000 per applicazione del servizio di ricerca.	Questo è il limite testato.
Rimozione dei risultati	100 URL in una singola operazione.	Questo è il numero massimo consigliato di URL che è possibile rimuovere dal sistema in un'unica operazione.

Ottimizzazioni

Nelle sezioni che seguono vengono illustrati i metodi per migliorare le prestazioni della farm.

Sono numerosi i fattori che possono influire sulle prestazioni, tra cui il numero di utenti, il tipo, la complessità e la frequenza delle operazioni utente, il numero di postback in un'operazione e le prestazioni delle connessioni dati. Ognuno di questi fattori può produrre un effetto importante sulla velocità effettiva della farm. È consigliabile valutare con attenzione ognuno di questi fattori quando si pianifica la distribuzione.

La capacità e le prestazioni di un sistema di ricerca dipendono in modo significativo dalla topologia del sistema. È possibile implementare la scalabilità verticale aumentando la capacità dei server esistenti oppure la scalabilità orizzontale aggiungendo server alla topologia.

Ottimizzazione del sistema delle query di ricerca

Per le ottimizzazioni delle query di ricerca in genere viene seguito uno degli scenari seguenti:

• Gli utenti si lamentano a causa della latenza delle query e pertanto è necessario ridurre la latenza delle query.

• Vengono eseguite più richieste di ricerca del previsto e le prestazioni hanno iniziato a peggiorare, pertanto è necessario aumentare la velocità effettiva delle query.

L'implementazione della scalabilità orizzontale o verticale del sottosistema di query comporta sempre la creazione di più componenti di query. Se si dispone di capacità in eccesso (RAM, I/O e CPU) in un server di query esistente, è possibile scegliere di implementare la scalabilità verticale creando ulteriori componenti di query in tale server, aumentando la RAM, la CPU o le operazioni di I/O qualora si verifichi un collo di bottiglia. In alternativa, è possibile scegliere di creare più componenti di query o spostare i componenti esistenti in un nuovo server per implementare la scalabilità orizzontale.

Nella sezione seguente vengono mostrati i diversi modi in cui è possibile procedere per aggiungere risorse di query al sistema delle query di ricerca.

Come ridurre la latenza delle query

Aggiunta di componenti di query per ridurre la latenza

Nel grafico riportato di seguito viene illustrato l'effetto prodotto dall'aggiunta di componenti di query attivi in server diversi senza modificare la dimensione dell'indice.

Aggiungere ulteriori componenti di query attivi per mantenere una latenza delle query inferiore al secondo con l'aumento del carico utente nel sistema (misurato in query utente simultanee).

Aggiunta di sistemi di elaborazione delle query (Servizio query di ricerca e impostazioni sito) per ridurre la latenza

Nel grafico seguente viene illustrato l'effetto prodotto dall'aggiunta di servizi di sistemi di elaborazione delle query attivi in server diversi senza modificare altre parti del sistema delle query.

Avviare altre istanze attive del Servizio query di ricerca e impostazioni sito in server diversi per mantenere una latenza delle query inferiore al secondo con l'aumento del carico utente nel sistema (misurato in query utente simultanee).

Implementare la scalabilità orizzontale per aumentare la velocità effettiva delle query

Aggiunta di componenti di query per migliorare la velocità effettiva delle query

Nel grafico riportato di seguito viene illustrato l'effetto prodotto dall'aggiunta di componenti di query attivi in server diversi senza modificare la dimensione dell'indice.

Aggiungere ulteriori componenti di query attivi per aumentare la velocità effettiva delle con l'aumento del carico utente nel sistema (misurato in query utente simultanee).

Aggiunta di sistemi di elaborazione delle query (Servizio query di ricerca e impostazioni sito) per aumentare la velocità effettiva delle query

Nel grafico seguente viene illustrato l'effetto prodotto dall'aggiunta di servizi di sistemi di elaborazione delle query attivi in server diversi senza modificare altre parti del sistema delle query.

Area di intervento globale: avviare altre istanze attive del Servizio query di ricerca e impostazioni sito in server diversi per aumentare la velocità effettiva con l'aumento del carico utente nel sistema (misurato in query utente simultanee).

Ottimizzazioni del sistema di ricerca per indicizzazione

Le ottimizzazioni del sistema di ricerca per indicizzazione vengono eseguite in genere se gli utenti si lamentano di risultati incompleti o non aggiornati.

Quando si tenta di eseguire la ricerca per indicizzazione dell'indirizzo iniziale dell'origine di contenuto nell'ambito degli obiettivi del livello di aggiornamento, è possibile che si verifichino i problemi di prestazioni della ricerca per indicizzazione seguenti:

• La velocità della ricerca per indicizzazione è ridotta a causa di colli di bottiglia delle operazioni di I/O al secondo (IOPS) nel sottosistema di ricerca per indicizzazione.

• La velocità della ricerca per indicizzazione è ridotta per l'assenza di thread della CPU nel sottosistema di ricerca per indicizzazione.

• La velocità della ricerca per indicizzazione è ridotta a causa della lentezza dei tempi di risposta dell'archivio.

Per ognuno di questi problemi si presuppone che la velocità della ricerca per indicizzazione sia ridotta. Vedere Use search administration reports (SharePoint Server 2010) (in base alle fasi del ciclo di vita del software) per stabilire un riferimento di base della velocità della ricerca per indicizzazione tipica per il sistema nel tempo. Quando ci si allontana da questo riferimento, è possibile risolvere i problemi di prestazioni della ricerca per indicizzazione come illustrato nelle sottosezioni seguenti.

Collo di bottiglia delle operazioni di I/O al secondo della ricerca per indicizzazione

Dopo aver determinato che un database di ricerca per indicizzazione o delle proprietà è un collo di bottiglia, è necessario implementare la scalabilità verticale oppure orizzontale del sistema di ricerca per indicizzazione per utilizzare le soluzioni appropriate. Nella tabella riportata di seguito viene illustrato come aggiungendo operazioni di I/O al secondo (IOPS), ovvero un altro database di ricerca per indicizzazione, si ottenga un miglioramento della velocità della ricerca per indicizzazione, finché l'aggiunta di ulteriori componenti non causa di nuovo un collo di bottiglia.

Area di intervento globale: verificare sempre il database di ricerca per indicizzazione per accertarsi che non costituisca un collo di bottiglia. Se le operazioni di I/O al secondo (IOPS) del database di ricerca per indicizzazione sono già bloccate in un collo di bottiglia, l'aggiunta di componenti di ricerca per indicizzazione o l'aumento del numero di thread non consente di risolvere il problema.

Topologia (Componente di ricerca per indicizzazione/ Database di ricerca per indicizzazione)	Percentuale di CPU	RAM: percentuale riscontri cache buffer	Latenza lettura	Latenza scrittura	Velocità ricerca per indicizzazione (doc/sec)
Database 2 / 1	19,5	99,6	142 ms	73 ms	50
Database 4 / 2	8,502	99,55	45 ms	75 ms	~75
Database 6 / 2	22	99,92	55 ms	1050 ms	~75

Collo di bottiglia dei thread della CPU di ricerca per indicizzazione

Se si dispone di un numero elevato di host e non sono presenti altri colli di bottiglia della ricerca per indicizzazione, è necessario implementare la scalabilità verticale oppure orizzontale del sistema di ricerca per indicizzazione utilizzando le soluzioni appropriate. Il crawler supporta un massimo di 256 thread per applicazione del servizio di ricerca. È consigliabile utilizzare un processore quad core per usufruire interamente dei vantaggi offerti dal numero massimo di thread. Dopo aver determinato definitivamente che l'archivio gestisce i dati in modo sufficientemente rapido (vedere la sezione "Collo di bottiglia della ricerca per indicizzazione nell'archivio" più avanti in questo articolo), la velocità effettiva della ricerca per indicizzazione può essere aumentata richiedendo dati più velocemente dall'archivio mediante un incremento del numero di thread del crawler. Per ottenere questo risultato, è possibile procedere in tre modi, come indicato di seguito:

1. Cambiare il livello di prestazioni dell'indicizzatore in Parzialmente ridotte o Massime utilizzando il cmdlet di Windows PowerShell seguente:

   • Get-SPEnterpriseSearchService | Set-SPEnterpriseSearchService –PerformanceLevel "Massime"

     Il valore Massime viene utilizzato in presenza di un processore con meno di quattro core.

2. Utilizzare le regole di impatto del crawler per aumentare il numero di thread per host. A tale scopo, considerare che è supportato un massimo di 256 thread e che l'assegnazione di un numero elevato di thread a pochi host può determinare un rallentamento del recupero dei dati da altri archivi.

3. Se è presente un numero elevato di host, la soluzione ideale consiste nell'aggiungere un altro componente della ricerca per indicizzazione in un indicizzatore separato per eseguire la ricerca per indicizzazione degli host che devono essere indicizzati più rapidamente.

La soluzione ideale per aumentare facilmente la velocità effettiva della ricerca per indicizzazione consiste nell'aggiungere un altro indicizzatore purché nel sottosistema di ricerca non siano presenti colli di bottiglia per le operazioni di I/O al secondo (IOPS) e l'archivio gestisca il contenuto rapidamente.

Collo di bottiglia della ricerca per indicizzazione nell'archivio

Quando un'applicazione Web di SharePoint con molte raccolte siti o condivisioni di file remote annidate viene sottoposta a ricerca per indicizzazione, è possibile che per il crawler di ricerca si verifichi un collo di bottiglia nell'archivio. Questo problema viene individuato se si verificano le due condizioni seguenti:

• Utilizzo ridotto della CPU (meno del 20%) nei server di ricerca per indicizzazione.

• Numero elevato di thread (quasi tutti nel peggiore dei casi) in attesa sulla rete.

  Il collo di bottiglia viene individuato esaminando il contatore delle prestazioni Servizio Gatherer ricerca di SharePoint Server/Thread che accedono alla rete.

Questa situazione indica che i thread sono bloccati in attesa di dati dall'archivio. In un ambiente con più origini di contenuto può rivelarsi utile identificare l'host con tempi di risposta lenti. A tale scopo, sospendere tutte le altre ricerche per indicizzazione e quindi eseguire una ricerca per indicizzazione utilizzando l'origine di contenuto il cui indirizzo iniziale è rappresentato dall'host sospetto.

Dopo aver identificato un host problematico, è necessario individuare la causa della lentezza dei tempi di risposta. Per il contenuto di SharePoint in particolare, vedere l'articolo Capacity management and sizing for SharePoint Server 2010.

La velocità effettiva della ricerca per indicizzazione può essere migliorata in modo significativo ottimizzando le prestazioni degli archivi dei dati sottoposti a ricerca per indicizzazione.

Risoluzione dei problemi di prestazioni e scalabilità

La conoscenza del carico della farm è fondamentale per la risoluzione dei problemi di prestazioni. Nella sezione riportata di seguito vengono utilizzati i dati relativi a una farm attiva contenente 60 milioni di elementi per illustrare diverse metriche di sistema in fasi diverse del ciclo di vita della ricerca.

Esempi di prestazioni durante il ciclo di vita della ricerca

Metrica	Acquisizione dell'indice	Gestione dell'indice	Pulizia dell'indice
CPU di SQL Server (in %) Database delle proprietà / database di ricerca per indicizzazione	14,8 / 19,13	35 / 55	11 / 63
Permanenza presunta delle pagine di SQL Server Database delle proprietà / database di ricerca per indicizzazione	60.548 / 5.913	83.366 / 5.373	33.927 / 2.806
Media scritture disco SQL Server / sec Database delle proprietà / database di ricerca per indicizzazione	9 ms / 48 ms MAX: 466 ms / 1.277 ms	12 ms / 28 ms	20 ms / 49 ms MAX: 253 ms / 1156 ms
Media letture disco SQL Server / sec Database delle proprietà / database di ricerca per indicizzazione	8 ms / 43 ms MAX: 1.362 ms / 2.688 ms	11 ms / 24 ms	24 ms / 29 ms MAX: 2 039 ms / 2 142 ms
CPU crawler (in %) Server di indicizzazione 1 (2 componenti di ricerca per indicizzazione) / Server di indicizzazione 2 (2 componenti di ricerca per indicizzazione)	18 / 11	25,76 / 21,62	8,34 / 7,49 Picchi massimi 99%
Scritture su disco/sec Server di indicizzazione 1 (2 componenti di ricerca per indicizzazione) / Server di indicizzazione 2 (2 componenti di ricerca per indicizzazione)	64,32 / 42,35	93,31 / 92,45	99,81 / 110,98
Letture su disco/sec Server di indicizzazione 1 (2 componenti di ricerca per indicizzazione) / Server di indicizzazione 2 (2 componenti di ricerca per indicizzazione)	0,23 / 0,20	4,92 / 2,03	1,38 / 1,97
Media scritture disco / sec Server di indicizzazione 1 (2 componenti di ricerca per indicizzazione) / Server di indicizzazione 2 (2 componenti di ricerca per indicizzazione)	11 ms / 11 ms	1 ms / 2 ms	5 ms / 4 ms MAX: 1.962 ms / 3.235 ms
Media letture disco / sec Server di indicizzazione 1 (2 componenti di ricerca per indicizzazione) / Server di indicizzazione 2 (2 componenti di ricerca per indicizzazione)	1 ms / 2 ms	12 ms / 11 ms	10 ms / 16 ms MAX: 2.366 ms / 5.206 ms

Risoluzione dei problemi di prestazioni delle query

Il servizio di ricerca di SharePoint dispone di una pipeline di query instrumentata e di report di amministrazione associati che consentono di risolvere i problemi di prestazioni delle query basati sul server. Per ulteriori informazioni, vedere Use search administration reports (SharePoint Server 2010). In questa sezione vengono mostrati i report, che vengono quindi utilizzati per indicare come risolvere i problemi nel server. In questa sezione sono contenuti inoltre gli strumenti e le informazioni aggiuntive disponibili per consentire di risolvere i problemi di prestazioni basati sul client (browser).

Problemi relativi alle query basati sul server

I problemi di prestazioni delle query basati sul server possono essere suddivisi nei due livelli seguenti:

• Problemi di prestazioni front-end del servizio di ricerca

• Problemi di prestazioni back-end del servizio di ricerca

Nelle due sottosezioni seguenti vengono forniti i dettagli per la risoluzione di queste due tipologie di problemi. Si noti che si tratta di linee guida di carattere generale.

Problemi di prestazioni front-end

Il primo passaggio per la risoluzione dei problemi di prestazioni front-end consiste nell'esaminare il report di amministrazione della ricerca Latenza query complessiva. Viene riportato di seguito un report di esempio:

In questo report le prestazioni front-end vengono rappresentate dalle serie di dati seguenti:

• Rendering server: questo valore rappresenta, per il minuto specificato, il tempo medio trascorso per query nelle diverse web part di ricerca nel server Web front-end.

• Modello a oggetti: questo valore rappresenta, per il minuto specificato, il tempo medio trascorso per le comunicazioni tra il server Web front-end e il back-end della ricerca.

Risoluzione dei problemi di rendering del server

I problemi di rendering del server possono dipendere da eventi che si verificano nel server Web front-end che gestisce la pagina dei risultati di ricerca. Verificare in genere quanto tempo viene dedicato al recupero delle diverse web part per individuare il punto in cui viene aggiunta l'ulteriore latenza. Abilitare il Dashboard di sviluppo (le informazioni potrebbero essere in lingua inglese) nella pagina dei risultati di ricerca per una segnalazione dettagliata della latenza. Tra i problemi comuni che indicano un'eccessiva latenza di rendering del server sono inclusi i seguenti:

• Problemi di piattaforma, ad esempio quelli indicati di seguito:

  • Lentezza delle ricerche con Active Directory

  • Tempi lenti di SQL Server

  • Lentezza delle richieste all'applicazione profilo utente nelle query utente in SharePoint Server 2010 o in tutte le query in FAST Search Server 2010 for SharePoint

  • Lentezza delle richieste per il recupero delle preferenze utente

  • Lentezza delle chiamate per ottenere il token dell'utente dal servizio token di sicurezza

• Problemi code-behind, ad esempio pagine dei risultati di ricerca modificate (come results.aspx e peopleresults.aspx) di cui viene eseguita l'archiviazione, ma non la pubblicazione.

Risoluzione dei problemi del modello a oggetti

I problemi del modello a oggetti possono dipendere dai fattori seguenti:

• Problemi con il livello WCF (Windows Communication Foundation), ad esempio:

  • Timeout ed eccezioni di interruzione di thread nelle chiamate WCF nella distribuzione.

  • Comunicazioni lente tra il server Web front-end e il server applicazioni che possono essere dovute a problemi di IPSec o a connessioni di rete lente.

• Problemi di comunicazione tra le farm di contenuto e di sevizio (se configurate).

Problemi di prestazioni back-end

Il primo passaggio per la risoluzione dei problemi di prestazioni back-end consiste nell'esaminare il report di amministrazione della ricerca Latenza query back-end SharePoint. Viene riportato di seguito un report di esempio:

In questo report le prestazioni back-end sono rappresentate dalle serie di dati seguenti (ognuna indica il tempo medio trascorso per query, nel minuto specificato), raggruppate per componente funzionale:

• Componente di query:

  • Query full-text: tempo medio trascorso per l'esecuzione di query nell'indice full-text per ottenere risultati.

• Database delle proprietà:

  • Recupero di più risultati: tempo medio trascorso per il recupero di metadati di documenti, ad esempio titolo o autore, che devono essere visualizzati nei risultati di query.

  • Query archivio proprietà: tempo medio trascorso per l'esecuzione di query nel database delle proprietà per query basate sulle proprietà.

• Database di amministrazione della ricerca:

  • Elementi di maggiore rilevanza: tempo medio trascorso per l'individuazione di eventuali elementi di maggiore rilevanza disponibili per i termini di query.

  • Risultati con confidenza elevata: tempo medio trascorso per il recupero di risultati con confidenza elevata per le query.

• Sistema di elaborazione query:

  • Limitazione per motivi di sicurezza: tempo medio trascorso per la rimozione di elementi a cui l'utente non ha accesso.

  • Rimozione duplicati: tempo medio trascorso per la rimozione di duplicati.

  • Popolamento risultati: tempo medio trascorso per la creazione della tabella in memoria da passare al modello a oggetti.

Risoluzione dei problemi di prestazioni dei componenti di query

I componenti di query sono a elevato utilizzo di risorse, soprattutto se il componente è attivo, ovvero risponde alle richieste di query. La risoluzione dei problemi di prestazioni dei componenti di query è una delle aree di ricerca più complicate. Vengono riportate di seguito le aree generali di cui tenere conto:

• L'evento dei componenti di query che comporta il più elevato utilizzo di risorse è l'unione master, in cui gli indici shadow vengono uniti con l'indice master. Questo evento si verifica in modo indipendente per ogni componente di query. Un esempio dell'effetto è visibile nel report Latenza query back-end SharePoint menzionato più indietro in questo articolo, in orari antecedenti alle 13:30. Se questo evento ha effetto sulla latenza delle query, è possibile definire periodi di blackout in cui viene evitato un evento di unione master a meno che la percentuale di modifiche non superi il limite definito.

• Valori molto elevati per l'ambiente indicano che probabilmente è necessario eseguire le operazioni seguenti:

  • Esaminare le dimensioni degli indici per ogni componente nel server. Verificare che nel server sia disponibile RAM sufficiente per supportare circa il 33% della somma delle dimensioni degli indici da memorizzare nella cache.

  • Esaminare il canale di I/O dei componenti di query nel server. Controllare che non si verifichi un collo di bottiglia di I/O.

  • Se le operazioni di I/O e la RAM non sono la causa del problema delle prestazioni, è consigliabile ripartizionare i componenti di query (aggiungendo partizioni di indice) implementando la scalabilità orizzontale con ulteriori componenti di query in nuovi server.

Risoluzione dei problemi di database delle proprietà

Esaminare lo stato di SQL Server utilizzando i concetti illustrati in Pianificazione e configurazione dell'archiviazione e della capacità di SQL Server (SharePoint Server 2010). Se si eseguono query personalizzate, potrebbe essere necessario esaminare i suggerimenti per l'esecuzione del piano di query corretto.

Risoluzione dei problemi dei database di amministrazione della ricerca

Esaminare lo stato di SQL Server utilizzando i concetti illustrati in Pianificazione e configurazione dell'archiviazione e della capacità di SQL Server (SharePoint Server 2010).

Risoluzione dei problemi dei sistemi di elaborazione delle query

La risoluzione dei problemi dei sistemi di elaborazione delle query dipende dall'area del sistema di elaborazione delle query tra quelle indicate di seguito che influisce sulla latenza delle query:

• Limitazione per motivi di sicurezza:

  • Per le attestazioni di Windows, esaminare la connessione Active Directory dal server che ospita il sistema di elaborazione delle query.

  • In tutti i casi, la dimensione della cache che viene utilizzata dal sistema di elaborazione delle query può essere aumentata se esiste una correlazione tra un numero elevato di round trip di SQL Server (determinati da SQL Server Profiler). In oltre il 25% delle query non dovrebbe essere necessaria una chiamata di SQL Server per recuperare i descrittori di sicurezza dal database di amministrazione della ricerca. In caso contrario, modificare la dimensione della cache del sistema di elaborazione delle query.

• Rimozione duplicati:

  • Controllare se si esegue la ricerca per indicizzazione dello stesso contenuto in più posizioni. Disabilitare il rilevamento dei duplicati nel Centro ricerche.

• Recupero di più risultati:

  • Esaminare lo stato di SQL Server utilizzando i concetti illustrati in Pianificazione e configurazione dell'archiviazione e della capacità di SQL Server (SharePoint Server 2010).

Problemi relativi alle query basati sul browser

Gli utenti possono essere soddisfatti o esasperati dalla velocità dei risultati di ricerca. Il tempo di caricamento delle pagine è uno dei fattori importanti per il livello di soddisfazione degli utenti relativamente alla funzionalità di ricerca. La maggior parte delle operazioni che influiscono sui tempi di caricamento delle pagine si verifica sul lato server, soprattutto per quanto riguarda il tempo impiegato dal server per restituire i risultati. Il rendering sul lato client tuttavia può rappresentare una parte significativa del tempo di caricamento delle pagine e deve essere preso in considerazione.

Le prestazioni del servizio di ricerca per gli utenti devono garantire risposte dell'ordine inferiore al secondo per il tempo di caricamento totale delle pagine. Il rendering del client in genere richiede meno di 280 millisecondi, a seconda del browser e della misurazione del rendering. Questo sistema offre risultati ottimali per gli utenti.

Se si personalizza l'esperienza relativa ai risultati, esiste il rischio di rallentare le prestazioni del rendering. Gli amministratori e gli sviluppatori del servizio di ricerca devono misurare con accuratezza il tempo di rendering dopo ogni modifica per evitare che le prestazioni subiscano rallentamenti significativi. Ogni aggiunta alla pagina, da una nuova web part a un nuovo foglio di stile CSS, determina un aumento del tempo di rendering nel browser e un ritardo dei risultati per gli utenti. L'entità del ritardo tuttavia può variare in modo significativo a seconda che siano state seguite le procedure consigliate durante la personalizzazione della pagina.

Vengono riportate di seguito alcune linee guida generali:

• Le personalizzazioni di base e dello stile non devono comportare un aggiunta superiore a circa 25 ms al tempo di caricamento delle pagine. Misurare il tempo di caricamento delle pagine prima e dopo l'implementazione delle personalizzazioni per osservare il cambiamento.

• Gli utenti in genere notano un cambiamento (aumento o riduzione della velocità) in un incremento del 20%. Tenere conto di questo aspetto quando si apportano modifiche. Il 20% del tempo di rendering standard corrisponde solo a 50 ms (fonte: Tempo di creazione e progettazione (le informazioni potrebbero essere in lingua inglese)).

• I fogli di stile CSS e JScript sono i fattori più comuni che determinano prestazioni di rendering elevate. Se sono stati personalizzati questi elementi, accertarsi che le personalizzazioni siano state limitate a un file ognuno.

• Il linguaggio JScript può essere caricato su richiesta dopo il rendering della pagina per fornire più rapidamente all'utente risultati visibili. Per informazioni dettagliate, vedere l'articolo relativo alle considerazioni sulle prestazioni.

• Maggiore è il numero di personalizzazioni aggiunte alla pagina, più lento sarà il caricamento. Valutare se la qualità delle funzionalità e dello stile aggiunti giustificano il ritardo aggiuntivo con cui vengono visualizzati i risultati agli utenti.

Oltre a queste linee guida, sono disponibili numerose informazioni su Internet su come ridurre i tempi di caricamento delle pagine e sugli effetti delle pagine lente sull'esperienza utente.

Risoluzione dei problemi di prestazioni della ricerca per indicizzazione

Nel servizio di ricerca di SharePoint possono verificarsi colli di bottiglia nel sottosistema di ricerca per indicizzazione man mano che il sistema attraversa le fasi di acquisizione, gestione ed eliminazione dell'indice. Per risolvere efficacemente i problemi di prestazioni della ricerca per indicizzazione, è consigliabile utilizzare i report di monitoraggio dello stato della ricerca congiuntamente alle informazioni fornite nella sezione "Comuni colli di bottiglia e relative cause" più avanti in questo articolo in modo da isolare i problemi di ricerca per indicizzazione.

Risoluzione dei problemi durante la fase di acquisizione dell'indice

Il primo strumento che consente di individuare eventuali problemi di ricerca per indicizzazione è il report sullo stato Frequenza di ricerca per indicizzazione per origine contenuto. Come illustrato più avanti in questo articolo, nel report viene fornita una panoramica della velocità della ricerca per indicizzazione per ogni origine di contenuto del sistema. La velocità della ricerca per indicizzazione in genere deve essere superiore a 15 documenti/sec per un'origine di contenuto degli utenti e a 35 documenti/sec per tutti gli altri tipi di origini di contenuto.

Se viene individuata un'origine di contenuto con una velocità della ricerca per indicizzazione non ottimale, è consigliabile eseguire le operazioni seguenti:

1. Sospendere tutte le altre ricerche per indicizzazione ad eccezione dell'origine di contenuto in esame. Verificare se la velocità della ricerca per indicizzazione è aumentata oltre l'obiettivo di 15-35 documenti/sec specificato.

2. Se il passaggio precedente non è risolutivo, controllare che l'archivio sottoposto a ricerca per indicizzazione risponda in tempi soddisfacenti e non sia la causa del rallentamento della velocità della ricerca per indicizzazione. Vedere la sezione "Collo di bottiglia della ricerca per indicizzazione nell'archivio" più indietro in questo articolo.

3. Se il problema non è rappresentato dall'archivio, individuare il collo di bottiglia nel server di ricerca per indicizzazione o nel server di database e implementare l'ottimizzazione. Per istruzioni, vedere le sezioni "Collo di bottiglia delle operazioni di I/O al secondo della ricerca per indicizzazione" e "Collo di bottiglia dei thread della CPU di ricerca per indicizzazione" più indietro in questo articolo.

Risoluzione dei problemi durante la fase di gestione dell'indice

L'obiettivo principale durante la fase di gestione dell'indice consiste nel mantenere l'indice il più aggiornato possibile. Vengono illustrati di seguito due indicatori chiave:

• Livello di aggiornamento dell'indice: verificare se le ricerche per indicizzazione vengono concluse nei tempi previsti e in conformità con le linee guida IT relative al livello di aggiornamento dell'indice.

• Velocità della ricerca per indicizzazione incrementale: se l'obiettivo del livello di aggiornamento dell'indice non viene raggiunto, controllare se la velocità della ricerca per indicizzazione incrementale è di 10 documenti/sec per le origini di contenuto degli utenti e di 35 documenti/sec per tutte le altre origini di contenuto. Se la velocità della ricerca per indicizzazione incrementale non è ottimale, è consigliabile eseguire un'analisi dei colli di bottiglia nell'archivio sottoposto a ricerca per indicizzazione e nel sottosistema di ricerca per indicizzazione, come descritto precedentemente.

Comuni colli di bottiglia e relative cause

Durante i test delle prestazioni si sono manifestati diversi colli di bottiglia comuni. Un collo di bottiglia è una condizione in cui viene raggiunto il limite di capacità di un singolo componente di una farm. Questa situazione dà origine a un ristagno o a una diminuzione della velocità effettiva della farm.

Nella tabella riportata di seguito vengono elencati alcuni comuni colli di bottiglia con le relative cause e le possibili soluzioni.

Collo di bottiglia	Sintomo (contatore delle prestazioni)	Soluzione
RAM database	Database delle proprietà, database di amministrazione della ricerca: Gestione buffer di SQL Server / permanenza presunta delle pagine < 300(s) (dovrebbe essere > 1000 (s)) Gestione buffer di SQL Server / percentuale riscontri cache buffer < 96% (dovrebbe essere > 98%)	Aggiungere memoria al server di database. Deframmentare il database delle proprietà, qualora la regola di deframmentazione settimanale sia stata disabilitata. Utilizzare SQL Server 2008 Enterprise Edition per abilitare la compressione delle pagine. Spostare il database in un server separato e aggiungere più database delle proprietà, se necessari.
Operazioni di I/O al secondo dei server di database	Database delle proprietà o database di ricerca per indicizzazione: Media letture disco / sec e media scritture disco / sec ~50 ms o > 50 ms	Verificare che il server di database disponga di RAM sufficiente per mantenere il 33% delle tabelle critiche (MSSDocSDIDs + MSSDocProps + MSSDocresults) nella cache. Aumentare il numero dedicato di operazioni di I/O al secondo (IOPS) per il database eseguendo le operazioni seguenti: Utilizzare array di archiviazione diversi. Ottimizzare la configurazione dello spazio di archiviazione, ad esempio aggiungendo dischi fisici (unità disco) all'array di archiviazione. Eseguire l'analizzatore dell'integrità di SharePoint "Ricerca - Uno o più database delle proprietà contengono indici frammentati", qualora sia stato disabilitato. Eseguire l'analizzatore dell'integrità di SharePoint "Ricerca - Uno o più database di ricerca per indicizzazione possono contenere indici frammentati". Utilizzare SQL Server 2008 Enterprise Edition per abilitare la compressione delle pagine. Spostare il database in un server separato, aggiungendo più database delle proprietà o di ricerca per indicizzazione oppure entrambi, se necessari.
Operazioni di I/O al secondo dei componenti di query	Disco logico utilizzato per l'indice di un componente di query: Media letture disco / sec e media scritture disco / sec ~30 ms o > 30 ms per un periodo di tempo esteso, ovvero la maggior parte del giorno e non solo durante un'unione di indice.	Verificare che ogni server applicazioni disponga di RAM sufficiente per mantenere il 33% dell'indice di ogni componente di query attivo di tale server nella cache del sistema operativo. Aumentare il numero dedicato di operazioni di I/O al secondo (IOPS) per l'unità utilizzata per l'indice del componente di query eseguendo le operazioni seguenti: Utilizzare array di archiviazione diversi per componenti diversi. Ottimizzare la configurazione dello spazio di archiviazione, ad esempio aggiungendo dischi fisici (unità disco) all'array di archiviazione.

Informazioni sull'autore

Brion Stone è Senior Program Manager per il servizio di ricerca di SharePoint Server presso Microsoft.