代码之家  ›  专栏  ›  技术社区  ›  Overflew

GridView+ObjectDataSource问题-大小结果集的性能同样差

  •  0
  • Overflew  · 技术社区  · 15 年前

    最近我接到一个旧的.NET旧版Web应用程序的电话。由于系统中的数据量翻了两番,性能最近已经下降到相当低的水平。在过去的2年里一直很好。

    它使用一个.xsd文件与一个存储过程进行对话,该存储过程充分缩小了结果的范围(尽管没有分页),并通过一个ObjectDatasource将结果提供给了一个GridView。

    我脑子里的那部分 ,加载1个结果140或1200需要大约7秒。0个结果案例花费了几秒钟的时间。(GridView正在处理分页)

    使用SQL事件探查器,我们可以看到查询花费了6.9秒。在SQL Management Studio中,使用相同的参数运行相同的查询需要100毫秒。我更改了周围的参数以确保它不仅仅是缓存的结果。长等待时间是可靠的可重复性。

    我知道 implementing paging 需要在这里完成,但现在我只是回顾性地试图在页面执行的背后找到一个解释。 同样差 对于小的和大的集合…

    (GridView的“简单”显示可以满足他们的需要-无需控制HTML)

    2 回复  |  直到 15 年前
        1
  •  2
  •   Andomar    15 年前

    我们有同样的问题:

    1. 检查您的统计数据是否最新:
        SELECT 
            ObjectName = Object_Name(ind.object_id),
            IndexName = ind.name,
            StatisticsDate = STATS_DATE(ind.object_id, ind.index_id)
        FROM SYS.INDEXES ind
        order by STATS_DATE(ind.object_id, ind.index_id) desc
    
    1. 删除SQL Server缓存:
        DBCC DROPCLEANBUFFERS
        DBCC FREEPROCCACHE
    
    1. 如果两者都不起作用,您可以尝试使用诸如“inner loop join”和“with(index=…)”之类的提示来实施SSMS查询计划。
        2
  •  1
  •   chris    15 年前

    您可以尝试查看从应用程序发送的执行计划和参数类型。例如,如果应用程序正在传递nvarchar与varchar列进行比较,则可能会导致问题。 http://weblogs.sqlteam.com/tarad/archive/2007/11/16/60408.aspx