Domande frequenti sulla gestione della cache

Questo articolo include le risposte alle domande più comuni su come gestire Cache Redis di Azure.

Importante

Cache di Azure per Redis ha annunciato la sequenza temporale del suo ritiro per tutti gli SKU. È consigliabile spostare le istanze di Cache Redis di Azure esistenti in Azure Managed Redis non appena è possibile.

Per altre informazioni sul ritiro:

• Ritiro di Azure Cache per Redis: cosa sapere e come prepararsi al cambiamento
• FAQ sull'abbandono di Azure Cache for Redis

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

• Utilizzare redis-benchmark.exe per eseguire il test di carico del server Redis. Usare redis-benchmark.exe per acquisire familiarità con le velocità effettive possibili prima di scrivere il proprio test delle prestazioni.
• Utilizzare redis-cli per monitorare la cache utilizzando il comando INFO. Per istruzioni sul download degli strumenti Redis, vedere Come si eseguono i comandi Redis?
• Se si utilizza Transport Layer Security/Secure Socket Layer (TLS/SSL) sull'istanza della cache, aggiungere il parametro --tls ai comandi degli strumenti Redis o utilizzare un proxy come stunnel per abilitare TLS/SSL.
• Redis-benchmark utilizza la porta 6379 per impostazione predefinita. Utilizzare il parametro -p per ignorare questa impostazione se la cache utilizza la porta SSL/TLS 6380 o la porta di livello Enterprise 10000.
• Se necessario, è possibile abilitare la porta non TLS tramite il portale di Azure prima di eseguire il test di carico.
• Assicurarsi che la macchina virtuale client usata per il test si trovi nella stessa area dell'istanza di Cache di Azure per Redis.
• Assicurarsi che la macchina virtuale client disponga almeno della capacità di elaborazione e della larghezza di banda della cache che si sta testando. Per ottenere risultati ottimali, usare le macchine virtuali serie D ed E per i client.
• Se si usa Windows, abilitare Virtual Receive-side Scaling (VRSS) nel computer client. Per ulteriori informazioni, vedere l'argomento relativo a Virtual Receive-Side Scaling in Windows Server 2012 R2.
• Abilitare la diagnostica della cache per monitorare l'integrità della cache. È possibile visualizzare le metriche nel portale di Azure, nonché scaricarle e analizzarle usando gli strumenti preferiti.
• Se il carico provoca la frammentazione elevata della memoria, passare a dimensioni di cache maggiori.

Gli esempi seguenti illustrano come usare redis-benchmark.exe. Per risultati accurati, eseguire questi comandi da una macchina virtuale situata nella stessa area della cache.

Innanzitutto, testare le richieste SET in pipeline usando un payload da 1k:

redis-benchmark.exe -h <yourcache>.redis.cache.windows.net -a <yourAccesskey> -t SET -n 1000000 -d 1024 -P 50

Dopo aver eseguito il test SET, eseguire le richieste GET in pipeline utilizzando un payload da 1k:

redis-benchmark.exe -h <yourcache>.redis.cache.windows.net -a <yourAccesskey> -t GET -n 1000000 -d 1024 -P 50

Come si abilita il server Garbage Collection per poter 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:

• L'elemento <gcServer>
• Nozioni fondamentali su Garbage Collection
• Garbage Collection e prestazioni

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

Il server Redis non supporta in modo nativo Transport Layer Security (TLS), ma Cache di Azure per Redis supporta TLS. Se ci si connette a Cache di Azure per Redis con un client come StackExchange.Redis che supporta TLS, usare TLS.

Note

Per le nuove istanze di Redis di Azure la porta non TLS è disabilitata per impostazione predefinita. Se il client non supporta TLS, abilitare la porta non TLS seguendo le istruzioni riportate in Porte di accesso.

Se la cache utilizza TLS, è necessario abilitare TLS utilizzando l'opzione --tls per gli strumenti Redis come redis-cli. È anche possibile usare un'utilità come stunnel per connettere in modo sicuro gli strumenti alla porta TLS seguendo le istruzioni disponibili nel post di blog Announcing ASP.NET Session State Provider for Redis Preview Release.

Per istruzioni sul download degli strumenti Redis, vedere Come si eseguono i comandi Redis?

