使用 Azure 受控 Redis 進行效能測試 （預覽）
測試 Redis 執行個體的效能可能是一項複雜的工作。 Redis 執行個體的效能可能會根據各種參數而有所不同，例如用戶端數目、資料值的大小，以及是否使用管線。 要最佳化輸送量還是延遲，也可能需要取捨。
所幸，有數項工具可讓 Redis 的效能評定更容易進行。 其中兩項最廣為使用的工具是 redis-benchmark 和 memtier-benchmark。 本文著重於memtier_benchmark，通常稱為 memtier。
如何使用 memtier_benchmark 公用程式
在可用於測試的用戶端虛擬機 （VM） 上安裝 memtier。 請遵循 Memtier 檔，以取得如何安裝 開放原始碼 映射的指示。
用於測試的用戶端虛擬機 （VM） 應位於 與 Azure 受控 Redis （AMR） 實例相同的區域中 。
請確定您使用的用戶端 VM 與目前測試的快取執行個體至少有一樣的計算能力和頻寬。
設定網路 隔離 和 VM 防火牆設定，以確保用戶端 VM 能夠存取您的 Azure 受控 Redis 實例。
如果您在快取實例上使用 TLS/SSL，則必須將 和
--tls-skip-verify參數新增--tls至 memtier_benchmark 命令。memtier_benchmark依預設會使用連接埠 6379。-p 10000使用 參數來覆寫此設定，因為AMR會改用埠 10000。針對使用 OSS 叢集原則的所有 Azure 受控 Redis 實例，您必須將 參數新增
--cluster-mode至 memtier 命令。 使用企業叢集原則的 AMR實例可以視為非叢集 快取，而且不需要此設定。從 VM 的 CLI 或殼層啟動
memtier_benchmark。 如需如何設定和執行工具的指示，請參閱 Memtier 檔。
效能評定建議
如果您未取得所需的效能，請嘗試相應增加至更進階的層級。 平衡層通常會有兩倍於記憶體優化層的 vCPU，而計算優化層通常會有兩倍於平衡層的 vCPU。 由於 Azure 受控 Redis 是以 Redis Enterprise 而非社群 Redis 為基礎所建置，因此核心 Redis 程式能夠利用多個 vCPU。 因此，具有更多 vCPU 的實例具有明顯更好的輸送量效能。
相應增加至較大的記憶體大小也會增加更多 vCPU，以提升效能。 不過，相應增加至較大的記憶體大小通常比使用效能更高的層要低。 如需每個大小和層級可用的 vCPU 詳細明細，請參閱 階層和 SKU 一目了然 。
對 Flash 優化層進行效能評定可能會很困難，因為有些金鑰會儲存在 DRAM 上，而有些金鑰則儲存在 NVMe 快閃磁碟上。 DRAM 基準檢驗上的金鑰幾乎和其他 Azure 受控 Redis 實例一樣快，但 NVMe 快閃磁碟上的密鑰速度較慢。 由於 Flash 優化層會以智慧方式將最常使用的金鑰放入 DRAM 中，因此請確定您的基準檢驗設定符合您預期的實際使用量。
使用 TLS/SSL 可降低輸送量效能，但強烈建議作為生產最佳做法。
在基準檢驗之前，必須先填入 Redis 實例的數據。 對空快取的效能評定會產生比您實際看到的更好的結果。
使用的連線數目對基準檢驗有顯著的影響。 使用太多聯機會開始降低快取的效能。 使用太少的連線不會示範快取的完整效能。 建議您根據實際的應用程式需求來設定連線數目。 您可以藉由將用戶端數目乘以線程數目來判斷連線總數。
管線設定對效能測試有顯著的影響。 如果您將管線設定設為較大，您會看到更多輸送量，但延遲更糟。 如需詳細資訊，請參閱管線。
memtier_benchmark範例
注意
此範例示範使用 OSS 叢集原則和 TLS 在計算優化 X3 實例上的效能評定。
測試前設定：準備快取實例，其中包含測試所需的數據。 使用數據載入實例可確保結果更準確地反映真實世界的情況。 {number-of-keys}參數應該由AMR實例的大小和每個索引鍵的大小來決定。 良好的經驗法則是填滿大約75%的實例，以占緩衝區。 您可以使用此公式： numberOfKeysToSet = (<TotalCacheSizeInBytes> * 0.75) / (1024 + 300)。 例如，如果您要對計算優化 X3 實例進行效能評定，請使用 1,024 位元組的索引鍵大小，如先前所示，這 {number-of-keys} = (3 * 1000000000 * 0.75) / (1024 + 300)表示 。 結果等於大約 1,699,396 個索引鍵。
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
注意
此範例使用 --tls、 --tls-skip-verify和 --cluster-mode 旗標。 如果您在非 TLS 模式中使用 Azure 受控 Redis，或分別使用企業叢集原則，則不需要這些專案。
若要測試輸送量： 此命令會測試具有 1k 承載的管線 GET 要求。 使用此命令來測試快取實例預期多少讀取輸送量。 此範例假設您使用 TLS 和 OSS 叢集原則。 參數 --key-pattern=R:R 可確保隨機存取索引鍵，以增加基準檢驗的現實主義。 此測試會執行五分鐘。
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
範例效能基準資料
下表顯示測試各種 Azure 受控 Redis 實例大小時觀察到的最大輸送量值。 我們從 IaaS Azure VM 對 Azure 受控 Redis 端點使用memtier_benchmark，並利用memtier_benchmark範例一節中顯示的 memtier 命令。 輸送量數字僅適用於 GET 命令。 一般而言，SET 命令的輸送量較低。 真實世界的效能會根據 Redis 組態和命令而有所不同。 這些數位會以參考點的形式提供，而不是保證。
警告
這些值並非保證值，也沒有關於這些數字的 SLA。 強烈建議您執行自己的效能測試，以確認您的應用程式適合的快取大小。 隨著我們定期公佈較新的結果，這些數字可能會變更。
重要
Microsoft 會定期更新快取執行個體中使用的基礎 VM。 這可以變更不同快取間和不同區域間的效能特性。 此頁面上的範例效能評定值會反映單一區域中較舊的快取硬體。 在實務上，您可能會看到更好的或不同的結果，特別是網路頻寬。
Azure 受控 Redis 提供叢集原則的選擇： 企業 和 OSS。 企業叢集原則是較簡單的設定，不需要用戶端支援叢集。 另一方面，OSS 叢集原則會使用 Redis 叢集通訊協議 來支援更高的輸送量。 多數情況下，我們建議使用 OSS 叢集原則。 如需詳細資訊，請參閱 叢集。
下表顯示這兩個叢集原則的基準。 針對 OSS 叢集原則數據表，會提供兩個效能評定設定：
- 300 個連線 （50 個用戶端和 6 個線程）
- 2,500 個連線（50 個用戶端和 50 個線程）
提供第二個基準檢驗是因為 300 個連線不足以完整示範較大快取實例的效能。
以下是AMR實例每秒1 kB承載的 GET 作業輸送量，以及用於基準檢驗的客戶端連線數目。 所有數位都是針對具有 SSL 連線的 AMR 實例計算，且網路頻寬會以 Mbps 來記錄。
OSS 叢集原則
| GB 大小 | vCPU/Network BW/Memory Optimized | vCPU/網路 BW/平衡 | 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 |
企業叢集原則
| GB 大小 | vCPU/Network BW/Memory Optimized | vCPU/網路 BW/平衡 | 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 |