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

SharePoint 2010
 

Si applica a: SharePoint Foundation 2010

Ultima modifica dell'argomento: 2015-03-09

In questo articolo vengono fornite informazioni sulla pianificazione della capacità per una distribuzione della ricerca di Microsoft SharePoint Foundation 2010.

Contenuto dell'articolo:

In questo articolo viene descritta una distribuzione specifica di SharePoint Foundation 2010 e sono incluse le seguenti specifiche utilizzate durante il test delle prestazioni e della capacità di SharePoint Foundation 2010 :

  • 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 della farm di test, inclusi i contenuti dei database, gli indici di ricerca e le origini dati esterne.

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

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.

Il servizio di ricerca di SharePoint Foundation 2010 fornisce le funzionalità di base per le ricerche per il contenuto locale di SharePoint Foundation. Se sono necessarie funzionalità di ricerca più avanzate, quali l'indicizzazione di cartelle condivise locali e contenuto SharePoint Foundation o HTTP remoto, utilizzare il servizio di ricerca di Microsoft Search Server Express 2010 o Microsoft SharePoint Server 2010.

In questo articolo viene descritto come eseguire quanto segue:

  • 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 implementare la scalabilità verticale o orizzontale nell'ambiente per raggiungere gli obiettivi di prestazioni e capacità. Per aumentare la capacità e le prestazioni di una delle topologie di partenza, è possibile procedere in due modi. È possibile implementare la scalabilità verticale aumentando la capacità dei server esistenti oppure implementare la scalabilità orizzontale aggiungendo ulteriori server alla topologia.

  • Monitorare l'ambiente in base a indicatori chiave.

In questa sezione vengono descritti lo scenario del test, il set di dati utilizzato durante il testing, i carichi di lavoro applicati a SharePoint Foundation durante la raccolta dei dati relativi alle prestazioni, l'hardware utilizzato nel corso del testing e la topologia di distribuzione di tale hardware.

Questo scenario del servizio di ricerca di SharePoint Foundation descrive una distribuzione di ricerca tipica, con le seguenti caratteristiche:

  • Il servizio di ricerca viene fornito per il contenuto di SharePoint Foundation nella farm. Non è possibile aggiungere contenuto esterno all'indice, ad esempio siti Web Intranet o file system.

  • Il servizio di ricerca può essere eseguito su un unico server nella farm per volta. La scalabilità orizzontale non è supportata.

  • È disponibile un'amministrazione di sistema limitata per la ricerca.

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.

 

Dimensione degli indici di ricerca (numero di elementi)

5677481

Dimensione del database di ricerca

54 GB

Dimensione del file di registro della ricerca

2 GB

Dimensione del database del contenuto

161 GB

Dimensione del file di registro del database del contenuto

10,6 GB

Dimensione della partizione di indice

23,7 GB

Numero totale di database di ricerca

8

Altri database utilizzati durante il testing delle prestazioni e della capacità di SharePoint Foundation 2010

SharePoint_Config; SharePoint_AdminContent; State_Service; Bdc_Service_db; WSS_UsageApplication; WSS_Content

In questa sezione vengono descritti i tipi di hardware utilizzati nel nostro laboratorio e la topologia di configurazione della farm utilizzata nei test.

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

ImportanteImportant
Dato che la farm eseguiva versioni non definitive di SharePoint Foundation 2010, l'hardware utilizzato presenta una capacità superiore rispetto a quanto richiesto in circostanze più tipiche.

Server applicazioni e server di contenuti

Server Combinato

Processori

1px4c a 3 GHz

RAM

16 GB

Sistema operativo

Windows Server 2008 R2, 64 bit

Archiviazione

6 x 450 GB serial attached SCSI (SAS)

Numero di schede di rete

2

Velocità delle schede di rete

1 gigabit

Autenticazione

NTLM

Tipo di servizio di bilanciamento del carico

Nessuno

Versione software

SharePoint Foundation 2010 (versione non definitiva)

Servizi in esecuzione localmente

Servizio timer flussi di lavoro Microsoft SharePoint Foundation; servizio di ricerca di SharePoint Foundation

Impostazione della cache oggetti

Predefinita (minimo 100 MB); cache per 60 secondi; clmq multi: 3

Computer Microsoft SQL Server

Server Combinato

Processori

2px4c a 3 GHz

RAM

16 GB

Sistema operativo

Windows Server 2008 R2, 64 bit

Archiviazione

6 x 450 GB SAS

Numero di schede di rete

2

Velocità delle schede di rete

1 gigabit

Autenticazione

NTLM

Tipo di servizio di bilanciamento del carico

Nessuno

Versione software

SQL Server 2008 Enterprise

Servizi in esecuzione localmente

Servizio SQL Server

Posizione del database dei dati

Unità condivisa con altri database