Quali sono alcune considerazioni per l'uso dei 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. Redis è un server a thread singolo che elabora un comando alla volta. Se si esegue il comando KEYS, Redis non elabora i comandi successivi fino al termine dell'elaborazione del comando KEYS.

  Il sito redis.io dispone di dettagli sulla complessità temporale per ogni operazione supportata. Selezionare i singoli comandi per informazioni sulla complessità di ogni operazione.

• Le dimensioni delle chiavi da utilizzare dipendono dallo scenario. Se lo scenario richiede chiavi più grandi, è possibile modificare regolare il valore di ConnectionTimeout, quindi riprovare e regolare la logica di ripetizione dei tentativi. Dal punto di vista del server Redis, valori chiave più piccoli offrono prestazioni migliori.

• Queste considerazioni non significano che non è possibile archiviare valori più grandi in Redis, ma le latenze sono più elevate. Se si dispone di un set di dati più grande di un altro, è possibile usare più istanze ConnectionMultiplexer, ognuna configurata con un set diverso di valori di timeout e ripetizione dei tentativi. Per altre informazioni, vedere Funzioni delle opzioni di configurazione di StackExchange.Redis

Quali sono alcune considerazioni sulle prestazioni per le connessioni?

Ogni piano tariffario di Cache di Azure per Redis ha limiti diversi per le connessioni client, la memoria e la larghezza di banda. Mentre ogni dimensione della cache consente fino a un determinato numero di connessioni, a ogni connessione a Redis è associato un sovraccarico. Un esempio di questo sovraccarico è 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 del sovraccarico della connessione sommato al carico delle operazioni client supera la capacità del sistema, la cache può riscontrare problemi di capacità anche se il limite della connessione non viene superato in base alla dimensione della cache corrente.

Per altre informazioni sui diversi limiti di connessione per ogni livello, vedere Prezzi di Cache di Azure per Redis. Per ulteriori informazioni sulle connessioni e altre configurazioni predefinite, vedere Configurazione predefinita del server Redis.

Quali sono alcune procedure consigliate per la produzione?

• Usare il livello Premium o Standard per i sistemi di produzione. Il livello Basic è un sistema a nodo singolo senza replica dei dati e senza contratto di servizio. Inoltre, utilizzare almeno una cache C1 per la produzione. Le cache di livello C0 sono usate solitamente in scenari semplici di sviluppo e test.
• Tenere presente che Redis è un archivio dati in memoria e che in alcuni scenari può verificarsi una perdita di dati. Per altre informazioni, vedere Risolvere i problemi relativi alla perdita di dati in Cache di Azure per Redis.
• Sviluppare il sistema in modo che possa gestire i problemi di connessione causati da applicazione di patch e failover.
• Usare le istanze del livello Premium di Redis di Azure per una migliore latenza di rete e velocità effettiva perché hanno hardware migliori per la CPU e la rete.

Procedure consigliate di StackExchange.Redis

• Impostare AbortConnect su false, quindi lasciare che ConnectionMultiplexer si riconnetta automaticamente.
• 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. Ad esempio, in Qual è l'intervallo di dimensioni del valore ideale per Redis?, 100 kb è considerato grande. Per altre informazioni, vedere Prendere in considerazione più chiavi e valori più piccoli.
• Configurare le impostazioni ThreadPool per evitare timeout.
• Utilizzare almeno il valore predefinito connectTimeout 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 contiene dettagli sulla complessità temporale di ogni operazione supportata. Selezionare i singoli comandi per informazioni sulla complessità di ogni operazione.

Informazioni importanti sulla crescita del pool di thread

L'oggetto ThreadPool Common Language Runtime ha due tipi di thread, i thread di lavoro e quelli porta di completamento I/O (IOCP).

• I thread WORKER vengono utilizzati 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 utilizzati per l'I/O asincrono, 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 minimum 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 minimum, l'oggetto ThreadPool limita la frequenza di inserimento dei nuovi thread a uno ogni 500 millisecondi.

In genere, se il sistema riceve un picco di lavoro che richiede un IOCP thread, elabora rapidamente il lavoro. Tuttavia, se il picco è superiore all'impostazione minimum 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.

Fondamentalmente, quando il numero di thread Busy è maggiore di Min thread, si verifica un ritardo di 500 ms prima che l'applicazione elabori il traffico di rete. Inoltre un thread esistente che rimane inattivo per più di 15 secondi, viene pulito e il ciclo di crescita e riduzione si ripete.

I messaggi di errore della build 1.0.450 o successiva di StackExchange.Redis stampano le statistiche di ThreadPool, come illustrato nell'esempio seguente.

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)

