locked
HttpRuntime.Cache & DataSet RRS feed

  • Question

  • User1111434469 posted

    Hello,

    I have a few questions about HttpRuntime.Cache & DataSet using together:

    1. Can I make HttpRuntime.Cache class to cache DataSet in user's browsers computer cache?

    2. Everywhere I see expressions like 'a large amount of data', 'a big amount of data' concerning state management or cache management and Cache & Sessions objects. Can you tell me how much is 'large amount', how much is 'middle / on the ednge amount of data' and how much is 'small amount of data'. You can say, it depends on your budget for server resources, your users (concurrent users), your data etc. Let's say that my initial budget is for a nornal / medium asp.net shared hosting account and I expect not more than 10 concurrent users and not more than 5000 users per month.


    3. I know that Session InProc setting is very fast, but when IIS, asp_net process restarts it deletes users Sessions. In what server unexpected circumstances HttpRuntime.Cache is deleted? I know about Cache dependences and manual way (through code) I can delete Cache, but I ask is there anything else than my code configurations and (all server resources down) to delete users cache? 

    Sunday, February 6, 2011 8:35 AM

Answers

  • User-158764254 posted

    1) no. the HttpRuntime.Cache holds data that is stored on the server using server memory.

    2) a large amount of data is a relative term that depends on how much memory your server has and how much data will be placed in the cache for concurrent usage.  Session is more problematic than cache in my opinion as each user gets their own session and data stored in session is not shared between users. Data stored in cache can be shared with all users of the app so a large entry in the cache is much less problematic than potentially hundreds/thousands of large objects stored in all the active sessions.  10 concurrent users is relatively small/low volume.  Storing datasets with hundreds of records or even a few thousand, is not apt to be an issue at all with that number of concurrent users.

    3) you can store session out of process using the session state server.  this can be enabled on the same server that runs the webs, so while it's true that it's not as fast as in-proc, since its the same box, the performance hit is relatively small and its a small price to pay to keep sessions alive across app recycles.  i love a fast running site, but i never use in-proc sessions to insure my users keeps their session when i deploy updates.

    cache items can be deleted either when they expire (absolute expire date / sliding expire date), or when a dependency expires, and also when server memory gets low.  if the available free memory gets low, cached items can be discarded even if they havent reached the expiration you have set for them.  whenever you use Cache, your code should always assume that the object will be missing from the cache and be prepared to recreate and re-cache that object. 

    note that "users cache" isnt necessarily a good way to refer to it.  unlike sessions, Cached items are available to all users and are not stored for any 1 specific user.

    Because a single cached item can be shared amongst all your application's users, i always prefer cache over session when storing data that  can be shared with all users.

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Sunday, February 6, 2011 10:14 AM
  • User-158764254 posted

    1) you can cache page output, css, javascript at the client (the stuff that renders to the browser).  the dataset remains at the server

    2) this really depends on exactly what you are storing

    3) almost always Cache will take less resources.

    If i put 1 item in Cache, then 1000 concurrent users can share that 1 item - we have just the 1 items in memory.

    if i put 1 item in Session - and i have 1000 concurrent users, then each user has 1 item - so we have 1000 items in memory.

    4) session are user specific - but cache is not.  cached items can be accessed/shared by all users.  so cached items do not belong to any one user.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Sunday, February 6, 2011 10:48 AM
  • User-158764254 posted

    1) rough html. structured data you use at the server does not/should not go here.

    2) look at what your columns can potentially hold.  this sound like it's going to consume a minuscule amount of memory, but if one of you columns is a Text type or a blob and you put giant amounts of data, then a single row could be large.  check the data types of your columns (ints, char, varchar, nvarchar, dates etc..) to see how much data could be consumed by a single row. 20-200 rows of data (assuming no columns of giant Text or Binary data) with 10 concurrent users is very very very small.

    3) Cache also gets cleared when the app recycles so it is not more durable. Cache will also automatically drop items as memory starts to get tight.  Session will not.  But if you use too much memory by overusing Session with many concurrent users and you consume 60% + of server memory, your app will recycle.

    Cache and Session both consume server memory.  If your objects being stored are user specific and cannot be shared across users, then Session is simpler.

    Based on the number you've indicated, I think you have a very small number of concurrent users with a very small amount of data that you wish to put in session.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Sunday, February 6, 2011 11:21 AM
  • User-158764254 posted

    2) columns are normal strings, let's say min 3, max 20 chars  each string. Please give me some example statistics for a normal/ average asp shared hosting account, how many concurrent users are confortable before these 60%?

    assuming worst case, then :

    • 20 chars X 30 columns = 600 chars
    • add a little overhead= 660
    • X 200 rows = 132,000
    • X 10 user = 1,320,000

    so thats a little over 1MB.  or double it to 2MB if you're using double byte text (2 bytes per character).  your actual utilization may end up averaging out to 1/2 of the max allotted size though as many of your strings will most likely be shorter than the max widths you've given your columns. so you're probably looking at approximately 1/2MB to 1MB of memory to hold that specific data.

    I dont know how hosts normally configure their servers for memory, but i think we can assume they've installed several GB's minimum. 

    cache (which is stored in in-process memory) gets clear on those items you noted.

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Sunday, February 6, 2011 3:22 PM

