Test delle prestazioni

Il test delle prestazioni di un'istanza di Redis può essere un'attività complessa. Le prestazioni di un'istanza di Redis possono variare in base a parametri quali il numero di client, le dimensioni dei valori dei dati e l'uso della pipelining. Può anche verificarsi un compromesso tra l'ottimizzazione della velocità effettiva o la latenza.

Fortunatamente, esistono diversi strumenti per semplificare il benchmarking di Redis. Due degli strumenti più diffusi sono redis-benchmark e memtier-benchmark. Questo articolo è incentrato su redis-benchmark.

Come usare l'utilità redis-benchmark

1. Installare il server Redis open source in macchine virtuali client che è possibile usare per i test. L'utilità redis-benchmark è incorporata nella distribuzione di Redis open source. Seguire la documentazione di Redis per istruzioni su come installare l'immagine open source.

2. La macchina virtuale client usata per il test deve trovarsi nella stessa area dell'istanza di Cache di Azure per Redis.

3. Assicurarsi che la macchina virtuale client usata abbia almeno la larghezza di banda e di calcolo usata per l'istanza della cache testata.

4. Configurare l'isolamento della rete e le impostazioni del firewall per assicurarsi che la macchina virtuale client sia in grado di accedere all'istanza di Cache di Azure per Redis.

5. Se si usa TLS/SSL nell'istanza della cache, è necessario aggiungere il --tls parametro al comando redis-benchmark o usare un proxy come stunnel.

6. Redis-benchmark usa la porta 6379 per impostazione predefinita. Usare il parametro -p per eseguire l'override di questa impostazione. È necessario usare -p, se si usa SSL/TLS (porta 6380) o si usa il livello Enterprise (porta 10000).

7. Se si usa un'istanza di Cache di Azure per Redis che usa il clustering, è necessario aggiungere il parametro --cluster al comando redis-benchmark. Le cache di livello enterprise che usano Enterprise Clustering possono essere considerate come cache non cluster e non richiedono questa impostazione.

8. Avviare redis-benchmark dall'interfaccia della riga di comando o dalla shell della macchina virtuale. Per istruzioni su come configurare ed eseguire lo strumento, vedere la documentazione di redis-benchmark e le sezioni degli esempi di redis-benchmark.

Raccomandazioni per il benchmarking

• È importante non solo testare le prestazioni della cache in condizioni di stato stabile. Eseguire il test anche in condizioni di failover e misurare il carico della CPU/server nella cache durante tale periodo. È possibile avviare un failover riavviando il nodo primario. Il test in condizioni di failover consente di visualizzare la velocità effettiva e la latenza dell'applicazione durante le condizioni di failover. Il failover può verificarsi durante gli aggiornamenti o durante un evento non pianificato. Idealmente, non si vuole visualizzare il picco di carico CPU/server fino a un massimo dell'80% anche durante un failover, in quanto ciò può influire sulle prestazioni.

• Prendere in considerazione l'uso di istanze di Cache Redis di Azure di livello Enterprise e Premium. Queste dimensioni della cache hanno una migliore latenza di rete e velocità effettiva perché sono in esecuzione su un hardware migliore.

• Il livello Enterprise offre in genere prestazioni ottimali, poiché Redis Enterprise consente al processo Redis principale di usare più vCPU. I livelli basati su Redis open source, ad esempio Standard e Premium, possono usare solo una vCPU per il processo Redis per ogni partizione.

• Il benchmarking del livello Enterprise Flash può essere difficile perché alcune chiavi vengono archiviate in DRAM mentre alcune sono archiviate in un disco flash NVMe. Le chiavi sul benchmark DRAM sono veloci quasi come un'istanza del livello Enterprise, ma le chiavi sul disco flash NVMe sono più lente. Poiché il livello Enterprise Flash inserisce in modo intelligente le chiavi più usate in DRAM, assicurarsi che la configurazione del benchmark corrisponda all'utilizzo effettivo previsto. Prendere in considerazione l'uso del parametro -r per randomizzare le chiavi a cui si accede.

• L'uso di TLS/SSL riduce le prestazioni della velocità effettiva, che possono essere visualizzate chiaramente nei dati di benchmarking di esempio nelle tabelle seguenti.

• Anche se un server Redis è a thread singolo, la scalabilità verticale tende a migliorare le prestazioni della velocità effettiva. I processi di sistema possono usare le vCPU aggiuntive anziché condividere la vCPU usata dal processo Redis. La scalabilità verticale è particolarmente utile per i livelli Enterprise ed Enterprise Flash perché Redis Enterprise non è limitato a un singolo thread.

• Nel livello Premium, il ridimensionamento orizzontale, il clustering, è in genere consigliato prima di aumentare le prestazioni. Il clustering consente al server Redis di usare più vCPU tramite il partizionamento orizzontale dei dati. La velocità effettiva dovrebbe aumentare approssimativamente linearmente quando si aggiungono partizioni in questo caso.

• Nelle cache standard C0 e C1, mentre l'analisi interna di Defender è in esecuzione nelle VM, potrebbero verificarsi brevi picchi di carico del server, non causati da un aumento delle richieste di cache. Si noterà una latenza più elevata per le richieste mentre le analisi interne di Defender vengono eseguite su questi livelli, un paio di volte al giorno. Le cache nei livelli C0 e C1 hanno un solo core per multitasking e dividono il lavoro di gestione delle analisi interne di Defender e delle richieste Redis. È possibile ridurre l'effetto ridimensionando a un'offerta di livello superiore con più core CPU, ad esempio C2.

  L'aumento delle dimensioni della cache nei livelli superiori consente di risolvere eventuali problemi di latenza. Inoltre, al livello C2, è disponibile il supporto per un massimo di 2.000 connessioni client.

Esempi di redis-benchmark

Configurazione preliminare del test: preparare l'istanza della cache con i dati necessari per il test della latenza e della velocità effettiva:

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t SET -n 10 -d 1024

Per testare la latenza: testare le richieste GET usando un payload 1k:

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t GET -d 1024 -P 50 -c 4

Per testare la velocità effettiva: richieste GET con pipeline con payload 1k:

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

Per testare la velocità effettiva di una cache di livello Basic, Standard o Premium tramite TLS: Richieste GET con pipeline con payload 1k:

redis-benchmark -h yourcache.redis.cache.windows.net -p 6380 -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50 -c 50 --tls

Per testare la velocità effettiva di una cache Enterprise o Enterprise Flash senza TLS usando la modalità cluster OSS: richieste GET con pipeline con payload 1k:

redis-benchmark -h yourcache.region.redisenterprise.cache.azure.net -p 10000 -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50 -c 50 --cluster

Dati di benchmark delle prestazioni di esempio

Le tabelle seguenti mostrano i valori massimi di velocità effettiva osservati durante il test di varie dimensioni delle cache Standard, Premium, Enterprise ed Enterprise Flash. È stato usato redis-benchmark e memtier-benchmark da una macchina virtuale di Azure IaaS rispetto all'endpoint cache di Azure per Redis. I numeri di velocità effettiva sono solo per i comandi GET. In genere, i comandi SET hanno una velocità effettiva inferiore. Questi numeri sono ottimizzati per la velocità effettiva. La velocità effettiva reale in condizioni di latenza accettabili potrebbe essere inferiore.

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

memtier_benchmark -h {your-cache-name}.{region}.redis.azure.net -p 10000 -a {your-access-key} --hide-histogram --pipeline=10 -c 50 -t 6 -d 1024 --key-maximum={number-of-keys} --key-pattern=P:P --ratio=0:1 --distinct-client-seed --randomize --test-time=600 --json-out-file=test_results.json --tls --tls-skip-verify

redis-benchmark -h yourcache.region.redisenterprise.cache.azure.net -p 10000 -a yourAccesskey -t GET -n 10000000 -d 1024 -P 50 -c 50 --threads 32

Passaggi successivi

• Sviluppo
• Domande frequenti sullo sviluppo in Cache Redis di Azure
• Failover e applicazione di patch per Cache di Azure per Redis