Valutare i requisiti di prestazioni e capacità per PerformancePoint Services

SharePoint 2010
 

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.

NotaNote
È 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:

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.

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.

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.

  1. Eseguire il rendering del dashboard.

  2. Selezionare uno dei due filtri, selezionare in modo casuale un valore di filtro e attendere che venga rieseguito il rendering del dashboard.

  3. Ripetere altre quattro volte, selezionando in modo casuale uno dei due filtri e un valore di filtro casuale.

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.

  1. Eseguire il rendering del dashboard.

  2. Selezionare un membro casuale in un grafico ed espanderlo.

  3. Selezionare un altro membro casuale nel grafico e comprimerlo.

  4. Selezionare un altro membro casuale nel grafico ed espanderlo.

  5. Selezionare un altro membro casuale nel grafico e comprimerlo.

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.

  1. Eseguire il rendering del dashboard. Selezionare un membro casuale in un griglia ed espanderlo.

  2. Selezionare un altro membro casuale nella griglia ed espanderlo.

  3. Selezionare un altro membro casuale nella griglia e comprimerlo.

  4. Selezionare un altro membro casuale nella griglia ed espanderlo.

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

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.

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) (http://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.

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

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

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

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

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

PPS_CapicityChart4

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

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%

PPS_CapicityChart5

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.

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) (http://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.

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) (http://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) (http://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) (http://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) (http://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 (http://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) (http://go.microsoft.com/fwlink/?linkid=200613&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

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) (http://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) (http://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) (http://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) (http://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) (http://go.microsoft.com/fwlink/?linkid=200613&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

Mostra: