Guida alla pianificazione della capacità per la memorizzazione nella cache di Windows Server AppFabric

Jason Roth, Rama Ramani, Jaime Alva Bravo

Marzo 2011

In questo documento vengono fornite indicazioni relative alla pianificazione della capacità per la memorizzazione nella cache di Windows Server AppFabric.

1. Introduzione

2. Valutazione delle prestazioni della memorizzazione nella cache di AppFabric

3. Metodologia di pianificazione della capacità

   1. Fase 1: Analisi dei colli di bottiglia e identificazione dei candidati per la memorizzazione nella cache

   2. Fase 2: Valutazione dei modelli di carico di lavoro correnti

   3. Fase 3: Analisi dell'infrastruttura fisica e delle risorse hardware

   4. Fase 4: Finalizzazione del contratto di servizio relativo alle prestazioni richiesto per tutte le applicazioni

   5. Fase 5: Identificazione delle funzionalità e delle impostazioni di configurazione appropriate di AppFabric

4. Strumento per la pianificazione della capacità

5. Fasi successive della pianificazione della capacità

6. Monitoraggio costante dei requisiti di capacità di memorizzazione nella cache

Introduzione

L'architettura della memorizzazione nella cache di Windows Server AppFabric consiste in un cluster di cache in memoria distribuito. In questo documento vengono fornite indicazioni sulla pianificazione della capacità per una distribuzione locale della memorizzazione nella cache di Windows Server AppFabric.

L'architettura è illustrata in modo dettagliato nella documentazione. Per ulteriori informazioni, vedere Funzionalità di memorizzazione nella cache di Windows Server AppFabric. In sintesi, un cluster di cache di AppFabric è costituito da uno o più server di cache, denominati anche host della cache. Le cache vengono distribuite tra gli host e archiviate in memoria.

Nota

È disponibile anche una versione di Windows Azure AppFabric per l'utilizzo della memorizzazione nella cache all'interno del cloud. Alcune delle fasi descritte in questo documento, relative alla valutazione dei requisiti di memoria, sono applicabili anche a una soluzione basata sul cloud, ma il documento si riferisce specificamente allo scenario di un cluster di cache locale. Per ulteriori informazioni sull'utilizzo della funzionalità di memorizzazione della cache di Azure AppFabric, vedere Servizio di memorizzazione nella cache di Windows Azure AppFabric.

Le informazioni riportate in questo documento sono basate sul lavoro di pianificazione svolto da Microsoft in collaborazione con i propri clienti. Tutti i clienti della memorizzazione nella cache di AppFabric chiedono informazioni riguardo al numero di server necessari per il proprio scenario di implementazione. A questa domanda viene in genere risposto che il numero di server dipende da diversi fattori. Durante la conversazione con il cliente vengono rapidamente esaminati i vari aspetti dello scenario fino a identificare il punto di partenza appropriato per la pianificazione. Nel corso del processo emergono altri interrogativi più specifici, in particolare:

• La quantità di memoria cache richiesta dalle applicazioni del cliente

• Il numero di computer da utilizzare in un cluster di cache

• La quantità di memoria da configurare in ogni computer e la relativa modalità di configurazione

• L'effetto prodotto dalla larghezza di banda di rete sulle prestazioni del cluster di cache

L'obiettivo di questo documento è di prendere spunto dalle lezioni apprese in questo tipo di conversazioni con i clienti in modo da definire una metodologia per la pianificazione della capacità.

È molto probabile che il lettore di questo documento si trovi in una delle seguenti fasi del processo di sviluppo:

1. Ha appena iniziato a valutare l'opportunità di utilizzare un servizio di memorizzazione nella cache distribuito e non dispone di dati dettagliati sulla combinazione dei carichi di lavoro, sui requisiti delle prestazioni o sulla topologia di distribuzione dei server. A questo punto, può essere opportuno iniziare esaminando alcuni dati relativi alle prestazioni della memorizzazione nella cache di AppFabric.

2. Ha già esaminato le funzionalità e le prestazioni della memorizzazione nella cache di AppFabric e ora ha bisogno di supporto per analizzare in dettaglio il proprio scenario e i requisiti principali. È a questo punto che è necessario entrare nel dettaglio della pianificazione della capacità.

3. È già in fase di produzione e desidera apprendere i criteri per l'analisi dei dati relativi alle prestazioni per verificare di disporre di capacità sufficiente. Desidera inoltre eseguire la pianificazione per futuri incrementi del carico di lavoro, essendo a conoscenza degli indicatori chiave e delle procedure consigliate in base al comportamento in fase di runtime della cache di AppFabric.

Il presente documento è stato strutturato in modo da presentare queste fasi in ordine sequenziale. Se si desidera semplicemente valutare le prestazioni di AppFabric, si consiglia di consultare un esauriente white paper redatto dal partner di Microsoft Grid Dynamics. In questo documento i dati del white paper sono presentati in maniera semplificata per facilitare l'utente nell'attività di valutazione e fornire informazioni su cui basare il processo di pianificazione della capacità.

Se il lettore è pronto ad affrontare il processo di pianificazione della capacità, in questo documento è illustrata una serie di fasi per formalizzare una metodologia applicabile a uno scenario specifico.

Se il lettore utilizza o esegue il test di un cluster di cache, può convalidare il processo di pianificazione della capacità esaminando un insieme di indicatori di prestazioni chiave per verificare di disporre della capacità adeguata. Nel documento verranno inoltre illustrate alcune procedure consigliate.

Valutazione delle prestazioni della memorizzazione nella cache di AppFabric

Il partner di Microsoft Grid Dynamics ha recentemente eseguito una serie di test sulle prestazioni della memorizzazione nella cache di AppFabric e ha pubblicato i risultati nel seguente white paper: Windows Server AppFabric Cache: A detailed performance & scalability datasheet.

Ogni test è finalizzato all'analisi di una variabile specifica, ad esempio la dimensione della cache o il numero di server nel cluster di cache. Lo studio di Grid Dynamics può essere utilizzato per valutare le prestazioni e la scalabilità della memorizzazione nella cache di AppFabric. È possibile confrontare i valori di velocità effettiva e latenza di un'ampia varietà di scenari e topologie di test con i requisiti delle proprie applicazioni. In ogni test è stata in genere prevista la variazione di solo uno o due parametri per un'analisi mirata dell'impatto prodotto sulle prestazioni. Di seguito sono elencati i parametri presi in esame.

Modello di carico	Modello di utilizzo della cache, ad esempio la percentuale di operazioni 'Get', 'Put', 'BulkGet', 'GetAndLock', 'PutAndUnlock'
Dimensione dei dati memorizzati nella cache	Quantità di dati memorizzati nella cache durante il test
Dimensione del cluster	Numero di server nel cluster di cache
Dimensione degli oggetti	Dimensione degli oggetti memorizzati nella cache, dopo la serializzazione
Complessità dei tipi	Varietà dei tipi di oggetti .NET, quali byte, string[] e così via, memorizzati nella cache
Sicurezza	Impostazioni relative alla sicurezza del cluster di cache