All replies

  • User-158764254 posted

    1) no. the HttpRuntime.Cache holds data that is stored on the server using server memory.

    2) a large amount of data is a relative term that depends on how much memory your server has and how much data will be placed in the cache for concurrent usage.  Session is more problematic than cache in my opinion as each user gets their own session and data stored in session is not shared between users. Data stored in cache can be shared with all users of the app so a large entry in the cache is much less problematic than potentially hundreds/thousands of large objects stored in all the active sessions.  10 concurrent users is relatively small/low volume.  Storing datasets with hundreds of records or even a few thousand, is not apt to be an issue at all with that number of concurrent users.

    3) you can store session out of process using the session state server.  this can be enabled on the same server that runs the webs, so while it's true that it's not as fast as in-proc, since its the same box, the performance hit is relatively small and its a small price to pay to keep sessions alive across app recycles.  i love a fast running site, but i never use in-proc sessions to insure my users keeps their session when i deploy updates.

    cache items can be deleted either when they expire (absolute expire date / sliding expire date), or when a dependency expires, and also when server memory gets low.  if the available free memory gets low, cached items can be discarded even if they havent reached the expiration you have set for them.  whenever you use Cache, your code should always assume that the object will be missing from the cache and be prepared to recreate and re-cache that object. 

    note that "users cache" isnt necessarily a good way to refer to it.  unlike sessions, Cached items are available to all users and are not stored for any 1 specific user.

    Because a single cached item can be shared amongst all your application's users, i always prefer cache over session when storing data that  can be shared with all users.

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Sunday, February 6, 2011 10:14 AM
  • User1111434469 posted

    1) Is there a qay to use users pc memory in some way for temporary storing DataSet?

    2) If I use Cache or Session, how to measure my data in KBs and calculate my maximum concurrent users for my hosting plan?

    3) Is Cache takes more resources  than Session State Server option? I suppose so, because Cache is available for all users, Session only for the current user.

    4) What do you mean by "note that "users cache" isnt necessarily a good way to refer to it."

    Sunday, February 6, 2011 10:42 AM
  • User-158764254 posted

    1) you can cache page output, css, javascript at the client (the stuff that renders to the browser).  the dataset remains at the server

    2) this really depends on exactly what you are storing

    3) almost always Cache will take less resources.

    If i put 1 item in Cache, then 1000 concurrent users can share that 1 item - we have just the 1 items in memory.

    if i put 1 item in Session - and i have 1000 concurrent users, then each user has 1 item - so we have 1000 items in memory.

    4) session are user specific - but cache is not.  cached items can be accessed/shared by all users.  so cached items do not belong to any one user.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Sunday, February 6, 2011 10:48 AM
  • User1111434469 posted

    1) is cache page output means always a rough html or you can store a structured piece of data like xml file in users Internet Explorer/Temp folder and use it as a dataset?

    2) I'm storing a DataTable with 30columns, 20-200 rows of string data, so how can i measure it?

    3) In my case the data I cache is user specific, so Session State Server is maybe is more appropriate. But I think, I prefer Cache, because it's more durable in app recycle processes. If Cache vs Session, Cache takes almost the same resources as Session, i think Cache is better, because I can put more data into Cache than into Session?

    Is statement 3 is OK or not?

    Sunday, February 6, 2011 11:07 AM
  • User-158764254 posted

    1) rough html. structured data you use at the server does not/should not go here.

    2) look at what your columns can potentially hold.  this sound like it's going to consume a minuscule amount of memory, but if one of you columns is a Text type or a blob and you put giant amounts of data, then a single row could be large.  check the data types of your columns (ints, char, varchar, nvarchar, dates etc..) to see how much data could be consumed by a single row. 20-200 rows of data (assuming no columns of giant Text or Binary data) with 10 concurrent users is very very very small.

    3) Cache also gets cleared when the app recycles so it is not more durable. Cache will also automatically drop items as memory starts to get tight.  Session will not.  But if you use too much memory by overusing Session with many concurrent users and you consume 60% + of server memory, your app will recycle.

    Cache and Session both consume server memory.  If your objects being stored are user specific and cannot be shared across users, then Session is simpler.

    Based on the number you've indicated, I think you have a very small number of concurrent users with a very small amount of data that you wish to put in session.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Sunday, February 6, 2011 11:21 AM
  • User1111434469 posted

    Thanks for all your asnwers, it's very helpful for me to plan & build my app.

    2) columns are normal strings, let's say min 3, max 20 chars  each string. Please give me some example statistics for a normal/ average asp shared hosting account, how many concurrent users are confortable before these 60%?

    3) is cache get cleared on:

    3.1) a file (cs, aspx, web.cofnig) change in app folder?

    3.2) IIS restart?

    3.3) asp process restart?

    Sunday, February 6, 2011 3:04 PM
  • User-158764254 posted

    2) columns are normal strings, let's say min 3, max 20 chars  each string. Please give me some example statistics for a normal/ average asp shared hosting account, how many concurrent users are confortable before these 60%?

    assuming worst case, then :

    • 20 chars X 30 columns = 600 chars
    • add a little overhead= 660
    • X 200 rows = 132,000
    • X 10 user = 1,320,000

    so thats a little over 1MB.  or double it to 2MB if you're using double byte text (2 bytes per character).  your actual utilization may end up averaging out to 1/2 of the max allotted size though as many of your strings will most likely be shorter than the max widths you've given your columns. so you're probably looking at approximately 1/2MB to 1MB of memory to hold that specific data.

    I dont know how hosts normally configure their servers for memory, but i think we can assume they've installed several GB's minimum. 

    cache (which is stored in in-process memory) gets clear on those items you noted.

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Sunday, February 6, 2011 3:22 PM