Hi all,
I've got a RadNumericTexBox inside an ASP.Net Repeater. They are wrapped in a
RadAJAXPanel. In the worse case scenario I'll have 200 of them displayed in my
page.
I've noticed that when I've changed my regular TextBoxes to RadNumerixTextBoxes,
my app's performance dramatically decreased. I’ve been reading several posts trying
to work out why this is happening. I’ve also implemented some tips like Skin=”None”
but nothing has changed.
I’d like to know if you guys have any idea of how I could improve my page’s performance for this scenario. I do need to use the numeric textbox and I don’t really want to write one myself
I look forward to hearing from you!
Andre.
7 Answers, 1 is accepted
Rank 1
I am sorry to hear you are having performance problems with the RadNumericTextBox. I believe the problem you are having is due to the sheer number of controls you are trying to add to your page. Each requires its own initialization in the client-side javascript library, and as such adds a certain size to the page when it is added. This is not an issue when only using a few on the page, but when you add as many as you have, the page size starts to get too large. I don't think the RadNumericTextBox was designed to scale to such a large number.
One way to speed up performance is to disable the embedded stylesheets and skins by setting the EnableEmbeddedBaseStylesheet and EnableEmbeddedSkins properties to false (assuming you do not need them). This saved me approximately 200k in resource downloads on the first page hit (subsequent hits use the cached resources).
Another option you might use is instead of loading up to 200 of the controls all at once on your page, you might consider using the RadGrid and loading a smaller number of them at a time. You can then use the paging feature to navigate to the controls you need to use. Here is an example using 200 records from the Northwind database:
| <%@ Page Language="C#" AutoEventWireup="true" CodeFile="RadNumericTextBox.aspx.cs" Inherits="RadNumericTextBox" %> | |
| <%@ Register Assembly="Telerik.Web.UI" Namespace="Telerik.Web.UI" TagPrefix="telerik" %> | |
| <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> | |
| <html xmlns="http://www.w3.org/1999/xhtml"> | |
| <head runat="server"> | |
| <title>Untitled Page</title> | |
| </head> | |
| <body> | |
| <form id="form1" runat="server"> | |
| <telerik:RadScriptManager ID="RadScriptManager1" runat="server" /> | |
| <telerik:RadGrid ID="RadGrid1" runat="server" | |
| AllowPaging="True" | |
| PageSize="20" | |
| AutoGenerateColumns="False" | |
| DataSourceID="SqlDataSource1" | |
| GridLines="None" | |
| ShowHeader="False"> | |
| <MasterTableView DataSourceID="SqlDataSource1"> | |
| <Columns> | |
| <telerik:GridBoundColumn DataField="ShippedDate" DataFormatString="{0:d}" /> | |
| <telerik:GridBoundColumn DataField="ShipName" /> | |
| <telerik:GridBoundColumn DataField="ShipCountry" /> | |
| <telerik:GridTemplateColumn> | |
| <ItemTemplate> | |
| <telerik:RadNumericTextBox ID="RadNumericTextBox1" runat="server" /> | |
| </ItemTemplate> | |
| </telerik:GridTemplateColumn> | |
| </Columns> | |
| </MasterTableView> | |
| </telerik:RadGrid> | |
| <asp:SqlDataSource ID="SqlDataSource1" runat="server" | |
| ConnectionString="Data Source=.\SQLSERVER;Initial Catalog=Northwind;User ID=sa;Password=*********" | |
| ProviderName="System.Data.SqlClient" | |
| SelectCommand="SELECT TOP 200 [ShipName], [ShipCountry], [ShippedDate] FROM [Orders]"> | |
| </asp:SqlDataSource> | |
| </form> | |
| </body> | |
| </html> | |
These approaches gave me the following download sizes per page-hit.
Repeater (first hit): 802,867 K
Repeater (subsequent hits): 599,083 K
RadGrid (first hit): 469,157 K
RadGrid (subsequent hits): 83,993 K
As you can see, using the RadGrid resulted in a 42% decrease in download size on the first hit and an 86% decrease in the download size on each subsequent hits. The downside of having to page through the records instead of having them all displayed on the page will give the benefit of a much more responsive page.
I hope this was helpful. Please let me know if you have further questions.
Sincerely,
Kevin Babcock
Rank 1
Unfortunately that didn't help. I really need to have a repeater as I have a custom layout i.e. divs, tables and so on and so forth ....
Do you have any other ideas?
Also, I could not set the properties you talked about: EnableEmbeddedBaseStylesheet and EnableEmbeddedSkins. I'm using Q1 2008 version.
Thanks,
Andre.
Rank 1
I'm also getting the warning:
"A script on this page is causing Internet Explorer to run slowly. If it continues to run, your computer may become unresponsive.
Do you want to abort the script?"
A page taking a while to render is one thing, but having IE prompt you everytime a page is hit is unacceptable. I'm hoping Telerik can respond with a proper work around.
I have one Numeric Text box that's inside a nested repeater. When the page loads the file size is 1.2 MB. If I remove the text box, it's now 200K. That's crazy talk. There's got to be a much better way of handling things.
Andre, thanks for the info too. Glad to see it wasn't just me there.
Rank 1
Many developers don't take the time to structure their applications for great performance. I'm going to present some tips that I have found here for writing high-performance asp web applications:
Use Server Controls Where Appropriate
The HTTP protocol is stateless; however, server controls provide a rich programming model that manages state between page requests by using view state. Server controls require a fixed amount of processing to establish the control and all of its child controls. This makes server controls relatively expensive compared to HTML controls or possibly static text. Scenarios where server controls are expensive include the following:
- Large payload over low bandwidth. The more controls that you have on a page, the higher the network payload is. Therefore, multiple controls decreases the time to last byte (TTLB) and the time to first byte (TTFB) for the response that is sent to the client. When the bandwidth between client and server is limited, as is the case when a client uses a low-speed dial-up connection, pages that carry a large view state payload can significantly affect performance.
- View state overhead. View state is serialized and deserialized on the server. The CPU effort is proportional to the view state size. In addition to server controls that use view state, it is easy to programmatically add any object that can be serialized to the view state property. However, adding objects to the view state adds to the overhead. Other techniques such as storing, computed data or storing several copies of common data adds unnecessary overhead.
- Composite controls or large number of controls. Pages that have composite controls such as DataGrid may increase the footprint of the view state. Pages that have a large number of server controls also may increase the footprint of the view state. Where possible, consider the alternatives that are presented later in this section.
When you do not need rich interaction, replace server controls with an inline representation of the user interface that you want to present. You might be able to replace a server control under the following conditions:
- You do not need to retain state across postbacks.
- The data that appears in the control is static. For example, a label is static data.
- You do not need programmatic access to the control on the server-side.
- The control is displaying read-only data.
- The control is not needed during postback processing.
Alternatives to server controls include simple rendering, HTML elements, inline Response.Write calls, and raw inline angle brackets (<% %>). It is essential to balance your tradeoffs. Avoid over optimization if the overhead is acceptable and if your application is within the limits of its performance objectives.
Avoid Creating Deep Hierarchies of Controls
Deeply nested hierarchies of controls compound the cost of creating a server control and its child controls. Deeply nested hierarchies create extra processing that could be avoided by using a different design that uses inline controls, or by using a flatter hierarchy of server controls. This is especially important when you use list controls such as Repeater, DataList, and DataGrid because they create additional child controls in the container.
For example, consider the following Repeater control.
| <asp:repeater id=r runat=server> |
| <itemtemplate> |
| <asp:label runat=server><%# Container.DataItem %><br></asp:label> |
| </itemtemplate> |
| </asp:repeater> |
Assuming there are 50 items in the data source, if you enable tracing for the page that contains the Repeater control, you would see that the page actually contains more than 200 controls.
Table 6.2: Partial Repeater Control Hierarchy
| Control ID | Type |
|---|---|
| Repeater | System.Web.UI.WebControls.Repeater |
| repeater:_ctl0 | System.Web.UI.WebControls.RepeaterItem |
| repeater_ctl0:_ctl1 | System.Web.UI.LiteralControl |
| repeater_ctl0:_ctl0 | System.Web.UI.WebControls.Label |
| repeater_ctl0:_ctl2 | System.Web.UI.LiteralControl |
| repeater:_ctl49 | System.Web.UI.WebControls.RepeaterItem |
| repeater_ctl49:_ctl1 | System.Web.UI.LiteralControl |
| repeater_ctl49:_ctl0 | System.Web.UI.WebControls.Label |
| repeater_ctl49:_ctl2 | System.Web.UI.LiteralControl |
The ASP.NET list controls are designed to handle many different scenarios and may not be optimized for your scenario. In situations where performance is critical, you can choose from the following options:
I hope the provided information is helpful.
<John:Peel />
Rank 1
I'm actually converting an existing .asp page into an .aspx page so how the page functions is already determined, I don't have any options in how to display the data. I was hoping Telerik had something like a 'render on server' option that would put the strain on the server, not the desktop.
The warning I got was for Internet Explorer itself rendering the controls, not the server. A page that takes a while to show is reasonable, one that tells the client that processing the javascript is taking too long is no good.
John, was there supposed to be a list after "In situations where performance is critical, you can choose from the following options: " ? with the : it would seem a list would follow.
Thanks for the input though, I will see what I can alter.
Rank 1
That looks great. I won't have the time to play with the Beta, but I'll keep tabs on when the next release comes out. It'll save me a lot of headaches, as we've still got a huge number of inputs on some page.
Thanks for updating the post.