Domande frequenti sulla gestione in Cache Redis di Azure

Il server Redis non offre il supporto nativo per TLS, ma tale supporto è disponibile in Cache Redis di Azure. Se ci si connette a Cache Redis di Azure e il client supporta TLS, ad esempio StackExchange.Redis, usare TLS.

Strumenti di Redis come redis-cli non funzionano con la porta TLS, ma è 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 (Annuncio del provider di stato della sessione ASP.NET per la versione di anteprima di Redis).

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

• 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 un'istanza singola e di lunga ConnectionMultiplexer durata anziché creare una nuova connessione per ogni richiesta. Per un esempio di come gestire una connessione, vedere la RedisConnection classe in Connetti alla cache con Redisconnection.
• Redis funziona meglio con valori inferiori, quindi considerare di suddividere i dati più grandi in più chiavi. In questa discussione di Redis, 100 kb viene considerato grande. Per altre informazioni, vedere Procedure consigliate per lo sviluppo.
• Configurare le impostazioni 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

• 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. Usare almeno una cache di livello C1. Le cache di livello C0 sono usate solitamente in scenari semplici di sviluppo e test.
• Tenere presente che Redis è un archivio dati in memoria . Per altre informazioni, vedere Risolvere la perdita di dati in cache di Azure per Redis in modo da essere consapevoli degli scenari in cui può verificarsi la perdita di dati.
• Sviluppare il sistema in modo che possa gestire i blip di connessione causati da patch e failover.

Test delle prestazioni

• Usare innanzitutto redis-benchmark.exe per acquisire familiarità con le velocità effettive possibili prima di scrivere il proprio test delle prestazioni. Il benchmark redis-benchmark non supporta TLS, quindi è necessario abilitare la porta non TLS tramite il portale di Azure prima di eseguire il test. Per esempi, vedere In che modo è possibile valutare e testare le prestazioni della cache?
• La macchina virtuale client usata per il test deve trovarsi nella stessa area dell'istanza di Cache Redis di Azure.
• È consigliabile usare macchine virtuali della serie Dv2 per il client poiché dispongono di hardware migliore e dovrebbero quindi dare risultati più precisi.
• Assicurarsi che la macchina virtuale client disponga almeno della capacità di elaborazione e della larghezza di banda della cache che si sta testando.
• Se si usa Windows, abilitare VRSS sul computer client. Per informazioni dettagliate, vedere qui.
• Le istanze del livello Premium di Redis hanno migliore latenza di rete e velocità effettiva perché sono in esecuzione su hardware migliori per CPU e rete.

• 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 ed elabora un comando 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 saranno più elevate. 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 di ripetizione dei tentativi, come descritto nella sezione precedente Qual è la funzione delle opzioni di configurazione StackExchange.Redis?.

• 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.
• È possibile usare redis-benchmark.exe per eseguire test di carico del server Redis.
• Assicurarsi che il client del test di carico e Cache Redis di Azure si trovino nella stessa area.
• Usare redis-cli.exe e monitorare la cache usando il comando INFO.
• Se il carico provoca la frammentazione elevata della memoria, è consigliabile passare a dimensioni di cache maggiori.
• Per istruzioni sul download degli strumenti Redis, vedere la sezione Come si eseguono i comandi Redis? .

Ecco alcuni esempi relativi all'uso di redis-benchmark.exe. Per risultati accurati, eseguire questi comandi da una macchina virtuale situata nella stessa area della cache. cache-development-faq.yml

• Testare le richieste SET in pipeline usando un payload 1 k

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

• Testare le richieste GET in pipeline usando un payload 1 k.

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

L'oggetto ThreadPool CLR ha due tipi di thread, i thread di lavoro (WORKER) e i thread IOCP (porta di completamento I/O).

• 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, o occupati, raggiunge il minimo, l'oggetto ThreadPool limita la frequenza di inserimento dei nuovi thread a uno ogni 500 millisecondi. Solitamente, se il sistema riceve un picco di lavoro che necessita di un thread IOCP, il lavoro viene elaborato rapidamente. 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 sostanza, quando il numero dei thread occupati è maggiore del numero minimo di thread, è probabile che si verifichi un ritardo di 500 ms prima che il traffico di rete venga elaborato dall'applicazione. Quando inoltre un thread esistente rimane inattivo per più di 15 secondi, viene pulito e il ciclo di crescita e riduzione si ripete.

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. I dettagli su IOCP e WORKER sono disponibili di seguito.

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 sono presenti sei thread IOCP occupati e il sistema è configurato per consentire un minimo di quattro thread. In questo caso, il client avrebbe probabilmente visto due ritardi da 500 ms, perché 6 > 4.

Recommendation

È consigliabile impostare il numero minimo dei thread IOCP e WORKER su un valore maggiore di quello predefinito. Non è possibile fornire indicazioni universali su questo valore, perché il valore corretto per un'applicazione sarebbe probabilmente troppo alto o troppo basso per un'altra. Questa impostazione può anche influire sulle prestazioni di altre parti di applicazioni complesse. È quindi necessario che venga adattata alle specifiche esigenze del cliente. Un buon punto di partenza è 200 o 300, da verificare e modificare a seconda delle necessità.

Come configurare questa impostazione:

• Si consiglia di modificare questa impostazione a livello di codice usando il metodo ThreadPool.SetMinThreads (...) in global.asax.cs. Ad esempio:

  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);
  }
  

  Nota

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

• È anche possibile specificare l'impostazione relativa al numero minimo di thread usando l'impostazione di configurazione minIoThreads o minWorkerThreads nell'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.

  Nota

  Il valore specificato in questo elemento di configurazione è un'impostazione per core. Ad esempio, se si ha un computer con 4 core e si vuole che l'impostazione minIoThreads sia 200 in fase di esecuzione, occorre 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
• Nozioni fondamentali di Garbage Collection
• Garbage Collection e prestazioni

Ogni piano tariffario presenta diversi limiti di connessioni client, memoria e 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 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 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 è stato superato in base alla dimensione della cache corrente.

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

Passaggi successivi

Informazioni su altre domande frequenti su Cache Redis di Azure.