效能測試
測試 Redis 執行個體的效能可能是一項複雜的工作。 Redis 執行個體的效能可能會根據各種參數而有所不同，例如用戶端數目、資料值的大小，以及是否使用管線。 要最佳化輸送量還是延遲，也可能需要取捨。
所幸，有數項工具可讓 Redis 的效能評定更容易進行。 其中兩項最廣為使用的工具是 redis-benchmark 和 memtier-benchmark。 本文聚焦於 redis-benchmark。
如何使用 redis-benchmark 公用程式
將 開放原始碼 Redis 伺服器安裝至用戶端虛擬機（VM），以用於測試。 redis-benchmark 公用程式內建於開放原始碼 Redis 發行版本中。 請參考 Redis 文件，以取得如何安裝開放原始碼映像的指示。
用來進行測試的用戶端 VM 應與您的 Azure Redis 快取執行個體位於相同的區域。
請確定您使用的用戶端 VM 與目前測試的快取執行個體至少有一樣的計算能力和頻寬。
如果您要在快取執行個體上使用 TLS/SSL，則必須將
--tls參數新增至 redis-benchmark 命令，或使用 stunnel 之類的 Proxy。Redis-benchmark依預設會使用連接埠 6379。 請使用-p參數覆寫此設定。 如果您使用 SSL/TLS (連接埠 6380)，或使用企業層 (連接埠 10000)，則需使用-p。如果您所使用的 Azure Cache for Redis 執行個體使用叢集，則必須將
--cluster參數新增至redis-benchmark命令。 使用 叢集 的企業層快取可以視為非叢集快取，而且不需要此設定。從 VM 的 CLI 或殼層啟動
redis-benchmark。 如需如何設定和執行工具的指示，請參閱 redis-benchmark 文件和 redis-benchmark 範例小節。
效能評定建議
切勿僅在穩定狀態條件下測試快取的效能。 「另請在容錯移轉條件下測試」，並在容錯移轉時測量快取上的 CPU/伺服器負載。 您可以重新啟動主要節點，同時啟動容錯移轉。 在容錯移轉條件下測試，讓您可以查看應用程式在容錯移轉期間的輸送量和延遲。 容錯移轉可能發生在更新或非計劃性事件期間。 在理想情況下，即使容錯移轉期間可能影響效能，您也不希望看到 CPU/伺服器負載尖峰超過 80%。
請考慮使用企業層和進階層 Azure Cache for Redis 執行個體。 這些快取大小提供更好的網路延遲和輸送量，因為這些快取在較好的硬體上執行。
企業層通常具有最佳效能，因為 Redis Enterprise 允許核心 Redis 程序使用多個 vCPU。 對於每個分區的 Redis 程序，以開放原始碼 Redis 為基礎的階層 (例如標準與進階) 只能使用一個 vCPU。
Enterprise Flash 層可能難以進行效能評定，因為有些金鑰儲存在 DRAM 上，有些金鑰則儲存在 NVMe 快閃磁碟上。 DRAM 基準上的金鑰幾乎和企業層執行個體一樣快，但 NVMe 快閃磁碟上的金鑰速度則較慢。 由於 Enterprise Flash 層會以智慧方式將最常使用的金鑰放入 DRAM 中，請確定您的基準設定符合您預期的實際使用量。 請考慮使用
-r參數隨機設定要存取的金鑰。使用 TLS/SSL 會降低輸送量效能，這點可從下列表格中的範例基準測試資料明確看出。
即便 Redis 伺服器是單一執行緒，擴大往往可改善輸送量效能。 系統程序可使用額外的 vCPU，而不共用 Redis 程序所使用的 vCPU。 擴大對於企業層和 Enterprise Flash 層特別有幫助，因為 Redis Enterprise 不限於單一執行緒。
在進階層中，通常會建議先進行叢集擴增，再進行擴大。 叢集可讓 Redis 伺服器藉由資料分區化使用更多 vCPU。 在此情況下，新增分區時，輸送量大致上應該會線性增長。
在 C0 和 C1 標準快取上，當內部 Defender 正在 VM 上執行掃描時，伺服器負載可能會出現不是因快取要求增加而導致的短暫峰值。 當每天在這些層級上多次執行內部 Defender 掃描時，要求延遲會更高。 C0 和 C1 層級上的快取只有單一核心可進行多工處理，並將內部 Defender 掃描和 Redis 要求的工作分割處理。 您可以透過使用多個 CPU 核心調整為較高層級供應專案 (例如 C2) 來降低影響。
較高層級上增加的快取大小有助於解決任何延遲問題。 此外，在 C2 層級，可支援多達 2,000 個用戶端連線。
Redis-Benchmark 範例
測試前的設定：準備快取執行個體，包含延遲和輸送量測試所需的資料：
redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t SET -n 10 -d 1024
測試延遲：使用 1k 承載測試 GET 要求：
redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t GET -d 1024 -P 50 -c 4
測試輸送量：使用 1k 承載的管道化 GET 要求：
redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t GET -n 1000000 -d 1024 -P 50 -c 50
若要使用 TLS 測試基本、標準或進階層快取的輸送量：使用 1k 承載的管線處理 GET 要求：
redis-benchmark -h yourcache.redis.cache.windows.net -p 6380 -a yourAccesskey -t GET -n 1000000 -d 1024 -P 50 -c 50 --tls
若要使用 OSS 叢集模式測試沒有 TLS 的企業層或 Enterprise Flash 層快取的輸送量：使用 1k 承載的管線處理 GET 要求：
redis-benchmark -h yourcache.region.redisenterprise.cache.azure.net -p 10000 -a yourAccesskey -t GET -n 1000000 -d 1024 -P 50 -c 50 --cluster
範例效能基準資料
下表顯示在測試各種大小的標準、進階、企業和 Enterprise Flash 層快取時觀察到的最大輸送量值。 我們已針對 Azure Cache for Redis 端點，使用 redis-benchmark IaaS memtier-benchmark Azure VM 並從中。 輸送量數字僅適用於 GET 命令。 一般而言，SET 命令的輸送量較低。 這是經過輸送量最佳化的數字。 可接受的延遲條件下的實際輸送量可能會較低。
警告
這些值並非保證值，也沒有關於這些數字的 SLA。 強烈建議您執行自己的效能測試，以確認您的應用程式適合的快取大小。 隨著我們定期公佈較新的結果，這些數字可能會變更。
重要
Microsoft 會定期更新快取執行個體中使用的基礎 VM。 這可以變更不同快取間和不同區域間的效能特性。 此頁面上的範例效能評定值會反映單一區域中較舊的快取硬體。 在實務上，您可能會看到更好的或不同的結果。
以下是用來對基本、標準和進階層的輸送量進行效能評定的設定：
redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t GET -n 1000000 -d 1024 -P 50 -c 50
標準層 Redis 基準檢驗
| 執行個體 | 大小 | vCPU | 預期的網路頻寬 (Mbps) | 未使用 SSL 的每秒 GET 要求數 (1 kB 值大小) | 使用 SSL 的每秒 GET 要求數 (1 kB 值大小) |
|---|---|---|---|---|---|
| C0 | 250 MB | 共用 | 100 | 15,000 | 7,500 |
| C1 | 1 GB | 1 | 500 | 38,000 | 20,720 |
| C2 | 2.5 GB | 2 | 500 | 41,000 | 37,000 |
| C3 | 6 GB | 4 | 1000 | 100,000 | 90,000 |
| C4 | 13GB | 2 | 500 | 60,000 | 55,000 |
| C5 | 26GB | 4 | 1,000 | 102,000 | 93,000 |
| C6 | 53 GB | 8 | 2,000 | 126,000 | 120,000 |
進階層 Redis 基準檢驗
| 執行個體 | 大小 | vCPU | 預期的網路頻寬 (Mbps) | 未使用 SSL 的每秒 GET 要求數 (1 kB 值大小) | 使用 SSL 的每秒 GET 要求數 (1 kB 值大小) |
|---|---|---|---|---|---|
| P1 | 6 GB | 2 | 1,500 | 180,000 | 172,000 |
| P2 | 13GB | 4 | 3,000 | 350,000 | 341,000 |
| P3 | 26GB | 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 |
重要
中國東部和中國北部區域的 P5 執行個體使用 20 個核心，而不是 32 個核心。
企業層和 Enterprise Flash 層
企業層和 Enterprise Flash 層提供叢集原則的選項：企業和 OSS。 企業叢集原則是較簡單的設定，不需要用戶端支援叢集。 另一方面，OSS 叢集原則會使用 Redis 叢集通訊協定支援更高的輸送量。 多數情況下，我們建議使用 OSS 叢集原則。 如需詳細資訊，請參閱 叢集 。 下表顯示這兩個叢集原則的基準。
以下是用來對企業層和 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
注意
此設定與用來對基本、標準和進階層進行效能評定的設定幾乎完全相同。 不過，先前的設定並未充分利用企業層更高的計算效能。 為了展現完整效能，已在此設定中新增額外的要求和執行緒。
企業叢集原則
| 執行個體 | 大小 | vCPU | 預期的網路頻寬 (Mbps) | GET 每秒沒有 SSL 的要求數 （1-kB 值大小） |
GET 每秒要求 SSL （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 |
OSS 叢集原則
| 執行個體 | 大小 | vCPU | 預期的網路頻寬 (Mbps) | GET 每秒沒有 SSL 的要求數 （1-kB 值大小） |
GET 每秒要求 SSL （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 |
企業層和 Enterprise Flash 層 - 擴增
除了藉由移至較大的快取大小進行擴大，您也可以透過擴增來提升效能。在企業層中，擴增就是增加快取執行個體的容量。 根據預設，快取執行個體的容量為二，即主要節點和複本節點。 容量為四的企業層快取執行個體，表示執行個體已擴增為兩倍。 擴增可讓您存取更多記憶體和 vCPU。 如需核心 Redis 進程在每個快取大小和容量上使用多少個 vCPU 的詳細數據，請參閱 分區化設定。 使用 OSS 叢集原則時，擴增最為有效。
下表顯示 GET 每秒使用不同的容量要求，並使用 SSL 和 1-kB 值大小。
擴增 - 企業叢集原則
| 執行個體 | 容量 2 | 容量 4 | 容量 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 |
| 執行個體 | 容量 3 | 容量 9 |
|---|---|---|
| F300 | 390,000 | 640,000 |
| F700 | 370,000 | 610,000 |
| F1500 | 390,000 | 670,000 |
擴增 - OSS 叢集原則
| 執行個體 | 容量 2 | 容量 4 | 容量 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 |
| 執行個體 | 容量 3 | 容量 9 |
|---|---|---|
| F300 | 1,200,000 | 2,600,000 |
| F700 | 1,200,000 | 2,600,000 |
| F1500 | 1,100,000 | 2,800,000 |