| Author |
 Topic Search  Topic Options
|
theSCIENTIST 
Senior Member
Joined: 31 July 2003
Location: United Kingdom
Status: Offline
Points: 440
|
 Post Options
 Thanks(0)
 Quote  Reply
 Topic: App vars and memory consumption
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.
|
|
|
 |
ljamal
Mod Builder Group
Joined: 16 April 2003
Status: Offline
Points: 888
|
Post Options
Thanks(0)
Quote Reply
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.
|
|
|
|
Mart
Senior Member
Joined: 30 November 2002
Status: Offline
Points: 2304
|
Post Options
Thanks(0)
Quote Reply
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.
|
|
Mart
Senior Member
Joined: 30 November 2002
Status: Offline
Points: 2304
|
Post Options
Thanks(0)
Quote Reply
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,.
|
|
dpyers
Senior Member
Joined: 12 May 2003
Status: Offline
Points: 3937
|
Post Options
Thanks(0)
Quote Reply
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.
|
|
theSCIENTIST
Senior Member
Joined: 31 July 2003
Location: United Kingdom
Status: Offline
Points: 440
|
Post Options
Thanks(0)
Quote Reply
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.
 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.
|
|
|
|
Mart
Senior Member
Joined: 30 November 2002
Status: Offline
Points: 2304
|
Post Options
Thanks(0)
Quote Reply
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 
|
|
