Q: 何時應該啟用非 TLS/SSL 連接埠來連線至 Redis？

Redis 伺服器無法原生支援 TLS，但 Azure Cache for Redis 則可支援。 如果您是連線至 Azure Cache for Redis，且您的用戶端支援 TLS (例如 StackExchange.Redis)，請使用 TLS。 注意 預設會停用新「Azure Cache for Redis」執行個體的非 TLS 連接埠。 如果您的用戶端不支援 TLS，則必須依照 在 Azure Cache for Redis 中設定快取 一文中 存取連接埠 一節的指示來啟用非 TLS 連接埠。 Redis 工具 (例如 redis-cli ) 無法搭配 TLS 連接埠運作，但您可以遵循 宣佈 Redis 預覽版本的 ASP.NET 工作階段狀態供應器 $英文$ 部落格文章中的指示，使用公用程式 (例如 stunnel ) 將工具安全地連線至 TLS 連接埠。 如需下載 Redis 工具的指示，請參閱 如何執行 Redis 命令？ 小節。

Q: 使用常見 Redis 命令時的一些考量為何？

針對需要花很長時間才能完成特定 Redis 命令，除非您充分了解這些命令的結果，否則應避免使用這些命令。 例如，請勿在生產環境中執行 KEYS $英文$ 命令。 視金鑰的數目而定，系統可能需要很長的時間才會傳回。 Redis 是單一執行緒伺服器，並且一次處理一個命令。 如果您在 KEYS 之後還發出其他命令，在 Redis 處理好 KEYS 命令之前，系統將不會處理這些命令。 Redis.io 網站 有它支援的每項作業的時間複雜度詳細資訊。 選取每個命令以查看每個作業的複雜度。 索引鍵大小 - 應該使用較小的索引鍵/值還是較大的索引鍵/值？ 這取決於案例。 如果您的案例需要較大的金鑰，您可以調整 ConnectionTimeout，然後重試值並調整重試邏輯。 從 Redis 伺服器的觀點，較小的值即表示有較佳的效能。 這些考量不表示您無法在 Redis 中儲存較大的值；您必須注意下列考量。 延遲會比較高。 如果您的其中一組資料較大，而另外一組較小，您可以使用多個 ConnectionMultiplexer 執行個體。 使用不同組合的逾時和重試值來設定每個值，如先前的 StackExchange.Redis 設定選項的作用為何 小節所述。

Q: 如何效能評定和測試我快取的效能？

啟用快取診斷 ，以 監視 您快取的健全狀況。 您可以在 Azure 入口網站中檢視度量，也可以使用您選擇的工具 下載並檢閱 它們。 您可以使用 redis-benchmark.exe 對 Redis 伺服器進行負載測試。 確定負載測試用戶端與「Azure Redis 快取」位於相同的區域。 使用 redis-cli.exe，並使用 INFO 命令來監視快取。 如果您的負載造成記憶體分散嚴重，則應該擴大為較大的快取大小。 如需下載 Redis 工具的指示，請參閱 如何執行 Redis 命令？ 小節。 以下是使用 redis-benchmark.exe 的一些範例。 請從與您快取位於相同區域的 VM 執行這些命令，來取得精確的結果。cache-development-faq.yml 使用 1k 承載測試進行管線處理的 SET 要求 redis-benchmark.exe -h **yourcache**.redis.cache.windows.net -a **yourAccesskey** -t SET -n 1000000 -d 1024 -P 50 使用 1k 承載測試進行管線處理的 GET 要求。 注意 請先執行上面所示的 SET 測試來填入快取 redis-benchmark.exe -h **yourcache**.redis.cache.windows.net -a **yourAccesskey** -t GET -n 1000000 -d 1024 -P 50

Q: 使用 StackExchange.Redis 時啟用伺服器 GC 在用戶端上取得更多輸送量

啟用伺服器 GC 可以最佳化用戶端，並在使用 StackExchange.Redis 時提供較佳的效能和輸送量。 如需有關伺服器 GC，以及如何加以啟用的詳細資訊，請參閱下列文件： 啟用伺服器 GC 記憶體回收的基本概念 Garbage Collection and Performance (記憶體回收與效能)

Q: 連線相關的效能考量

