Asp.Net页面请求性能大隐患 你是否做了这样的事情-阿里云开发者社区

开发者社区> 开发与运维> 正文
登录阅读全文

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

简介:

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

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

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

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

    这下问题就不明显了,我禁用了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的循环、遍历算法的行为随处可见。现在,我们能做的,就是在意识到这些后,一点点的改变这些习惯把。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章
最新文章
相关文章