L'esempio mostra che per il thread IOCP, ci sono sei thread occupati e il sistema è configurato per consentire un minimo di quattro thread. In questo caso, è probabile che il client visualizzi due ritardi di 500 ms, perché 6 > 4.

Note

StackExchange.Redis può raggiungere i timeout se la crescita di uno IOCP o WORKER dei thread è limitata.

È consigliabile impostare il valore di configurazione minimo i thread IOCP e WORKER su un valore maggiore rispetto al valore predefinito. Non esistono indicazioni univoche per tutti su questo valore, perché il valore corretto per un'applicazione è probabilmente troppo alto o basso per un'altra applicazione. Questa impostazione può anche influire sulle prestazioni di altre parti di applicazioni complesse. È necessario ottimizzare questa impostazione in base alle proprie esigenze specifiche. Un buon punto di partenza è 200 o 300. Quindi testare e modificare secondo necessità.

Configurare l'impostazione del numero minimo di thread

È possibile modificare questa impostazione a livello di codice usando il metodo ThreadPool.SetMinThreads (...).

Ad esempio, in NET Framework, questo valore viene impostato in Global.asax.cs nel metodo Application_Start:

    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, si imposta il valore in Program.cs appena prima della chiamata a WebApplication.CreateBuilder():

    const int minThreads = 200
                  
    ThreadPool.SetMinThreads(minThreads, minThreads);
    
    var builder = WebApplication.CreateBuilder(args);
    // rest of application setup

Note

Il valore specificato da questo metodo è un'impostazione globale, che interessa l'intero dominio dell'applicazione. Ad esempio, se si dispone di una macchina virtuale a quattro core e si desidera impostare minWorkerThreads e minIoThreads su 50 per CPU durante il runtime, utilizzare ThreadPool.SetMinThreads(200, 200).

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

Non è consigliabile impostare il numero minimo di thread in questo modo perché si tratta di un'impostazione a livello di sistema. Se si impostano i thread minimi in questo modo, è necessario riavviare il pool di applicazioni.

Note

Il valore specificato da questo metodo è un'impostazione per core. Ad esempio, se si dispone di un computer a quattro core e si desidera che l'impostazione minIoThreads sia 200 in fase di esecuzione, utilizzare <processModel minIoThreads="50">.

Contenuti correlati

• Vedere altre domande frequenti su Cache di Azure per Redis.

Questo articolo include le risposte alle domande più comuni su come gestire Cache Redis di Azure.

Importante

Cache di Azure per Redis ha annunciato la sequenza temporale del suo ritiro per tutti gli SKU. È consigliabile spostare le istanze di Cache Redis di Azure esistenti in Azure Managed Redis non appena è possibile.

Per altre informazioni sul ritiro:

• Ritiro di Azure Cache per Redis: cosa sapere e come prepararsi al cambiamento
• FAQ sull'abbandono di Azure Cache for Redis

• Utilizzare redis-benchmark.exe per eseguire il test di carico del server Redis. Usare redis-benchmark.exe per acquisire familiarità con le velocità effettive possibili prima di scrivere il proprio test delle prestazioni.
• Utilizzare redis-cli per monitorare la cache utilizzando il comando INFO. Per istruzioni sul download degli strumenti Redis, vedere Come si eseguono i comandi Redis?
• Se si utilizza Transport Layer Security/Secure Socket Layer (TLS/SSL) sull'istanza della cache, aggiungere il parametro --tls ai comandi degli strumenti Redis o utilizzare un proxy come stunnel per abilitare TLS/SSL.
• Redis-benchmark utilizza la porta 6379 per impostazione predefinita. Utilizzare il parametro -p per ignorare questa impostazione se la cache utilizza la porta SSL/TLS 6380 o la porta di livello Enterprise 10000.
• Se necessario, è possibile abilitare la porta non TLS tramite il portale di Azure prima di eseguire il test di carico.
• Assicurarsi che la macchina virtuale client usata per il test si trovi nella stessa area dell'istanza di Cache di Azure per Redis.
• Assicurarsi che la macchina virtuale client disponga almeno della capacità di elaborazione e della larghezza di banda della cache che si sta testando. Per ottenere risultati ottimali, usare le macchine virtuali serie D ed E per i client.
• Se si usa Windows, abilitare Virtual Receive-side Scaling (VRSS) nel computer client. Per ulteriori informazioni, vedere l'argomento relativo a Virtual Receive-Side Scaling in Windows Server 2012 R2.
• Abilitare la diagnostica della cache per monitorare l'integrità della cache. È possibile visualizzare le metriche nel portale di Azure, nonché scaricarle e analizzarle usando gli strumenti preferiti.
• Se il carico provoca la frammentazione elevata della memoria, passare a dimensioni di cache maggiori.

