Domande frequenti sulla gestione redis gestita di Azure (anteprima)

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

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 (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 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. 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. 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 visualizzerà due ritardi di 500 ms, perché 6 > 4.

Elemento consigliato

È consigliabile impostare il numero minimo dei thread IOCP e WORKER su un valore maggiore di quello predefinito. Non è possibile fornire indicazioni specifiche su ciò che questo valore deve essere 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. È 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 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 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\. 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 dispone di un computer con quattro core e si vuole che l'impostazione minIoThreads sia 200 in fase di esecuzione, si userà <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

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 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 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. Per ulteriori informazioni sulle connessioni e altre configurazioni predefinite, vedere Configurazione predefinita del server Redis.

Passaggi successivi

Altre domande frequenti su Redis gestito di Azure.