Oltre a verificare le prestazioni e la scalabilità della memorizzazione nella cache di AppFabric, Grid Dynamics ha reso disponibile il test harness per consentire agli utenti di ripetere i test con i propri dati e carichi di lavoro. Questa è un'altra opzione offerta per valutare le prestazioni della memorizzazione nella cache per uno scenario specifico.

Anche se è altamente consigliabile esaminare l'intero studio e le relative conclusioni, di seguito è riportata una sintesi dei risultati, sui quali saranno basate le procedure consigliate illustrate nelle sezioni successive di questo documento.

• La memorizzazione nella cache di AppFabric viene scalata in maniera lineare con la progressiva introduzione di computer in un cluster di cache.

• La dimensione della cache ha un impatto limitato, tranne nel caso di cache di grandi dimensioni con un'elevata percentuale di operazioni di scrittura. Tra gli altri fattori, i carichi di lavoro elevati delle operazioni di scrittura producono una pressione maggiore sulla Garbage Collection di .NET, quando l'heap gestito è di grandi dimensioni.

• L'elevata complessità dei tipi influisce solo sulle prestazioni sul lato client a causa della serializzazione.

• Le chiamate Bulk Get hanno come risultato un migliore utilizzo della rete. L'accesso diretto alla cache risulta molto più veloce rispetto ai proxy (ASP.NET, WCF), ma questo vantaggio è dovuto più alle prestazioni del livello intermedio che non a quelle della memorizzazione nella cache.

• Il blocco pessimistico e quello ottimistico hanno un effetto analogo sulle prestazioni. È quindi opportuno utilizzare la tecnica più adatta alle proprie applicazioni. Sia la latenza sia la velocità effettiva migliorano in caso di riduzione della percentuale dei conflitti.

• La sicurezza del cluster di cache ha effetti negativi sulle prestazioni ed è abilitata per impostazione predefinita. I valori massimi di velocità effettiva e quelli minimi di latenza vengono raggiunti quando la sicurezza è disabilitata, ma questa condizione può essere inaccettabile in considerazione della riservatezza dei dati e dei requisiti aziendali.

• È possibile ridurre i colli di bottiglia della rete utilizzando una rete dedicata tra i server applicazioni e i server di cache.

Il white paper di Grid Dynamics rappresenta un ottimo punto di partenza per effettuare una valutazione della memorizzazione nella cache di AppFabric e inoltre contiene dati non elaborati e modelli osservati sui quali è possibile basare il processo di pianificazione della capacità.

Metodologia di pianificazione della capacità

Dopo aver stabilito che la propria applicazione può trarre vantaggio dall'utilizzo di una cache in memoria distribuita, come quella di AppFabric, è possibile passare alla pianificazione della capacità. Anche se alcune fasi della pianificazione della capacità possono essere completate mediante l'esecuzione di test diretti su un cluster di cache di AppFabric, può essere necessario creare una stima senza eseguire questo tipo di test. Questo è l'argomento centrale trattato in questa sezione. Le fasi elencate di seguito forniscono un metodo sistematico per la valutazione dei requisiti per la memorizzazione nella cache di AppFabric:

1. Analisi dei colli di bottiglia e identificazione dei candidati per la memorizzazione nella cache

2. Valutazione dei modelli di carico di lavoro correnti

3. Analisi dell'infrastruttura fisica e delle risorse hardware

4. Finalizzazione del contratto di servizio relativo alle prestazioni richiesto per tutte le applicazioni

5. Identificazione delle funzionalità e delle impostazioni di configurazione appropriate di AppFabric

In questo documento sono riportati esempi relativi a queste fasi e vengono esaminati i requisiti di un'applicazione di negozio online di esempio. La memorizzazione nella cache può tuttavia essere utilizzata da qualsiasi tipo di applicazione .NET ed è possibile avere più applicazioni che accedono allo stesso cluster di cache. In uno scenario di questo tipo è opportuno eseguire le fasi descritte di seguito per ogni applicazione e quindi aggregare i risultati per ottenere una stima accurata della capacità.

Fase 1: Analisi dei colli di bottiglia e identificazione dei candidati per la memorizzazione nella cache

È innanzitutto necessario identificare i dati da memorizzare nella cache. Questa operazione viene effettuata mediante strumenti per l'analisi delle prestazioni quali SQL Server Profiler, Performance Monitor, strumenti di test di Visual Studio e molti altri. Questi strumenti sono in grado di identificare gli oggetti di database a cui si accede di frequente o le chiamate lente a servizi Web. I set di dati restituiti da questi archivi back-end rappresentano potenziali candidati per la memorizzazione nella cache. La memorizzazione temporanea di questi dati nella cache può migliorare le prestazioni e alleggerire la pressione sugli archivi back-end.

Una volta identificati i potenziali candidati per la memorizzazione nella cache, è un utile esercizio classificare tali oggetti in una delle seguenti tre categorie principali: Dati dell'attività, Dati di riferimento e Dati della risorsa. Di seguito sono riportati esempi illustrativi di queste categorie.

• Dati dell'attività: include i dati in lettura/scrittura correlati a un singolo utente. In un negozio online, ad esempio, il carrello di un utente fa parte di questa categoria di dati. Si applica alla sessione corrente dell'utente e può cambiare di frequente. Anche se è importante garantire un'elevata disponibilità del carrello, i dati da cui è costituito non richiedono necessariamente l'archiviazione permanente in un database back-end. In considerazione di queste caratteristiche di temporaneità, i dati dell'attività rientrano logicamente tra i candidati per la memorizzazione nella cache.

• Dati di riferimento: include i dati in sola lettura condivisi da più utenti o da più istanze di applicazione. L'accesso a tali dati è frequente, ma le modifiche vengono apportate con minore frequenza. Sempre in un negozio online, il catalogo prodotti costituisce un esempio di dati di riferimento. Il catalogo può rimanere invariato per uno o più giorni, ma è possibile che venga consultato migliaia di volte da utenti differenti. Anche i dati di questo tipo sono tra i candidati ideali per la memorizzazione nella cache. Senza una soluzione di memorizzazione nella cache, ogni utente che visualizza il catalogo prodotti richiede l'accesso ai dati dal database. Il ricorso a una soluzione di questo tipo può quindi limitare la pressione sul database back-end risultante da richieste ripetute su dati semi-statici. In considerazione di queste caratteristiche di permanenza, anche i dati di riferimento rientrano logicamente tra i candidati per la memorizzazione nella cache.

• Dati della risorsa: include i dati in lettura/scrittura condivisi tra utenti. I dati di questo tipo possono ad esempio essere presenti in un forum di supporto. Le risposte ai post dei forum possono essere lette da tutti gli utenti.

Poiché i diversi tipi di dati memorizzati nella cache presentano modelli di utilizzo differenti, può essere utile classificare i dati in queste categorie. Ad esempio, la classificazione di un oggetto come dati di riferimento suggerisce che non si tratta semplicemente di un carico di lavoro in sola lettura. La classificazione può inoltre essere utile per determinare i criteri di scadenza, che tendono ad essere più brevi per i dati che cambiano con maggiore frequenza. Dal punto di vista dello sviluppo, queste suddivisioni logiche possono offrire lo spunto per la definizione di aree da incapsulare nel codice.

