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.
Nota
È importante tenere presente che i valori specifici della capacità e delle prestazioni presentati in questo articolo sono diversi da quelli degli ambienti reali. I valori presentati hanno lo scopo di fornire un punto di partenza per la progettazione di un ambiente con scalabilità appropriata. Dopo aver completato la progettazione iniziale del sistema, testare la configurazione per determinare se il sistema supporterà i fattori specifici del proprio ambiente.
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.
| Nome | Descrizione | Dimensioni |
|---|---|---|
Filtro uno |
Filtro di selezione dei membri |
7 membri di dimensione |
Filtro due |
Filtro di selezione dei membri |
20 membri di dimensione |
Scorecard |
Scorecard |
15 righe di membri di dimensione per 4 colonne (2 indicatori KPI) |
Grafico uno |
Grafico a linee |
3 serie per 12 colonne |
Grafico due |
Grafico a barre in pila |
37 serie per 3 colonne |
Griglia |
Griglia analitica |
5 righe per 3 colonne |
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.
| Nome test | Descrizione test |
|---|---|
Rendering di un dashboard e modifica casuale di uno dei due filtri cinque volte con una pausa di 15 secondi tra le interazioni. |
|
Rendering di un dashboard, selezione di un grafico ed espansione e compressione del grafico per cinque volte con una pausa di 15 secondi tra le interazioni. |
|
Rendering di un dashboard, selezione di una griglia ed espansione e compressione della griglia per cinque volte con una pausa di 15 secondi tra le interazioni. |
|
È stata utilizzata una singola combinazione di test costituita dalle percentuali seguenti di test avviati.
| Nome test | Combinazione di test |
|---|---|
Rendering di un dashboard e modifica casuale di uno dei due filtri per cinque volte. |
80% |
Rendering di un dashboard, selezione di un grafico ed espansione e compressione del grafico per cinque volte. |
10% |
Rendering di un dashboard, selezione di una griglia ed espansione e compressione della griglia per cinque volte. |
10% |
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.
| Server Web | Server applicazioni | Computer con SQL Server | Computer con Analysis Services | |
|---|---|---|---|---|
Processori |
2px4c @ 2.66 GHz |
2px4c @ 2.66 GHz |
2px4c @ 2.66 GHz |
4px6c @ 2.4 GHz |
RAM |
16 GB |
32 GB |
16 GB |
64 GB |
Sistema operativo |
Windows Server 2008 R2 Enterprise |
Windows Server 2008 R2 Enterprise |
Windows Server 2008 R2 Enterprise |
Windows Server 2008 R2 Enterprise |
Scheda di interfaccia di rete |
1x1 gigabit |
1x1 gigabit |
1x1 gigabit |
1x1 gigabit |
Autenticazione |
NTLM e Kerberos |
NTLM e Kerberos |
NTLM e Kerberos |
NTLM e Kerberos |
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.
| Misura | Descrizione |
|---|---|
Numero di utenti |
Numero totali di utenti riportato da Visual Studio. |
Richieste al secondo (RPS) |
Numero totale di richieste al secondo riportato da Visual Studio, in cui sono incluse tutte le richieste e le richieste di un file statico, ad esempio immagini e fogli di stile. |
Visualizzazioni al secondo |
Visualizzazioni totali di cui è possibile eseguire il rendering in PerformancePoint Services. Una visualizzazione è un filtro, una scorecard, una griglia o un grafico di cui viene eseguito il rendering in PerformancePoint Services oppure una richiesta Web per l'URL del servizio di rendering contenente RenderWebPartContent o CreateReportHtml. Per ulteriori informazioni su CreateReportHtml e RenderWebPartContent, vedere Specifica del protocollo del servizio di rendering di PerformancePoint Services (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=200609&clcid=0x410) (le informazioni potrebbero essere in lingua inglese). È possibile ricercare queste richieste ne registri IIS in modo da ottenere indicazioni per la pianificazione della capacità di PerformancePoint Services. Questa misura inoltre restituisce un numero che non dipende in modo significativo dalla composizione del dashboard. Un dashboard con due visualizzazioni può essere paragonato a un dashboard con 10 visualizzazioni. |
Suggerimento
Se si utilizza un'origine dati configurata per l'utilizzo dell'autenticazione basata sull'account di servizio automatico, la regola per il rapporto di server dedicati è di un server Web ogni due server applicazioni in cui viene eseguito PerformancePoint Services.
Suggerimento
Se si utilizza un'origine dati configurata per l'utilizzo dell'autenticazione basata sull'identità per utente, la regola per il rapporto di server dedicati è di un server Web ogni quattro o più server applicazioni in cui viene eseguito 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
| Topologia (WFE x APP x SQL) | Utenti | Richieste al secondo (RPS) | Visualizzazioni al secondo |
|---|---|---|---|
2C (1x0x1) |
360 |
83 |
50 |
3C (1x1x1) |
540 |
127 |
75 |
4C (1x2x1) |
840 |
196 |
117 |
5C (1x3x1) |
950 |
215 |
129 |
6C (2x3x1) |
1.250 |
292 |
175 |
7C (2x4x1) |
1.500 |
346 |
205 |
Riepilogo per l'autenticazione basata sull'identità per utente
| Topologia (WFE x APP x SQL) | Utenti | Richieste al secondo (RPS) | Visualizzazioni al secondo |
|---|---|---|---|
2C (1x0x1) |
200 |
47 |
27 |
3C (1x1x1) |
240 |
56 |
33 |
4C (1x2x1) |
300 |
67 |
40 |
5C (1x3x1) |
325 |
74 |
44 |
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
| Numero di utenti | 50 | 150 | 250 | 360 |
|---|---|---|---|---|
Media WFE/APP CPU |
19,20% |
57,70% |
94,00% |
96,70% |
RPS |
18 |
53 |
83 |
83 |
Visualizzazioni al secondo |
10,73 |
31,72 |
49,27 |
49,67 |
Tempo di risposta medio (sec) |
0,12 |
0,15 |
0,38 |
2 |
.png "PPS_CapicityChart1")
Autenticazione basata sull'identità per utente
| Numero di utenti | 50 | 100 | 150 | 200 |
|---|---|---|---|---|
Media WFE/APP CPU |
30,80% |
61,30% |
86,50% |
93,30% |
RPS |
17 |
32 |
43 |
47 |
Visualizzazioni al secondo |
10,3 |
19,32 |
26,04 |
27,75 |
Tempo di risposta medio (sec) |
0,28 |
0,45 |
0,81 |
2 |
.png "PPS_CapicityChart2")
Risultati farm 3C (1x1x1)
Autenticazione basata sull'account di servizio automatico
| Numero di utenti | 100 | 250 | 400 | 540 |
|---|---|---|---|---|
RPS |
36 |
87 |
124 |
127 |
Visualizzazioni al secondo |
21 |
52 |
74 |
75 |
Tempo di risposta medio (sec) |
0,12 |
0,18 |
0,65 |
2 |
Utilizzo medio CPU WFE |
11% |
28% |
43% |
46% |
Numero massimo byte privati WFE del processo di lavoro W3WP di Internet Information Services (IIS) di SharePoint Server. |
0,7 GB |
1,4 GB |
2,0 GB |
2,4 GB |
Utilizzo medio CPU APP |
25% |
62% |
94% |
95% |
Numero massimo byte privati APP di W3WP di PerformancePoint Services |
5,9 GB |
10,8 GB |
14,1 GB |
14,6 GB |
.png "PPS_CapicityChart3")
Autenticazione basata sull'identità per utente
| Numero di utenti | 50 | 120 | 180 | 240 |
|---|---|---|---|---|
RPS |
17 |
39 |
52 |
56 |
Visualizzazioni al secondo |
10 |
23 |
31 |
33 |
Tempo di risposta medio (sec) |
0,28 |
0,48 |
0,91 |
2 |
Utilizzo medio CPU WFE |
5% |
12% |
17% |
19% |
Numero massimo byte privati WFE di W3WP di SharePoint Server |
0,78 GB |
1,3 GB |
1,6 GB |
1,9 GB |
Utilizzo medio CPU APP |
25% |
57% |
81% |
81% |
Numero massimo byte privati APP di W3WP di PerformancePoint Services |
19 GB |
20,1 GB |
20,5 GB |
20,9 GB |
.png "PPS_CapicityChart4")
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.
| 4C (1x2x1) | 5C (1x3x1) | 6C (2x3x1) | 7C (2x4x1) | |
|---|---|---|---|---|
Numero di utenti |
840 |
950 |
1.250 |
1.500 |
RPS |
196 |
216 |
292 |
346 |
Visualizzazioni al secondo |
117 |
131 |
175 |
206 |
Utilizzo medio CPU WFE |
77% |
63% |
54% |
73% |
Numero massimo byte privati WFE di W3WP di SharePoint Server |
2,1 GB |
1,7 GB |
2,1 GB |
2,0 GB |
Utilizzo medio CPU APP |
83% |
94% |
88% |
80% |
Numero massimo byte privati APP di W3WP di PerformancePoint Services |
16 GB |
12 GB |
15 GB |
15 GB |
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.
| 3C (1x1x1) | 4C (1x2x1) | 5C (1x3x1) | 6C (1x4x1) | |
|---|---|---|---|---|
Numero di utenti |
240 |
300 |
325 |
325 |
RPS |
56 |
67 |
74 |
74 |
Visualizzazioni al secondo |
33 |
40 |
44 |
45 |
Utilizzo medio CPU WFE |
19% |
24% |
26% |
12% |
Numero massimo byte privati WFE di W3WP di SharePoint Server |
2,1 GB |
1,9 GB |
1,9 GB |
1,5 GB |
Utilizzo medio CPU APP |
89% |
68% |
53% |
53% |
Numero massimo byte privati APP di W3WP di PerformancePoint Services |
20 GB |
20 GB |
20 GB |
20 GB |
CPU Analysis Services |
17% |
44% |
57% |
68% |
.png "PPS_CapicityChart5")
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.
| Problema | Soluzione |
|---|---|
L'utilizzo del processore del server applicazioni è ridotto e nel server applicazioni vengono eseguiti altri servizi. |
Aggiungere ulteriore memoria fisica o limitare la memoria della cache di ASP.NET. |
L'utilizzo del processore del server applicazioni è ridotto e nel server applicazioni viene eseguito solo PerformancePoint Services. |
Se accettabile, configurare le impostazioni della cache di ASP.NET in modo da utilizzare più memoria nella cache oppure aggiungere altra memoria. |
L'utilizzo del processore del server applicazioni è elevato. |
Aggiungere un altro server applicazioni. |
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.
| Proprietà Analysis Services | Valore |
|---|---|
Memoria \ HeapTypeForObjects |
0 |
Memoria \ MemoryHeapType |
2 |
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.
| Possibile collo di bottiglia | Causa ed elementi da monitorare | Soluzione |
|---|---|---|
Prestazioni heap di memoria di Analysis Services |
Per impostazione predefinita, Analysis Services utilizza il proprio heap di memoria anziché l'heap di Windows, con conseguenti prestazioni ridotte della velocità effettiva multiutente. Esaminare i tempi di elaborazione delle query di Analysis Services utilizzando viste a gestione dinamica (DMV) per controllare se i tempi di esecuzione delle query aumentano con il carico utente e l'utilizzo del processore di Analysis Services è basso. |
Modificare Analysis Services in modo da utilizzare l'heap di Windows. Per istruzioni, vedere la sezione "Analysis Services" più indietro in questo articolo e 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). |
Thread di query e di elaborazione di Analysis Services |
Per impostazione predefinita, Analysis Services limita il numero di thread di query e di elaborazione per le query. È possibile che le query di lunga durata e con carichi utente elevati utilizzino tutti i thread disponibili. Monitorare i thread inattivi e i contatori delle prestazioni delle code dei processi nella categoria MSAS 2008: Thread. |
Aumentare il numero di thread disponibili per le query e i processi. Per istruzioni, vedere la sezione relativa ad Analysis Services del 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). |
Memoria dei server applicazioni |
PerformancePoint Services memorizza nella cache i risultati delle query di Analysis Services e di altre origini dati per la durata della cache delle origini dati. Questi elementi possono utilizzare un'elevata quantità di memoria. Monitorare il contatore Applicazioni ASP.NET \ Tagli API nella cache del pool di applicazioni PerformancePoint Services per determinare se le rimozioni o i tagli dalla cache sono forzati da ASP.NET a causa di una situazione di memoria insufficiente. |
Aggiungere memoria o aumentare i limiti di memoria cache di ASP.NET predefiniti. Per ulteriori dettagli, vedere la sezione Utilizzo della memoria più indietro in questo documento. Vedere inoltre Elemento cache per caching (schema delle impostazioni ASP.NET) (https://go.microsoft.com/fwlink/?linkid=200610&clcid=0x410) e il post di blog di Thomas Marquardt in Alcuni dati sui limiti di memoria cache di ASP.NET (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=200611&clcid=0x410) (le informazioni potrebbero essere in lingua inglese). |
Impostazioni di limitazione di WCF |
PerformancePoint Services viene implementato come servizio WCF. WCF limita il numero di chiamate simultanee nell'ambito di un comportamento di limitazione del servizio. Sebbene per le query di lunga durata possa verificarsi questo collo di bottiglia, si tratta di una situazione non comune. Monitorare le chiamate in attesa nel contatore delle prestazioni WCF / Modello ServiceModel per PerformancePoint Services e confrontarle con il numero massimo di chiamate simultanee. |
Se necessario, modificare il comportamento di limitazione di Windows Communication Foundation (WCF). Vedere Comportamenti di limitazione del servizio WCF (https://go.microsoft.com/fwlink/?linkid=200612&clcid=0x410) e il post di blog di Wenlong Dong su Limitazione delle richieste e scalabilità dei server di WCF (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=200613&clcid=0x410) (le informazioni potrebbero essere in lingua inglese). |
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.
| Contatore delle prestazioni | Istanza contatore | Note |
|---|---|---|
Applicazioni ASP.NET / Tagli API nella cache |
Pool di applicazioni PerformancePoint Services |
Se il valore è maggiore di zero, vedere la sezione "Utilizzo della memoria". |
MSAS 2008: Thread / Thread inattivi pool di query |
N/D |
Se il valore è uguale a zero, vedere la sezione relativa ad Analysis Services nel 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). |
MSAS 2008: Thread / Lunghezza coda processi nel pool di query |
N/D |
Se il valore è maggiore di zero, vedere la sezione relativa ad Analysis Services nel 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). |
MSAS 2008: Thread / Thread inattivi pool di elaborazione |
N/D |
Se il valore è maggiore di zero, vedere la sezione relativa ad Analysis Services nel 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). |
MSAS 2008: Thread / Lunghezza coda processi nel pool di elaborazione |
N/D |
Se il valore è maggiore di zero, vedere la sezione relativa ad Analysis Services nella 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). |
WCF CountersServiceModelService 3.0.0.0(*)\Chiamate in sospeso |
Istanza di PerformancePoint Services |
Se il valore è maggiore di zero, vedere Limitazione delle richieste e scalabilità dei server di WCF (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=200613&clcid=0x410) (le informazioni potrebbero essere in lingua inglese). |
See Also
Concepts
Pianificare PerformancePoint Services (SharePoint Server 2010)