background:
existing asp.net web application employs a number of dynamically-loaded user
controls and pages
many of these pages and user controls depend on parent page context
a new project containing “version 2” of the application needs to integrate with aforementioned legacy version in production while “version 2” continues to be developed
scenario:
I’m using a response.redirect with a parameterized URL to navigate from “version 2” page back to a dynamically-loaded legacy page - a "page 1", if you will. This works fine. However, the ultimate goal/target is to navigate directly to a dynamically-loaded legacy page which is “2 clicks away” from the initial target. The “clicks” would be from the dynamically-rendered controls.
question:
Is it possible from my “version 2” page in the code-behind to navigate directly to this ultimate target? When I call the user click procedures in code immediately following the call stack from the initial redirect, it still lands me on legacy page 1.
So the basic question is more conceptual in terms of handling direct navigation several “hops” into dynamically-loaded pages. In other words, can navigation be controlled in code-behind from dynamic controls without actually rendering them back to the client onscreen?
Much obliged for any help to get me beyond this impasse.
/John
The crux of the issue was how to reach a dynamically generated target page from a point in the application which required multiple click events (i.e. multiple round trips), and reduce that to a single round-trip in the code-behind.
Invoking consecutive click events in the code-behind without rendering would have been a recursive violation of the page life-cycle.
Essentially, sequential click events cannot be leveraged in 1 round trip - the solution is to leverage the relevant underlying procedure calls, and/or write new ones in order to yield the target page.
i am facing a big speed problem with my application..we have to go for production but it got push backed becoz of this speed issue..
In my application..i have a page which is the main and important page of whole application..
in this page user spend most of the time...
in this page i am using 6 to 7 javascript files and jquery plugins..
whole page is ajax based and will do the jquery validations...
in this page i have 3 update panels (nested)..one update panel contains one formview and
other will contain one grid and a 4 formviews(will make visible of user selection..4 of the won't come at time..depends on grid view item i will get visible..like grid view record is type one then type one formview will visible on the page)..one update panel is parent update panel..
each formview contains more than 10 controls..dropdowns will load on formview onload event from database loopup tables..
this page won't refresh at all..because ever thing is in update panels..
i can't set the view state to false because of update panels..
i have to make more than 5 database calls each time..
this page works fine at the beginning of application start..after some amount of time its getting slower and slower..the database calls are pretty fast at the beginning and getting very slow after some time...
i don't know how to debug this thing and how to find which one causes this problem....please help me...
Update:
my view state is growing from 35 kb to 160 kb..
and i tried fullpost back triggers for some controls in updatepanels.. but the view state not getting down..its stays like that..on a double or triple browser refresh it got back to 35 kb..is this the issue?? thanks for your replies and suggestions...
I can't really help you if you don't show your code (specifically, the code the runs the database queries that start to slow down), but I can make one (hopefully good) guess:
It sounds like you might not be disposing your database connections properly. Every time you open a connection to the database, make sure you either wrap it in a try/finally block (where .Close() is called in the finally block) or create it with a using block.
You should look into a tool like JetBrains dotTrace that allows your monitor performance on a granular level. Then you will be able to see what the actual cause of your poor performance is. You get a 10 day trial at the website I linked to.
after a very long testing i found the problem...its because of update panels...we should not use update panel for too many controls..I didn't know that and the only control we have in asp.net is update panel for ajax..that's why i used the updatepanels...please stop using updatepanels and try to use jquery..i suffered a lot with this issue...thanks for your support guys...
I have an odd question that im not sure has been asked/answered, and im not sure if mvc can do this but:
I have a really massive page/controller which i have been able to code well enough. The user can edit information on this page and wont get it saved to the database unless they specifically say, save. However, there is a list at the bottom of this page that you can add/edit and delete elements. Adding and editing takes you to a different page, and before the page change happens, i want to save the form data to session memory, but i dont know how to access it outside a postback. Can MVC do this?
I do not believe this is possible. There is no way to interact with Session object outside of some form of postback.
You may want to architect your solution as such that you can mitigate the need to go to a different page and return.
The adding/editing portion of your form could instead be handled through asynchronous web POSTS independent of your main form. JQuery UI's dialog window and UI Tabs come in nicely for sophisticated forms that need CRUD capabilities to other components of your web application.
I'm investigating an asp.net web application that extensively uses User Controls on each page. Most pages contain around 10-20 user controls. The User controls seem to be the visual representation of the business objects (if that makes sense), although at a finer granularity such as each tab of a tab control having its contents in a user control. The project itself has over 200 user controls (ascx files).
The performance of the application is very poor (and the reason I'm investigating). Each event (such as a click or dropdown selection etc) requires about 5 seconds for the page to load (10 seconds whilst in visual studio). The application has no use of Ajax.
Tracing is painful as the aspx pages themselves have no code in the code-behind as the user controls look after all of this, so tracing a single page requires trace statements in all the user controls that are on that page.
I actually think that having each user control look after its business code and being re-usable is a smart idea, but is an excessive use of user controls going to incur a performance hit? Does this seem like the structure of an asp.net application that was written by someone with a strong WinForms background?
EDIT
thought I should add that i'm not questioning the use of user controls (or even the amount) but simply whether having so many on a page that all accomplish things (each user control connects to the database for example) will generally cause performance problems...For example, if just one user control postsback to do something, what about the processing of all the others, some are visible and some aren't...#David McEwing mentioned that he had 40 optimised user controls performing etc, but if the developer was WinForms based or "not familiar with asp.net", then how are they going to make sure each one is optimised...
EDIT2
After getting a sql statement trace, the same calls for data are being executed 5-6 times per page call for each event as the different user controls require data that is not stored commonly e.g. each user control in the tab (mentioned above) makes the same call to populate an object from the database...I'm really not here to accuse user controls of being the problem (should i delete the question?) as clearly the problem is NOT user controls but with the use of them in this particular case...which I believe is excessive!
10-20 (or even hundreds) User Controls alone is beyond trivial. The presence of the controls themselves, and the idea of encapsulation, is definitely not the source of your problems.
It's impossible to say precisely what the problem is without actually profiling the application of course, but based on my experience I can say this:
What is more likely is the specific implementation of the business logic inside each user control is poor. With postbacks taking as long as you describe, each control probably looks back to your DAL for its own data on each request. This can be mitigated by two things:
Make sure user controls cache all their data on first load and never re-load it unless explicitly instructed to (usually by an event from a lower-level service)
Ensure the controls all use a set of common services which can reuse data. E.g. if two controls need access to the customers list, and they are executing in the context of the same request session, that should only require one customer list lookup.
I'll put myself firmly in the camp of folks that suggest there is no hard limit to a number of user controls that should be used on a page. It sounds like application-wide tracing is in order here instead of page-level tracing. It may very well be that a handful of these controls is causing the problem. Heck, it could be a single control causing all the fuss. However, since it's impossible to make any assumption about the level of resource-usage that the "average" (if there is such a thing) user-control takes up, it's likewise impossible to suggest a limit. Otherwise, we'd be able to come up with similar limits to the number of members to a class or the number of stored procedures to a database.
Now, if we're talking about 20 complex user-controls that are each retrieving their own data with each refresh and each with a bunch of sub-controls using ViewState whether needed or not, then yeah, that's a problem. Still, it has more to do with overall design than with there being too many controls. If, on the other hand, they've created a common user control to act as nothing more than the composite of a label to the left of a textbox (or maybe even every combination of label + user-actionable control) and have sprinkled this control throughout the app, I can imagine that you'd get a bunch of these on a page and I can't see why that would necessarily hurt anything.
I take it that you are not familiar with applications which use so many user controls?
It sounds like you may be jumping to the conclusion that this unfamiliar aspect of the application is the cause of the unfamiliar bad performance. Instead of making assumptions, why not try one of the following profiling tools, and find out:
JetBrains' dotTrace
Red-Gate ANTS
Automated QA's AQTime
These can all do memory and CPU profiling of ASP.NET applications.
I believe that one of the key purposes of UserControls is code reuse. That is, if the same functionality occurs on multiple web pages, then it is better to create a UserControl for it. That not only saves the developer from writing (or copying and pasting) the same code to several web pages, but it also makes maintenance much easier. Any change made to the UserControl is implemented automatically everywhere the UserControl is used. The maintenance developer doesn't have to worry about finding all the different places that the code needs changing.
I'm not sure if a single-use UserControl is as effective. They do encapsulate and segreate the code, which is nice on a busy web page.
Can you ascertain whether your UserControls are reused, or are many of them only used once.
I agree with Saunders about doing some profiling to determine the impact certain things have.
Note that you can get some free stress-testing tools for IIS here: http://support.microsoft.com/kb/840671
I will say, though, that having too many controls is probably not a good thing, IMHO. Without knowing more, I'd tentatively say 20 is too many.
Currently I am working on a web page that has six ReportViewer controls that are using remote processing and that allow for drill-down. When a user clicks on one control the entire page refreshes and the other five reports all refresh as well. Users are currently requesting that the refreshing of the other controls be removed in favor of only the one they click on refreshing. Is there a way of doing this, I've noticed that in Sharepoint that clicking a drill-down report does not require the entire entire page to be reloaded and I'm wondering if I can provide the same functionality.
I have been doing some more research on this issue and it looks like the AsyncRendering property of the ReportViewer control controls the functionality that I'm looking for. When it is set to "false" it prevents the "Report is Being Generated" message from being displayed which is what the users were commenting on. The downside is that the page can take a bit longer to load than before, but as we are working on a development machine this might not be as noticeable once we move to the actual production box.