Si consiglia di effettuare stime relative a singoli oggetti e quindi di aggregare tali dati. Nella tabella riportata di seguito è illustrato un esempio delle informazioni raccolte in questa fase.

Oggetto da memorizzare nella cache	Categoria di memorizzazione nella cache	Posizione di archiviazione permanente
Carrello	Dati dell'attività	Nessuna
Preferenze utente	Dati dell'attività	Database back-end
Catalogo prodotti	Dati di riferimento	Database back-end
Thread forum utenti	Dati della risorsa	Database back-end

Durante la fase di identificazione dei candidati per la memorizzazione nella cache, non è necessario trovare dati per ciascuna categoria. Le prestazioni e la scalabilità possono ad esempio essere migliorate semplicemente dalla memorizzazione nella cache dei dati del carrello dell'applicazione. Il punto essenziale in questa fase consiste nell'utilizzare le informazioni disponibili per identificare gli elementi ideali da memorizzare nella cache.

Fase 2: Valutazione dei modelli di carico di lavoro correnti

Una volta determinati i dati appropriati per la memorizzazione nella cache, è necessario comprendere il modo in cui l'applicazione esegue l'accesso ai dati e i modelli di carico di lavoro associati. Al termine di questa fase sarà possibile giungere a una stima approssimativa dei requisiti di memoria per la memorizzazione nella cache. Sarà inoltre possibile comprendere meglio la modalità di accesso e utilizzo dei dati, che sarà importante nelle fasi successive.

Se ad esempio si identifica il catalogo prodotti come candidato per la memorizzazione nella cache, sarà opportuno verificare quando l'applicazione recupera i dati del catalogo e con quale frequenza vengono effettuate queste richieste. In base all'analisi eseguita nella fase precedente, il catalogo risulta incluso nella categoria dei dati di riferimento e quindi il carico di lavoro è principalmente di sola lettura. Una comprensione approfondita dei modelli di carico di lavoro relativi ai diversi oggetti fornisce un'ottima guida per le decisioni future relative alla capacità. Di seguito verranno presentati in dettaglio i vari fattori coinvolti in questa fase.

Esistono più metodi per comprendere meglio i modelli di accesso ai dati correnti:

1. Esaminare con attenzione il codice per identificare il punto in viene effettuato l'accesso ai dati e la frequenza di tale accesso.

2. Utilizzare un Code Profiler in grado di fornire la frequenza delle chiamate ai metodi e i dati sulle prestazioni associati.

3. Instrumentare il codice in corrispondenza delle specifiche sezioni di accesso ai dati. Registrare il tentativo di accesso ai dati e le prestazioni associate dell'operazione sui dati.

4. Utilizzare un Database Profiler, ad esempio SQL Server Profiler, per osservare il numero e la durata delle operazioni sul database.

È opportuno notare che molte di queste tecniche avrebbero potuto essere utilizzate nella fase precedente per determinare i potenziali dati da memorizzare nella cache. Tuttavia, è in questa fase che si ha la necessità di ottenere numeri più precisi da utilizzare nei calcoli per la pianificazione della capacità futura.

Parte di questa valutazione riguarda anche la comprensione del rapporto tra operazioni di lettura e scrittura. La valutazione del carico di lavoro in base a questo rapporto può influire sulle future decisioni relative alla capacità. Ad esempio, un carico di lavoro con una percentuale elevata di operazioni di scrittura determina un incremento della Garbage Collection di .NET. Questo aspetto verrà approfondito in una fase successiva.

Un altro fattore consiste nella frequenza delle operazioni di lettura e scrittura in condizioni di massimo carico. Nella tabella riportata di seguito sono illustrati i dati di esempio raccolti in questa fase per l'oggetto carrello.

Oggetto da analizzare	Carrello
% operazioni di lettura	50%
% operazioni di scrittura	50%
Operazioni di lettura al secondo (max)	250
Operazioni di scrittura al secondo (max)	250

Anche in questo caso è opportuno eseguire la stessa analisi per ogni tipo di oggetto. Tipi di oggetti differenti presentano diversi modelli di accesso e diversi valori massimi per la frequenza delle operazioni di lettura e scrittura in condizioni di carico.

Per comprendere i requisiti per la memorizzazione nella cache, è necessario avere una stima del numero massimo di oggetti attivi per ogni tipo presente nella cache in qualsiasi momento, in cui sia previsto un bilanciamento tra la frequenza degli inserimenti di oggetti e la permanenza presunta di tali oggetti. È possibile comprendere più facilmente questo concetto facendo ricorso a un esempio.

Nell'esempio dell'applicazione Web ASP.NET, i dati operativi possono mostrare la presenza di momenti di picco con 25.000 accessi utente simultanei. Poiché ogni utente richiede informazioni sullo stato sessione, nella cache risultano memorizzati 25.000 oggetti. Per questi oggetti può tuttavia essere impostata una scadenza di trenta minuti. Durante i momenti di picco, i dati operativi possono mostrare l'inserimento di 5.000 nuovi utenti all'ora. Questo significa che durante il periodo di scadenza di 30 minuti è possibile che vengano inseriti 2.500 nuovi utenti. È inoltre possibile che alcuni utenti chiudano il browser e aprano una nuova sessione. In questo caso, l'utente sarà lo stesso, ma la sessione sarà differente. È necessario prendere in considerazione anche questo fattore nella valutazione dell'opportunità di aggiungere riempimento. Può infine essere opportuno pianificare una possibile crescita per i 6-12 mesi successivi. In conclusione, il calcolo del numero massimo di oggetti attivi nella cache può avere il seguente aspetto:

Oggetto da analizzare	Carrello
Utenti simultanei in fase di picco	25.000
Nuovi utenti durante il periodo di scadenza (30 minuti)	2.500
Utenti esistenti che avviano nuove sessioni del browser	250
Stima di crescita futura (25%)	6.940
Totale oggetti attivi (max)	~35.000 oggetti attivi (max)

In caso di variazione dei dati di input, ad esempio il periodo di scadenza, cambierà anche il numero di oggetti non scaduti residenti nella cache durante il periodo di picco del carico. Questo è un semplice esempio del ragionamento da seguire nel calcolo della capacità. È possibile che altri tipi di oggetti presentino modelli e variabili differenti da prendere in considerazione nel calcolo. Se ad esempio un catalogo prodotti condiviso rimane valido per un'intera giornata, il numero massimo di oggetti catalogo prodotti nella cache per un giorno deve essere uno solo.

