Condividi tramite

Test delle prestazioni con Redis gestito di Azure (anteprima)

  • 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 memtier_benchmark, spesso chiamato memtier.

Come usare l'utilità memtier_benchmark

  1. Installare memtier in macchine virtuali client che è possibile usare per i test. Seguire la documentazione di Memtier per istruzioni su come installare l'immagine open source.

  2. La macchina virtuale client usata per i test deve trovarsi nella stessa area dell'istanza di Azure Managed Redis (AMR).

  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 della macchina virtuale per assicurarsi che la macchina virtuale client sia in grado di accedere all'istanza di Redis gestita di Azure.

  5. Se si usa TLS/SSL nell'istanza della cache, è necessario aggiungere i --tls parametri e --tls-skip-verify al comando memtier_benchmark.

  6. memtier_benchmark usa la porta 6379 per impostazione predefinita. Usare il parametro per eseguire l'override -p 10000 di questa impostazione, perché AMR usa invece la porta 10000.

  7. Per tutte le istanze di Redis gestite di Azure usando i criteri del cluster OSS, è necessario aggiungere il --cluster-mode parametro al comando memtier. Le istanze AMR che usano i criteri del cluster enterprise possono essere considerate come cache non cluster e non richiedono questa impostazione.

  8. Avviare memtier_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 Memtier.

Raccomandazioni per il benchmarking

  • Se non si ottengono le prestazioni necessarie, provare a passare a un livello più avanzato. Il livello bilanciato ha in genere il doppio di vCPU come livello ottimizzato per la memoria e il livello ottimizzato per il calcolo ha in genere il doppio di vCPU come livello bilanciato. Poiché Redis gestito di Azure è basato su Redis Enterprise anziché su Redis della community, il processo Redis principale è in grado di usare più vCPU. Di conseguenza, le istanze con più vCPU hanno prestazioni di velocità effettiva notevolmente migliori.

  • La scalabilità fino a dimensioni di memoria maggiori aggiunge anche più vCPU, aumentando le prestazioni. Tuttavia, la scalabilità fino a dimensioni di memoria maggiori è in genere meno efficace rispetto all'uso di un livello più efficiente. Per una suddivisione dettagliata delle vCPU disponibili per ogni dimensione e livello, vedere Livelli e SKU a colpo d'occhio .

  • Il benchmarking del livello Flash Optimized 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 quasi veloci come altre istanze di Redis gestite di Azure, ma le chiavi sul disco flash NVMe sono più lente. Poiché il livello Ottimizzato per Flash inserisce in modo intelligente le chiavi più usate in DRAM, assicurarsi che la configurazione del benchmark corrisponda all'utilizzo effettivo previsto.

  • L'uso di TLS/SSL riduce le prestazioni della velocità effettiva, ma è altamente consigliato come procedura consigliata per la produzione.

  • È essenziale prima compilare l'istanza di Redis con i dati prima del benchmarking. Il benchmarking in una cache vuota produce risultati molto migliori rispetto a quelli visualizzati in pratica.

  • Il numero di connessioni usate ha un effetto significativo sul benchmark. L'uso di troppe connessioni inizia a ridurre le prestazioni della cache. L'uso di troppe connessioni non dimostra le prestazioni complete della cache. È consigliabile configurare il numero di connessioni in base alle esigenze effettive dell'applicazione. Si determina il numero totale di connessioni moltiplicando il numero di client per il numero di thread.

  • La configurazione della pipeline ha un effetto significativo sui test delle prestazioni. Se si imposta l'impostazione della pipeline su un valore maggiore, si noterà una maggiore velocità effettiva, ma una latenza peggiore. Per altre informazioni, vedere pipelining.

esempi di memtier_benchmark

Nota

Questo esempio mostra il benchmarking in un'istanza X3 ottimizzata per il calcolo usando i criteri del cluster OSS e TLS.

Configurazione preliminare del test: preparare l'istanza della cache con i dati necessari per il test. Il caricamento dell'istanza con dati garantisce che i risultati riflettano in modo più accurato le condizioni reali. Il {number-of-keys} parametro deve essere determinato dalle dimensioni dell'istanza AMR e dalle dimensioni di ogni chiave. Una buona regola generale consiste nel riempire l'istanza di circa il 75% pieno, tenendo conto dei buffer. È possibile usare questa formula: numberOfKeysToSet = (<TotalCacheSizeInBytes> * 0.75) / (1024 + 300). Ad esempio, se si esegue il benchmarking in un'istanza X3 ottimizzata per il calcolo, usando dimensioni di chiave a 1.024 byte, come illustrato in precedenza, questo implica {number-of-keys} = (3 * 1000000000 * 0.75) / (1024 + 300). Il risultato è uguale a circa 1.699.396 chiavi.

