Domande frequenti sulla gestione redis gestita di Azure

Questo articolo offre risposte alle domande comuni su come gestire Redis gestito di Azure.

Quando è consigliabile abilitare la porta non TLS/SSL per la connessione a Redis?

L'uso di TLS è consigliato come procedura consigliata in tutti i casi d'uso di Redis. L'opzione per connettersi senza TLS è inclusa per motivi di compatibilità con le versioni precedenti.

Quali sono alcune procedure consigliate per la produzione?

• Procedure consigliate di StackExchange.Redis
• Configurazione e concetti
• Test delle prestazioni

Procedure consigliate di StackExchange.Redis

• Impostare AbortConnect su false, quindi consentire a ConnectionMultiplexer di eseguire la riconnessione automatica.
• Usare una sola istanza ConnectionMultiplexer di lunga durata anziché creare una nuova connessione per ogni richiesta.
• Redis funziona meglio con valori inferiori, quindi considerare di suddividere i dati più grandi in più chiavi. Nella discussione di Redis, 100 kb è considerato di grandi dimensioni. Per altre informazioni, vedere Procedure consigliate per lo sviluppo.
• Configurare le impostazioni di ThreadPool per evitare timeout.
• Usare almeno il connectTimeout predefinito di 5 secondi. Questo intervallo fornisce a StackExchange.Redis tempo sufficiente per ristabilire la connessione in caso di un problema di rete.
• Tenere presente i costi delle prestazioni associati a diverse operazioni in esecuzione. Ad esempio, il comando KEYS è un'operazione O(n) e deve essere evitato. Il sito redis.io fornisce i dettagli sulla complessità del tempo per ogni operazione supportata. Selezionare i singoli comandi per informazioni sulla complessità di ogni operazione.

Configurazione e concetti

• Tenere presente che Redis è un archivio dati in memoria . Per altre informazioni, vedere Risolvere la perdita di dati in Azure Managed Redis in modo da conoscere gli scenari in cui può verificarsi la perdita di dati.
• Sviluppare il sistema in modo che possa gestire i problemi di connessione causati da failover e applicazione di patch.

Test delle prestazioni

• Vedere Test delle prestazioni con Azure Managed Redis per esempi di benchmark e istruzioni per l'esecuzione di test delle prestazioni personalizzati in Azure Managed Redis.

Che cosa occorre prendere in considerazione quando si usano i comandi Redis comuni?

• Evitare di usare determinati comandi Redis che impiegano molto tempo per il completamento se non se ne comprende appieno il risultato. Ad esempio, non eseguire il comando KEYS nell'ambiente di produzione. In base al numero delle chiavi, la restituzione di un valore potrebbe infatti richiedere molto tempo. Ogni partizione Redis è a thread singolo e elabora i comandi uno alla volta. Eventuali comandi inviati dopo KEYS verranno elaborati solo dopo l'elaborazione del comando KEYS. Il sito redis.io fornisce i dettagli sulla complessità del tempo per ogni operazione supportata. Selezionare i singoli comandi per informazioni sulla complessità di ogni operazione.
• È consigliabile usare coppie chiave-valore di piccole o di grandi dimensioni? Dipende dallo scenario. Se lo scenario richiede chiavi di dimensioni maggiori, si può modificare il valore di ConnectionTimeout e dei nuovi tentativi e regolare la logica di ripetizione dei tentativi. Dal punto di vista del server Redis, valori più piccoli offrono prestazioni migliori.
• Ciò non significa che non sia possibile archiviare valori di dimensioni maggiori in Redis. Occorre tenere presenti le considerazioni seguenti. Le latenze sono superiori. Se sono presenti due set di dati, uno di dimensioni maggiori e l'altro di dimensioni minori, è possibile usare più istanze di ConnectionMultiplexer. Configurare ognuno con un set diverso di valori di timeout e ripetizione dei tentativi, come descritto nella sezione precedente What do the StackExchange.Redis configuration options do .

In che modo è possibile valutare e testare le prestazioni della cache?

• Abilitare la diagnostica della cache in modo da poter monitorare l'integrità della cache. È possibile visualizzare le metriche nel portale di Azure, nonché scaricarle e analizzarle usando gli strumenti preferiti.
• Vedere Test delle prestazioni con Azure Managed Redis per esempi di benchmark e istruzioni per l'esecuzione di test delle prestazioni personalizzati in Azure Managed Redis.

