Domande frequenti sulla gestione della cache

• Utilizzare redis-benchmark.exe per eseguire il test di carico del server Redis. Utilizzare redis-benchmark.exe per avere un'idea della possibile velocità effettiva prima di scrivere i propri test delle prestazioni.
• Utilizzare redis-cli per monitorare la cache utilizzando il INFO comando. Per istruzioni sul download degli strumenti Redis, vedere Come è possibile eseguire i comandi Redis?
• Se utilizzi Transport Layer Security/Secure Socket Layer (TLS/SSL) sull'istanza della cache, aggiungi il --tls parametro ai comandi degli strumenti Redis o utilizza un proxy come stunnel abilitare TLS/SSL.
• Redis-benchmark Utilizza la porta 6379 per impostazione predefinita. Utilizzare il -p parametro per ignorare questa impostazione se la cache utilizza la porta 6380 SSL/TLS o la porta 10000di livello Enterprise.
• 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 di funzionalità di calcolo e larghezza di banda almeno pari a quella 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 altre informazioni, vedere Scalabilità virtuale sul lato di ricezione in Windows Server 2012 R2.
• Abilitare la diagnostica della cache in modo da poter monitorare l'integrità della cache. È possibile visualizzare le metriche nel portale di Azure ed è anche possibile scaricare ed esaminare le metriche usando gli strumenti desiderati.
• Se il carico causa un'elevata frammentazione della memoria, aumentare le dimensioni della cache fino a ottenere dimensioni maggiori.

Negli esempi seguenti viene illustrato come utilizzare redis-benchmark.exe. Eseguire questi comandi da una macchina virtuale nella stessa area della cache per ottenere risultati accurati.

Innanzitutto, testa le richieste in SET pipeline utilizzando 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 SET test, esegui le richieste in GET 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 della Garbage Collection del server (GC) può ottimizzare il client e fornire prestazioni e velocità effettiva migliori quando si utilizza StackExchange.Redis. Per altre informazioni sul server Garbage Collection e sulla relativa abilitazione, vedere gli articoli seguenti:

• L'elemento <gcServer>
• Nozioni fondamentali di 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.

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 quella di connettere in modo sicuro gli strumenti alla porta TLS seguendo le istruzioni riportate nel post di blog Annuncio ASP.NET provider di stato della sessione per la versione di anteprima Redis .

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

  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 i valori , ConnectionTimeoutquindi riprovare e regolare la logica di ripetizione dei tentativi. Dal punto di vista del server Redis, valori di 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ù ConnectionMultiplexer istanze, 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 di cache consente fino a un certo numero di connessioni, ogni connessione a Redis comporta un sovraccarico associato. Un esempio di tale 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 dal sovraccarico della connessione e il carico dalle operazioni client superano la capacità del 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 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 Standard o Premium 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.
• Sviluppa il tuo sistema in modo che possa gestire i problemi di connessione causati da patch e failover.
• Usare le istanze di Azure Redis di livello Premium per migliorare la latenza di rete e la velocità effettiva, perché dispongono di hardware migliore sia per la CPU che per la rete.

Procedure consigliate di StackExchange.Redis

• Impostare AbortConnect su false, quindi lasciare che la riconnessione si riconnetta ConnectionMultiplexer 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 offre a StackExchange.Redis tempo sufficiente per ristabilire la connessione se si verifica un errore di rete.
• Tenere presente i costi delle prestazioni associati alle diverse operazioni eseguite. 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.

Il ThreadPool di Common Language Runtime (CLR) dispone di due tipi di thread, Worker e I/O Completion Port (IOCP).

• WORKER I thread vengono utilizzati per operazioni come l'elaborazione dei Task.Run(…)metodi , or ThreadPool.QueueUserWorkItem(…) . Vari componenti di CLR utilizzano questi thread anche quando è necessario lavorare su un thread in background.
• IOCP I thread 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 di I/O su richiesta senza alcuna limitazione fino a quando non raggiunge l'impostazione minimum per ogni tipo di thread. Per impostazione predefinita, il numero minimo di thread corrisponde al numero di processori in un sistema.

Una volta che il numero di thread occupati esistenti raggiunge il minimum numero di thread, ThreadPool limita la velocità con cui inserisce nuovi thread a un thread 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 burst è superiore all'impostazione configurata minimum , si verifica un ritardo nell'elaborazione di parte del lavoro poiché ThreadPool attende una delle due possibilità:

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

Fondamentalmente, quando il numero di thread è maggiore dei Busy thread, si verifica un ritardo di Min 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 questo ciclo di crescita e restringimento può ripetersi.

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)

Nell'esempio viene illustrato che per il IOCP thread sono presenti sei thread occupati e che il sistema è configurato in modo da consentire un numero minimo di quattro thread. In questo caso, è probabile che il client visualizzi due ritardi di 500 ms, perché 6 > 4.

È consigliabile impostare il valore di configurazione minimo per IOCP and WORKER threads 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 utilizzando il metodo ThreadPool.SetMinThreads (...) .

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

    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

È anche possibile specificare l'impostazione dei thread minimi utilizzando l'impostazione minIoThreads di minWorkerThreads or sotto l'elemento <processModel> configuration 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 si impostano i thread minimi in questo modo, è necessario riavviare il pool di applicazioni.

Contenuti correlati

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