ASP. NET page request performance hazards have you done this?

In the project test, the customer responded to us that the request speed on a page was extremely slow and almost intolerable. Here is a brief description of some cases: For a project with a low number of users and a low number of concurrent operations, customers will not make too many performance requirements. For them, the waiting time of several hundred Ms does not bring more emotions.

However, when you request a page and come back with a cup of tea, you will find that the page is still dead, And the progress bar will grow slowly at 1.1 points, which will be intolerable. ExploitationDebug of Firefox[Debug?]After testing, the average request time is about 19 s, and the time required for the page to be imported is more than 18 s, the problem must be on the page.

The page is contained by IFRAME, which contains 5 Textbox, 4 dropdownlist, 3 checkbox, and 3 buttons (as the query condition of the page ), the following is the paged DataGrid (10 data entries per page ). I noticed that there was more than 200 listitems in one dropdownlist. I checked response and foundViewstateBlack press one piece. Obviously, this is also a reason that affects performance [Retrieve one page of data at a time].

After discussing with the customer, we changed the dropdownlist to textbox for fuzzy query. Well, the speed is about 15 s, which is 3 to 4 seconds faster. This improvement is already a good result, but we still have to wait for 15 s and obviously cannot satisfy our customers. [Not too many dropdownlist data items]

This problem is not obvious. I disabled viewstate and found that there was not much effect. The page data volume is not very big either. Several dropdownlist initialization, paging implementation is to use the stored procedure, in the server database, using the cursor to retrieve the number of records. The transfer is only 10.

View pageSource codeI found N-long JS, isn't the problem with loading the date control? I blocked the date control and tested it again. The problem is still 15 s !!

It feels a little cool. There is no problem in testing other pages, and the response speed is very good, even some pages with N controls.

Click "Next page" on the page inadvertently. Well, it takes a long time! However, I only read the next 10 pieces of data for the next page! I tested the stored procedure in the Server Query analyzer and the response was correct. The problem should be caused by the binding of the DataGrid. At this time, I noticed that javasird contains many template columns, including many linkbuttons, which involve logical operations for displaying non-displayed data, such:

<Asp: templatecolumn>
<Headerstyle width = "50px"> <Itemtemplate>
<Asp: linkbutton id = "lbtnedit1" runat = "server" causesvalidation = "false" commandname = "disabled" visible = ''<% # databinder. eval (container. dataitem, "isdisable "). tostring () = "1" %> ''> <span onclick =" Return confirm (''are you sure you want to invalidate it? '')"> Void </span> </ASP: linkbutton>
<Asp: linkbutton id = "lbtnedit2" runat = "server" causesvalidation = "false" commandname = "able" visible = ''<% # databinder. eval (container. dataitem, "isdisable "). tostring () = "2" %> ''> <span onclick =" Return confirm (''are you sure you want to recover? '')"> Restore </span> </ASP: linkbutton>
<Asp: linkbutton id = "lbtnedit3" runat = "server" causesvalidation = "false "-

Commandname = "disabling" visible = ''<% # databinder. eval (container. dataitem, "isdisable "). tostring () = "0" %> ''> <span onclick =" Return confirm (''are you sure you want to decommission? '')"> To be decommissioned </span> </ASP: linkbutton>
</Itemtemplate>
</ASP: templatecolumn>

Suddenly, I had an idea, would it be?Trigger itemdatabind eventWhich system resources are consumed when the table control is traversed?

Block this part of the function! The results were satisfactory. The response time was about 3 seconds, and the speed was unsatisfactory. I'm so angry ......

Summary:

The advantages and disadvantages of viewstate coexist. How to use it is worth balancing. Sometimes, there is no way, you may wish to communicate with the customer and change some implementation methods.

AlwaysDo not do too many things in itemdatabind.. You may wish to put data processing in a database (view, stored procedure), or write a method before binding.

Performance is always an invisible demand, and I have little experience in this area. In particular, the current project scale is small, and the variable declaration, CPU-consuming cycle, traversal, and squandering memory left during Code ExecutionAlgorithmBehaviors can be seen everywhere. What we can do now is to change these habits a little bit after realizing this.

from: http://www.diybl.com/course/4_webprogram/asp.net/asp_netshl/2008313/104552.html