每個定價層都有不同的用戶端連線、記憶體和頻寬的限制。 雖然每個快取大小都可允許以某個數目為「上限」 的連線數，但是針對 Redis 所進行的每個連線都會有相關聯的額外負荷。 此類額外負荷的其中一個範例，是因 TLS/SSL 加密而產生的 CPU 與記憶體使用量。 所指定快取大小的連線數上限是假設快取負載情況為輕度。 如果來自連線額外負荷的負載「加上」 來自用戶端作業的負載超過系統的容量，則即使您尚未超出目前快取大小的連線限制，快取也可能會發生容量問題。 如需有關每個層級之不同連線限制的詳細資訊，請參閱 Azure Redis 快取價格 。 如需有關連線及其他預設組態的詳細資訊，請參閱 預設 Redis 伺服器組態 。

Question 1

何時應該啟用非 TLS/SSL 連接埠來連線至 Redis？

Accepted Answer

Redis 伺服器無法原生支援 TLS，但 Azure Cache for Redis 則可支援。如果您是連線至 Azure Cache for Redis，且您的用戶端支援 TLS (例如 StackExchange.Redis)，請使用 TLS。

注意

預設會停用新「Azure Cache for Redis」執行個體的非 TLS 連接埠。如果您的用戶端不支援 TLS，則必須依照在 Azure Cache for Redis 中設定快取一文中存取連接埠一節的指示來啟用非 TLS 連接埠。

Redis 工具 (例如 redis-cli) 無法搭配 TLS 連接埠運作，但您可以遵循宣佈 Redis 預覽版本的 ASP.NET 工作階段狀態供應器 $英文$ 部落格文章中的指示，使用公用程式 (例如 stunnel) 將工具安全地連線至 TLS 連接埠。

如需下載 Redis 工具的指示，請參閱如何執行 Redis 命令？小節。

Question 2

生產環境的最佳作法有哪些？

Accepted Answer

StackExchange.Redis 最佳作法
組態和概念
效能測試

StackExchange.Redis 最佳作法

將 AbortConnect 設定為 false，然後讓 ConnectionMultiplexer 自動重新連線。
使用單一長時間存留的 ConnectionMultiplexer 執行個體，而不針對每個要求建立新的連線。如需如何管理連線的範例，請參閱使用 RedisConnection 連線至快取中的 RedisConnection 類別。
Redis 在值越小時運作得最好，因此請考慮將較大的資料切分成多個金鑰。在此 Redis 討論中，100kb 就算很大。如需詳細資訊，請參閱最佳做法開發。
設定您的執行緒集區設定以避免逾時。
使用至少 5 秒的預設 connectTimeout。此間隔可讓 StackExchange.Redis 在發生網路短暫中斷的情況下，有足夠的時間重新建立連線。
請注意與您所執行之不同作業相關聯的效能成本。例如， KEYS 命令是一種 O(n) 作業，應該盡量避免。 Redis.io 網站有它支援的每項作業的時間複雜度詳細資訊。選取每個命令以查看每個作業的複雜度。

組態和概念

為生產環境系統使用標準或進階層。基本層是一個單一節點的系統，沒有資料複寫也沒有 SLA。此外，請至少使用 C1 快取。 C0 快取通常用於簡單的開發/測試案例。
請記住，Redis 是一種 記憶體內部 資料存放區。如需詳細資訊，請參閱針對 Azure Cache for Redis 中的資料遺失進行疑難排解，如此您就能掌握可能發生資料遺失的情況。
開發系統，讓系統可以處理因修補和容錯移轉所造成的連線短暫中斷。

效能測試

先使用 redis-benchmark.exe ，在撰寫您自己的效能測試之前了解可能的輸送量。因為 redis-benchmark 不支援 TLS，您必須在執行測試之前透過 Azure 入口網站啟用非 TLS 連接埠。例如，參閱如何效能評定和測試我快取的效能？
用來進行測試的用戶端 VM 應該與您的「Azure Redis 快取」執行個體位於相同的區域。
我們建議為您的用戶端使用 Dv2 VM 系列，因為此系列有更好的硬體，能提供最佳的結果。
請確定您選擇的用戶端 VM 與您進行測試的快取至少有一樣多的運算和頻寬能力。
如果您是在 Windows 上，請在用戶端電腦上啟用 VRSS。參閱此處了解詳細資訊。
進階層 Redis 執行個體會有比較好的網路延遲和輸送量，因為其是在比較好的硬體 (CPU 和網路) 上執行。