Tuttavia, la conoscenza del numero massimo di oggetti nella cache è utile solo se si conosce anche la dimensione media degli oggetti. Questo è di per sé un problema complesso. Nell'esempio del carrello, è possibile che un utente inserisca nel carrello un solo prodotto e che invece un altro utente ne inserisca dieci o venti. L'obiettivo è di identificare la media. Come per la maggior parte dei valori individuati in questo processo, la media non sarà perfetta, ma sarà comunque un valore ben ponderato da utilizzare come punto di partenza per la pianificazione del cluster di cache in sostituzione di una semplice ipotesi.

Gli oggetti vengono memorizzati nella cache in formato serializzato. Di conseguenza, per comprendere la dimensione media degli oggetti, è necessario calcolare quella degli oggetti serializzati. Prima di memorizzare gli elementi nella cache, AppFabric ne esegue la serializzazione utilizzando la classe NetDataContractSerializer. Per determinare la dimensione media degli oggetti, è necessario aggiungere all'applicazione codice di strumentazione in grado di serializzare gli oggetti e registrare la relativa dimensione serializzata.

Nell'esempio di codice riportato di seguito viene effettuato un tentativo di stima della dimensione media di un singolo oggetto. L'oggetto sottoposto a serializzazione è denominato obj. Per la registrazione della lunghezza viene utilizzata la variabile length. In caso di problemi durante il tentativo di ottenere la dimensione con NetDataContractSerializer, viene utilizzato in alternativa BinaryFormatter. Per facilitare l'utilizzo di questo codice è possibile eseguirne il wrapping in un metodo. In tal caso, obj verrebbe passato come parametro e length verrebbe restituito dal metodo.

// requires following assembly references:
//
//using System.Xml;
//using System.IO;
//using System.Runtime.Serialization;
//using System.Runtime.Serialization.Formatters.Binary;
//
// Target object “obj”
//
long length = 0;

MemoryStream stream1 = new MemoryStream();
using (XmlDictionaryWriter writer = 
    XmlDictionaryWriter.CreateBinaryWriter(stream1))
{
    NetDataContractSerializer serializer = new NetDataContractSerializer();
    serializer.WriteObject(writer, obj);
    length = stream1.Length; 
}

if (length == 0)
{
    MemoryStream stream2 = new MemoryStream();
    BinaryFormatter bf = new BinaryFormatter();
    bf.Serialize(stream2, obj);
    length = stream2.Length;
}

Nota

Se si dispone di un programma di test per la configurazione di cluster di cache, è possibile aggiungere elementi alla cache e utilizzare il comando di Windows PowerShell Get-CacheStatistics per individuare la dimensione di uno o più oggetti aggiunti alla cache. In alternativa, è possibile ripartire la dimensione degli oggetti nella cache in base al numero di oggetti. La raccolta dei valori stimati può essere effettuata tramite codice o mediante test.

Se si prevede di utilizzare la memorizzazione nella cache di AppFabric per lo stato sessione, è importante comprendere che lo stato sessione del provider di SQL Server per ASP.NET utilizza sempre BinaryFormatter anziché NetDataContractSerializer. Talvolta, gli oggetti serializzati dalla classe NetDataContractSerializer possono essere di dimensioni molto maggiori rispetto agli oggetti per i quali viene utilizzato BinaryFormatter. Questa informazione è importante se si è interessati alla dimensione degli oggetti stato sessione in SQL Server poiché non è possibile utilizzare tale dimensione e presupporre che sarà la stessa all'interno della cache. È possibile moltiplicare per sei tale valore per ottenere una stima approssimativa oppure utilizzare il codice sopra riportato sugli oggetti memorizzati in stato sessione per ottenere una stima più attendibile. Con i dati raccolti fino a questo punto, sarà possibile iniziare a formulare una stima dei requisiti di memoria totale. In questa fase sono coinvolte le seguenti sottoattività:

1. Identificare un tipo di oggetto, ad esempio il carrello.

2. Per tale oggetto, calcolare innanzitutto la dimensione media degli oggetti serializzati.

3. Aggiungere quindi 500 byte alla dimensione media per tenere conto del sovraccarico della cache.

4. Moltiplicare tale dimensione per il numero massimo di oggetti attivi. Il risultato di questa operazione consente di individuare i requisiti di memoria totale per la memorizzazione nella cache del tipo di oggetto.

5. Aggiungere un valore stimato di sovraccarico per le strutture interne di memorizzazione nella cache (5%).

6. Ripetere queste attività per ogni tipo di oggetto identificato.

7. Aggregare i risultati per i requisiti di memoria totale per la memorizzazione nella cache.

In questo processo è possibile notare che è previsto un sovraccarico di circa 0,5 KB per oggetto da sommare ai valori stimati delle dimensioni. Esistono anche altre strutture dei dati interne per le quali è richiesta memoria nella cache. Per la gestione di aree, tag e notifiche è necessaria una quantità maggiore di memoria. Nei calcoli di esempio, per tenere conto di queste strutture interne è stata aggiunta una percentuale pari al 5% del totale, ma questo valore può variare a seconda dell'extent a cui vengono applicate le funzionalità di memorizzazione nella cache.

A questo punto è opportuno valutare l'impatto di una funzionalità specifica della memorizzazione nella cache di AppFabric, ovvero la disponibilità elevata, che determina la creazione di copie degli elementi memorizzati nella cache su server secondari. In questo modo, se un singolo server di cache si arresta, il controllo viene assunto da un server di cache secondario e i dati non vengono persi. Se si sceglie di utilizzare la disponibilità elevata, è necessario raddoppiare le stime relative alla memoria. È inoltre necessario utilizzare Windows Server 2008 Enterprise Edition o superiore. È opportuno notare che la funzionalità di disponibilità elevata viene definita al livello di cache denominata. Di conseguenza, se si creano due cache denominate nello stesso cluster, non è necessario utilizzare la disponibilità elevata per ciascuna cache. L'applicazione può inserire alcuni elementi nella cache denominata con disponibilità elevata e altri nella cache senza disponibilità elevata. Questa soluzione può essere utile per sfruttare al meglio le risorse di memoria. In conclusione, è importante conoscere la decisione riguardo alla disponibilità elevata perché questa funzionalità ha l'effetto di raddoppiare i requisiti di memoria delle cache da cui viene utilizzata.

Di seguito è riportata, a titolo esemplificativo, una tabella di valutazione dei requisiti per le categorie Dati dell'attività e Dati di riferimento nella stessa applicazione. A seconda dello scenario, è possibile scegliere di effettuare una stima al livello di oggetto o al livello di applicazione. In tal caso è sufficiente aggiungere a questo esempio altre colonne con un'etichetta appropriata.

Oggetto da analizzare	Dati dell'attività	Dati di riferimento
Dimensione media degli oggetti serializzati	250 KB	60 KB
Sovraccarico del cluster di cache per oggetto	0,5 KB	0,5 KB
Dimensione media rettificata degli oggetti serializzati	250,5 KB	60,5 KB
Numero massimo di oggetti attivi	~35.000	~68.000
Requisiti di memoria per la memorizzazione nella cache	8,4 GB	3,9 GB
Abilitazione della disponibilità elevata	16,8 GB	No
Sovraccarico delle strutture dei dati interne (5%)	0,8 GB	0,2 GB
Requisiti di memoria totale	17,6 GB	4,1 GB

