Valutare i requisiti di prestazioni e capacità per PerformancePoint Services

Si applica a: SharePoint Server 2010

Ultima modifica dell'argomento: 2017-01-18

In questo articolo viene descritto l'effetto prodotto dall'utilizzo di PerformancePoint Services sulle topologie in cui viene eseguito Microsoft SharePoint Server 2010.

Contenuto dell'articolo:

• Caratteristiche della farm di testing

• Risultati dei test

• Suggerimenti

Per informazioni generali su come pianificare ed eseguire la pianificazione della capacità per SharePoint Server 2010, vedere Capacity management and sizing for SharePoint Server 2010.

Caratteristiche della farm di testing

Set di dati

Il set di dati è costituito da un portale aziendale creato utilizzando SharePoint Server 2010 e PerformancePoint Services contenente un unico dashboard di medie dimensioni. Nel dashboard sono contenuti due filtri collegati a una scorecard, due grafici e una griglia. Il dashboard si basa su una singola origine dati di Microsoft SQL Server 2008 Analysis Services (SSAS) in cui viene utilizzato il database di esempio AdventureWorks per il cubo SQL Server 2008 Analysis Services.

Nella tabella riportata di seguito vengono descritti il tipo e le dimensioni di ogni elemento del dashboard.

Il dashboard di medie dimensioni si basa sul modello di intestazione e due colonne, mentre le dimensioni degli elementi del dashboard sono impostate sul ridimensionamento automatico o su una percentuale specifica del dashboard. Il rendering di ogni elemento del dashboard è stato eseguito con un'altezza e una larghezza casuali comprese tra 400 e 500 pixel per simulare le differenze di dimensioni tra le finestre dei Web browser. È importante modificare l'altezza e la larghezza di ogni elemento del dashboard perché il rendering dei grafici dipende dalle dimensioni delle finestre dei Web browser.

Scenari e processi di test

In questa sezione vengono definiti gli scenari di test e viene illustrato il processo di test utilizzato per ogni scenario. Per informazioni dettagliate, ad esempio i risultati dei test e i parametri specifici, vedere la sezione Risultati dei test più avanti in questo articolo.

È stata utilizzata una singola combinazione di test costituita dalle percentuali seguenti di test avviati.

Sono stati utilizzati gli strumenti di test di carico di Microsoft Visual Studio 2008 per creare un insieme di test Web e test di carico in grado di simulare uno scenario in cui gli utenti modificano i filtri in modo casuale e si spostano nell'ambito di griglie e grafici. Nei test utilizzati in questo articolo è contenuta una normale distribuzione di pause da 15 secondi, conosciute anche come "tempo interazione utente," tra le interazioni e un tempo interazione utente di 15 secondi tra le iterazioni dei test. Il carico è stato applicato per produrre un tempo di risposta medio di due secondi per il rendering di una scorecard o di un report. Il tempo medio di risposta è stato misurato su un periodo di 15 minuti dopo un tempo di riscaldamento iniziale di 10 minuti.

Ogni nuova iterazione di test seleziona un account utente diverso in un pool di 5000 account e un indirizzo IP casuale (con commutazione IP di Visual Studio) in un pool di circa 2200 indirizzi.

La combinazione di test è stata eseguita due volte per lo stesso dashboard di medie dimensione. Nella prima esecuzione l'autenticazione dell'origine dati è stata configurata per l'utilizzo dell'account di servizio automatico, che utilizza un account comune per richiedere i dati. I risultati dei dati sono identici per più utenti e PerformancePoint Services può utilizzare la memorizzazione nella cache per migliorare le prestazioni. Nella seconda esecuzione l'autenticazione dell'origine dati è stata configurata per l'utilizzo dell'identità per utente e il cubo SQL Server Analysis Services è stato configurato per l'utilizzo della sicurezza dinamica. In questa configurazione PerformancePoint Services si basa sull'identità dell'utente per richiedere i dati. Poiché i risultati dei dati possono essere diversi, non è possibile condividere tra gli utenti la memorizzazione nella cache. In alcuni casi la memorizzazione nella cache per l'identità per utente può essere condivisa se non è configurata la sicurezza dinamica Analysis Services e se i ruoli di Analysis Services a cui sono assegnati gli utenti e i gruppi di Microsoft Windows sono identici.

Impostazione e topologia hardware

Hardware di laboratorio

Per offrire informazioni dettagliate sui risultati dei test generali, sono state utilizzate diverse configurazioni di farm per i test. Le configurazioni di farm sono costituite da uno a tre server Web, da uno a quattro server applicazioni e da un singolo server di database in cui è in esecuzione Microsoft SQL Server 2008. È stata eseguita un'installazione aziendale predefinita di SharePoint Server 2010.

Nella tabella riportata di seguito vengono elencati i componenti hardware specifici utilizzati per i test.

Dopo aver implementato nella farm la scalabilità orizzontale per più server Web, è stato utilizzato un bilanciamento del carico hardware per bilanciare il carico utente su più server Web tramite l'affinità dell'indirizzo di origine. L'affinità dell'indirizzo di origine registra l'indirizzo IP di origine delle richieste in ingresso e l'host dei servizi in cui è stato eseguito il bilanciamento del carico e incanala tutte le transazioni future verso lo stesso host.