La farm di testing è una farm a due server. Un server è il server Web e applicazioni e il secondo server è il server di database.

Topologia della farm di testing

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

 

Caratteristiche del carico di lavoro Valore

Descrizione di alto livello del carico di lavoro (collaborazione, gestione del contenuto Web, social)

Farm di ricerca e farm del contenuto

Media di query al minuto

Non applicabile

Media utenti simultanei

Non applicabile

Numero totale di query al giorno

Non applicabile

Carico di processi timer

Processi timer: Avvisi immediati, Aggiornamento servizio di ricerca di SharePoint Foundation, Processo di analisi integrità

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

Le misurazioni riportate di seguito state effettuate su 140.000 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. La memoria CPU e le operazioni di I/O al secondo sono state lette direttamente dai contatori Perfmon. La latenza è stata misurata utilizzando un progetto Microsoft Visual Studio Team System 2008 Database Edition che eseguiva un insieme di circa 2.000 query su un sito del team.

 

Categoria di metrica Metrica scorecard Test di query

CPU

Utilizzo medio della CPU di SQL Server

21,83

Contatori delle prestazioni

Media di server Web front-end, server di query, indicizzazione CPU

95,84

Richieste ASP.NET in coda (media di tutti i server Web front-end)

Non applicabile

Blocchi di SQL Server: tempo medio di attesa (ms)

0,342

Blocchi di SQL Server: tempo di attesa blocchi (ms)

0,171

Blocchi di SQL Server: deadlock/sec

0

Latch SQL Server: tempo medio di attesa (ms)

0,147

Compilazioni SQL Server/sec

191,75

Statistiche SQL Server: ricompilazioni SQL Server/sec

0,075

Lunghezza coda disco media (server di query)

0,007

Lunghezza coda del disco: letture (server di query)

Non applicabile

Risultati dei test

Lunghezza coda del disco: scritture (server di query)

0,007

Letture disco/sec (server di query)

0,188

Scritture disco/sec (server di query)

125,676

Lunghezza media della coda del disco (indicizzatore, server Web front-end, server di query)

0,006

Lunghezza coda del disco: letture (indicizzatore, server Web front-end, server di query)

Non applicabile

Lunghezza coda del disco: scritture (indicizzatore, server Web front-end, server di query)

0,003

Letture disco/sec (indicizzatore, server Web front-end, server di query)

0,706

Scritture disco/sec (indicizzatore, server Web front-end, server di query)

11,79

Memoria media utilizzata (indicizzatore, server Web front-end, server di query)

14,129

Memoria massima utilizzata (indicizzatore, server Web front-end, server di query)

14,331

Rapporto riscontri cache (SQL Server)

100

Risultati dei test

Latenza interfaccia utente query (75° percentile) (sec)

0,128

Latenza interfaccia utente query (95° percentile) (sec)

0,151

Velocità effettiva delle query (carico utente 80) (richieste/sec)

60,86

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

 

Categoria di metrica Metrica scorecard Test della ricerca per indicizzazione per raggiungere la dimensione dell'indice di 140.000

CPU

Utilizzo medio della CPU di SQL Server

9,48

Contatori delle prestazioni

Media di server Web front-end, server di query, indicizzazione CPU

87,32

Richieste ASP.NET in coda (media di tutti i server Web front-end)

Non applicabile

Blocchi di SQL Server: tempo medio di attesa (ms)

13,45

Blocchi di SQL Server: tempo di attesa blocchi (ms)

11,39

Blocchi di SQL Server: deadlock/sec

0

Latch SQL Server: tempo medio di attesa (ms)

3,03

Compilazioni SQL Server/sec

27,8

Statistiche SQL Server: ricompilazioni SQL Server/sec

1,048

Lunghezza media della coda del disco (SQL Server)

4,524

Lunghezza coda del disco: letture (SQL Server)

Non applicabile

Risultati dei test

Lunghezza coda del disco: scritture (SQL Server)

3,918

Letture disco/sec (SQL Server)

71,76

Scritture disco/sec (SQL Server)

349,485

Lunghezza media della coda del disco (indicizzatore, server Web front-end, server di query)

0,058

Lunghezza coda del disco: letture (indicizzatore, server Web front-end, server di query)

Non applicabile

Lunghezza coda del disco: scritture (indicizzatore, server Web front-end, server di query)

0,049

Letture disco/sec (indicizzatore, server Web front-end, server di query)

3,295

Scritture disco/sec (indicizzatore, server Web front-end, server di query)

138,83

Memoria media utilizzata (indicizzatore, server Web front-end, server di query)

15,28%

Memoria massima utilizzata (indicizzatore, server Web front-end, server di query)

15,84%

Rapporto riscontri cache (SQL Server)

99,865

Risultati dei test

Velocità ricerca per indicizzazione totale (elementi/sec)

