New caching doesn’t seem to be a productivity improvement
I’ve experience the above plenty of times – hit F5, wait for your projects to build then sit back and enjoy anywhere from a minute to five minutes of peaceful reflection while the Azure emulator gets up to speed.
After some playing with procmon I discovered that the vast majority of activity in those interminable minutes could be put into three broad buckets:
- Logging to DFAgent.log, sometimes tens of times a second (something I’m seriously considering symlinking to NUL, or at the very least a ramdisk)
- Various things to do with installing the Windows Azure Cache Emulator
- Lots of communications with ‘something cloudy’ at 168.63.0.*
Troubles seemed to start with the install of the 1.8 SDK, but in fact appear now to be linked to whether or not ‘Enable Caching’ is turned on in the cloud role properties:
j’accuse!
Some timings from my machine on a particularly large solution, from ‘Starting emulator’ to a usable deployment:
- Enable Caching ‘On’: ~3 minutes average
- Enable Caching ‘Off’: ~15 seconds average
This is a bugger though, as you can’t have cloud-configuration-specific settings for your caching – it’s either globally on or globally off. In addition, without caching enabled anything that attempts to use it will fail with an exception (fine, if those classes fall back to a null cache implementation). So – for my purposes, my local development environment setup changes from:
- Caching enabled
- Use Azure caching for session state management
to a new cloud project specifically for development with:
- Caching disabled
- Use the Session State service for session state management (configured in web.config) and web.config transforms to convert to Azure Caching session state management for deployment
And my F5 experience goes from three to five minutes down to 15-20 seconds. Not ideal, as I’ve taken my development environment another step further away from my deployment environment, but from a productivity point of view it’s a no-brainer.
Have yet to diagnose why installing the Windows Azure Cloud Cache components as happens during a development run is so costly – more investigation required…
Thanks very much for this! Of all the “Roles instances are taking longer than expected to start” commentary I was able to find, this was the only one that mentioned caching which turned out to be the problem in my case.
It’s weird – I’d thought there’d be more out there for it but no such luck. Am hoping it’ll be addressed in some future SDK update, or that a more light-weight simulation of the Azure caching might appear…
It seems the Windows Azure Cache Emulator takes a sizeable chunk of RAM and has memory leaks, I’ve watched it spiral through memory and double/treble in size
One simple tip I found that occasionally helps if you are running locally is to check how many instances of the appllication you are running locally. I sometimes forget that I have deployment settings running and 2 or 3 instances of a role set. The cache emulator is memory hungry and leaky, cutting down the number of instances can help
It helped me a lot and I am able to debug my webrole.
Kieran: That’s also true and something I should have mentioned really. I too have noticed the caching emulator sat at ~4GB of RAM usage over time, even when the application makes no use of cache. Reducing the number of instances definitely helps start-up time, presumably because the caching emulator’s ‘installing’ (or at least setting itself up) once per instance.
It can, though, be quite a frustrating development experience as to get around the caching emulator’s shortcomings you have to take your development environment further away from your deployment environment – two things that I like to keep as close together as I can manage.
Thank you!