Need to be able to test both basic and standard Redis cache deployments but don't want to have to delete them between use cases. Running standard pricing tier redis cache uses most of my MSDN Azure Free trial credit. If I could shut it down, I would like to be able to save the costs.

It should be possible to set a smaller interval for Redis snapshots (or a manually triggered one) and to choose between AOF or RDB or both for the persistence method.

It would be great to have Windows Azure Cache Service (currently in Preview) REST API similar way Service Bus service has it (http://msdn.microsoft.com/en-us/library/windowsazure/hh780717.aspx)

Current version is 3.0.0 while latest stable is 3.2.0.

There are big features which are missing like geo api and many more.

The smallest instance right now is 250 megs. I think you should have a tiny instance too of around 50 megs. The price for 250 megs can be high if you start a new application that require some caching but just for few megs.

Currently I havn't seen any UI command to Restart Azure Redis Cache Service.
I know there is a way to shutdown and start however missing in the portal.

I have a requirement, where need high network performance and enhanced security but only 50MB and 250MB or 1GB size, 6GB cache and paying £205/mo doesn't fit well our current total spend is £450/mo

Allow me to have Redis Caches in different regions and link them together in a bi-directional sync configuration so when you add something to the cache in one region, the data gets replicated to the other caches. This keeps the cache local and fast when you're running a site in multiple regions.

The time of creating a Redis Cache is to long. It should be improved

We can't configure "retention" for Azure Redis Cache Diagnostics right now, even though we were used to configure it from Preview Portal. Please re-enable "retention" setting so that we don't need to delete logs manually.

-Japanese-
Redis Cache の診断ログにおいて、以前はプレビューポータルからリテンションを設定することができましたが、現在は設定することができません。利用者が手動でログを削除する必要がないようにリテンションの設定を有効化してください。

it would be great if we could further secure our Redis instance by defining the allowed IP addresses. Typically our cache is only accessed by our IIS application server therefore there is no need for the cache to be exposed to the public internet.

We sometimes face performance issues. Microsoft provides the following documentation to investigate timeout problem.
<https://azure.microsoft.com/en-us/documentation/articles/cache-how-to-troubleshoot/#stackexchangeredis-timeout-exceptions>

But we can't identify root cause easily. So personally I think measurable unit of Redis Cache Performance like DTU for SQL database is very useful for customer. I understand Redis Cache Advisor is very helpful for us. But if you can, could you please consider this kind of ability for good experience.

Give an option to rescale back to Basic tier. I started with Basic, switched to Standard but soon realized that I can not utilize it in near future and wanted to roll back to Basic. I was surprised when I saw that this option was not available.

Allow us override the default SSL and non-SSL ports. Its really hard to get these ports opened in the Corporate firewall

Server unavailable are really hard to diagnose please provide some help in the portal like a Test Connection or better a Diagnose button

Please add support of RedisCache in Azure Stack

Azure RedisCache is a fundamental backbone service for applications using autoscaling (e.g: Cloud Service Web and Worker Role).

I wanted to test the Redis Cache Failover scenario (with Standard edition) for an enterprise application. But with current portal there are no ways we can test this capability.

Also would also like to test scenarios when one of the cache server is not performing well what are the heuristic defined for failing over to other node.

My web role was not working properly and VM log was saying Cache.exe has been crashed unexpectedly. It looks like there were issue in Caching service issue on the VM where web role was deployed.

Finally I deleted the existing deployment and re-deployed the azure package file and after that everything is working fine.

Please take some fruitful action on such issues.

In-Role Cache has been marked for end-of-life and Redis Cache is now the only supported solution. Please keep In-Role cache as an option because it is the ONLY caching solution that actually scales with node count. Azure is about scalability, right?

https://azure.microsoft.com/en-us/blog/azure-managed-cache-and-in-role-cache-services-to-be-retired-on-11-30-2016