使用Telerik网格提高ASPX页面性能

时间:2014-04-09 06:39:16

标签: javascript asp.net telerik-grid pagemethods ie8-compatibility-mode

我的问题与改进aspx页面的性能有关。因此,在阅读本文后,请评论是否有可能提高此页面的性能。

以下是该方案。

我正在使用以下工具开发一个asp.net Web应用程序

  1. .Net 3.5
  2. 类型化数据集(10个表格)
  3. IE 8兼容性视图-IE7标准(应用程序无法在FF,Chrome或任何其他浏览器上运行)
  4. Telerik RadControls。 (网格,数字文本框,带自动填充的下拉菜单)
  5. App Fabric Cache。
  6. Jquery和其他特定页面的javascripts。
  7. ASPX页面包含

    1. 8个网格(其中6个为telerik网格,2个为html表格)
    2. 所有telerik网格都定义了EditFormTemplates。
    3. 很多控件(我不知道实际使用了多少控件,所以我不太热衷于清理aspx页面,因为这可能需要很多dev / qa工作,遗憾的是现在不能选择。)
    4. RadScriptBlock中的很多javascript。(我们还有javascrtip,它可以摆弄网格的宽度和其他UI)
    5. 为页面上的所有网格和控件启用ViewState。
    6. 这些网格上的操作是 - 插入,更新,删除,复制,全部删除。

      所有这些操作都是通过重复的回复来完成的。

      由于大多数数据都缓存在appfabric中,因此数据库命中次数不多。

      现在这可能听起来很糟糕,但这个单页中有数千行代码。代码中约有30k行,jS中有5k行,aspx页面中有大约4k行(html / js组合)。 后面的代码中存在复杂的逻辑,它运行在页面加载以及每个部分回发上,并且大多数网格几乎在每次回发时都被重新绑定(编辑)。

      我们为提高绩效所做的事情(这没有多大帮助)。 注意:重新编写整个页面不是一个选项,因此所有增强功能都必须放在此页面中。

      1. 缩小所有javascripts,CSS
      2. 在Radscript漫画中添加了所有脚本脚本集合(我不知道这在任何情况下都会有所帮助,但是被告知这样做。)
      3. 将在aspx上编写的所有javascript移动到RadScriptBlock
      4. 中的js文件
      5. 重构了大量代码并最大限度地减少了appfabric(push,get)的使用。
      6. RadCompression已经实施。
      7. 所有网格都使用服务器分页(每页5条记录)。
      8. Page几乎没有任何静态内容。 页面缓存,片段缓存无法查看此页面的用法

        我不知道这是否令任何人感到惊讶,但此页面上的部分回发操作大约需要4-6秒(Request + Response + Render)。我认为这很有意思,看看后台运行的代码。但客户并不喜欢这样。

        期望页面上的任何操作都不应超过1-1.5秒。

        问题

        1. 是否可以通过查看此页面中使用的基础架构来提升性能
        2. 如果可能的话,我可能缺少的是什么,这可以使页面表现更好。
        3. 我看到每个网格的ItemCreated和ItemDatabound被调用的次数比RowCount多很多倍。我知道这是针对每个项目,即页眉,页脚和项目,但如果我的行数为5,为什么这些方法被调用超过10次?
        4. 我在代码中看到开发人员像疯了一样使用Rebind()方法(可能这是#3的原因)。任何人都可以告诉我调用Rebind的正确方法和位置是什么?我知道Telerik网格调用会重新插入插入内容,但在什么情况下我们需要显式调用rebind?
        5. 我正在尝试检查整个代码库并试图找出瓶颈。

          如果有人给我任何建议我准备试用代码,我真的很感激。

          如果需要更多信息,请与我们联系。

          谢谢。

          修改

          在分析之后,我检查了整个页面的视图状态,大约是33kb。此外,当我从页面中删除AjaxSettings时,页面在2/3秒内加载速度非常快。所以我觉得页面的Ajax化在渲染页面时会产生一些问题。

          我还记录了服务器进程时间,根据哪个网格运行需要大约1/2秒。

2 个答案:

答案 0 :(得分:1)

经过大量分析,挖掘不同层次,我们发现有几个存储过程是罪魁祸首。还向程序确定了不必要的电话,这使得页面的速度相当缓慢。修复使我们获得了良好的性能提升。我们还必须在网格渲染事件中进行一些调整。

不确定这个答案是否有助于将来的某个人,但我希望至少它会给出一些指示。 Dynatrace在这个练习中变得非常方便。

答案 1 :(得分:0)

我有一些示例,其中没有正确配置Telerik的数据访问,这导致数百个单独的SQL查询弹出控件而不是执行一次查询所有数据的单个查询。 不要重复我们分析和修复它的所有步骤,我希望如果我只是将链接发布到我写的关于此的博客文章中就可以了:http://apmblog.dynatrace.com/2014/04/03/database-access-patterns-gone-wild-inside-telerik-sharepoint-and-asp-net/