L'aggregazione di questi valori stimati rappresenta i requisiti iniziali di memoria per il cluster di cache. In questo esempio il totale è pari a 21,7 GB. Una volta completata questa stima, è possibile iniziare a esaminare altri fattori, quali l'infrastruttura fisica, i requisiti del contratto di servizio e le impostazioni di configurazione della cache di AppFabric.

Fase 3: Analisi dell'infrastruttura fisica e delle risorse hardware

È importante essere a conoscenza dell'infrastruttura fisica e della disponibilità delle risorse. Di seguito sono elencati gli aspetti principali da prendere in considerazione:

1. Disponibilità di computer fisici o macchine virtuali

2. Configurazione di eventuale hardware già esistente, ad esempio 8 GB di RAM, processore Quad-Core

3. Eventuale posizionamento del cluster di cache nello stesso centro dati dei server applicativi

4. Capacità della rete

Se si sta valutando l'opportunità di utilizzare macchine virtuali per i server di cache, è necessario prendere in considerazione alcuni fattori, ad esempio l'impatto che possono avere più macchine virtuali sullo stesso computer fisico. Se più macchine virtuali condividono la scheda di rete, aumenta la possibilità che si verifichino colli di bottiglia sulla rete. È anche possibile che la disponibilità elevata sia configurata tra un host della cache principale e uno secondario, che sono macchine virtuali sullo stesso computer fisico. In caso di arresto del computer, non rimarrà alcuna copia dei dati. Per ulteriori informazioni, vedere le istruzioni relative all'esecuzione del servizio di memorizzazione nella cache di AppFabric su una macchina virtuale.

Per i computer già esistenti non sono definite specifiche consigliate, ma per i cluster di cache di grandi dimensioni sono state riscontrate prestazioni ottimali sui computer con 16 GB di RAM e processore Quad-Core. In linea generale, i fattori più importanti da prendere in considerazione nella pianificazione sono la quantità corretta di memoria fisica e il carico di rete.

Sia per i computer fisici sia per le macchine virtuali, è opportuno prestare attenzione alla posizione del cluster di cache rispetto ai server applicativi o ai server Web che fanno uso della cache. Se si trovano in centri dati separati, accertarsi che la latenza fra tali centri dati non influisca negativamente sulle prestazioni. In questa fase è possibile essere tentati a utilizzare i server applicativi o i server Web per i server di cache, ma questa configurazione, sebbene possibile, non è supportata. In primo luogo, eventuali picchi nell'utilizzo delle risorse da parte di servizi quali IIS su tali computer possono avere un impatto negativo sul cluster di cache. In secondo luogo, il servizio di memorizzazione nella cache presuppone di essere configurato su un server dedicato e di poter eventualmente utilizzare molta più memoria di quella specificata.

Per quanto riguarda le capacità di rete, è opportuno valutare il carico di rete previsto e confrontarlo con l'infrastruttura disponibile. È innanzitutto necessario conoscere la quantità di dati che presumibilmente verranno gestiti da ogni server di cache e verificare se le capacità della scheda di rete sono sufficienti. In caso contrario possono essere necessari altri server di cache. Si consideri ad esempio uno scenario in cui la dimensione media degli oggetti memorizzati nella cache è di 500,5 KB e sul cluster di cache vengono eseguite 240 operazioni al secondo. Utilizzando un unico host della cache si otterrebbero i seguenti risultati:

Numero di operazioni di lettura/scrittura sugli oggetti al secondo	240
Numero di computer nel cluster di cache	1
Numero di operazioni nella cache per computer al secondo	240
Dimensione media degli oggetti	500,5 KB
Dimensione dei dati trasmessi al secondo	240 * 500,5 = 117,3 MBps

Se ciascun computer è dotato di una scheda di rete da 1 Gbps, la velocità effettiva massima sarà di circa 119 MBps. È molto probabile che il valore calcolato di 117,3 MBps determini un sovraccarico eccessivo del singolo server e che quindi la rete si trasformi in un collo di bottiglia. Se tuttavia vengono utilizzati tre computer nel cluster di cache, una distribuzione uniforme delle richieste di cache avrà come risultato l'assegnazione di 1/3 del carico a ogni server.

È inoltre opportuno considerare l'utilizzo della rete da parte dei server applicativi che accedono al cluster di cache. Se questi scambiano una notevole quantità di dati con altri sistemi, sarà necessario valutare l'opportunità di creare una rete dedicata tra i server applicativi e il cluster di cache. A tale scopo sarà necessario montare una scheda di rete aggiuntiva su ogni server applicativo.

In ultima analisi è opportuno valutare se la rete è in grado di gestire il carico richiesto lungo l'intero percorso. Una scheda di rete da 1 Gbps su ogni server di cache non è sufficiente. Anche il commutatore e altri punti lungo la rete devono essere in grado di gestire il carico. Collaborare con il personale operativo per accertarsi che questo requisito sia soddisfatto.

Fase 4: Finalizzazione del contratto di servizio relativo alle prestazioni richiesto per tutte le applicazioni

Prima di prendere una decisione riguardo alla configurazione finale è necessario essere a conoscenza anche di eventuali requisiti aziendali, inclusi i contratti di servizio relativi all'affidabilità e alle prestazioni. Da un punto di vista pratico, questa fase influisce sulla decisione relativa al numero di cluster di cache e al numero di host della cache in ogni cluster.

Se ad esempio un cluster di cache viene utilizzato da un'applicazione di importanza strategica, può essere opportuno isolare tale cluster da altre applicazioni con priorità inferiore. Queste ultime potrebbero utilizzare una maggiore quantità di risorse di memoria, rete o CPU con conseguenti effetti negativi sull'applicazione più importante.

Di seguito vengono descritti i fattori che influiscono su questa decisione.

• La sicurezza viene mantenuta al livello di cluster di cache. Se un utente accede al cluster di cache, può accedere a qualsiasi dato presente su tale cluster, purché conosca il nome e la chiave della cache da richiedere. Se sono necessarie impostazioni di sicurezza differenti a seconda del tipo di dati, può essere opportuno configurare cluster di cache separati. Per ulteriori informazioni, vedere Gestione della protezione.

• Quando la memoria raggiunge il livello del limite massimo, vengono rimossi gli oggetti non scaduti. Se si sottovaluta la quantità di memoria necessaria per una singola cache, questo può influire su tutte le cache nel cluster. Quando la rimozione avviene a causa di una pressione eccessiva sulla memoria, gli oggetti vengono rimossi in tutte le cache, anche se una sola cache è responsabile di tale pressione. È possibile limitare gli effetti di questo problema mediante la creazione di cache non rimovibili, ma questa operazione deve essere eseguita con cautela. Per ulteriori informazioni, vedere Scadenza e rimozione.

• L'utilizzo di cluster di cache separati può facilitare la gestione, ma entro certi limiti. Può non essere opportuno gestire cluster separati per 100 cache differenti, ma può essere utile avere cluster separati per due cache differenti di grandi dimensioni, poiché in questo modo sarà possibile gestire, scalare e monitorare le cache separatamente.