Question 3

使用常見 Redis 命令時的一些考量為何？

Accepted Answer

針對需要花很長時間才能完成特定 Redis 命令，除非您充分了解這些命令的結果，否則應避免使用這些命令。例如，請勿在生產環境中執行 KEYS $英文$ 命令。視金鑰的數目而定，系統可能需要很長的時間才會傳回。 Redis 是單一執行緒伺服器，並且一次處理一個命令。如果您在 KEYS 之後還發出其他命令，在 Redis 處理好 KEYS 命令之前，系統將不會處理這些命令。 Redis.io 網站有它支援的每項作業的時間複雜度詳細資訊。選取每個命令以查看每個作業的複雜度。
索引鍵大小 - 應該使用較小的索引鍵/值還是較大的索引鍵/值？這取決於案例。如果您的案例需要較大的金鑰，您可以調整 ConnectionTimeout，然後重試值並調整重試邏輯。從 Redis 伺服器的觀點，較小的值即表示有較佳的效能。
這些考量不表示您無法在 Redis 中儲存較大的值；您必須注意下列考量。延遲會比較高。如果您的其中一組資料較大，而另外一組較小，您可以使用多個 ConnectionMultiplexer 執行個體。使用不同組合的逾時和重試值來設定每個值，如先前的 StackExchange.Redis 設定選項的作用為何小節所述。

Question 4

如何效能評定和測試我快取的效能？

Accepted Answer

啟用快取診斷，以監視您快取的健全狀況。您可以在 Azure 入口網站中檢視度量，也可以使用您選擇的工具下載並檢閱它們。
您可以使用 redis-benchmark.exe 對 Redis 伺服器進行負載測試。
確定負載測試用戶端與「Azure Redis 快取」位於相同的區域。
使用 redis-cli.exe，並使用 INFO 命令來監視快取。
如果您的負載造成記憶體分散嚴重，則應該擴大為較大的快取大小。
如需下載 Redis 工具的指示，請參閱如何執行 Redis 命令？小節。

以下是使用 redis-benchmark.exe 的一些範例。請從與您快取位於相同區域的 VM 執行這些命令，來取得精確的結果。cache-development-faq.yml

使用 1k 承載測試進行管線處理的 SET 要求

redis-benchmark.exe -h **yourcache**.redis.cache.windows.net -a **yourAccesskey** -t SET -n 1000000 -d 1024 -P 50
使用 1k 承載測試進行管線處理的 GET 要求。

注意

請先執行上面所示的 SET 測試來填入快取

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

Question 5

執行緒集區成長的重要詳細資料

Accepted Answer

CLR 執行緒集區有兩種類型的執行緒：「背景工作」和「I/O 完成連接埠」(IOCP) 執行緒。

背景工作執行緒是用於處理 Task.Run(…) 或 ThreadPool.QueueUserWorkItem(…) 方法之類的作業。需要在背景執行緒上開啟工作時，CLR 中的各種元件也會使用這些執行緒。
發生非同步 IO (例如從網路讀取) 時，會使用 IOCP 執行緒。

執行緒集區可視需要提供新背景工作執行緒或 I/O 完成執行緒 (而不需要任何節流)，直到它到達每個類型執行緒的「最低」設定。根據預設，執行緒的數目下限設為系統上的處理器數目。

一旦現有 (忙碌) 執行緒的數量達到執行緒集區的「最低」執行緒數目，執行緒集區會以每 500 毫秒將一個新執行緒插入執行緒的速率節流。通常，如果您的系統需要 IOCP 執行緒的工作暴增，系統將可快速處理該工作。不過，如果高載超過設定的「最低」設定，部分工作的處理會發生一些延遲，因為 ThreadPool 會等待下列兩種情況之一發生：

現有的執行緒變得可用來處理工作。
在過去 500 毫秒內沒有現有的執行緒變得可用，且會建立一個新的執行緒。

