效能測試

  • 發行項

測試 Redis 實例的效能可能是一項複雜的工作。 Redis 實例的效能可能會根據參數而有所不同，例如客戶端數目、數據值的大小，以及是否使用管線。 您也可以在優化輸送量或延遲之間取捨。

幸運的是，有數個工具可讓 Redis 更容易進行基準檢驗。 其中兩個最受歡迎的工具是 redis-benchmark 和 memtier-benchmark。 本文著重於 redis-benchmark。

如何使用 redis-benchmark 公用程式

  1. 將 開放原始碼 Redis 伺服器安裝到可用來測試的用戶端 VM。 redis 基準檢驗公用程式內建於 開放原始碼 Redis 散發中。 請遵循 Redis 檔，以取得如何安裝 開放原始碼 映像的指示。

  2. 用於測試的用戶端 VM 應該位於 與 Azure Cache for Redis 實例相同的區域中 。

  3. 請確定您使用的用戶端 VM 與 所測試快取實例的計算和頻寬 至少一樣多。

  4. 設定網路 隔離 和 防火牆 設定，以確保用戶端 VM 能夠存取 Azure Cache for Redis 實例。

  5. 如果您在快取實例上使用 TLS/SSL，您必須將 參數新增--tls至 redis-benchmark 命令，或使用 stunnel 之類的 Proxy。

  6. Redis-benchmark 預設會使用埠 6379。 -p使用 參數覆寫此設定。 如果您使用 SSL/TLS（連接埠 6380）或使用企業層（連接埠 10000），則需要使用 -p。

  7. 如果您使用使用叢 集的 Azure Cache for Redis 實例，您必須將 參數新增 --cluster 至命令 redis-benchmark 。 使用 企業叢集原則 的企業層快取可以視為非叢集快取，而且不需要此設定。

  8. 從 VM 的 CLI 或殼層啟動 redis-benchmark 。 如需如何設定和執行工具的指示，請參閱 redis-benchmark 檔和redis-benchmark 範例 小節。

基準檢驗建議

  • 請務必不僅在穩定狀態條件下測試快取的效能。 在故障轉移條件下進行測試，並在該時間測量快取上的CPU/伺服器負載。 您可以重新啟動 主要節點來啟動故障轉移。 在故障轉移條件下進行測試可讓您在故障轉移條件期間查看應用程式的輸送量和延遲。 故障轉移可能發生在更新期間或非計劃性事件期間。 在理想情況下，即使故障轉移期間，您也不想看到 CPU/伺服器負載尖峰達到 80% 以上，因為可能會影響效能。

  • 請考慮使用 Enterprise 和 進階版 層 Azure Cache for Redis 實例。 這些快取大小具有較佳的網路等待時間和輸送量，因為它們在較佳的硬體上執行。

  • 企業層通常具有最佳效能，因為 Redis Enterprise 允許核心 Redis 程式利用多個 vCPU。 以 開放原始碼 Redis 為基礎的階層，例如 Standard 和 進階版，只能針對每個分區的 Redis 進程使用一個 vCPU。

  • 企業快閃層的效能評定可能會很困難，因為有些密鑰會儲存在 DRAM 上，而有些金鑰則儲存在 NVMe 快閃磁碟上。 DRAM 基準檢驗上的金鑰幾乎和企業層實例一樣快，但 NVMe 快閃磁碟上的金鑰速度較慢。 由於企業 Flash 層會以智慧方式將最常使用的金鑰放入 DRAM 中，因此請確定您的基準檢驗設定符合您預期的實際使用量。 請考慮使用 -r 參數來隨機存取哪些金鑰。

  • 使用 TLS/SSL 可降低輸送量效能，這在下表的基準檢驗數據範例中可以清楚地看到。

  • 即使 Redis 伺服器是單個線程，但相應增加通常會改善輸送量效能。 系統進程可以使用額外的 vCPU，而不是共用 Redis 進程所使用的 vCPU。 相應增加對於 Enterprise 和 Enterprise Flash 層特別有幫助，因為 Redis Enterprise 不限於單個線程。 如需詳細資訊，請參閱 企業層最佳做法。

  • 在 進階版 層上，通常會建議在相應增加之前相應放大、叢集。 叢集可讓 Redis 伺服器透過分區化數據來使用更多 vCPU。 在此案例中新增分區時，輸送量應該大致上增加線性。

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 的企業或企業快取輸送量： 具有 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

效能效能評定數據的範例

下表顯示測試各種標準、進階版、企業和企業快取大小時觀察到的最大輸送量值。 我們從 IaaS Azure VM 針對 Azure Cache for Redis 端點使用 redis-benchmark 。 輸送量數位僅適用於 GET 命令。 一般而言，SET 命令的輸送量較低。 這些數位已針對輸送量進行優化。 可接受的延遲條件下的實際輸送量可能會較低。

下列組態可用來對基本、標準和 進階版 層的輸送量進行基準檢驗：

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50  -c 50

警告

這些值不保證，而且這些數字沒有 SLA。 強烈建議您 執行自己的效能測試 ，以判斷應用程式的正確快取大小。 隨著我們定期公佈較新的結果，這些數字可能會變更。

重要

Microsoft 會定期更新快取實例中使用的基礎 VM。 這可以將效能特性從快取變更為快取，以及從區域變更為區域。 此頁面上的範例基準檢驗值會反映單一區域中較舊的快取硬體。 在實務上，您可能會看到更好的或不同的結果。

標準層

執行個體 大小 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

進階層

執行個體 大小 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 和 Enterprise Flash 層

企業和企業 Flash 層提供叢集原則的選擇： 企業 和 OSS。 企業叢集原則是較簡單的設定，不需要用戶端支援叢集。 另一方面，OSS 叢集原則會使用 Redis 叢集通訊協議 來支援更高的輸送量。 在大部分情況下，我們建議使用 OSS 叢集原則。 如需詳細資訊，請參閱 Enterprise 上的叢集。 下表顯示這兩個叢集原則的基準檢驗。

下列組態可用來對企業和企業快閃層的輸送量進行效能評定：

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) 不含 SSL 的每秒 GET 要求數 （1-kB 值大小） 每秒具有 SSL 的 GET 要求數 （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) 不含 SSL 的每秒 GET 要求數 （1-kB 值大小） 每秒具有 SSL 的 GET 要求數 （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

企業和企業 Flash 層 - 相應放大

除了藉由移至較大的快取大小來相應增加，您也可以相應 放大來提升效能。在企業層中，相應放大稱為增加 快取實例的容量 。 根據預設，快取實例的容量為主要節點和復本節點。 容量為 4 的企業快取實例表示實例已由兩個因素相應放大。 相應放大可讓您存取更多記憶體和 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

下一步