memtier_benchmark -h {your-cache-name}.{region}.redis.azure.net -p 10000 -a {your-access-key} --hide-histogram --pipeline=10 -clients=50 -threads=6 --key-maximum=1699396 -n allkeys --key-pattern=P:P --ratio=1:0 -data-size=1024 --tls --cluster-mode

Nota

In questo esempio vengono usati i --tlsflag , --tls-skip-verifye --cluster-mode . Non sono necessari se si usa Redis gestito di Azure in modalità non TLS o se si usano rispettivamente i criteri del cluster Enterprise.

Per testare la velocità effettiva: questo comando testa le richieste GET con pipeline con payload 1k. Usare questo comando per testare la velocità effettiva di lettura prevista dall'istanza della cache. In questo esempio si presuppone che si usi TLS e i criteri del cluster OSS. Il --key-pattern=R:R parametro garantisce che le chiavi siano accessibili in modo casuale, aumentando il realismo del benchmark. Questo test viene eseguito per cinque minuti.

memtier_benchmark -h {your-cache-name}.{region}.redis.azure.net -p 10000 -a {your-access-key} --hide-histogram --pipeline=10 -clients=50 -threads=6 -d 1024 --key-maximum=1699396 --key-pattern=R:R --ratio=0:1 --distinct-client-seed --test-time=300 --json-out-file=test_results.json --tls --tls-skip-verify --cluster-mode

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 istanze di Redis gestite di Azure. È stato usato memtier_benchmark da una macchina virtuale di Azure IaaS con l'endpoint Redis gestito di Azure, usando i comandi memtier illustrati nella sezione degli esempi di memtier_benchmark. I numeri di velocità effettiva sono solo per i comandi GET. In genere, i comandi SET hanno una velocità effettiva inferiore. Le prestazioni reali variano in base alla configurazione e ai comandi di Redis. Questi numeri vengono forniti come punto di riferimento, non come garanzia.

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. È possibile che si verifichino risultati migliori o diversi, soprattutto con la larghezza di banda di rete.

Redis gestito di Azure offre una scelta di criteri del 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 una maggiore velocità effettiva. È 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. Per la tabella dei criteri del cluster OSS, vengono fornite due configurazioni di benchmarking:

  • 300 connessioni (50 client e 6 thread)
  • 2.500 connessioni (50 client e 50 thread)

I secondi benchmark vengono forniti perché 300 connessioni non sono sufficienti per illustrare completamente le prestazioni delle istanze della cache più grandi.

Di seguito sono riportate le operazioni GET al secondo sul payload 1 kB per le istanze AMR lungo il numero di connessioni client usate per il benchmarking. Tutti i numeri sono stati calcolati per le istanze AMR con connessioni SSL e la larghezza di banda di rete viene registrata in Mbps.

Criteri del cluster OSS

Dimensioni in GB vCPU/Network BW/Memory Optimized vCPU/Network BW/Balanced vCPU/Network BW/Compute Optimized
1 - 2/5,000/103,500 -
3 - 2/2,000/104,500 4/10,000/221,100
6 - 2/2,000/106,500 4/10,000/210,850
12 2/2,000/106,000 4/4,000/223,900 8/12,500/499,900
24 4/4,000/227,800 8/8,000/495,300 16/12,500/485,920
60 8/8,000/496,000 16/10,000/476,500 32/16,000/454,200
120 16/10,000/476,200 32/16,000/462,200 64/28,000/463,800

Criteri del cluster Enterprise

Dimensioni in GB vCPU/Network BW/Memory Optimized vCPU/Network BW/Balanced vCPU/Network BW/Compute Optimized
1 - 2/5,000/56,900 -
3 - 2/2,000/56,900 4/10,000/118,900
6 - 2/2,000/59,200 4/10,000/111,950
12 2/2,000/55,800 4/4,000/118,500 8/12,500/206,500
24 4/4,000/122,000 8/8,000/205,500 16/12,500/294,700
60 8/8,000/208,100 16/10,000/293,400 32/16,000/441,400
120 16/10,000/285,600 32/16,000/451,700 64/28,000/516,200