Print Page | Close Window

App vars and memory consumption

Printed From: Web Wiz Forums
Category: General Discussion
Forum Name: Classic ASP Discussion
Forum Description: Discussion on Active Server Pages (Classic ASP).
URL: https://forums.webwiz.net/forum_posts.asp?TID=12048
Printed Date: 31 March 2026 at 1:36am
Software Version: Web Wiz Forums 12.08 - https://www.webwizforums.com


Topic: App vars and memory consumption
Posted By: theSCIENTIST
Subject: App vars and memory consumption
Date Posted: 05 October 2004 at 3:41pm
Hi folks, I'm about to start a major project, and my concern is with regards to application variables, we all know how useful they are and what they do, but what is the compromise for using them?

What I mean and need is to cache data to avoid DB hamering, my server only has 512MB of memory, my SQL Server is most of the time idle and can take some hits (for now, maybe not in the future) so what compromise would I go for, save SQL server, or save main memory by not caching data?

Let's take the example of WWF, it uses app vars to cache DB data, avoiding having to go to the DB to get data all the time, but how much memory does it use, as opposed to not caching the data? Or is it negligible and I shouldn't worry too much about the memory taken by the cache as it is a small ammount? (talking about what WWF uses)

Thx.

-------------
:: http://www.mylittlehost.com/ - www.mylittlehost.com



Replies:
Posted By: ljamal
Date Posted: 05 October 2004 at 10:46pm
Some data that are constants are much better stored in in config files which is something that WWF doesn't utilize enough.

-------------
L. Jamal Walton

http://www.ljamal.com/" rel="nofollow - L. Jamal Inc : Web/ Print Design and ASP Programming


Posted By: Mart
Date Posted: 06 October 2004 at 2:09am
I don't know about memory consumption but I know you should never store STA's (Single Threaded Applications) in an application variable... e.g. you shouldn't store an ADO connection object in an application variable. Not sure if that helps, but there you go.


Posted By: Mart
Date Posted: 06 October 2004 at 2:56am
btw How much and what are you thinking about storing in application variables... It should be fine for a few fields if you just want to store some commonly used variables like settings, but if you are planning to store a 10,000 row data table in there you may hit a proble,.


Posted By: dpyers
Date Posted: 06 October 2004 at 8:23am

A good web server with 2gb of ram can handle a thousand or two web sites so memory used in the setup, execution, and breakdown of applications and sessions is pretty minimal. You'd probably use more setting up and breaking down componentswithin your code.

What your impact upon performance will be is like Mart said, pretty much determined by the amount of data you stash in the app memory space vs the number of call to the db, the structure of the db, and the abount of data pulled by each call.

As far as the performance tradeoff between using memory and round-tripping to the sql server goes, there's really no way to start figuring your break even point until the code runs under load.

I saw something clever once where an app using a flaky db connection pulled look-up data from the db upon instatiation then seriailized the record set into an xml file on the local machine. When it needed the data, it just pulled it in from the xml file and cleared it out of memory when it was done. They were just doing it for testing while the network was getting straightened out, but the performance was surprisingly good.



-------------

Lead me not into temptation... I know the short cut, follow me.


Posted By: theSCIENTIST
Date Posted: 06 October 2004 at 11:59am
The original idea was to cache as much as possible, but then it hitted me, with all this cached, the fresh data will not show, unless the cache is invalidated after say 5 mins, but that will cause another DB pull next time the data is needed, so I'm very much inclined now to partially scrape the idea, and only cache config data, the kind of data that is unlikely to change frequently.

I even went further and thought about creating some kind of bookmarking system created by newly updated data, what I mean is that I would cache lots of data, and only recycle the branches where a bookmark was found so the whole cache didn't require any kind of recycling every 5 mins.

Originally posted by Mart Mart wrote:

...I know you should never store STA's (Single Threaded Applications) in an application variable... e.g. you shouldn't store an ADO connection object in an application variable...


I've actually read app vars are very good for this king of thing, what's the problems we could face by doing so?

Does anyone done any measurment on WWF running with and without the use of app vars? Or does anyone has any data we can analyse regarding WWF used in both scenarios?

Thx all.

-------------
:: http://www.mylittlehost.com/ - www.mylittlehost.com


Posted By: Mart
Date Posted: 06 October 2004 at 12:41pm
Its all to do with threads, bottom line is: low performance. When you save an object (a variable created with the Set message) IIS will store and maintain it until the server is restarted, the problem is the object is stored in a specific thread so any script that wants to access the variable has to be on the same thread or use mashalling, which is very expensive performance wise. IIS operates in a multi-thread manner so by storing an object in application variables you are causing IIS to wait for the thread its being stored in to become active, which is not good



Print Page | Close Window

Forum Software by Web Wiz Forums® version 12.08 - https://www.webwizforums.com
Copyright ©2001-2026 Web Wiz Ltd. - https://www.webwiz.net