Informazioni importanti sulla crescita del pool di thread

Il pool di thread CLR include due tipi di thread: thread di lavoro e porta di completamento I/O (IOCP).

• I thread di lavoro vengono usati per operazioni come l'elaborazione dei metodi Task.Run(…) o ThreadPool.QueueUserWorkItem(…). Questi thread vengono usati anche da vari componenti CLR quando il lavoro deve essere eseguito in un thread in background.
• I thread IOCP vengono usati quando si verificano I/O asincroni, ad esempio, durante la lettura dalla rete.

Il pool di thread fornisce nuovi thread di lavoro o thread di completamento I/O su richiesta, senza alcuna limitazione, fino a quando non viene raggiunta l'impostazione minima per ogni tipo di thread. Per impostazione predefinita, il numero minimo di thread corrisponde al numero di processori in un sistema.

Quando il numero di thread esistenti (occupati) raggiunge il numero minimo di thread, ThreadPool limita la velocità con cui inserisce nuovi thread in un thread per 500 millisecondi. In genere, se il sistema ottiene un picco di lavoro che richiede un thread IOCP, elabora rapidamente il funzionamento. Tuttavia, se il picco è superiore all'impostazione minima configurata, si nota un ritardo nell'elaborazione di una parte del lavoro mentre l'oggetto ThreadPool attende che si verifichi una delle situazioni seguenti:

• Un thread esistente diventa disponibile per elaborare il lavoro.
• Nessun thread esistente diventa disponibile per 500 ms e viene creato un nuovo thread.

In pratica, quando il numero di thread occupato è maggiore di Min thread, è probabile che si stia pagando un ritardo di 500 ms prima che l'applicazione elabori il traffico di rete. Inoltre, quando un thread esistente rimane inattiva per più di 15 secondi, viene pulito e questo ciclo di crescita e compattazione può ripetersi.

Se si osserva un messaggio di errore di esempio restituito da StackExchange.Redis, build 1.0.450 o versione successiva, è possibile notare che ora le statistiche dell'oggetto ThreadPool vengono stampate. Vedere i dettagli di IOCP e WORKER più avanti nell'articolo.

System.TimeoutException: Timeout performing GET MyKey, inst: 2, mgr: Inactive,
queue: 6, qu: 0, qs: 6, qc: 0, wr: 0, wq: 0, in: 0, ar: 0,
IOCP: (Busy=6,Free=994,Min=4,Max=1000),
WORKER: (Busy=3,Free=997,Min=4,Max=1000)

Come illustrato nell'esempio, si noterà che per il thread IOCP sono presenti sei thread occupati e il sistema è configurato per consentire quattro thread minimi. In questo caso, il client visualizzerà due ritardi di 500 ms, perché 6 > 4.

Annotazioni

StackExchange.Redis può raggiungere il timeout se la crescita dei thread IOCP o WORKER viene limitata.

Raccomandazione

È consigliabile che i clienti impostino il valore di configurazione minimo per i thread IOCP e WORKER su un valore maggiore del valore predefinito. Non è possibile fornire indicazioni specifiche su questo valore perché il valore corretto per un'applicazione può essere troppo alto o basso per un'altra applicazione. Questa impostazione può anche influire sulle prestazioni di altre parti di applicazioni complesse. Ogni cliente deve ottimizzare questa impostazione in modo da soddisfare le esigenze specifiche. Un buon punto di partenza è 200 o 300, da verificare e modificare a seconda delle necessità.

Come configurare questa impostazione:

È consigliabile modificare questa impostazione a livello di codice usando il metodo ThreadPool.SetMinThreads (...) nelle applicazioni .NET Framework e .NET Core.

Ad esempio, in NET Framework, è necessario impostarlo nel Global.asax.csApplication_Start metodo :

```csharp
private readonly int minThreads = 200;
void Application_Start(object sender, EventArgs e)
{
    // Code that runs on application startup
    AreaRegistration.RegisterAllAreas();
    RouteConfig.RegisterRoutes(RouteTable.Routes);
    BundleConfig.RegisterBundles(BundleTable.Bundles);
    ThreadPool.SetMinThreads(minThreads, minThreads);
}
```

Se si usa .NET Core, è necessario impostarlo in Program.cs, subito prima della chiamata a WebApplication.CreateBuilder():

```csharp
const int minThreads = 200
              
ThreadPool.SetMinThreads(minThreads, minThreads);

var builder = WebApplication.CreateBuilder(args);
// rest of application setup
```

