My Clients Azure PAAS site uses In-role Cache. The caching service faces frequent downtimes due to high CPU Usage. On investigation from Microsoft, it is strongly recommended to move to Redis Cache. But since it doesn't support the session_end event. We want to explore either MongoDb or SQL sessionstate providers.

I want to hear your views on MongoDB session provider (pros & cons) , specifically, Are there any security pitfalls when using MongoDB session providers? Anyone who has experience using both , Please put in your two cents on this.

1 Answer 1


We are using MongoDB extensively at present, rather than SQL, for Azure deployments. The number of MongoDB collections required for Sitecore's xDB means we run our own MongoDB server cluster as it's much more cost-effective than PaaS solutions at the moment, and cheaper than equivalent SQL performance too. Azure PaaS DocumentDB is billed per-collection and you'll need about 18 of them! If you have some linux boxes they are very cheap, and you can add as many collections as you want - we have lots of utility stuff in there, as well as ELMAH logging into a "fixed size" collection.

I think the gold standard will be to get Redis going, either on the Azure Redis PaaS or on a standalone setup. Up until recently, the Azure Redis system did not support callbacks for items evicted from the cache (called keyspace notifications in Redis-speak). This made it clunky to support the OnSessionEnd event that Sitecore attaches its xDB processing tasks to. The currently available Redis ASPNET Session State provider does not support this critical event. We use Redis as well as MongoDB, but more for volatile cache and backing APIs.

I imagine it won't be too long before someone has a good crack at this. I've looked into it, and it seems straight-forward enough, I just haven't had the time to string it all together.

Until that's available, the Mongo provider on Ubuntu will perform better for the same price. There's no special security issues to speak of, as long as you remember to configure user accounts against your MongoDB.

  • 1
    I don't want to make an answer about this, but recently I know that Sitecore has been suggesting that using the SQL Session provider instead of Mongo provider has shown increases in performance. I don't have any data of my own to back that up, but it did influence a decision to use SQL session instead of mongo. Commented Oct 26, 2016 at 16:30
  • @PeteNavarra I've been told the same thing by a number of folks from Sitecore
    – sestocker
    Commented Oct 26, 2016 at 17:17
  • I saw that too. I don't know what their test setup was, but our testing in this environment, with these components, came out the other way. Commented Oct 26, 2016 at 19:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.