Gli esempi seguenti illustrano come usare redis-benchmark.exe. Per risultati accurati, eseguire questi comandi da una macchina virtuale situata nella stessa area della cache.

Innanzitutto, testare le richieste SET in pipeline usando un payload da 1k:

redis-benchmark.exe -h <yourcache>.redis.cache.windows.net -a <yourAccesskey> -t SET -n 1000000 -d 1024 -P 50

Dopo aver eseguito il test SET, eseguire le richieste GET in pipeline utilizzando un payload da 1k:

redis-benchmark.exe -h <yourcache>.redis.cache.windows.net -a <yourAccesskey> -t GET -n 1000000 -d 1024 -P 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:

• L'elemento <gcServer>
• Nozioni fondamentali su Garbage Collection
• Garbage Collection e prestazioni

Il server Redis non supporta in modo nativo Transport Layer Security (TLS), ma Cache di Azure per Redis supporta TLS. Se ci si connette a Cache di Azure per Redis con un client come StackExchange.Redis che supporta TLS, usare TLS.

Note

Per le nuove istanze di Redis di Azure la porta non TLS è disabilitata per impostazione predefinita. Se il client non supporta TLS, abilitare la porta non TLS seguendo le istruzioni riportate in Porte di accesso.

Se la cache utilizza TLS, è necessario abilitare TLS utilizzando l'opzione --tls per gli strumenti Redis come redis-cli. È anche possibile usare un'utilità come stunnel per connettere in modo sicuro gli strumenti alla porta TLS seguendo le istruzioni disponibili nel post di blog Announcing ASP.NET Session State Provider for Redis Preview Release.

Per istruzioni sul download degli strumenti Redis, vedere Come si eseguono i comandi 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. Redis è un server a thread singolo che elabora un comando alla volta. Se si esegue il comando KEYS, Redis non elabora i comandi successivi fino al termine dell'elaborazione del comando KEYS.

  Il sito redis.io dispone di dettagli sulla complessità temporale per ogni operazione supportata. Selezionare i singoli comandi per informazioni sulla complessità di ogni operazione.

• Le dimensioni delle chiavi da utilizzare dipendono dallo scenario. Se lo scenario richiede chiavi più grandi, è possibile modificare regolare il valore di ConnectionTimeout, quindi riprovare e regolare la logica di ripetizione dei tentativi. Dal punto di vista del server Redis, valori chiave più piccoli offrono prestazioni migliori.

• Queste considerazioni non significano che non è possibile archiviare valori più grandi in Redis, ma le latenze sono più elevate. Se si dispone di un set di dati più grande di un altro, è possibile usare più istanze ConnectionMultiplexer, ognuna configurata con un set diverso di valori di timeout e ripetizione dei tentativi. Per altre informazioni, vedere Funzioni delle opzioni di configurazione di StackExchange.Redis

Ogni piano tariffario di Cache di Azure per Redis ha limiti diversi per le connessioni client, la memoria e la larghezza di banda. Mentre ogni dimensione della cache consente fino a un determinato numero di connessioni, a ogni connessione a Redis è associato un sovraccarico. Un esempio di questo sovraccarico è 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 del sovraccarico della connessione sommato al carico delle operazioni client supera la capacità del sistema, la cache può riscontrare problemi di capacità anche se il limite della connessione non viene superato in base alla dimensione della cache corrente.

Per altre informazioni sui diversi limiti di connessione per ogni livello, vedere Prezzi di Cache di Azure per Redis. Per ulteriori informazioni sulle connessioni e altre configurazioni predefinite, vedere Configurazione predefinita del server Redis.

• Usare il livello Premium o Standard per i sistemi di produzione. Il livello Basic è un sistema a nodo singolo senza replica dei dati e senza contratto di servizio. Inoltre, utilizzare almeno una cache C1 per la produzione. Le cache di livello C0 sono usate solitamente in scenari semplici di sviluppo e test.
• Tenere presente che Redis è un archivio dati in memoria e che in alcuni scenari può verificarsi una perdita di dati. Per altre informazioni, vedere Risolvere i problemi relativi alla perdita di dati in Cache di Azure per Redis.
• Sviluppare il sistema in modo che possa gestire i problemi di connessione causati da applicazione di patch e failover.
• Usare le istanze del livello Premium di Redis di Azure per una migliore latenza di rete e velocità effettiva perché hanno hardware migliori per la CPU e la rete.