Annotazioni

Il valore specificato da questo metodo è un'impostazione globale, che interessa l'intero dominio dell'applicazione. Ad esempio, se si dispone di un computer con quattro core e si vuole impostare minWorkerThreads e minIoThreads su 50 per CPU durante l'esecuzione, usare ThreadPool.SetMinThreads(200, 200).

È anche possibile specificare l'impostazione minima dei thread usando l'impostazione minIoThreads di minWorkerThreads o nell'elemento <processModel> di configurazione in Machine.config. Machine.config si trova in genere in %SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\.

L'impostazione del numero minimo di thread in questo modo non è consigliata perché si tratta di un'impostazione a livello di sistema. Se la si imposta in questo modo, è necessario riavviare il pool di applicazioni.

Annotazioni

Il valore specificato in questo elemento di configurazione è un'impostazione per core. Ad esempio, se si ha un computer a quattro core e si vuole che l'impostazione minIoThreads sia 200 in fase di esecuzione, usare <processModel minIoThreads="50">.

Abilitare il server Garbage Collection in modo da ottenere una velocità effettiva maggiore sul client quando si usa StackExchange.Redis

L'abilitazione del server Garbage Collection consente di ottimizzare il client e fornire velocità effettiva e prestazioni migliori quando si usa StackExchange.Redis. Per altre informazioni sul server Garbage Collection e sulla relativa abilitazione, vedere gli articoli seguenti:

• Per abilitare il server Garbage Collection
• Fondamenti della Garbage Collection
• Garbage Collection e prestazioni

Considerazioni sulle prestazioni per le connessioni

Sku diversi potrebbero avere limiti diversi per le connessioni client, la memoria e la larghezza di banda. Mentre ogni dimensione della cache consente fino a un certo numero di connessioni, ogni connessione a Redis ha un sovraccarico associato. Un esempio di questo sovraccarico potrebbe essere l'utilizzo della CPU e della memoria a causa della crittografia TLS/SSL. Il limite massimo di connessioni per una dimensione della cache specificata presuppone una cache leggermente caricata. Se il carico dal sovraccarico di connessione più il carico delle operazioni client supera la capacità per il sistema, la cache può riscontrare problemi di capacità anche se non si supera il limite di connessione per le dimensioni correnti della cache.

Per altre informazioni sui diversi limiti di connessioni per ogni livello, vedere Prezzi di Redis gestiti di Azure.

Contenuti correlati

• Altre domande frequenti su Redis gestito di Azure.

Questo articolo offre risposte alle domande comuni su come gestire Redis gestito di Azure.

L'uso di TLS è consigliato come procedura consigliata in tutti i casi d'uso di Redis. L'opzione per connettersi senza TLS è inclusa per motivi di compatibilità con le versioni precedenti.

• Procedure consigliate di StackExchange.Redis
• Configurazione e concetti
• Test delle prestazioni

Procedure consigliate di StackExchange.Redis

• Impostare AbortConnect su false, quindi consentire a ConnectionMultiplexer di eseguire la riconnessione automatica.
• Usare una sola istanza ConnectionMultiplexer di lunga durata anziché creare una nuova connessione per ogni richiesta.
• Redis funziona meglio con valori inferiori, quindi considerare di suddividere i dati più grandi in più chiavi. Nella discussione di Redis, 100 kb è considerato di grandi dimensioni. Per altre informazioni, vedere Procedure consigliate per lo sviluppo.
• Configurare le impostazioni di ThreadPool per evitare timeout.
• Usare almeno il connectTimeout predefinito di 5 secondi. Questo intervallo fornisce a StackExchange.Redis tempo sufficiente per ristabilire la connessione in caso di un problema di rete.
• Tenere presente i costi delle prestazioni associati a diverse operazioni in esecuzione. Ad esempio, il comando KEYS è un'operazione O(n) e deve essere evitato. Il sito redis.io fornisce i dettagli sulla complessità del tempo per ogni operazione supportata. Selezionare i singoli comandi per informazioni sulla complessità di ogni operazione.

Configurazione e concetti

• Tenere presente che Redis è un archivio dati in memoria . Per altre informazioni, vedere Risolvere la perdita di dati in Azure Managed Redis in modo da conoscere gli scenari in cui può verificarsi la perdita di dati.
• Sviluppare il sistema in modo che possa gestire i problemi di connessione causati da failover e applicazione di patch.

Test delle prestazioni