Alcune considerazioni relative ai requisiti possono infine riguardare la latenza e la velocità effettiva. Per prendere questa decisione in modo consapevole, vedere il white paper di Grid Dynamics in cui sono riportati risultati di test e indicazioni utili. È ad esempio possibile confrontare i propri requisiti di velocità effettiva per il cluster di cache con i risultati dei test pubblicati sul white paper di Grid Dynamics. Dall'esame di questo studio può risultare che il numero di server disponibili è inferiore ai propri obiettivi di velocità effettiva. È importante tenere presente che questo studio può non corrispondere esattamente ai tipi e alle dimensioni dei propri oggetti né all'infrastruttura fisica e logica in uso, ma fornisce comunque risultati di test collaudati che possono essere utili per giungere a una decisione consapevole.

Fase 5: Identificazione delle funzionalità e delle impostazioni di configurazione appropriate di AppFabric

In questa fase del processo vengono prese in considerazione specifiche impostazioni di configurazione della memorizzazione nella cache di AppFabric e l'architettura di un cluster di cache di AppFabric. Anche se si sono raccolti tutti i dati empirici e aziendali corretti, ignorando le impostazioni relative alla memorizzazione nella cache di AppFabric si corre il rischio di commettere qualche errore di pianificazione.

Nella seguente tabella è riportata una serie di funzionalità di memorizzazione nella cache di AppFabric con le considerazioni correlate per la pianificazione della capacità.

Aree	È possibile creare più aree, ma ogni area è presente su un singolo host della cache. Per trarre vantaggio dalla cache distribuita, le applicazioni devono utilizzare più aree. È opportuno notare che tutte le chiamate in cui non è presente un riferimento automatico ad aree specifiche utilizzano aree predefinite internamente. Ogni host nel cluster di cache deve essere in grado di ospitare la dimensione massima dell'area più grande.
Notifiche	È possibile abilitare le notifiche al livello di cache in modo che possano essere ricevute dai client della cache. Questo determina un aumento del traffico di rete e dell'utilizzo del processore sul lato server. L'effetto varia a seconda dell'intervallo di notifica e del numero di notifiche inviate. L'invio di numerose notifiche a intervalli molto brevi può avere un impatto negativo sulle prestazioni e sulla scalabilità. Poiché non esistono linee guida precise per la valutazione di questo impatto, sarà necessario osservarlo durante la fase di test.
Cache locale	L'utilizzo della cache locale consente di ottenere migliori prestazioni poiché gli oggetti vengono memorizzati nella cache sui client e sul server. Quando si utilizza la cache locale è opportuno considerare l'impatto della memoria sui computer client. Questa funzionalità non interessa la pianificazione della capacità per la memoria sul lato server poiché tutti gli elementi memorizzati nella cache locale sono presenti anche sul server. Se tuttavia vengono utilizzate le notifiche per invalidare la cache locale, l'elaborazione delle notifiche può avere effetto anche sul lato server.
Progettazione e configurazione delle applicazioni sul lato client	La progettazione delle applicazioni sul lato client può influire sulle prestazioni generali. È ad esempio necessario memorizzare gli oggetti DataCacheFactory creati in modo da poterli riutilizzare anziché crearli nuovamente per ogni chiamata. Può anche essere utile creare un singolo oggetto DataCacheFactory per thread oppure, se si condivide un solo oggetto DataCacheFactory per più thread, valutare l'opportunità di aumentare il valore dell'impostazione MaxConnectionsToServer. In questo modo si aumenta il numero di connessioni ai server di cache per DataCacheFactory.
Disponibilità elevata	Come già indicato in precedenza, le cache che utilizzano la disponibilità elevata richiedono il doppio del requisito di memoria calcolato. Per questa funzionalità sono inoltre necessari almeno tre server. In caso di arresto di un server, ne devono rimanere due per supportare la copia principale e quella secondaria di ogni elemento dopo un errore. È infine necessario che in tutti i server sia installato Windows Server 2008 Enterprise Edition o superiore.
Cache denominate	Attualmente è definito un limite di 128 cache denominate. Questo influisce sulla decisione di pianificazione della capacità nel caso di applicazioni che richiedono un numero superiore di cache denominate. In casi di questo tipo è necessario configurare più cluster di cache o progettare le applicazioni in modo da utilizzare un numero inferiore di cache. Un'altra strategia consiste nel creare, a livello di programmazione, più aree all'interno delle cache denominate.
Archivio di configurazione XML	Quando si utilizza un'area di rete condivisa per l'archivio di configurazione del cluster di cache, è necessario avere almeno tre server nel cluster, tutti designati come host principali. Per informazioni sui motivi, vedere Aggiornamento dei server di cache.

È evidente che le impostazioni più importanti da comprendere sono quelle relative alla memoria su ogni host della cache. È possibile visualizzare le impostazioni predefinite della memoria su ogni host della cache utilizzando il comando Get-CacheHostConfig di Windows PowerShell.

Nota

Per informazioni sull'utilizzo dei comandi di Windows PowerShell relativi alla memorizzazione nella cache, vedere Attività comuni di gestione del cluster di cache.

Nella schermata riportata di seguito è illustrato l'output del comando Get-CacheHostConfig su un computer con 4 GB di RAM.

Per impostazione predefinita, la quantità di memoria riservata per la cache su un determinato server corrisponde al 50% della memoria RAM totale. In questo esempio la metà della RAM è pari a 2 GB. La memoria rimanente è quindi disponibile per il sistema operativo e per i servizi. Si consiglia di mantenere questa impostazione predefinita anche sui computer dotati di una quantità di memoria molto più elevata. Come indicato in precedenza, il servizio di memorizzazione nella cache presuppone di essere eseguito su un computer dedicato e può quindi utilizzare molta più memoria di quella allocata per la cache. Sebbene una parte di questo utilizzo della memoria sia dovuta alla progettazione interna del servizio di memorizzazione nella cache, un'altra parte è correlata alla gestione della memoria .NET e alla Garbage Collection. Anche dopo il rilascio della memoria in un'applicazione .NET, è necessario attendere che la Garbage Collection venga liberata dalla memoria del processo. Il processo richiede un buffer di memoria fisica per tenere conto della natura non deterministica della Garbage Collection.

