Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Menguji performa instans Redis bisa menjadi tugas yang rumit. Performa instans Redis dapat bervariasi berdasarkan parameter seperti jumlah klien, ukuran nilai data, dan apakah pipelining sedang digunakan. Juga dapat terjadi tradeoff antara mengoptimalkan throughput atau latensi.
Untungnya, ada beberapa alat untuk membuat tolok ukur Redis lebih mudah. Dua alat paling populer adalah redis-benchmark dan memtier-benchmark . Artikel ini berfokus pada memtier_benchmark, sering disebut memtier.
Cara menggunakan utilitas memtier_benchmark
Instal memtier pada komputer virtual klien (VM) yang dapat Anda gunakan untuk pengujian. Ikuti dokumentasi Memtier untuk petunjuk tentang cara menginstal gambar sumber terbuka.
Komputer virtual klien (VM) yang digunakan untuk pengujian harus berada di wilayah yang sama dengan instans Azure Managed Redis (AMR) Anda.
Pastikan VM klien yang Anda gunakan memiliki setidaknya komputasi dan bandwidth sebanyak instans cache yang sedang diuji.
Konfigurasikan pengaturan isolasi jaringan dan firewall VM Anda untuk memastikan bahwa VM klien dapat mengakses instans Azure Managed Redis Anda.
Jika Anda menggunakan TLS/SSL pada instans cache, Anda perlu menambahkan
--tlsparameter dan--tls-skip-verifyke perintah memtier_benchmark Anda.memtier_benchmarkmenggunakan port 6379 secara default.-p 10000Gunakan parameter untuk mengambil alih pengaturan ini, karena AMR menggunakan port 10000 sebagai gantinya.Untuk semua instans Azure Managed Redis menggunakan kebijakan kluster OSS, Anda perlu menambahkan
--cluster-modeparameter ke perintah memtier Anda. Instans AMR yang menggunakan kebijakan kluster Enterprise dapat diperlakukan sebagai cache non-kluster dan tidak memerlukan pengaturan ini.Luncurkan
memtier_benchmarkdari CLI atau shell VM. Untuk petunjuk tentang cara mengonfigurasi dan menjalankan alat, lihat dokumentasi Memtier.
Rekomendasi tolok ukur
Jika Anda tidak mendapatkan performa yang Anda butuhkan, coba tingkatkan skala ke tingkat yang lebih canggih. Tingkat Seimbang biasanya memiliki vCPU dua kali lebih banyak dari tingkat Memori yang Dioptimalkan, dan tingkat Komputasi yang Dioptimalkan biasanya memiliki vCPU dua kali lebih banyak dari tingkat Seimbang. Karena Azure Managed Redis dibangun di Redis Enterprise daripada Redis komunitas, proses Redis inti dapat menggunakan beberapa vCPU. Akibatnya, instans dengan lebih banyak vCPU memiliki performa throughput yang jauh lebih baik.
Meningkatkan skala ke ukuran memori yang lebih besar juga menambahkan lebih banyak vCPU, meningkatkan performa. Namun, meningkatkan skala ke ukuran memori yang lebih besar biasanya kurang efektif daripada menggunakan tingkat yang lebih berkinerja. Lihat Tingkatan dan SKU secara sekilasuntuk perincian terperinci dari vCPU yang tersedia untuk setiap ukuran dan tingkatan.
Tolok ukur tingkat Flash Optimized bisa sulit karena beberapa kunci disimpan di DRAM sementara beberapa disimpan pada disk flash NVMe. Kunci pada tolok ukur DRAM hampir secepat instans Azure Managed Redis lainnya, tetapi kunci pada disk flash NVMe lebih lambat. Karena tingkat Flash Optimized dengan cerdas menempatkan kunci yang paling banyak digunakan ke DRAM, pastikan konfigurasi tolok ukur Anda cocok dengan penggunaan aktual yang Anda harapkan.
Menggunakan TLS/SSL mengurangi performa throughput, tetapi sangat direkomendasikan sebagai praktik terbaik produksi.
Sangat penting untuk terlebih dahulu mengisi instans Redis dengan data sebelum melakukan tolok ukur. Tolok ukur pada cache kosong menghasilkan hasil yang jauh lebih baik daripada yang Anda lihat dalam praktik.
Jumlah koneksi yang digunakan memiliki efek signifikan pada tolok ukur. Menggunakan terlalu banyak koneksi mulai menurunkan performa cache. Menggunakan terlalu sedikit koneksi tidak menunjukkan performa penuh cache. Sebaiknya konfigurasikan jumlah koneksi berdasarkan kebutuhan aplikasi Anda yang sebenarnya. Anda menentukan jumlah total koneksi dengan mengalikan jumlah klien dengan jumlah utas.
Konfigurasi alur memiliki efek signifikan pada pengujian performa. Jika Anda mengatur pengaturan alur menjadi lebih besar, Anda akan melihat lebih banyak throughput, tetapi latensi yang lebih buruk. Untuk informasi selengkapnya, lihat alur.
contoh memtier_benchmark
Nota
Contoh ini menunjukkan tolok ukur pada instans Compute Optimized X3 menggunakan kebijakan kluster OSS dan TLS.
Penyiapan pra-pengujian: Siapkan instans cache dengan data yang diperlukan untuk pengujian. Memuat instans dengan data memastikan bahwa hasilnya lebih akurat mencerminkan kondisi dunia nyata. Parameter {number-of-keys} harus ditentukan oleh ukuran instans AMR Anda dan ukuran setiap kunci. Aturan praktis yang baik adalah mengisi instans sekitar 75% penuh, memperhitungkan buffer. Anda bisa menggunakan rumus ini: numberOfKeysToSet = (<TotalCacheSizeInBytes> * 0.75) / (1024 + 300). Misalnya, jika Anda melakukan tolok ukur pada instans Compute Optimized X3, menggunakan ukuran kunci 1.024 byte, seperti yang ditunjukkan sebelumnya, yang menyiratkan {number-of-keys} = (3 * 1000000000 * 0.75) / (1024 + 300). Hasilnya sama dengan sekitar 1.699.396 kunci.
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
Contoh ini menggunakan --tlsbendera , --tls-skip-verify, dan --cluster-mode . Anda tidak memerlukan ini jika Anda menggunakan Azure Managed Redis dalam mode non-TLS atau jika Anda menggunakan kebijakan kluster Enterprise, masing-masing.
Untuk menguji throughput: Perintah ini menguji permintaan GET yang disalurkan dengan payload 1k. Gunakan perintah ini untuk menguji berapa banyak throughput baca yang diharapkan dari instans cache Anda. Contoh ini mengasumsikan Anda menggunakan TLS dan kebijakan kluster OSS. Parameter --key-pattern=R:R memastikan bahwa kunci diakses secara acak, meningkatkan realisme tolok ukur. Pengujian ini berjalan selama lima menit.
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
Contoh data tolok ukur performa
Tabel di bawah ini menunjukkan throughput optimal yang kami amati saat menguji berbagai ukuran instans Azure Managed Redis dengan beban kerja semua perintah baca dan payload 1KB. Beban kerja tersebut sama di seluruh SKU, kecuali untuk jumlah koneksi, yaitu jumlah utas dan klien yang berbeda seperti yang diperlukan oleh memtier_benchmark. Jumlah koneksi dipilih per SKU untuk memanfaatkan instans Azure Managed Redis secara optimal. Kami menggunakan memtier_benchmark dari IaaS Azure VM terhadap titik akhir Azure Managed Redis, menggunakan perintah memtier yang ditunjukkan di bagian contoh memtier_benchmark. Angka throughput hanya untuk perintah GET. Biasanya, perintah SET memiliki throughput yang lebih rendah. Performa dunia nyata bervariasi berdasarkan konfigurasi dan perintah Redis. Angka-angka ini disediakan sebagai titik referensi, bukan jaminan.
Perhatian
Nilai-nilai ini tidak dijamin dan tidak ada SLA untuk angka-angka ini. Kami sangat menyarankan Anda untuk melakukan pengujian performa Anda sendiri untuk menentukan ukuran cache yang tepat untuk aplikasi Anda. Performa dapat bervariasi karena berbagai alasan seperti jumlah koneksi yang berbeda, ukuran payload, perintah yang dijalankan, dll.
Penting
Microsoft secara berkala memperbarui VM yang mendasar yang digunakan dalam instans cache. Ini dapat mengubah karakteristik performa dari cache ke cache dan dari wilayah ke wilayah. Contoh nilai tolok ukur pada halaman ini mencerminkan perangkat keras cache generasi tertentu dalam satu wilayah. Anda mungkin melihat hasil yang berbeda dalam praktiknya, terutama dengan bandwidth jaringan.
Azure Managed Redis menawarkan pilihan kebijakan kluster: Enterprise dan OSS. Kebijakan kluster perusahaan adalah konfigurasi yang lebih sederhana yang tidak mengharuskan klien untuk mendukung pengklusteran. Di sisi lain, kebijakan kluster OSS menggunakan protokol kluster Redis untuk mendukung throughput yang lebih tinggi. Sebaiknya gunakan kebijakan kluster OSS dalam banyak kasus, terutama ketika Anda memerlukan performa tinggi. Untuk informasi selengkapnya, lihat Pengklusteran.
| Ukuran dalam GB | Permintaan GET per detik untuk Memori yang Dioptimalkan | Permintaan GET per detik untuk Balanced | Permintaan GET per detik untuk Compute Optimized |
|---|---|---|---|
| 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 (enam puluh) | 810,000 | 1.500.000 | 2.000.000 |
| 120 | 1.500.000 | 2.000.000 | 2,900,000 |
Tabel berikut mencantumkan jumlah koneksi dalam konteks jumlah thread memtier_benchmark dan jumlah klien yang digunakan untuk menghasilkan nilai throughput. Seperti disebutkan di atas, mengubah jumlah koneksi dapat mengakibatkan berbagai performa.
| Ukuran dalam GB | Klien/Utas/Jumlah Koneksi untuk Memori yang Dioptimalkan | Klien/Utas/Jumlah Koneksi untuk Seimbang | Klien/Rangkaian/Jumlah Koneksi untuk Komputasi Dioptimalkan |
|---|---|---|---|
| 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 (enam puluh) | 10/16/160 | 20/16/320 | 20/32/640 |
| 120 | 20/16/320 | 20/32/640 | 20/64/1280 |