Azure – How to disable an Azure Redis Cache

Finally, found way to enable TLS session tickets on win2k12 r2 and win2k16. You need to follow these steps:

1. Create a key (DWORD) in registry with value 1 HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\EnableSslSessionTicket

2. Create a new TLS session ticket key through this powershell command: New-TlsSessionTicketKey -Password <password> -Path "C:\KeyConfig\TlsSessionTicketKey.config" -ServiceAccountName "System" https://technet.microsoft.com/en-us/itpro/powershell/windows/tls/new-tlssessionticketkey

3. Enable TLS session ticket key through this powershell command: Enable-TlsSessionTicketKey -Password <password> -Path "C:\KeyConfig\TlsSessionTicketKey.config" -ServiceAccountName "System" https://technet.microsoft.com/en-us/itpro/powershell/windows/tls/enable-tlssessionticketkey

4. Reboot the server to enable TLS session ticket generation. Reboot is required for the registry entry to take effect.

IMPORTANT: To re-use same TLS session tickets across load balanced servers, you need to copy "C:\KeyConfig\TlsSessionTicketKey.config" file generated after running "New-TlsSessionTicketKey" command on one of the servers and then copy the config file on all remaining servers and run "Enable-TlsSessionTicketKey" powershell command on each file. Unfortunately this worked for me only on win2k16. It did not work on win2k12r2.

Since nobody else had an answer here, thought I'd share the only thing that has worked for us. First, these ideas did not work:

• larger cache instance type: was having the same problem on smaller instances than the cache.r3.2xlarge we're using now
• tweaking maxmemory-policy: neither volatile-lru nor allkeys-lru seemed to make any difference
• bumping up maxmemory-samples
• bumping up reserved-memory
• forcing all clients to set an expiration time, generally at most 24 hours with a few rare callers allowing up to 7 days, but the vast majority of callers using 1-6 hours' expiration time.

Here is what finally did help, a lot: running a job every twelve hours which runs a SCAN over all keys in chunks (COUNT) of 10,000. Here is the BytesUsedForCache of that same instance, still a cache.r3.2xlarge instance under even heavier usage than before, with the same settings as before:

The sawtooth drops in memory usage correspond to the times of the cron job. Over this two week period our swap usage has topped out at ~45 MB (topped out at ~5 GB before restarts before). And the Cache Events tab in ElastiCache reports no more Cache Restart events.

Yes, this seems like a kludge that users shouldn't have to do themselves, and that Redis should be smart enough to handle this cleanup on its own. So why does this work? Well, Redis doesn't do much or any pre-emptive cleaning of expired keys, instead relying on eviction of expired keys during GETs. Or, if Redis realizes memory is full, then it will start evicting keys for each new SET, but my theory is that at that point Redis is already hosed.