0

We current move our existing web application to Azure. Azure Caching is very slow.

Is there any alternative caching mechanism (better than Azure Caching) for multi instances in Azure? For example, storing caching in Azure Storage or Azure SQL.

Thank you for your input!

Added

public class AzureCacheService : ICacheService
{
    readonly DataCacheFactory _factory = new DataCacheFactory();

    private readonly DataCache _cache;

    public AzureCacheService()
    {
        _cache = _factory.GetDefaultCache();
    }

    public object Get(string key)
    {
        return _cache.Get(key);
    }

    public void Insert(string key, object obj)
    {
        if (obj != null)
        {
            _cache.Put(key, obj, new TimeSpan(3, 0, 0));
        }
    }

    public void Remove(string key)
    {
        _cache.Remove(key);
    }
}

*** Accessing *** 
IoC.Resolve<ICacheService>().Insert(key, MyObject);

IoC.Resolve<ICacheService>().Remove(key);
Community
  • 1
  • 1
Win
  • 61,100
  • 13
  • 102
  • 181
  • Can you give us a little more about what exactly is the latency you are seeing (as well as the APIs you are using, object sizes etc)? May help to determine where the problem is. – Tom Apr 27 '12 at 17:51
  • While the initial startup can take a few seconds, once the connections are made it's very quick. I typically see latencies under 10ms. If it's significantly slower than that, then most likely you're doing something wrong. – Brian Reischl Apr 27 '12 at 18:08
  • Tom & Breishl - I added the code. – Win Apr 27 '12 at 18:32
  • 1
    It looks like you're creating a new DataCacheFactory for each call. Don't do that. You should create a single DataCacheFactory and keep it around for a long time, possibly the lifespan of the app. You could try it easily by marking that declaration "static". – Brian Reischl Apr 27 '12 at 22:00

3 Answers3

2

In general, WA Caching is not slow, particularly if you turn on "local caching" (which should generally turn the latency down to around 0ms, as long as the data fits in memory). Memcached is another possibility: http://blog.smarx.com/posts/memcached-in-windows-azure.

You won't find an order-of-magnitude difference in performance between WA Caching and Memcached, but in my experience Memcached is a little faster. Memcached won't be able to beat the "local caching" feature in WA Caching, though, since there's literally no latency on that. (It's in-proc data access without serialization. Just about as efficient as is possible.)

user94559
  • 59,196
  • 6
  • 103
  • 103
  • Local cache will be massively increase your cache performance when reading if it's hit in your local cache. But I don't think it will increase the write performance since it still need to go to the AppFabric Cache. – Shaun Xu Apr 28 '12 at 01:49
0

It was my misunderstanding that Windows Azure Caching is based on SQL Azure and after taking to correct resources I was able to verify that it sure is inmemory cache. so if you decide to write your own using SQL Azure, that would be much slower the what you are already getting now and same goes with Azure Table storage. [Rest of the comment is removed]

AvkashChauhan
  • 20,495
  • 3
  • 34
  • 65
  • 1
    "Windows Azure Caching backend is based on SQL Azure." Are you sure of that? My understanding is that it's built on the AppFabric Caching component (same one that ships for Windows), which is purely an in-memory cache. – user94559 Apr 27 '12 at 15:35
  • That's just not correct. Azure Caching is basically Windows Appfabric Cache, which is an in-memory cache. It does not involve SQL Server. "Caching provides a distributed, in-memory, application cache" - http://www.windowsazure.com/en-us/home/features/caching/ – Brian Reischl Apr 27 '12 at 18:06
0

You can use the recently released Windows Azure Caching (Preview). It has 5x improvement over the shared caching counterpart.

Link : http://www.windowsazure.com/en-us/develop/net/how-to-guides/cache/

Karthik R
  • 11
  • 1
  • Karthik R - Yes, you can use Windows Sever AppFabric features in new Windows Azure Caching (Preview). I'll leave the accepted answer as is since the answer was correct for that time. Thank you for your answer! – Win Jun 22 '12 at 14:55