Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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
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.
La macchina virtuale client usata per i test deve trovarsi nella stessa area dell'istanza di Redis Gestito di Azure (AMR).
Assicurarsi che la macchina virtuale client usata abbia almeno la larghezza di banda e di calcolo usata per l'istanza della cache testata.
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 Gestito di Azure.
Se si usa TLS/SSL nell'istanza della cache, è necessario aggiungere i parametri
--tlse--tls-skip-verifyal comando memtier_benchmark.memtier_benchmarkusa la porta 6379 per impostazione predefinita. Usare il parametro-p 10000per eseguire l'override di questa impostazione, perché AMR usa invece la porta 10000.Per tutte le istanze di Redis Gestito di Azure che usano i criteri del cluster OSS, è necessario aggiungere il parametro
--cluster-modeal comando memtier. Le istanze di AMR che usano i criteri di clustering Enterprise possono essere considerate come cache non cluster e non richiedono questa impostazione.Avviare
memtier_benchmarkdall'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, mentre il livello Ottimizzato per il Calcolo ha in genere il doppio di vCPU rispetto al 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 Ottimizzato per 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 quasi veloci come altre istanze di Redis Gestito 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 più indicata per la produzione.
È essenziale 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. Il numero totale di connessioni viene calcolato 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 la pipeline su un valore maggiore, si noterà una maggiore velocità effettiva, ma una latenza peggiore. Per altre informazioni, vedere pipelining.
esempi di memtier_benchmark
Annotazioni
Questo esempio mostra il benchmarking in un'istanza X3 Ottimizzata per il Calcolo usando i criteri del cluster OSS e TLS.
Configurazione pre-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 parametro {number-of-keys} deve essere determinato dalle dimensioni dell'istanza AMR e dalle dimensioni di ogni chiave. Una buona regola generale consiste nel riempire l'istanza fino a 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
Annotazioni
In questo esempio vengono usati i flag --tls, --tls-skip-verify e --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 parametro --key-pattern=R:R 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
La tabella seguente mostra una velocità effettiva ottimale osservata durante il test di varie dimensioni delle istanze di Redis gestite di Azure con un carico di lavoro di tutti i comandi di lettura e il payload di 1 KB. Il carico di lavoro è lo stesso in tutti gli SKU, ad eccezione del conteggio delle connessioni, ovvero thread e conteggi client diversi richiesti da memtier_benchmark. Il numero di connessioni viene scelto per SKU per sfruttare in modo ottimale l'istanza di Redis gestita di Azure. Si è utilizzato 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. Le prestazioni possono variare per vari motivi, ad esempio numero di connessioni diverse, dimensioni del payload, comandi eseguiti e così via.
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 un hardware di cache di una generazione particolare in una regione unica. È possibile che vengano visualizzati risultati diversi in pratica, 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 velocità effettive più elevate. È consigliabile usare i criteri del cluster OSS nella maggior parte dei casi, soprattutto quando sono necessarie prestazioni elevate. Per altre informazioni, vedere Clustering.
| Dimensioni in GB | Richieste GET al secondo per Ottimizzato per la Memoria | Richieste GET al secondo per Bilanciato | Richieste GET per secondo per Calcolo Ottimizzato |
|---|---|---|---|
| 0,5 | - | 120.000 | - |
| 1 | - | 120.000 | - |
| 3 | - | 230.000 | 480.000 |
| 6 | - | 230.000 | 480.000 |
| 12 | 230.000 | 480.000 | 810.000 |
| 24 | 480.000 | 810.000 | 1,600,000 |
| 60 | 810.000 | 1,500,000 | 2.000.000 |
| 120 | 1,500,000 | 2.000.000 | 2.900.000 |
La tabella seguente elenca il numero di connessioni basato sul conteggio dei thread di memtier_benchmark e sul numero di client utilizzato per produrre i dati di throughput. Come accennato in precedenza, la modifica del numero di connessioni potrebbe comportare prestazioni variabili.
| Dimensioni in GB | Client/Thread/Conteggio delle connessioni per Ottimizzato per la Memoria | Client/Thread/Conteggio connessioni per Bilanciato | Client/Thread/Numero di connessioni per Ottimizzato per il Calcolo |
|---|---|---|---|
| 0,5 | - | 10/4/40 | - |
| 1 | - | 10/4/40 | - |
| 3 | - | 10/4/40 | 10/8/80 |
| 6 | - | 10/4/40 | 10/8/80 |
| 12 | 10/4/40 | 10/8/80 | 10/16/160 |
| 24 | 10/8/80 | 10/16/160 | 20/16/320 |
| 60 | 10/16/160 | 20/16/320 | 20/32/640 |
| 120 | 20/16/320 | 20/32/640 | 20/64/1280 |