5

In our still-in-development project we have noticed sudden delays when accessing our ASP.NET Web API services. Using the awesome Mini Profiler we nailed it that these delays are caused when connections to the Azure Data Cache (Preview) services are dropped and they have to be reestablished. This process takes about 3.3 seconds. After reconnecting, getting an object from the cache takes 1.4 ms.

When I increased maxConnectionsToServer from 1 to 20, I noticed another thing. If I don't make requests to the Web API for 1 or 2 minutes (that's usually when the connections are dropped) and then start making calls, next 20 requests are delayed for 3.3 seconds, which is how connection pooling works I guess (round-tripping the connections from the pool).

Both the Web API and Caching service are hosted in the East US region, we have disabled local cache, SSL is disabled, auto discover is enabled.

So, I'm wondering if something is wrong with our configuration or is this a thing because Azure Cache is still in preview?

Any information will be valued.

Thanks!

Gorgi Rankovski
  • 2,303
  • 1
  • 23
  • 32

2 Answers2

0

It sounds like your shared cache is being offloaded due to inactivity. One way to test this would be to add an In-Role Cache to an existing service (if available) and swap your cache usage to this new cache. In-Role cache is described here.

Once the cache is moved off of a shared offering, wait the requisite 1-2 minutes for idle time out and retry the connection, the delay should not be present.

Assuming you want to stick with the shared cache option after isolating the problem, the only current workaround that I am aware of is running a background task that will periodically ping the cache to keep it alive.

If you are running a full Web role you can launch a background task on application start up.
If you deploying via Mobile Services, then you can run the "ping" via Scheduled Jobs. The only issue you may run into here is that the minimum time for a scheduled job is 1 minute, which may not be aggressive enough to keep your cache alive 100% of the time.

MOverlund
  • 173
  • 4
  • Thanks for your response. We are not using the Shared Caching Service, but rather the new Azure Cache: http://msdn.microsoft.com/en-us/library/windowsazure/dn386094.aspx – Gorgi Rankovski Mar 19 '14 at 11:24
  • I should have clarified - the tier you choose determines whether your cache is shared or dedicated. If you are running under the basic tier, you run on shared hardware, if you have opted for the standard or premium tiers you are running on dedicated hardware. Tier details here: http://msdn.microsoft.com/en-us/library/windowsazure/dn386114.aspx. – MOverlund Mar 19 '14 at 14:14
  • Tried with the Standard offering - same thing. Connections take about 3 seconds to be established. – Gorgi Rankovski Mar 20 '14 at 11:30
0

Nothing that I see points to you doing anything wrong per se. It may be the Azure is genuinely having problems getting the cache connections up and running quickly. According to several best practices documents and MSDN posts, you want to increase your number of connections to caches to allow for a failover to an active connection, which you've effectively done with your configuration change.

Try making sure that your cache accessor is a static object (another MSDN recommendation) and this may be a long shot but consider using the Sliding Window option for object expiration and see if that not only tells the countdown for the object store to reset, but also prompts the cache service to reset the connection.

gfish3000
  • 1,557
  • 1
  • 11
  • 22