Procedure consigliate di StackExchange.Redis

• Impostare AbortConnect su false, quindi lasciare che ConnectionMultiplexer si riconnetta automaticamente.
• 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. Ad esempio, in Qual è l'intervallo di dimensioni del valore ideale per Redis?, 100 kb è considerato grande. Per altre informazioni, vedere Prendere in considerazione più chiavi e valori più piccoli.
• Configurare le impostazioni ThreadPool per evitare timeout.
• Utilizzare almeno il valore predefinito connectTimeout 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 contiene dettagli sulla complessità temporale di ogni operazione supportata. Selezionare i singoli comandi per informazioni sulla complessità di ogni operazione.

L'oggetto ThreadPool Common Language Runtime ha due tipi di thread, i thread di lavoro e quelli porta di completamento I/O (IOCP).

• I thread WORKER vengono utilizzati 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 utilizzati per l'I/O asincrono, 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 minimum 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 minimum, l'oggetto ThreadPool limita la frequenza di inserimento dei nuovi thread a uno ogni 500 millisecondi.

In genere, se il sistema riceve un picco di lavoro che richiede un IOCP thread, elabora rapidamente il lavoro. Tuttavia, se il picco è superiore all'impostazione minimum 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.

Fondamentalmente, quando il numero di thread Busy è maggiore di Min thread, si verifica un ritardo di 500 ms prima che l'applicazione elabori il traffico di rete. Inoltre un thread esistente che rimane inattivo per più di 15 secondi, viene pulito e il ciclo di crescita e riduzione si ripete.

I messaggi di errore della build 1.0.450 o successiva di StackExchange.Redis stampano le statistiche di ThreadPool, come illustrato nell'esempio seguente.

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)

L'esempio mostra che per il thread IOCP, ci sono sei thread occupati e il sistema è configurato per consentire un minimo di quattro thread. In questo caso, è probabile che il client visualizzi due ritardi di 500 ms, perché 6 > 4.

Note

StackExchange.Redis può raggiungere i timeout se la crescita di uno IOCP o WORKER dei thread è limitata.

È consigliabile impostare il valore di configurazione minimo i thread IOCP e WORKER su un valore maggiore rispetto al valore predefinito. Non esistono indicazioni univoche per tutti su questo valore, perché il valore corretto per un'applicazione è probabilmente troppo alto o basso per un'altra applicazione. Questa impostazione può anche influire sulle prestazioni di altre parti di applicazioni complesse. È necessario ottimizzare questa impostazione in base alle proprie esigenze specifiche. Un buon punto di partenza è 200 o 300. Quindi testare e modificare secondo necessità.

Configurare l'impostazione del numero minimo di thread

È possibile modificare questa impostazione a livello di codice usando il metodo ThreadPool.SetMinThreads (...).

Ad esempio, in NET Framework, questo valore viene impostato in Global.asax.cs nel metodo Application_Start:

    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, si imposta il valore in Program.cs appena prima della chiamata a WebApplication.CreateBuilder():

    const int minThreads = 200
                  
    ThreadPool.SetMinThreads(minThreads, minThreads);
    
    var builder = WebApplication.CreateBuilder(args);
    // rest of application setup

Note

Il valore specificato da questo metodo è un'impostazione globale, che interessa l'intero dominio dell'applicazione. Ad esempio, se si dispone di una macchina virtuale a quattro core e si desidera impostare minWorkerThreads e minIoThreads su 50 per CPU durante il runtime, utilizzare ThreadPool.SetMinThreads(200, 200).

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

Non è consigliabile impostare il numero minimo di thread in questo modo perché si tratta di un'impostazione a livello di sistema. Se si impostano i thread minimi in questo modo, è necessario riavviare il pool di applicazioni.

Note

Il valore specificato da questo metodo è un'impostazione per core. Ad esempio, se si dispone di un computer a quattro core e si desidera che l'impostazione minIoThreads sia 200 in fase di esecuzione, utilizzare <processModel minIoThreads="50">.

Contenuti correlati

• Vedere altre domande frequenti su Cache di Azure per Redis.