ASP.NET Page performance

Question

We have a rather complex page that loads the user controls dynamically (some of them are nested). It is a very slow performing page.

Could adding the controls dynamically be adding to the bottleneck? Would it help if we add the control in the .NET cache object and not use LoadControl if it already exists in the cache?

Any other tips/strategies on making the page faster?

Answer 1

We once improved an ASP.Net project performance by an order of magnitude. Here is a list of the things we tried:

• Set SessionState to false or ReadOnly when possible. Note that the method for setting session state is different for ASPages, web services, and applications.
• Store session state in-process if possible.
• Set EnableViewState to false when possible.
• Use caching when possible.
• Use HTML controls instead of server-side controls if you do not need access to the control from the server.
• Avoid round trips (submitting data to the server and reloading the page) when possible. Note that you only need to round-trip to read data from, or write data to, the server. Validation and feedback can be done client-side. Use the IsPostBack property in Page_Load to avoid regenerating data on postback.
• Use the StringBuilder class for repetitive concatenation.
• Use try/catch blocks only for unexpected situations; do not use them as general control constructs.
• Use early binding as much as possible. In other words, avoid reflection.
• Avoid unmanaged code such as COM.
• Disable debug mode for shipping apps.
• Use stored procedures for database access rather than SQL strings.
• Use the DataReader classes for reading data rather than DataSets.
• Use the most restrictive classes possible, such as SqlDataReader rather than DbDataReader.

Answer 2

将Trace =“true”添加到@Page指令中，您将能够看到哪些方法花费的时间最长。

Answer 3

I'd be a bit surprised if simply loading the controls dynamically incurred a large performance cost. However, if there are a lot of controls, and they are deeply nested, ASP.NET can sometimes be quite slow to render them to html. Obviously, do profiling as others have suggested to determine where your bottleneck really lies.

One thing to check, for a complex page, is the size of the rendered html. With many server controls, the page size can climb up to multiple megabytes surprisingly quickly. Turning on or tweaking your http compression may be the answer you're looking for.

Answer 4

The first step in investigating performance issues is identifying the bottleneck: is it network traffic (too many HTTP requests? too much HTML coming down the pipe?) or CPU bound on the server? or too many database calls?

In many cases it's the sheer size of the page that causes slowdowns. If you're including a lot of controls on your page then there will be a lot of HTML, so if you do a view source on the final rendered product and find 20000 lines of HTML/javascript then it's likely that the slowdown is too much data being sent over the network.

I suggest using a tool like YSlow to help gain a better understanding of the final rendered product.

Key items to look at:

• Managing the viewstate size
• Making sure parts of the page that are hidden are set to .Visible=False (instead of just style="display: none;")
• Centralizing and consolidating javascript
• Minimizing the number of HTTP requests

Answer 5

loading user controls dynamically is definitely not the reason for slow performance. one thing which generally deters an ASPX page performance dramatically is viewstate. I woudl recommend to take viewstate out of the page [even if you have enabled it on some of the controls].

Store the complete viewstate as a session variable on the server and only transfer the identifier in the viewstate field. you can take a look at the complete article here , the article also gives performance measurement metrics.

Answer 6

I would doubt that its the act of dynamically loading controls that's slowing it down and more the behavior of each control. Do they all hit the DB? I would see if you could streamline the performance of the controls (caching DB calls, etc) before trying to optimize their loading.

Answer 7

I would do some profiling on the page to see where the true slowdowns are occurring. Usually in my experience what I think might be causing the slowdowns in actuality are not the slowest spots. I have found it best to profile my apps/pages when things start running slow, that then gives me very good info on what areas I could best speed up to get dramatic improvents. You could find it is too many DB calls, or the usercontrol loading, or something else that you hadn't considered.

Answer 8

There are so many reasons why a web page can be a slow performer. You really need to use some tools like the Performance Wizard to start nailing down what's going on.

Our latest performance problems boiled down to anonymous types and linq. It is so easy to kill performance with those two things due to all the JIT compiling going on.