基本上，當忙碌執行緒數目超過「最低」執行緒數量時，在應用程式處理網路流量之前，您可能需要為 500 毫秒延遲支付費用。此外，當現有的執行緒處於閒置的時間超過 15 秒，系統會加以清除，而且這個增長和壓縮的循環可能會重複。

如果我們查看來自 StackExchange.Redis (組建 1.0.450 或更新版本) 的範例錯誤訊息，我們會看到其現在會列印 ThreadPool 統計資料。請參閱下面的 IOCP 和 WORKER 詳細資料。

System.TimeoutException: Timeout performing GET MyKey, inst: 2, mgr: Inactive,
queue: 6, qu: 0, qs: 6, qc: 0, wr: 0, wq: 0, in: 0, ar: 0,
IOCP: (Busy=6,Free=994,Min=4,Max=1000),
WORKER: (Busy=3,Free=997,Min=4,Max=1000)

如上述範例所示，您可以看到 IOCP 執行緒有六個忙碌執行緒，而系統設定所允許的最低執行緒為四個。在此情況下，用戶端就可能會看到兩個 500 毫秒延遲，因為 6 > 4。

注意

如果 IOCP 或 WORKER 執行緒的成長發生節流，StackExchange.Redis 可能會發生逾時。

建議

經由這項資訊，我們強烈建議客戶將 IOCP 和背景工作執行緒的「最低」組態值設定成大於預設值的數值。對於這個值應該為何，我們無法提供一體適用的指引，因為某個應用程式的適用值對另一個應用程式來說有可能太高或太低。此設定也會影響複雜應用程式其他部分的效能，因此每位客戶需要微調此設定來滿足其特定需求。 200 或 300 是好的起點，那麼請測試並視需要調整。

如何設定這項設定：

建議使用 global.asax.cs 中的 ThreadPool.SetMinThreads (...) 方法，以程式設計方式變更這項設定。例如：
```
private readonly int minThreads = 200;
void Application_Start(object sender, EventArgs e)
{
    // Code that runs on application startup
    AreaRegistration.RegisterAllAreas();
    RouteConfig.RegisterRoutes(RouteTable.Routes);
    BundleConfig.RegisterBundles(BundleTable.Bundles);
    ThreadPool.SetMinThreads(minThreads, minThreads);
}
```
注意

此方法指定的值是全域設定，會影響整個 AppDomain。舉例來說，如果您有一部 4 核心電腦，而且想要將「minWorkerThreads」和「minIoThreads」設為執行階段期間每個 CPU 50 個，請使用 ThreadPool.SetMinThreads (200, 200)。
您也可以使用 Machine.config 中設定元素底下的 minIoThreads 或 minWorkerThreads 組態設定來指定最低執行緒設定。 Machine.config 通常位於 %SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\。 我們不建議以這種方式設定最低執行緒數，因為其為全系統設定。

注意

這個組態元素中指定的值是「每一核心」設定。例如，如果您有 4 核心的電腦，並且想要在執行階段將 minIOThreads 設為 200，您會使用。

Question 6

使用 StackExchange.Redis 時啟用伺服器 GC 在用戶端上取得更多輸送量

Accepted Answer

啟用伺服器 GC 可以最佳化用戶端，並在使用 StackExchange.Redis 時提供較佳的效能和輸送量。如需有關伺服器 GC，以及如何加以啟用的詳細資訊，請參閱下列文件：

Question 7

連線相關的效能考量

Accepted Answer

每個定價層都有不同的用戶端連線、記憶體和頻寬的限制。雖然每個快取大小都可允許以某個數目為「上限」的連線數，但是針對 Redis 所進行的每個連線都會有相關聯的額外負荷。此類額外負荷的其中一個範例，是因 TLS/SSL 加密而產生的 CPU 與記憶體使用量。所指定快取大小的連線數上限是假設快取負載情況為輕度。如果來自連線額外負荷的負載「加上」來自用戶端作業的負載超過系統的容量，則即使您尚未超出目前快取大小的連線限制，快取也可能會發生容量問題。

如需有關每個層級之不同連線限制的詳細資訊，請參閱 Azure Redis 快取價格。如需有關連線及其他預設組態的詳細資訊，請參閱預設 Redis 伺服器組態。

共用方式為

Azure Cache for Redis 管理常見問題集