171,73

Numero di esiti positivi

138590

Numero di errori

12

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

Nel grafico riportato di seguito vengono mostrati i percentili di latenza delle query della farm man mano che aumenta il carico utente. Un percentile di query del 95% indica che il 95% delle latenze delle query misurate è stato inferiore a tale valore.

Grafico del confronto della latenza query con il numero

Da questo grafico risulta che l'aumento delle dimensioni del contenuto sottoposto a ricerca per indicizzazione dalla farm incide sulla latenza delle query quando il carico utente supera i 20 utenti simultanei.

Con circa 5 milioni di elementi nell'indice, le latenze delle query sono molto elevate, come mostrato nel grafico seguente.

Grafico della latenza query all'aumentare del carico utente

Nel grafico riportato di seguito viene mostrata la velocità effettiva delle query della farm man mano che aumenta il carico utente.

Grafico della velocità effettiva della query all'aumentare del carico utente

Da questo grafico risulta che l'aumento delle dimensioni del contenuto sottoposto a ricerca per indicizzazione dalla farm incide significativamente sulla velocità effettiva delle query, aumentandola quando il carico supera i 10 utenti simultanei.

Con circa 5 milioni di elementi nell'indice, la velocità effettiva delle query può ridursi drasticamente, come mostrato nel grafico seguente.

Grafico del confronto della velocità effettiva della query con il numero

Nel grafico riportato di seguito viene illustrata la velocità della ricerca per indicizzazione per la farm durante la fase di acquisizione dell'indice con diverse dimensioni di indice esistenti. Tenere presente che la velocità della ricerca per indicizzazione si riduce man mano che l'indice cresce.

Grafico della frequenza della ricerca per indicizzazione durante l'acquisizione dell'indice

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

Per informazioni specifiche sui requisiti di sistema minimi e consigliati, vedere Requisiti hardware e software (SharePoint Foundation 2010).

La scalabilità orizzontale non può essere applicata al sottosistema di ricerca per SharePoint Foundation 2010. In generale, in presenza di più di 1 milione di elementi da indicizzare, è consigliabile utilizzare il servizio di ricerca di Server di ricerca 2010 Microsoft o SharePoint Server 2010.

Alcuni dei problemi relativi alla bassa velocità effettiva e alla latenza elevata delle query possono essere evitati applicando la scalabilità verticale a CPU, RAM e operazioni di I/O al secondo nei server applicazioni e nei computer con SQL Server.

Per determinare quando è necessario implementare la scalabilità verticale o orizzontale per il sistema, utilizzare i contatori delle prestazioni per monitorare l'integrità del sistema.

Utilizzare le informazioni riportate nelle tabelle seguenti per stabilire quali contatori delle prestazioni monitorare e a quale processo applicarli.

Nella tabella riportata di seguito sono indicati i contatori delle prestazioni e i processi da monitorare per i server Web della farm.

 

Contatore delle prestazioni Oggetto a cui si applica Note

Tempo processore

Totale

Indica la percentuale del tempo trascorso in cui il thread corrente ha utilizzato il processore per eseguire istruzioni.

Utilizzo memoria

Pool di applicazioni (W3wp.exe)

Indica l'utilizzo medio della memoria del sistema per il pool di applicazioni. È necessario specificare il pool di applicazioni corretto (istanza di W3wp.exe) da monitorare. È consigliabile determinare il picco di utilizzo della memoria per una determinata applicazione Web e assegnare tale numero più 10 al pool di applicazioni associato.

Nella tabella riportata di seguito sono indicati i contatori delle prestazioni e i processi da monitorare per i server di database della farm.

 

Contatore delle prestazioni Oggetto a cui si applica Note

Lunghezza media della coda del disco

Disco rigido contenente SharedServices.mdf

Valori medi superiori a 1,5 per asse indicano che i tempi di scrittura per tale disco rigido non sono sufficienti.

Media secondi/trasf. disco

Disco rigido contenente SharedServices.mdf

Tempo medio impiegato per trasferire dati nel e dal disco.

  • Un valore inferiore a 20 ms è ottimo.

  • Un valore compreso tra 20 e 40 ms è buono.

  • Un valore superiore a 50 ms indica che è necessaria l'ottimizzazione con l'aggiunta di operazioni di I/O al secondo.

Tempo processore

Processo di SQL Server

Valori medi superiori all'80% indicano che la capacità del processore nel server di database non è sufficiente.

Utilizzo memoria

Totale

Indica l'utilizzo medio della memoria del sistema.

Percentuale riscontri cache buffer

Gestione buffer di SQL Server

Una percentuale di riscontri cache buffer inferiore al 96% indica un collo di bottiglia della memoria. Per risolvere il problema, aggiungere ulteriori RAM. La percentuale ottimale è superiore al 98%.

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

Mostra: