Condividi tramite

Test delle prestazioni

  • Articolo

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

Attenzione

Questi valori non sono garantiti e non esiste alcun contratto di servizio per questi numeri. È consigliabile eseguire il test delle prestazioni personalizzati per determinare le dimensioni corrette della cache per l'applicazione. È possibile che questi numeri subiscano modifiche, poiché vengono pubblicati periodicamente risultati più recenti.

Importante

Microsoft aggiorna periodicamente la macchina virtuale sottostante usata nelle istanze della cache. Ciò può modificare le caratteristiche delle prestazioni da cache a cache e da area ad area. I valori di benchmarking di esempio in questa pagina riflettono l'hardware della cache di generazione precedente in una singola area. Si potrebbero vedere risultati migliori o diversi nella pratica.

La configurazione seguente è stata usata per eseguire il benchmark della velocità effettiva per i livelli Basic, Standard e Premium:

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

Benchmark Redis di livello Standard

Istanza Dimensione vCPU Larghezza di banda di rete prevista (Mbps) Richieste GET al secondo senza SSL (dimensioni del valore 1 kB) Richieste GET al secondo con SSL (dimensioni del valore 1 kB)
C0 250 MB Condiviso 100 15.000 7.500
C1 1 GB 1 500 38.000 20.720
S2 2.5 GB 2 500 41.000 37.000
C3 6 GB 4 1000 100,000 90.000
C4 13 GB 2 500 60.000 55.000
C5 26 GB 4 1.000 102.000 93.000
C6 53 GB 8 2.000 126.000 120.000

Benchmark Redis di livello Premium

Istanza Dimensione vCPU Larghezza di banda di rete prevista (Mbps) Richieste GET al secondo senza SSL (dimensioni del valore 1 kB) Richieste GET al secondo con SSL (dimensioni del valore 1 kB)
P1 6 GB 2 1.500 180,000 172.000
P2 13 GB 4 3,000 350.000 341.000
P3 26 GB 4 3,000 350.000 341.000
P4 53 GB 8 6.000 400.000 373.000
P5 120 GB 32 6.000 400.000 373.000

Importante

Le istanze P5 nelle aree Cina orientale e Cina settentrionale usano 20 core, non 32 core.

Livelli Enterprise & Enterprise Flash

I livelli Enterprise ed Enterprise Flash offrono una scelta di criteri di cluster: Enterprise e OSS. I criteri del cluster aziendale sono una configurazione più semplice che non richiede al client di supportare il clustering. I criteri del cluster OSS, d'altra parte, usano il protocollo del cluster Redis per supportare velocità effettive più elevate. È consigliabile usare i criteri del cluster OSS nella maggior parte dei casi. Per altre informazioni, vedere Clustering . I benchmark per entrambi i criteri del cluster sono illustrati nelle tabelle seguenti.

La configurazione seguente è stata usata per eseguire il benchmark della velocità effettiva per i livelli Enterprise ed Enterprise flash:

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

Nota

Questa configurazione è quasi identica a quella usata per eseguire il benchmark dei livelli Basic, Standard e Premium. La configurazione precedente, tuttavia, non ha completamente utilizzato le prestazioni di calcolo maggiori dei livelli Enterprise. Richieste e thread aggiuntivi sono stati aggiunti a questa configurazione per illustrare le prestazioni complete.

Criteri del cluster Enterprise
Istanza Dimensione vCPU Larghezza di banda di rete prevista (Mbps) GET richieste al secondo senza SSL (dimensioni del valore di 1 kB) GET richieste al secondo con SSL (dimensioni del valore di 1 kB)
E10 12 GB 4 4.000 300.000 207,000
E20 25 GB 4 4.000 680,000 480,000
E50 50 GB 8 8.000 1,200,000 900,000
E100 100 GB 16 10,000 1,700,000 1,650,000
F300 384 GB 8 3.200 500,000 390,000
F700 715 GB 16 6.400 500,000 370,000
F1500 1455 GB 32 12.800 530,000 390,000
Criteri del cluster OSS
Istanza Dimensione vCPU Larghezza di banda di rete prevista (Mbps) GET richieste al secondo senza SSL (dimensioni del valore di 1 kB) GET richieste al secondo con SSL (dimensioni del valore di 1 kB)
E10 12 GB 4 4.000 1.400.000 1\.000.000
E20 25 GB 4 4.000 1,200,000 900,000
E50 50 GB 8 8.000 2,300,000 1,700,000
E100 100 GB 16 10,000 3,000,000 2,500,000
F300 384 GB 8 3.200 1,500,000 1,200,000
F700 715 GB 16 6.400 1,600,000 1,200,000
F1500 1455 GB 32 12.800 1,600,000 1,110,000

Livelli Enterprise & Enterprise Flash - Scalabilità orizzontale

Oltre a aumentare le prestazioni passando a dimensioni della cache maggiori, è possibile aumentare le prestazioni aumentando le prestazioni. Nei livelli Enterprise, la scalabilità orizzontale viene chiamata aumento della capacità dell'istanza della cache. Per impostazione predefinita, un'istanza della cache ha capacità di due significati di un nodo primario e di replica. Un'istanza della cache aziendale con una capacità di quattro indica che l'istanza è stata ridimensionata di un fattore pari a due. L'aumento del numero di istanze consente di accedere a più risorse di memoria e vCPU. I dettagli sul numero di vCPU usati dal processo Redis principale a ogni dimensione e capacità della cache sono disponibili nella configurazione del partizionamento orizzontale. La scalabilità orizzontale è più efficace quando si usano i criteri del cluster OSS.

Le tabelle seguenti mostrano le GET richieste al secondo in capacità diverse, usando SSL e una dimensione di 1 kB.

Scalabilità orizzontale - Criteri del cluster aziendale
Istanza Capacità 2 Capacità 4 Capacità 6
E10 200.000 830,000 930,000
E20 480,000 710,000 950,000
E50 900,000 1,110,000 1,200,000
E100 1,600,000 1,120,000 1,200,000
Istanza Capacità 3 Capacità 9
F300 390,000 640,000
F700 370,000 610,000
F1500 390,000 670,000
Scalabilità orizzontale - Criteri del cluster OSS
Istanza Capacità 2 Capacità 4 Capacità 6
E10 1\.000.000 1,900,000 2,500,000
E20 900,000 1,700,000 2,300,000
E50 1,700,000 3,000,000 3,900,000
E100 2,500,000 4,400,000 4,900,000
Istanza Capacità 3 Capacità 9
F300 1,200,000 2,600,000
F700 1,200,000 2,600,000
F1500 1,100,000 2,800,000

Passaggi successivi