• Vedere Test delle prestazioni con Azure Managed Redis per esempi di benchmark e istruzioni per l'esecuzione di test delle prestazioni personalizzati in Azure Managed Redis.

• Evitare di usare determinati comandi Redis che impiegano molto tempo per il completamento se non se ne comprende appieno il risultato. Ad esempio, non eseguire il comando KEYS nell'ambiente di produzione. In base al numero delle chiavi, la restituzione di un valore potrebbe infatti richiedere molto tempo. Ogni partizione Redis è a thread singolo e elabora i comandi uno alla volta. Eventuali comandi inviati dopo KEYS verranno elaborati solo dopo l'elaborazione del comando KEYS. Il sito redis.io fornisce i dettagli sulla complessità del tempo per ogni operazione supportata. Selezionare i singoli comandi per informazioni sulla complessità di ogni operazione.
• È consigliabile usare coppie chiave-valore di piccole o di grandi dimensioni? Dipende dallo scenario. Se lo scenario richiede chiavi di dimensioni maggiori, si può modificare il valore di ConnectionTimeout e dei nuovi tentativi e regolare la logica di ripetizione dei tentativi. Dal punto di vista del server Redis, valori più piccoli offrono prestazioni migliori.
• Ciò non significa che non sia possibile archiviare valori di dimensioni maggiori in Redis. Occorre tenere presenti le considerazioni seguenti. Le latenze sono superiori. Se sono presenti due set di dati, uno di dimensioni maggiori e l'altro di dimensioni minori, è possibile usare più istanze di ConnectionMultiplexer. Configurare ognuno con un set diverso di valori di timeout e ripetizione dei tentativi, come descritto nella sezione precedente What do the StackExchange.Redis configuration options do .

• Abilitare la diagnostica della cache in modo da poter monitorare l'integrità della cache. È possibile visualizzare le metriche nel portale di Azure, nonché scaricarle e analizzarle usando gli strumenti preferiti.
• Vedere Test delle prestazioni con Azure Managed Redis per esempi di benchmark e istruzioni per l'esecuzione di test delle prestazioni personalizzati in Azure Managed Redis.

Il pool di thread CLR include due tipi di thread: thread di lavoro e porta di completamento I/O (IOCP).

• I thread di lavoro vengono usati per operazioni come l'elaborazione dei metodi Task.Run(…) o ThreadPool.QueueUserWorkItem(…). Questi thread vengono usati anche da vari componenti CLR quando il lavoro deve essere eseguito in un thread in background.
• I thread IOCP vengono usati quando si verificano I/O asincroni, ad esempio, durante la lettura dalla rete.

Il pool di thread fornisce nuovi thread di lavoro o thread di completamento I/O su richiesta, senza alcuna limitazione, fino a quando non viene raggiunta l'impostazione minima per ogni tipo di thread. Per impostazione predefinita, il numero minimo di thread corrisponde al numero di processori in un sistema.

Quando il numero di thread esistenti (occupati) raggiunge il numero minimo di thread, ThreadPool limita la velocità con cui inserisce nuovi thread in un thread per 500 millisecondi. In genere, se il sistema ottiene un picco di lavoro che richiede un thread IOCP, elabora rapidamente il funzionamento. Tuttavia, se il picco è superiore all'impostazione minima configurata, si nota un ritardo nell'elaborazione di una parte del lavoro mentre l'oggetto ThreadPool attende che si verifichi una delle situazioni seguenti:

• Un thread esistente diventa disponibile per elaborare il lavoro.
• Nessun thread esistente diventa disponibile per 500 ms e viene creato un nuovo thread.

In pratica, quando il numero di thread occupato è maggiore di Min thread, è probabile che si stia pagando un ritardo di 500 ms prima che l'applicazione elabori il traffico di rete. Inoltre, quando un thread esistente rimane inattiva per più di 15 secondi, viene pulito e questo ciclo di crescita e compattazione può ripetersi.

Se si osserva un messaggio di errore di esempio restituito da StackExchange.Redis, build 1.0.450 o versione successiva, è possibile notare che ora le statistiche dell'oggetto ThreadPool vengono stampate. Vedere i dettagli di IOCP e WORKER più avanti nell'articolo.

System.TimeoutException: Timeout performing GET MyKey, inst: 2, mgr: Inactive,
queue: 6, qu: 0, qs: 6, qc: 0, wr: 0, wq: 0, in: 0, ar: 0,
IOCP: (Busy=6,Free=994,Min=4,Max=1000),
WORKER: (Busy=3,Free=997,Min=4,Max=1000)