Topologia

La topologia di partenza è costituita da due server fisici, con un server che agisce da server Web e server applicazioni e il secondo server che agisce da server di database. Questa topologia di partenza è considerata una topologia con due computer (2C) o topologia "1 per 0 per 1", in cui è elencato per primo il numero di server Web dedicati, seguiti dai server applicazioni dedicati e quindi dai server di database.

I server Web vengono anche indicati come server Web front-end (WFE) più avanti in questo documento. Il carico è stato applicato finché non sono stati rilevati fattori di limite. La CPU nel server Web o nel server applicazioni in genere è un fattore di limite, per ovviare al quale sono state aggiunte alcune risorse. I fattori di limite e le topologie variano in modo significativo in base alla configurazione dell'autenticazione dell'origine dati basata sull'account di servizio automatico o sull'identità per utente con la sicurezza dei cubi dinamici.

Risultati dei test

I risultati dei test contengono tre misure importanti che consentono di definire la capacità di PerformancePoint Services.

Nel caso di topologie con più di quattro server applicazioni, è probabile che il collo di bottiglia sia rappresentato dal server Analysis Services. Valutare la possibilità di monitorare la CPU e i tempi di esecuzione delle query per il server Analysis Services per determinare se è opportuno implementare in Analysis Services la scalabilità orizzontale per più server. Eventuali ritardi nei tempi di esecuzione delle query nel server Analysis Services determina un aumento significativo dei tempi medi di risposta di PerformancePoint Services oltre la soglia auspicata di due secondi.

Nelle tabelle riportate di seguito vengono riepilogati i risultati dei test sia per l'autenticazione basata sull'account di servizio automatico che per l'autenticazione basata sull'identità per utente quando si implementa la scalabilità orizzontale da due a sette server. Più avanti in questo documento vengono forniti risultati dettagliati che includono ulteriori contatori delle prestazioni.

Riepilogo per l'autenticazione basata sull'account di servizio automatico

Riepilogo per l'autenticazione basata sull'identità per utente

Topologie 2C e 3C

Per illustrare il costo hardware per transazione e e la curva dei tempi di risposta, i test di carico sono stati eseguiti con quattro carichi utente crescenti fino al massimo carico utente per le topologie 2C e 3C.

Autenticazione basata sull'account di servizio automatico

Autenticazione basata sull'identità per utente

Risultati farm 3C (1x1x1)

Autenticazione basata sull'account di servizio automatico

Autenticazione basata sull'identità per utente

Risultati della topologia 4C+ per l'autenticazione basata sull'account di servizio automatico

Partendo da una topologia 4C, è stato applicato un carico per produrre un tempo di risposta medio di due secondi per il rendering di una scorecard o di un report. È stato aggiunto quindi un ulteriore server per risolvere il fattore di limite (sempre la CPU nel server Web o nel server applicazioni) e quindi è stata rieseguita la combinazione di test. Questa logica è stata ripetuta finché non è stato raggiunto un massimo di sette server.

Risultati 4C+ per l'autenticazione basata sull'identità per utente

Gli stessi test sono stati ripetuti per un'origine dati configurata per l'autenticazione basata sull'identità per utente. Si noti che l'aggiunta di un server applicazioni per la creazione di una topologia con quattro server applicazioni non ha comportato un aumento del numero di utenti o di richieste al secondo per PerformancePoint Services a causa dei ritardi delle query prodotti da Analysis Services.

Suggerimenti

Consigli per i componenti hardware

Utilizzare i contatori per la memoria e per i processori illustrati nelle tabelle dei test per determinare i requisiti hardware per un'installazione di PerformancePoint Services. Per i server Web, in PerformancePoint Services vengono utilizzati i requisiti hardware di SharePoint Server 2010 consigliati. Potrebbe essere necessario cambiare i requisiti hardware dei server applicazioni se PerformancePoint Services utilizza una quantità elevata di memoria. Questo problema si riscontra se le origini dati sono configurate per l'autenticazione basata sull'identità per utente o se nel server applicazioni vengono eseguiti molti dashboard con timeout per le origini dati impostati su valori elevati.

Il server di database non si è rivelato un collo di bottiglia nei test e ha registrato un utilizzo massimo della CPU del 31% nel dashboard con autenticazione basata sull'account di servizio automatico in una topologia 7C. Le definizioni di contenuto di PerformancePoint Services, ad esempio report, scorecard e indicatori KPI, vengono archiviate in elenchi SharePoint e memorizzate nella cache da PerformancePoint Services, riducendo in questo modo il carico sul server di database.

Utilizzo della memoria

