Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Jan 25, 2012 08:47 PM by atconway
Nov 29, 2011 03:43 AM|LINK
Saving in session might affect you if the users scale up later.
The solution would be to save it in application cache and can be used across session.
Also provide cache time out so that after sometime the cache gets cleared and get a fresh load from the DB. That will resolve your new user addition problem.
Nov 29, 2011 04:26 PM|LINK
thanks for this; do you have a reference of instructions on using the application cache under .net 4.0? Also is this working under IIS7?
Nov 30, 2011 12:32 AM|LINK
You may check the following links. What you need is data caching.
The way we use caching doesn't differ much across various framework versions.
Jan 23, 2012 09:50 AM|LINK
I am revisiting the issue on performance. What we have now is a "dashboard" page showing a long list of items (projects) on a grid. The grid contains some 25 columns of data and around 3000 rows; we are using filters to reduce the number of records flowing
from the server to the client.
The dashboard also has uses AJAX and has a ScriptManager and UpdatePanel which contains everything else. We also have a timer set to 5 minutes so as to refresh the dashboard (projects are worked on and their properties change, such as status, assigned persons
Currently everytime the screen is refreshed a postback causes the object data source to execute the db functions to retrieve the data, and this creates a huge overhead and slow responses, for which the users complain.
Another issue I have is that the users get kicked out as their session expires every 20 minutes or so and we would like to keep the session alive for a longer period of time. I wonder whether the automatic postback of the timer should refresh the session
timer as well.
Is there a better way to design this so as to avoid the full postbacks and the long delays? Would a conversion of the List<Project> objects to a datatable be more efficient than dataset binding through the object datasource?
Jan 24, 2012 08:21 AM|LINK
Jan 25, 2012 08:47 PM|LINK
The grid contains some 25 columns of data and around 3000 rows; we are using filters to reduce the number of records flowing from the server to the client.
I hope so because having 3000 rows in the page's source will slow down the processing of that page big time. Have a look at the size of the ViewState as well through a tool like ViewStateHelper to see how big the page is:
Currently every time the screen is refreshed a postback causes the object data source to execute the db functions to retrieve the data, and this creates a huge overhead and slow responses, for which the users complain.
This is another big problem. Why go back to the database every time a postback occurs; it is not a good idea unless you are worried about stale data. The problem is the Object Data Source more than likely. The ODS is both a curse and a blessing. It's problem
is it has so much built in functionality and not all of it is always desired, but it cuts down on a lot of the manual binding code that would need to be written otherwise. It is probably calling the 'Select' method on your postback and getting all that data.
You should use caching on the Object Data Source. However getting the cache to be client specific takes a bit of work so make sure to read this:
Using Caching on an Object Data Source and Making it Unique Per User:
Another issue I have is that the users get kicked out as their session expires every 20 minutes or so and we would like to keep the session alive for a longer period of time.
Easy. This is configurable via the timeout property. Read the following link:
I wonder whether the automatic postback of the timer should refresh the session timer as well.
Yes it will reset the timer on session.