domande frequenti sulla gestione dei cache di Azure per Redis

Questo articolo fornisce le risposte alle domande comuni su come gestire i cache di Azure per Redis.

Domande e risposte comuni

In questa sezione vengono illustrate le domande frequenti seguenti:

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

Il server Redis non supporta TLS in modo nativo, ma cache di Azure per Redis in modo nativo. Se ci si connette a cache di Azure per Redis e il client supporta TLS, ad esempio StackExchange.Redis, usare TLS.

Nota

Per le nuove istanze di Cache Redis di Azure la porta non TLS è disabilitata per impostazione predefinita. Se il client non supporta TLS, sarà necessario abilitare la porta non TLS seguendo le istruzioni disponibili nella sezione Porte di accesso dell'articolo Configurare una cache in Cache Redis di Azure.

Gli strumenti Redis, ad esempio, non funzionano con la porta TLS, ma è possibile usare un'utilità come per connettere in modo sicuro gli strumenti alla porta TLS seguendo le istruzioni riportate nel post di redis-cli stunnel blog Announcing ASP.NET Session State Provider for Redis Preview Release (Annuncio della versione di anteprima del provider di stato sessione per Redis).

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

Quali sono alcune procedure consigliate per la produzione?

Procedure consigliate di StackExchange.Redis

  • Impostare AbortConnect su false, quindi consentire a ConnectionMultiplexer di eseguire la riconnessione automatica. Per informazioni dettagliate, vedere qui.
  • Riutilizzare ConnectionMultiplexer: non crearne uno nuovo per ogni richiesta. Usare invece questo modello. Modello Lazy<ConnectionMultiplexer> illustrato di seguito.
  • 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. Leggere in questo articolo per un problema di esempio che può essere causato da valori di grandi dimensioni.
  • Configurare le impostazioni ThreadPool per evitare timeout.
  • Usare almeno il connectTimeout predefinito di 5 secondi. Questo intervallo concede a StackExchange.Redis tempo sufficiente per ristabilire la connessione in caso di problemi di rete.
  • Tenere presenti i costi delle prestazioni associati alle 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 ogni comando per visualizzare la 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 . Leggere questo articolo per conoscere gli scenari in cui può verificarsi una perdita di dati.
  • Sviluppare il sistema in modo che possa gestire i problemi di connessione causati dall'applicazione di patch e dal 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. Poiché non supporta TLS, è necessario abilitare la porta non TLS tramite il portale di Azure redis-benchmark 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 scelta abbia almeno la capacità di calcolo e 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 Redis di livello Premium hanno una velocità effettiva e una latenza di rete migliori perché vengono eseguite su hardware migliore sia per la CPU che per la rete.

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

  • Evitare di usare determinati comandi Redis che durano molto tempo, a meno che non si comprendi completamente il risultato di questi comandi. 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. Se sono stati emessi altri comandi dopo KEYS, non vengono elaborati fino a quando Redis non elabora il comando KEYS. Il sito redis.io fornisce i dettagli sulla complessità del tempo per ogni operazione supportata. Selezionare ogni comando per visualizzare la 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 si ha un set di dati più grande e uno più piccolo, è possibile usare più istanze connectionMultiplexer. Configurare ognuno con un set diverso di valori di timeout e ripetizione dei tentativi, come descritto nella sezione Precedente Che cosa fanno le opzioni di configurazione stackExchange.Redis.

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

  • 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 di uso di redis-benchmark.exe. Eseguire questi comandi da una macchina virtuale nella stessa area della cache per ottenere risultati accurati.

  • 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.

Nota

eseguire il test SET mostrato in alto prima di popolare la cache

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

Informazioni importanti sulla crescita del pool di thread

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 burst è superiore all'impostazione "Minima" configurata, si verifica un ritardo nell'elaborazione di parte del lavoro perché ThreadPool attende una delle due possibilità seguenti:

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

Fondamentalmente, quando il numero di thread occupati è maggiore di Thread minimi, è probabile che si paga un ritardo di 500 ms prima che il traffico di rete venga elaborato dall'applicazione. Inoltre, quando un thread esistente rimane inattivo per più di 15 secondi, viene pulito e questo ciclo di crescita e riduzione può ripetersi.

Se si osserva un messaggio di errore di esempio da StackExchange.Redis (build 1.0.450 o versione successiva), si noti che ora vengono stampate statistiche threadpool. Vedere i dettagli di IOCP e WORKER 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, si può vedere che per il thread IOCP sono presenti sei thread occupati e il sistema è configurato per consentire quattro thread minimi. In questo caso si verificheranno probabilmente due ritardi di 500 ms, perché 6 > 4.

Nota

StackExchange.Redis può determinare timeout se l'aumento della crescita dei thread IOCP o WORKER viene limitato.

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ò influire anche sulle prestazioni di altre parti di applicazioni complesse, quindi ogni cliente deve ottimizzare questa impostazione in base alle proprie esigenze specifiche. 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 dispone di un computer a 4 core e si desidera impostare minWorkerThreads e minIoThreads su 50 per CPU durante il run-time, usare ThreadPool.SetMinThreads(200, 200).

  • È anche possibile specificare l'impostazione minima dei thread usando l'impostazione di configurazione minIoThreads o minWorkerThreads 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é è 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"/>.

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:

Considerazioni sulle prestazioni per le connessioni

Ogni piano tariffario presenta diversi limiti di connessioni client, memoria e larghezza di banda. Anche se ogni dimensione della cache consente fino a un certo numero di connessioni, a ogni connessione a Redis è associato un sovraccarico. 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 dovuto al sovraccarico della connessione e al carico delle operazioni client supera la capacità per il sistema, la cache può verificarsi problemi di capacità anche se non è stato superato il limite di connessione per le dimensioni correnti della cache.

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 cache di Azure per Redis domande frequenti.