0

We're running a PaaS ASP.NET application in an Azure App Service with 3 instances and managing session data outproc in a SQL Server database.

The application is live and we've noticed a large amount of session data for some users when following certain paths e.g. some users have session data upwards of 500k (for a simply site visit with no login the average session is around the 750 - 3000 mark which is what I'd expect).

500k sounds excessive but was wondering what is normal in large enterprise applications these days and the cons of holding so much data in session.

My initial thoughts would be,

  • No affect on Web App CPU (possible decrease in fact) because not constantly doing queries,
  • No affect on Web App Memory because we running outproc,
  • Large spikes in DTU on Sql Server session database when garbage collection runs,
  • Application may be a bit slower because it takes longer to read and write session data between requests,
  • May not be ideal for users with poor internet connections,
  • Possible increase in memory leaks if objects aren't scoped correctly.

Does my reasoning make sense or have I missed something?

Any thoughts and advice would be appreciated,

Many thanks.

Bruce
  • 99
  • 1
  • 9

1 Answers1

0

I totally agree with your reasoning behind using out-proc session management in Azure App instances.Using IN-PROC sessions in the cloud is a strict no. The reason to host to cloud is to have high availability which is done by having a distributed environment.

Understanding from your point, i assume that speed is a concern to you or if matters to most of the web application , To overcome this , you might think of using Azure redis cache.

Here is the article for configuring session management using Azure redis cache:

Refer the documentation here: https://learn.microsoft.com/en-us/azure/redis-cache/cache-aspnet-session-state-provider

Mohit Verma
  • 5,140
  • 2
  • 12
  • 27
  • Thanks Mohit for your feedback. Yea we were using Redis but switched it out because it wasn't handling our large session data. My understanding is Redis is fast but only if you data size is not to big. It can handle lots of keys but the key (or pair) size can't be to big. I suspect we were hitting the upper limits which is why we started having issues with it. – Bruce Mar 12 '19 at 07:44