We have one page which is about 300 KB after compression of viewstate. It's loading very slow. We are using telerik tabstrip. There are 8 user controls being loaded for this tab. Is there anyway we can improve the performance of this page? Any ideas please.
Thanks..
Yes, don't enable viewstate is one approach. Alternatively, you could load each tab on demand, so when the tab is clicked, cause a postback, and show that tab's content (which could be wrapped in a RadAjaxPanel from Telerik).
Lastly, Telerik has a rich web service model; bind the information to the UI via web services when the tab is clicked. This is something we had to do and it worked out very well performance-wise.
HTH.
You can try page level caching - here
In terms of the RadTabStrip itself you could also potentially look into using the Load-on-Demand feature as well, found on this demo page.
As for overall page efficiency if you are using the Telerik RadControls already you could look into using the RadAjax control; particularly the RadAjaxManager. This will allow you set up partial postbacks and get a more efficient page. A demo of this can be found here.
Our of the box use of the telerik tab control is not efficient. Each tab not in use STILL GETS put through the page lifecycle. There isn't anything that you can do about that out of the box, but with a little extra configuration you can gain some efficiency.
For the tab that is to be shown, you can dynamically LoadControl for the UserControl that is to be shown on the selected tab.
Have you enabled RADCOMPRESSION ?
http://www.telerikwatch.com/2009/01/optimization-tips-radcompression-module.html
You could always not use telerik! It creates such a heavy internal dependence on itself with bloated, unnecessarily complex features it makes me want to vomit. Do it yourself for best results...MVC rocks! Or just follow the answers above and get ready for lots of trial and error... :sadface:
Related
Hello I am trying to lear how to create Dynamic User Controls in asp.net.
I just know that this type of controls are created or loaded at run time.
Someone knows a good tutorial about this topic?
thanks in advance,
The best thing you can learn about dynamic controls in ASP.Net webforms is how to avoid them. Dynamic controls in asp.net are filled with pitfalls. I almost always recommend one of the following alternatives:
Place a reasonable fixed number of controls on the page, and then only show the ones you need.
Figure out the source for the dynamic controls and abstract it out to a datasource (array, ienumerable, list, etc) that you can bind to a repeater, even if it's just a call to Enumerable.Range().
Build a user control that outputs the html you want, bypassing the entire "controls" metaphor for this content.
If you really must work with dynamic controls, it's important to keep the stateless nature of http in mind, along with the asp.net page life cycle. Each adds it's own wrinkle to making dynamic controls work: the former that you need to create or recreate the controls every time you do a postback, and the latter that you need to do this before hitting the page load event - usually in page init or pre-init.
Typically what people are talking about here is the dynamic instantiation and addition of a control to a placeholder.
For example
Control ControlInstance = LoadControl("MyControl.ascx");
myPlaceholder.Controls.Add(ControlInstance);
The above instantiates MyControl.ascx and places it inside of a placeholder with id of myPlaceholder.
I agree with #Joel by knowing the page lifecycle, the stateless nature in mind etc it is possible to avoid the pitfalls. The main things to watch out for, which I have had to do, are:
Page_Init – initialise the controls that are on the page here as they were the last time you rendered the page. This is important as ViewState runs after Init and requires the same controls initalised the same way as the way they were previously rendered. You can load the control using the code from #Mitchel i.e.
Control ControlInstance = LoadControl("MyControl.ascx");
myPlaceholder.Controls.Add(ControlInstance);
Page_Load – Load the content of the controls in here as you would with any control that isn’t dynamically loaded. If you have kept a reference to them in your page_init they will therefore be available here.
Keeping to this structure I haven’t had too much difficulty as this is appears to be the way that ASP.NET was designed to work, even if all the samples on MSDN don’t do it this way. The biggest thing that you then have to watch is tracking what state the page was in in regard to the controls that you have had rendered.
In my case it was take the section number of the multipage survey and reload the questions from the database, so all I had to do was track the currently rendered section number which wasn’t difficult.
Having said all that if you are using dynamic controls just to show and hide different views of the same screen then I suggest you don’t use them. In this case I would much rather use either user controls (with the inappropriate ones hidden), placeholders to mark areas that aren’t to be rendered yet, or separate pages/views etc. as that way you keep the pages to a single responsibility which makes it easier to debug and/or get useful information from the user about which page they were on.
The Microsoft article is very good, but the best article that I have been read is in the bellow link:
https://web.archive.org/web/20210330142645/http://www.4guysfromrolla.com/articles/092904-1.aspx
If you are really interested in ASP.NET Web Forms dynamic controls, I recommend that you study the DotNetNuke CMS Portal. DotNetNuke is one of the best cases using dynamic controls as your core feature to build dynamic portals and pages using ASP.NET Portals. It is free for download in www.dotnetnuke.com.
I hope it helps
I have a web page devoloped in visual studio 2008.
I have 4 dropdowns and a repeater in the page.based on the selection(search criteria) from the dropdowns the repeater value will change.
and one dropdown selection will bind values to the other dropdown also.
Since the page is causing a lot of postback we decided to implement ajax here.
I am yet to learn ajax.
Can anyone tell what is the best way to do this .which ajax control replace dropdowns?
i have already server side code written on all dropdowns.
Please give me a good solution which i can implement in less time and reuse my code.
One more update: i have a master page used in the project.
I am using update panel of ajax which does not work if i use master page.
(That means all the dropdown controls and repeater i put it in update panel.But still page postback occurs.)
In a normal page(without master page) it works? why is this happening?
Thanks
SNA
You are able to use UpdatePanel and place dropdowns inside it.
Your solution will depend on the AJAX framework you choose, but here are cascading dropdown examples in ASP.NET AJAX and jQuery
If your main reason for using AJAX is to remove the number of postbacks you are getting, then I would recommend against using Microsoft's built in solution, e.g updatepanels.
The learning curve will be higher but learn to use jQuery, maybe with a little help from jTemplate to help you build your drop downs on the page.
Using updatepanels will not reduce your postbacks as behind the scenes asp.net is doing a full page life-cycle, sending all content back to your client but only updating the update panel. jQuery will be far more efficient. (and the reason I use it!!)
Update
If you don't believe me, see... Why Update Panels are dangerous
Update #2
If you don't want to go the whole way of learning Ajax just yet (although I'd recommend it) you could always pre-load your page with all the possible drop down combinations and then swap them using javascript / javascript + jQuery.
Here is one example of how you may do it -- use jQuery for dependent drop down combos
Using this method you are more likely to be able to save the code you've already written to work out the drop down options.
Which control is best in terms of performance... multi-view or TabContainer in asp.net ?
According to your description I would probably don't use any of those two controls. I wouldn't go with tabs as you don't really need to be able to switch between them all the time as is seems. The tabs container uses javascript to enable you to change tab on the client side.
About the multiview. I find it bad practice to have that much different logic in the same place and it will probably give you problems later on. In my opinion and experience it's usually better to split that up in different pages and have one for each thing you want to add/modify (you can have the delete at the modify page and/or in the listings). I would recommend to stay away from the multiview control for tasks like this, as I think that having one page to show multiple pages is usually a bad idea.
As far as i know TabContainer isn't a native control in ASP.NET, you could use TabStrip from microsoft.web.ui.webcontrols, but this is limited to Internet Explorer.
So if you have TabContainer from a third party source, use MultiView which is native to asp.net therefore faster. But everything in ASP.NET eventually renders as basic HTML.
I don't know how they render in HTML.
I'm using a ReportViewer control which often runs into problems with the javascript associated with UpdatePanels in ASP.NET. I've created a second page which is very simple, no Update Panels. What's the best way to link the two pages? An iframe sounds bad. However, having to run a report, then be returned a link to the results also sounds bad. Sending the user to the simple display won't work in this case. Any suggestions, am I seeing things wrong here?
What I would do is rewrite the page that uses an update panel such that it uses straight javascript web method calls. This would remove the need for the reportviewer control to be on a seperate page because you would no longer need an update panel.
For example,
If I have a textbox with runat=server on a page, The value will be posted back to the server so I can access the properties in the code-behind.
However, under the following situations, does it still hold true?
A textbox with runat=server but does not appear in the function that is post back to. For example, a button is also on the page, when clicked a post back occurs and within the method that is raised, this textbox was not used.
Within a MasterPage, will a textbox residing on the Masterpage itself be posted back?
Because just thinking, isn't this mechanism bloated in nature?
If all input controls and its value are posted back on every single button click (even when the input control is not needed), doesn't this deteriorate performance?
Having just one Form Tag on the page really restricts us to using this mechanism?
Truly Understanding ViewState is a must read article on the subject of ASP.NET ViewState
There are several options to cut down on the bloat (and yes, there's a lot of it when dealing with lots of controls):
Use AJAX to post only the items required - although be careful to allow clients that don't have JavaScript enabled to still use the page/ site.
The MVC framework allows multiple form tags to be used so you can group sections if needs be.
Set the EnableViewState to false on pages/ controls.
Break up your pages into smaller ones.
Additionally, check out this brilliant graphical representation of the Page Life Cycle in ASP.NET.
Every input on the page is posted back fully unless you use ajax, because of the single form tag. Welcome to asp.net...
As long as the method that you're hitting on the server-side is a non-static member of the page's class, it'll have access to the textbox and all other controls on the page.
And yes, all controls rendered to the browser (whether in the MasterPage, user control, etc.) will be available on post-back.
You may want to look into Understanding ASP.NET View State.
There surely are performance hits with this architecture, but (depending on complexity of the page) it's usually not an issue from the server load perspective, because hardware upgrades are typically cheaper than additional programming hours spend on optimizing application performance.
With that said, (and as others have pointed out) look into using AJAX if you want to avoid whole page-level postbacks to the server.
Yes, it's all posted back, and yes it can cause bloat. I'm sure if you search for ViewState you will find plenty of people ranting about it and how to minimise it :)
Yes your text box will be available in both cases, yes it is bloated. This is where AJAX comes into play. Using AJAX you can send just the data you need.
If you want to send a minimal ammount of data, you could use a Page Method (static method on page decorated so the script manager builds javascript to call it or you could call it using jquery or other methods), or a script enabled web service works nice as well.
You also have viewstate which can get very large. ASP.Net MVC is a new paradigm instead of using WebForms which doesn't have view state, or post backs. It embraces HTTP instead of hidding it giving developers more control.
The textbox data would be posted back as noted. In addition to using Ajax, disabling view state greatly imporoves your page's performance though even then data in properties critical to the functioning of controls (Control state) would still be posted back.
If you didn't have postback for every control on the form, you wouldn't be able to access it in code-behind. I.e. if in your button press you wanted to modify the property of the text control you couldn't do that because ASP.Net would know nothing about the text control.
Since the communication between the server and the client is stateless and every time a page is server the server forgets all about it Postbacks are important if you want to work with the same page again. No matter what programming language you use, this or similar mechanism exists for processing server side code.
If you wish to minimize postback (viewstate size), do this.
Set enableviewstate=false on all controls that you don't want posted back.
Use AJAX and web services wherever possible (and don't use UpdatePanel).
Use HTML control as much as possible instead of ASP.Net controls.
Hmm.. There are some excellent suggestion in other answers and good links too.
You've pretty much hit the nail on the head with vanilla ASP.NET - it's not very good! In both the instances you describe the answer is yes - the textbox will be sent with the form.
The whole postback/ViewState problem is a bit of a pain, one of the first things any competent ASP.NET developer learns to do is avoid them!