ASP.NET 2.0 Performance Inspection Questions - Pages

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Srinath Vasireddy, Ashish Babbar, Rico Mariani, and Alex Mackman


Have you taken steps to reduce your page size?

Try to keep the page size to a minimum. Large page sizes place increased load on the CPU because of increased processing and a significant increase in network bandwidth utilization, which may lead to network congestion. Both of these factors lead to increased response times for clients. Consider the following guidelines to help reduce page size:

  • Use script includes (script tags rather than interspersing code with HTML).
  • Remove redundant white space characters from your HTML.
  • Disable view state for server controls where it is not needed.
  • Avoid long control names.
  • Minimize the use of graphics, and use compressed images.
  • Consider using cascading style sheets to avoid sending the same formatting directives to the client repeatedly.

Is buffering disabled?

Ensure that you have buffering enabled. Buffering causes the server to buffer the output and send it only after it has finished the processing of the page. If buffering is disabled, the worker process needs to continuously stream responses from all concurrent requests; this can be a significant overhead on memory and the processor, especially when you use the ASP.NET process model.

To find out if you have buffering disabled, you can search your code base for the following strings: "buffer" and "BufferOutput."

Make sure that the buffer attribute is set to true on the <pages> element in your application's Web.config file.

  <pages buffer="True">

Do you use Response.Redirect?

Search your code for "Response.Redirect" and consider replacing it with Server.Transfer. This does not incur the cost of a new request because it avoids any client-side redirection.

You cannot always simply replace Response.Redirect calls with Server.Transfer calls because Server.Transfer uses a new handler during the handler phase of execution. Response.Redirect generates a second request. If you need different authentication and authorization, caching, or other run-time devices on the target, the two mechanisms are not equivalent. Response.Redirect causes an extra request to be sent to the server. Response.Redirect also makes the URL visible to the user. This may be required in some scenarios where you require the user to bookmark the new location.

Do you use Page.IsPostBack?

Check that the logic in your page uses the Page.IsPostBack property to reduce redundant processing and avoid unnecessary initialization costs. Use the Page.IsPostBack property to conditionally execute code, depending on whether the page is generated in response to a server control event or whether it is loaded for the first time.

Do you validate user input?

Check that you validate user input on the client to reduce round trips to the server. This also provides better feedback to the user. For security reasons, ensure that any client-side validation is complimented with the equivalent server-side validation.

For more information about validation design guidelines for building secure .NET Web applications, see Web Application Security Design Guidelines - Input / Data Validation.

Have you set Explicit and Strict to true?

Ensure you use Option Strict and Explicit to reduce inadvertent late binding when using Visual Basic .NET.

  <%@ Page Language="VB" Explicit="true" Strict="true" %>

This can be easily searched for by using the Findstr.exe file with regular expressions.

  C:\findstr /i /s /r /c:"<%.*@.*page.*%>" *.aspx
  pag\default.aspx:<%@ Page Language="VB" %>
  pag\login.aspx:<%@ page Language="VB" %>
  pag\main.aspx:<%@ Page Language="VB" Explicit="true" Strict="true" %>

Have you disabled debugging?

Check your Web.config file and ensure debug is set to false in the <compilation> section and check your .aspx pages to ensure debug is set to false. If debugging is enabled, the compiler does not generate optimized code and pages are not batch compiled.

You can check your .aspx pages by using the Findstr.exe file with regular expressions.

  C:\pag>findstr /i /r /c:"<%.*@.*page.*debug=.*true*.*%>" *.aspx
  login.aspx:<%@ page Language="VB" Debug="True" %>
  main.aspx:<%@ Page Language="c#" Debug="True" %>

Have you disabled tracing?

Check your Web.config file to ensure trace is disabled in the <trace> section. Also check your .aspx pages to ensure trace is set to false.

You can check your .aspx pages by using the Findstr.exe file with regular expressions.

  C:\pag>findstr /i /r /c:"<%.*@.*page.*trace=.*true*.*%>" *.aspx
  login.aspx:<%@ page Language="VB" Trace="True" %>
  main.aspx:<%@ Page Language="c#" Trace="True" %>

Do you set aggressive timeouts?

Set timeouts aggressively and tune accordingly. Evaluate each page and determine a reasonable timeout. The default page timeout is 90 seconds specified by the executionTimeout attribute in Machine.config. Server resources are held up until the request is processed completely or the execution times out, whichever is earlier.

In most scenarios, users do not wait for such a long period for the requests to complete. They either abandon the request totally or send a new request which further increases the load on the server.

Related Items

For more information about the questions and issues raised in this section, see ASP.NET 2.0 Performance Guidelines - Pages.

Personal tools