Last post Feb 06, 2018 09:46 PM by PinkhamSoftware
Jan 31, 2018 09:31 PM|codequest|LINK
I'm converting a VS2005-era web application to updated ASP.NET technology. It will run in an Azure App Service. The application makes extensive use of Session State and Application Cache. I need to decide whether to convert to Redis in order to support
multiple instances, now or later. The decision is primarily business driven. i.e. time, budget, business model. If I can support X users on a single instance, then I might postpone the Redis conversion, which would not be pretty (I like Massimo Fabiano's
quote on this at the start of this article https://www.codeproject.com/Articles/1132742/In-Search-of-the-Ultimate-DataTable-Serializer).
The estimated transaction rate on the server from all concurrent users appears not to be an issue. The major constraint appears to be cache memory usage.
> I have what I believe are good estimates for the high, low and medium session and application cache memory requirements per concurrent user (very padded out).
> I know how much memory I can configure on an Azure App Service
> What I don't know is how much of that memory will be available for cache after OS, application code and application paging.
Any guidance on how to understand those values would be appreciated.
Feb 01, 2018 10:23 AM|DA924|LINK
Maybe, you should post to the forum.
Feb 06, 2018 09:57 AM|PinkhamSoftware|LINK
If you want to create a highly scalable website I would suggest that you create a generic caching interface with a Redis implementation.
Hook that up to a Redis instance in Azure and you can now scale your application.
Your current design limits you to one instance of your application.
With distributed caching your application should now be stateless, allowing multiple instance to be spun up.
Allowing you to scale further.
Jeff - Pinkham Software Consulting
Feb 06, 2018 05:51 PM|codequest|LINK
I appreciate that, however, the project is a upgrade of an old architecture that won't convert to Redis easily (reliance on complex objects in cache). Not in the budget for the first round.
So I'm looking for actual information on memory use.
Feb 06, 2018 09:46 PM|PinkhamSoftware|LINK
I would suggest deploying it into an Azure App Service, and just monitor the memory usage, 8Gb is good for most web apps.
Scale to 16Gb if you and reduce it if everything looks good.
If you set up application insights on it you should get emails when its running out of memory.