Performance issues with large structured object in .Net Application Cache?

Question

My ASP.NET app provides many complete separate group discussions. As currently written, the active global data is kept in a complex GroupDiscussionObject that is stored in System.Web.HttpContext.Current.Application under a key specific to that discussion, i.e.

Dim thisDiscussionID as integer = 99
Dim thisDiscussionObject as GroupDiscussionObject
Dim workHT as HashTable
Dim AC = System.Web.HttpContext.Current.Application
thisDiscussionObject = AC("GroupDiscussionObject_" & Trim(Str(thisDiscussionID)))
workHT = thisDicussionObject.ThatHashTable

The GroupDiscussionObject type is a class object with many Public variables, private variables accessible through public properties, Hashtables, Queues and so on.

GroupDiscussionObjects elements are initially loaded from disk and updates to child elements are sync'd with disk (and controlled through a queue to eliminate contentions) where needed.

This all works fine now. However, in an enhancement, I'm adding more and more variables to GroupDiscussionObject.

My question is, within the framework of this approach, are there going to be performance issues with having all the data for one discussion behind one Application Cache key, versus breaking it up and having the partial elements under difference Cache keys?

Upate: To refined my question, does having all the data under one application cache key create some kind of bottleneck, versus having it divided among many keys? Or is it just another memory address, and subject to the same access constraints as any memory address?

Answer 1

Memory is not the main problem. Concurrency is the main problem.

Application state is free threaded. In order to save anything in there, you're supposed to be using Application.Lock. Only one thread can have the lock at a time. And I do mean ONE, sitewide. Not one per user, not one per discussion, not one per application variable. One, period.

If you have anything other than a very low number of users or discussions, you will find a lot of your threads are blocking, waiting for application state to unlock. You can very rapidly run out of worker threads this way. At that point your web site will start throwing 500.13 Server Too Busy errors and nobody will be able to access any of the pages.

My recommendation is to store discussions in a database. Databases are designed to handle concurrency much more readily. Application variables are not intended for this sort of use.

Answer 2

The answer lies in the concrete numbers of conversations, conversation object sizes, the size of your extensions, available memory AND performance requirements for this system.

Even if you don't add any extra data but increase the number of conversations (system gets busier) you may hit issues.

BTW. It may be enough to upgrade the memory of server before you change the way the conversations are stored.

• wayfarer: I updated the question to hopefully clarify what I'm asking about.