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.
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
etc).
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?
I think this may help you out in cutting down the hits on the database http://msdn.microsoft.com/en-us/library/ie/ms178604.aspx Session timeout is set in the web.config, set it using the timeout attribute of the sessionState node.
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:
http://www.binaryfortress.com/ASPNET-ViewState-Helper/
cloucas
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:
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.
Sanjesh Kizh...
Member
78 Points
14 Posts
Re: Ways to improve the performance of an ASP.Net application
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.
cloucas
Member
64 Points
65 Posts
Re: Ways to improve the performance of an ASP.Net application
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?
Sanjesh Kizh...
Member
78 Points
14 Posts
Re: Ways to improve the performance of an ASP.Net application
Nov 30, 2011 12:32 AM|LINK
You may check the following links. What you need is data caching.
http://www.4guysfromrolla.com/articles/100902-1.2.aspx
http://weblogs.asp.net/dotnetstories/archive/2011/02/15/data-caching-in-asp-net-applications.aspx
http://www.asp.net/data-access/tutorials/caching-data-at-application-startup-cs
The way we use caching doesn't differ much across various framework versions.
cloucas
Member
64 Points
65 Posts
Re: Ways to improve the performance of an ASP.Net application
Jan 23, 2012 09:50 AM|LINK
Hi again
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 etc).
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?
frez
Contributor
5418 Points
913 Posts
Re: Ways to improve the performance of an ASP.Net application
Jan 24, 2012 08:21 AM|LINK
atconway
All-Star
16846 Points
2756 Posts
Re: Ways to improve the performance of an ASP.Net application
Jan 25, 2012 08:47 PM|LINK
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: http://www.binaryfortress.com/ASPNET-ViewState-Helper/
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:
http://allen-conway-dotnet.blogspot.com/2010/05/using-caching-on-object-data-source-and.html
Easy. This is configurable via the timeout property. Read the following link: http://msdn.microsoft.com/en-us/library/h6bb9cz9(v=vs.100).aspx
Yes it will reset the timer on session.