Una volta compreso l'impatto della Garbage Collection, è possibile notare che i carichi di lavoro con una percentuale elevata e una notevole frequenza di operazioni di scrittura richiedono un buffer di memoria più grande per tenere conto dei cicli di Garbage Collection. Questa considerazione non è necessaria per i carichi di lavoro che sono principalmente di sola lettura. In tal caso, è talvolta possibile valutare l'opportunità di aumentare la quantità di memoria riservata per la memorizzazione nella cache. Su un computer con 16 GB di memoria, ad esempio, è possibile decidere di riservare 12 GB per l'impostazione relativa alla dimensione della cache, in sostituzione del valore predefinito di 8 GB, in modo da rendere disponibili 4 GB aggiuntivi per il sistema operativo e i servizi. Questa impostazione presuppone che il computer sia dedicato al servizio di memorizzazione nella cache, che è attualmente l'unica configurazione supportata. In questo esempio è necessario eseguire il test della configurazione di memoria con il carico previsto. Se l'allocazione della memoria è troppo aggressiva, il test rivelerà questo errore segnalando problemi correlati alla memoria, quali la rimozione o la limitazione. Per ulteriori informazioni, vedere Risoluzione dei problemi del server (Memorizzazione nella cache di Windows Server AppFabric). Nell'esempio riportato di seguito viene utilizzato il comando Set-CacheHostConfig per impostare 12 GB come dimensione della cache su un server denominato Server1:

Set-CacheHostConfig -HostName Server1 -CachePort 22233 -CacheSize 12288

L'altro aspetto da osservare nell'output di Get-CacheHostConfig riguarda i valori dei limiti. Il valore predefinito di LowWatermark corrisponde al 70% della dimensione della cache impostata. Quando la memoria cache raggiunge il valore di LowWatermark, il servizio di memorizzazione nella cache inizia a rimuovere gli oggetti già scaduti. Questa operazione ha un effetto positivo poiché tali oggetti sono comunque inaccessibili.

Il valore predefinito di HighWatermark corrisponde al 90% della dimensione della cache impostata. Quando viene raggiunto il livello di HighWatermark, gli oggetti vengono rimossi indipendentemente dalla relativa scadenza finché la memoria non torna al livello di LowWatermark. Questo può determinare un peggioramento delle prestazioni e può avere risultati negativi sull'esperienza utente.

Si consiglia di pianificare un utilizzo della cache fino al livello di LowWatermark per evitare il rischio di raggiungere il livello di HighWatermark. Per una descrizione più dettagliata, vedere Scadenza e rimozione.

Suggerimento

I cicli completi di Garbage Collection possono causare un lieve ritardo, che è spesso rivelato da errori di ripetizione di tentativo. Per evitare questo inconveniente, è opportuno che ogni host della cache non abbia più di 16 GB di memoria. Sui computer con oltre 16 GB di RAM possono verificarsi pause più lunghe per i cicli completi di Garbage Collection. A parte questo inconveniente, non esistono limitazioni all'utilizzo di maggiore memoria per ogni host della cache. È possibile che un carico di lavoro prevalentemente di sola lettura non determini l'esecuzione frequente di cicli completi di Garbage Collection. Il modo migliore per determinare la quantità di memoria ottimale consiste nell'esecuzione di test di carico.

In un esempio precedente è stata calcolata una stima di 21,7 GB come requisito di memoria totale per la memorizzazione nella cache. Poiché si desidera abilitare la disponibilità elevata, sono necessari almeno tre server. Si supponga che ogni server sia dotato di 16 GB di RAM. In questo esempio verrà mantenuta l'impostazione predefinita di 8 GB per la dimensione della cache su ogni server. Come indicato in precedenza, è opportuno che su ogni server sia disponibile una quantità di memoria pari al livello di LowWatermark (70%). In altri termini, la quantità di memoria stimata per ogni server di è pari a 5,6 GB. In base a questi fattori, nella tabella riportata di seguito viene mostrato che i quattro server sono in grado di fornire 22,4 GB di memoria per la memorizzazione nella cache e quindi di soddisfare il requisito di 21,7 GB.

Requisito di memoria totale	21,7 GB
Memoria iniziale (host della cache)	16 GB
Impostazione della dimensione della cache (host della cache)	8 GB
Limite minimo (host della cache)	70%
Memoria target rettificata per host della cache	5,6 GB
Memoria totale sul cluster di cache (3 computer)	5,6 GB * 4 server = 22,4

È ancora una volta importante ricordare che è possibile utilizzare anche i risultati pubblicati nel white paper di Grid Dynamics per verificare questa stima rispetto agli obiettivi di velocità effettiva e latenza. I risultati dei test possono portare a correggere leggermente questa stima iniziale, ad esempio con l'aggiunta di un altro server di cache. Il punto importante è quello di utilizzare le risorse disponibili, come questo documento, per prendere una decisione consapevole.

Strumento per la pianificazione della capacità

Un foglio di calcolo è uno strumento logico che può essere utile per eseguire le operazioni di pianificazione della capacità descritte nelle sezioni precedenti. È stato predisposto un foglio di calcolo di esempio che è possibile scaricare qui. Le voci contrassegnate con un asterisco devono essere modificate in base alla pianificazione e alle risorse disponibili, mentre gli altri calcoli vengono eseguiti automaticamente.

Nella prima parte del foglio di calcolo è specificata la configurazione server di ciascun host della cache. Tale configurazione potrà essere modificata durante il processo di pianificazione e le differenze potranno essere osservate nei calcoli finali. Di seguito è riportata la schermata relativa a questa prima sezione.

Importante

A meno che non vengano utilizzati i valori di installazione predefiniti, spetta allo sviluppatore eseguire il comando Set-CacheHostConfig su ciascun host della cache per applicare le impostazioni CacheSize e LowWatermark.

Nella seconda sezione è possibile inserire stime per diversi tipi di oggetti. Nel foglio di calcolo di esempio vengono utilizzate due sole sezioni per i dati dell'attività e i dati di riferimento. Sono quindi disponibili alcune colonne vuote che è possibile rinominare in base al livello di granularità adottato per la pianificazione (oggetto, categoria, applicazione e così via). Di seguito è riportata la schermata relativa a questa seconda sezione.

Nella terza sezione viene effettuata la stima dei requisiti di rete. È necessario specificare le dimensioni medie degli oggetti in lettura/scrittura e il numero massimo di operazioni di lettura/scrittura al secondo e automaticamente viene calcolata la larghezza di banda di rete massima per il tipo di oggetto specificato. Questa procedura consente di verificare se il raggruppamento di computer e schede di rete utilizzato è in grado di gestire il carico. Come illustrato nelle sezioni precedenti, sarà possibile anche analizzare la larghezza di banda nell'intero percorso di rete. Di seguito è riportata la schermata relativa a questa terza sezione.

Nell'ultima sezione del foglio di calcolo vengono aggregati i requisiti specificati nelle sezioni relative alla memoria e alla rete, quindi viene utilizzata la configurazione di computer specificata nella prima sezione per calcolare il numero di server. Il campo relativo ai server aggiuntivi consente, se necessario, di aumentare il totale calcolato. Se ad esempio dai calcoli risulta che sono necessari due soli server, è possibile aggiungere un altro server al totale finale per garantire il supporto di una disponibilità elevata. Di seguito è riportata la schermata relativa a questa sezione finale.

Nota

Nelle schermate riportate in precedenza vengono utilizzati valori simili a quelli dell'esempio illustrato in questo documento. I server stimati sono tuttavia tre anziché quattro. Nel foglio di calcolo il valore Cache Size Setting(Set-CacheHostConfig) è infatti impostato su 12 GB per mostrare il comportamento dell'impostazione personalizzata. Se tale valore viene impostato su 8 GB, i risultati ottenuti saranno analoghi a quelli riportati nelle sezioni precedenti di questo documento.

