现在的位置: 首页 > 综合 > 正文

Asp.Net页面请求性能大隐患 你是否做了这样的事情

2013年03月25日 ⁄ 综合 ⁄ 共 2321字 ⁄ 字号 评论关闭

  项目测试中,客户向我们反应,某个页面请求速度特别慢,简直无法忍受。这里简单插一些情况的描述:对于一个使用人数、并发操作并不多的项目,客户不会过多的在性能上提出要求,对他们来说,多几百ms的等待时间,不会带来更多情绪。

    但是,当你请求某个页面后,去泡杯茶回来,发现页面还死死的在那里,进度条不紧不慢的一点一点增长,就无法忍受了。利用Firefox的debug[ debug ?]测了一下,平均请求时间19s左右,而光import那个页面所需要的时间就是18s多,问题肯定出在页面上。

    那个页面是被IFrame包含进来的,包含5个TextBox、4个DropdownList、3个CheckBox、3个Button(作为分页的查询条件),下面就是分页的DataGrid(每页10条数据)。我注意到其中有一个DropdownList的ListItem有200多项,查了一下Response,发现ViewState黑压压一块。显然,这也是影响性能的一个原因[一次取一页数据]。

    在跟客户商量后,将这个DropdownList改成了TextBox,做成模糊查询。恩,速度到了15s左右,快了3到4秒。这样的改善已经是很不错的成绩了,但是我们还要等待15s,显然无法让客户满意。 [DropDownList 数据项不要太多]

    这下问题就不明显了,我禁用了viewstate,发现并没有多少效果。页面数据量也不是很大啊,几个DropdownList的初始化,分页的实现是利用存储过程,在服务器数据库中,利用游标取记录条数。传递过来,也仅仅是10条而已。

    查看页面源代码发现N长的JS,是不是问题出在加载日期控件上呢?我将日期控件屏蔽了,再测,问题依旧,还是15s!!

    感觉有点束手了,测试其他页面,没有问题,响应速度很理想,甚至是一些控件N多的页面。

    不经意间点分页的“下一页”,恩,时间很漫长!可是我下一页的操作,只读取了下一个10条数据啊!我在服务器查询分析器下测试了存储过程,反应没问题。那问题应该是出在DataGrid的绑定了,这时候,我注意到,datagird中包含不少模板列,其中有不少LinkButton,涉及到显示不显示的逻辑操作,例如:

<asp:TemplateColumn>
        <HeaderStyle Width="50px"></HeaderStyle>                        
        <ItemTemplate>
                <asp:LinkButton id="lbtnEdit1" runat="server" CausesValidation="false" CommandName="Disabled" Visible=''<%# DataBinder. Eval(Container.DataItem, "IsDisable").ToString()=="1"  %>''> <span onclick="return confirm(''确认作废?'')">作废</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(''确认恢复?'')">恢复</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(''确认待报废?'')">待报废</span></asp:LinkButton>
        </ItemTemplate>
</asp:TemplateColumn>

    顿时,有了个想法,会不会是触发ItemDataBind事件,遍历表格控件时,消耗系统资源呢?

    将这部分功能屏蔽,果然!效果理想,响应时间到了3s左右,速度差强人意。我暗舒口气......

    总结:

    viewstate利弊共存,怎么使用,值得权衡。有时候,没有办法,不妨跟客户沟通一下,变换一些实现方法。

    永远不要在ItemDataBind时,做太多事情。不妨,将数据处理放在数据库(视图、存储过程)、或者是在绑定之前,写方法处理。

    性能永远是一个隐形的需求,而我在这方面经验匮乏。尤其是,目前的项目规模小,那些在code时,留下的挥霍内存的变量声明、占用CPU的循环、遍历算法的行为随处可见。现在,我们能做的,就是在意识到这些后,一点点的改变这些习惯把。

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

抱歉!评论已关闭.