PerformancePoint Services può utilizzare quantità elevate di memoria in alcune configurazioni ed è importante monitorare l'utilizzo della memoria del pool di applicazioni PerformancePoint Services. PerformancePoint Services memorizza nella cache diversi elementi, tra cui i risultati delle query di Analysis Services e altre origini dati per la durata della cache delle origini dati (l'impostazione predefinita è 10 minuti). Se si utilizza un'origine dati configurata per l'autenticazione basata sull'account di servizio automatico, questi risultati delle query vengono archiviati solo una volta e condivisi tra più utenti. Se tuttavia si utilizza un'origine dati configurata per l'autenticazione basata sull'identità per utente e la sicurezza dei cubi dinamici Analysis Services, i risultati delle query vengono archiviati una volta per ogni utente per ogni visualizzazione (questa è una combinazione "per filtro").

L'interfaccia API della cache sottostante utilizzata da PerformancePoint Services è l'API della cache ASP.NET. L'utilizzo di questa API offre come vantaggio la gestione della cache da parte di ASP.NET, che rimuove gli oggetti (operazione nota anche come taglio) in base ai limiti di memoria per evitare che si verifichino errori di memoria esaurita. Il limite di memoria predefinito è impostato sul 60% della memoria fisica. Dopo aver raggiunto questi limiti, PerformancePoint Services ha continuato a eseguire il rendering delle visualizzazioni, ma i tempi di risposta sono aumentati in modo significativo sul breve periodo quando ASP.NET ha rimosso le voci memorizzate nella cache.

Il contatore delle prestazioni "Applicazioni ASP.NET \ Tagli API nella cache" del pool di applicazioni che ospita PerformancePoint Services può essere utilizzato per monitorare le rimozioni delle voci dalla cache da parte di ASP.NET a causa dell'utilizzo della memoria. Se il valore di questo contatore è maggiore di zero, esaminare la tabella riportata di seguito per individuare possibili soluzioni.

Un'origine dati configurata per utilizzare l'autenticazione basata sull'identità per utente può condividere i risultati delle query e le voci della cache se gli insiemi di utenti di appartenenza al ruolo di Analysis Services sono identici e se non è configurata la sicurezza dei cubi dinamici. Questa è una nuova caratteristica di PerformancePoint Services in Microsoft SharePoint Server 2010. Se ad esempio l'utente A è incluso nel ruolo 1 e 2, l'utente B è incluso nel ruolo 1 e 2 e l'utente C è incluso nel ruolo 1, 2 e 3, solo l'utente A e l'utente B potranno condividere le voci della cache. Se è configurata la sicurezza dei cubi dinamici, non potranno condividere le voci della cache né gli utenti A e B né l'utente C.

Analysis Services

Quando PerformancePoint Services è stato testato con l'autenticazione basata sull'identità per utente, sono state modificate due proprietà di Analysis Services per migliorare le prestazioni della velocità effettiva multiutente. Nella tabella riportata di seguito sono elencate le proprietà che sono state modificate con il nuovo valore assegnato.

Queste due impostazioni di memoria configurano Analysis Services per l'utilizzo dell'heap di Windows anziché dell'heap di Analysis Services. Prima di modificare queste proprietà e durante l'aggiunta del carico utente, i tempi di risposta sono aumentati in modo significativo passando da 0,2 secondi a oltre 30 secondi, mentre l'utilizzo della CPU nei server Web, applicazioni e di Analysis Services sono rimasti bassi. Per la risoluzione dei problemi, i tempi di esecuzione delle query sono stati raccolti utilizzando le viste a gestione dinamica (DMV) di Analysis Services, che hanno mostrato un aumento dei tempi di esecuzione delle singole query da 10 millisecondi a 5000 millisecondi. Questi risultati hanno indotto a modificare le impostazioni di memoria sopra riportate.

È importante notare che nonostante il miglioramento significativo della velocità effettiva, secondo il team Analysis Services la modifica di queste impostazioni ha un costo piccolo ma percepibile sulle query utente singolo.

Prima di modificare qualsiasi proprietà di Analysis Services, vedere il White paper di SQL Server 2008: Guida alle prestazioni di Analysis Services (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x410) (le informazioni potrebbero essere in lingua inglese) per informazioni sulle procedure consigliate per migliorare le prestazioni della velocità effettiva in modalità utente singolo.

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. Nei casi in cui è stato riscontrato un collo di bottiglia dovuto a un elevato utilizzo del processore, sono stati aggiunti altri server per risolvere il problema. Nella tabella riportata di seguito vengono elencati alcuni comuni colli di bottiglia e le possibili soluzioni presupponendo che l'utilizzo del processore sia basso e non rappresenti il collo di bottiglia.

Monitoraggio delle prestazioni

Per determinare quando implementare la scalabilità verticale oppure orizzontale del sistema, utilizzare i contatori delle prestazioni per monitorare lo stato del sistema. PerformancePoint Services è un servizio WCF di ASP.NET e può essere monitorato utilizzando gli stessi contatori delle prestazioni utilizzati per monitorare qualsiasi altro servizio WCF di ASP.NET. Utilizzare inoltre le informazioni contenute nella tabella seguente per individuare ulteriori contatori delle prestazioni da monitorare e determinare il processo a cui deve essere applicato ogni contatore delle prestazioni.

See Also

Concepts

Pianificare PerformancePoint Services (SharePoint Server 2010)