Fasi successive della pianificazione della capacità

Nella sezione precedente è stata illustrata una metodologia per effettuare una stima iniziale del numero di cluster di cache, del numero di host della cache da utilizzare in ciascun cluster e della configurazione di tali host. È tuttavia necessario tenere presente che si tratta di una stima, che può variare in base alle operazioni di test e monitoraggio costante.

Se si decide di procedere all'introduzione del servizio di memorizzazione nella cache di AppFabric, è possibile creare un modello di prova per verificare il funzionamento di tale servizio all'interno della soluzione utilizzata. Successivamente sarà possibile configurare un cluster di cache per eseguire test nell'ambiente in uso. In base ai risultati dei test, può essere utile apportare ulteriori modifiche alla configurazione per soddisfare i requisiti di capacità, prestazioni e scalabilità. Nella sezione successiva vengono descritte metriche specifiche che è possibile monitorare costantemente durante le fasi di test e produzione.

Monitoraggio costante dei requisiti di capacità di memorizzazione nella cache

La pianificazione della capacità per la memorizzazione nella cache non fornisce mai risultati definitivi. Molti dei valori conclusivi sono di per sé valori stimati. Inoltre, i modelli e l'utilizzo delle applicazioni possono variare con il tempo. Per questi motivi, è necessario monitorare gli indicatori di prestazioni per verificare che il cluster di cache sia in grado di soddisfare i requisiti di capacità. La corretta pianificazione della capacità è il risultato di un processo eseguito costantemente in ambienti sia di test che di produzione.

Performance Monitor è lo strumento ideale per monitorare la capacità in modo costante. Per ciascun host della cache è consigliabile monitorare i seguenti contatori:

Categoria di monitoraggio	Contatori di Performance Monitor
Memoria	Memorizzazione nella cache di AppFabric:Host\Byte totali dimensione dati Memorizzazione nella cache di AppFabric:Host\Totale oggetti rimossi Memorizzazione nella cache di AppFabric:Host\Totale esecuzioni di rimozione Memorizzazione nella cache di AppFabric:Host\Memoria totale rimossa Memorizzazione nella cache di AppFabric:Host\Conteggio oggetti totale Memoria CLR .NET(DistributedCacheService)\Raccolte di generazione 0 Memoria CLR .NET(DistributedCacheService)\Raccolte di generazione 1 Memoria CLR .NET(DistributedCacheService)\Raccolte di generazione 2 Memoria CLR .NET(DistributedCacheService)\Oggetti bloccati Memoria CLR .NET(DistributedCacheService)\% tempo in GC Memoria CLR .NET(DistributedCacheService)\Dimensione heap oggetti grandi Memoria CLR .NET(DistributedCacheService)\Dimensione heap di generazione 0 Memoria CLR .NET(DistributedCacheService)\Dimensione heap di generazione 1 Memoria CLR .NET(DistributedCacheService)\Dimensione heap di generazione 2 Memoria\MB disponibili
Rete	Interfaccia di rete(*)\Byte ricevuti al secondo Interfaccia di rete(*)\Byte inviati al secondo Interfaccia di rete(*)\Larghezza di banda corrente
CPU	Processo(DistributedCacheService)\% tempo processore Processo(DistributedCacheService)\Conteggio dei thread Processo(DistributedCacheService)\Working set Processore(_Total)\% tempo processore
Velocità effettiva	Memorizzazione nella cache di AppFabric:Host\Totale richieste client Memorizzazione nella cache di AppFabric:Host\Totale richieste client /sec Memorizzazione nella cache di AppFabric:Host\Totale richieste Get Memorizzazione nella cache di AppFabric:Host\Totale richieste Get /sec Memorizzazione nella cache di AppFabric:Host\Totale richieste Get Memorizzazione nella cache di AppFabric:Host\Totale richieste Get /sec Memorizzazione nella cache di AppFabric:Host\Totale richieste GetAndLock Memorizzazione nella cache di AppFabric:Host\Totale richieste GetAndLock /sec Memorizzazione nella cache di AppFabric:Host\Totale richieste di lettura Memorizzazione nella cache di AppFabric:Host\Totale richieste di lettura /sec Memorizzazione nella cache di AppFabric:Host\Totale operazioni di scrittura Memorizzazione nella cache di AppFabric:Host\Totale operazioni di scrittura /sec
Varie	Memorizzazione nella cache di AppFabric:Host\Percentuale di mancato riscontro nella cache Memorizzazione nella cache di AppFabric:Host\Totale oggetti scaduti Memorizzazione nella cache di AppFabric:Host\Totale notifiche recapitate

Molti dei contatori inclusi in questo elenco sono direttamente collegati al processo di pianificazione della capacità, ad esempio alcuni contatori di memoria. "Memoria\MB disponibili" indica, in megabyte, la quantità di memoria fisica ancora disponibile nel computer. Se questo contatore scende sotto il 10% della memoria fisica totale, è molto probabile che si verifichi una situazione di limitazione. Per ulteriori informazioni, vedere Risoluzione dei problemi relativi alla limitazione. Altri contatori sono specifici delle funzionalità di memorizzazione nella cache. "Memorizzazione nella cache di AppFabric:Host\Totale esecuzioni di rimozione" indica la frequenza con cui vengono rimossi gli oggetti dalla memoria. Quando i livelli di memoria superano il limite massimo, questo contatore punterà alle esecuzioni di rimozione mentre la memoria viene riportata al limite minimo. In modo analogo, gli altri contatori sono associati alla pianificazione della capacità attraverso il processo descritto nelle precedenti sezioni di questo documento.

Vengono rilevati anche i valori dei contatori di processo del servizio (DistributedCacheService) e quelli del contatore del processore del computer Un elevato utilizzo del processore può avere effetti negativi sulle prestazioni del cluster di cache. Se vengono rilevati periodi di elevato utilizzo del processore, è importante verificare se si tratta di un fenomeno correlato al servizio di memorizzazione nella cache (DistributedCacheService.exe) o a un altro processo eseguito sul computer.

Oltre allo strumento Performance Monitor, è possibile utilizzare i comandi di Windows PowerShell installati con AppFabric. Molti di questi comandi consentono di monitorare lo stato del cluster di cache. Per ulteriori informazioni, vedere Strumenti di monitoraggio dello stato e il post relativo a registrazione e contatori nella cache di AppFabric.

Vedere anche

Altre risorse

Installazione di Windows Server AppFabric
Funzionalità di memorizzazione nella cache di Windows Server AppFabric
Sviluppo di un client cache
Configurazione di un provider di stato sessione di ASP.NET
Opzioni di archiviazione della configurazione del cluster
Guida alla distribuzione e alla gestione delle funzionalità di memorizzazione nella cache di Windows Server AppFabric
Collegamenti e risorse di Windows Server AppFabric e Windows Azure AppFabric

  2011-12-05