Come illustrato nell'esempio, si noterà che per il thread IOCP sono presenti sei thread occupati e il sistema è configurato per consentire quattro thread minimi. In questo caso, il client visualizzerà due ritardi di 500 ms, perché 6 > 4.

Annotazioni

StackExchange.Redis può raggiungere il timeout se la crescita dei thread IOCP o WORKER viene limitata.

Raccomandazione

È consigliabile che i clienti impostino il valore di configurazione minimo per i thread IOCP e WORKER su un valore maggiore del valore predefinito. Non è possibile fornire indicazioni specifiche su questo valore perché il valore corretto per un'applicazione può essere troppo alto o basso per un'altra applicazione. Questa impostazione può anche influire sulle prestazioni di altre parti di applicazioni complesse. Ogni cliente deve ottimizzare questa impostazione in modo da soddisfare le esigenze specifiche. Un buon punto di partenza è 200 o 300, da verificare e modificare a seconda delle necessità.

Come configurare questa impostazione:

È consigliabile modificare questa impostazione a livello di codice usando il metodo ThreadPool.SetMinThreads (...) nelle applicazioni .NET Framework e .NET Core.

Ad esempio, in NET Framework, è necessario impostarlo nel Global.asax.csApplication_Start metodo :

```csharp
private readonly int minThreads = 200;
void Application_Start(object sender, EventArgs e)
{
    // Code that runs on application startup
    AreaRegistration.RegisterAllAreas();
    RouteConfig.RegisterRoutes(RouteTable.Routes);
    BundleConfig.RegisterBundles(BundleTable.Bundles);
    ThreadPool.SetMinThreads(minThreads, minThreads);
}
```

Se si usa .NET Core, è necessario impostarlo in Program.cs, subito prima della chiamata a WebApplication.CreateBuilder():

```csharp
const int minThreads = 200
              
ThreadPool.SetMinThreads(minThreads, minThreads);

var builder = WebApplication.CreateBuilder(args);
// rest of application setup
```

Annotazioni

Il valore specificato da questo metodo è un'impostazione globale, che interessa l'intero dominio dell'applicazione. Ad esempio, se si dispone di un computer con quattro core e si vuole impostare minWorkerThreads e minIoThreads su 50 per CPU durante l'esecuzione, usare ThreadPool.SetMinThreads(200, 200).

È anche possibile specificare l'impostazione minima dei thread usando l'impostazione minIoThreads di minWorkerThreads o nell'elemento <processModel> di configurazione in Machine.config. Machine.config si trova in genere in %SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\.

L'impostazione del numero minimo di thread in questo modo non è consigliata perché si tratta di un'impostazione a livello di sistema. Se la si imposta in questo modo, è necessario riavviare il pool di applicazioni.

Annotazioni

Il valore specificato in questo elemento di configurazione è un'impostazione per core. Ad esempio, se si ha un computer a quattro core e si vuole che l'impostazione minIoThreads sia 200 in fase di esecuzione, usare <processModel minIoThreads="50">.

L'abilitazione del server Garbage Collection consente di ottimizzare il client e fornire velocità effettiva e prestazioni migliori quando si usa StackExchange.Redis. Per altre informazioni sul server Garbage Collection e sulla relativa abilitazione, vedere gli articoli seguenti:

• Per abilitare il server Garbage Collection
• Fondamenti della Garbage Collection
• Garbage Collection e prestazioni

Sku diversi potrebbero avere limiti diversi per le connessioni client, la memoria e la larghezza di banda. Mentre ogni dimensione della cache consente fino a un certo numero di connessioni, ogni connessione a Redis ha un sovraccarico associato. Un esempio di questo sovraccarico potrebbe essere l'utilizzo della CPU e della memoria a causa della crittografia TLS/SSL. Il limite massimo di connessioni per una dimensione della cache specificata presuppone una cache leggermente caricata. Se il carico dal sovraccarico di connessione più il carico delle operazioni client supera la capacità per il sistema, la cache può riscontrare problemi di capacità anche se non si supera il limite di connessione per le dimensioni correnti della cache.

Per altre informazioni sui diversi limiti di connessioni per ogni livello, vedere Prezzi di Redis gestiti di Azure.

Contenuti correlati

• Altre domande frequenti su Redis gestito di Azure.