加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 编程开发 > asp.Net > 正文

asp.net-mvc-3 – Glimpse HUD和SQL选项卡中数据库查询计数之间

发布时间:2020-12-16 06:38:50 所属栏目:asp.Net 来源:网络整理
导读:这个问题涉及Glimpse.MVC3和Glimpse.EF5包.我正在尝试在旧的MVC3站点上调试性能问题.根据Glimpse的HUD,一个特定的GET请求共有12个查询,总共28ms – 但是当我展开以打开主面板,然后单击SQL选项卡时,它说只有6个查询,总共10.41ms.顶部的计数都是6,当我计算它列
这个问题涉及Glimpse.MVC3和Glimpse.EF5包.我正在尝试在旧的MVC3站点上调试性能问题.根据Glimpse的HUD,一个特定的GET请求共有12个查询,总共28ms – 但是当我展开以打开主面板,然后单击SQL选项卡时,它说只有6个查询,总共10.41ms.顶部的计数都是6,当我计算它列出的查询时,有6个.当我看到编写的代码时,这也是有意义的. (无论哪种方式,我都可以看到太多是懒惰加载,它需要修复.)

没有来自Glimpse的指标,相同的6个查询正在被执行两次(当我看到HUD显示的面板数量是面板的两倍时,这就是我的大脑所在的位置).

此外,HUD显示0个Ajax请求,但历史部分实际显示1(这绝对是准确的).

有什么想法会出现差异吗? (请记住,我更关心与查询的差异.)

编辑 – 请求的文件中的JSON:

glimpse_sql:
{
  data:
  {
    "SQL Statistics":
    [
      {
        connectionCount: 6
        queryCount: 6
        transactionCount: 0
        queryExecutionTime: 6.91
        connectionOpenTime: 116.08
      }
    ]
    Queries:
    [
      [
        Commands per Connection
        Duration
      ]

hud:
  {
    sql:
    {
      data:
      {
        queryCount: 12
        connectionCount: 12
        transactionCount: 0
        queryExecutionTime: 41.87
        connectionOpenTime: 242.96
      }
      name: sql
    }

编辑2 – 查询

"Queries":[["Commands per Connection","Duration"],[[["Transaction Start","Ordinal","Command","Parameters","Records","Duration","Offset","Async","Transaction End","Errors"],[null,"1","SELECT TOP (2) rn[Extent1].[TrxnID] AS [TrxnID],rn[Extent1].[StartTime] AS [StartTime],rn[Extent1].[Lane] AS [Lane],rn[Extent1].[EmployeeID] AS [EmployeeID],rn[Extent1].[OptionsCompleted] AS [OptionsCompleted],rn[Extent1].[StoreID] AS [StoreID],rn[Extent1].[NoVehicleTireCheck] AS [NoVehicleTireCheck],rnFROM [Activity].[Trxn] AS [Extent1]rnWHERE [Extent1].[TrxnID] = 353 /* @p__linq__0 */",[["Name","Value","Type","Size"],["@p__linq__0",353,"Int32",0]],1,1.12,76.67,false,null,""]],5.85],"SELECT rn[Extent1].[TrxnID] AS [TrxnID],rn[Extent1].[CustomerID] AS [CustomerID],rn[Extent1].[FirstName] AS [FirstName],rn[Extent1].[LastName] AS [LastName],rn[Extent1].[RewardAccountID] AS [RewardAccountID],rn[Extent1].[CustomerEmail] AS [CustomerEmail],rn[Extent1].[HomePhone] AS [HomePhone]rnFROM [Activity].[Trxn_Customers] AS [Extent1]rnWHERE [Extent1].[TrxnID] = 353 /* @EntityKeyValue1 */",["@EntityKeyValue1",1.18,102.7,21.7],rn[Extent1].[VehicleID] AS [VehicleID],rn[Extent1].[VehicleVIN] AS [VehicleVIN],rn[Extent1].[VehicleOdometer] AS [VehicleOdometer],rn[Extent1].[VehicleEngineID] AS [VehicleEngineID],rn[Extent1].[VehicleMakeID] AS [VehicleMakeID],rn[Extent1].[ModelYear] AS [ModelYear]rnFROM [Activity].[Trxn_Vehicles] AS [Extent1]rnWHERE [Extent1].[TrxnID] = 353 /* @EntityKeyValue1 */",1.26,2301.56,27.72],rn[Extent1].[SecondaryVehicleID] AS [SecondaryVehicleID],rn[Extent1].[SecondaryVehicleVIN] AS [SecondaryVehicleVIN],rn[Extent1].[SecondaryVehicleTypeID] AS [SecondaryVehicleTypeID],rn FROM [Activity].[Trxn_SecondaryVehicles] AS [Extent1]rn WHERE [Extent1].[TrxnID] = 353 /* @EntityKeyValue1 */",1.15,2325.95,23.15],"SELECT rn[Extent1].[TrxnServiceID] AS [TrxnServiceID],rn[Extent1].[TrxnID] AS [TrxnID],rn[Extent1].[PackageID] AS [PackageID],rn[Extent1].[PartID] AS [PartID],rn[Extent1].[Qty] AS [Qty]rnFROM [Activity].[Trxn_Services] AS [Extent1]rnWHERE [Extent1].[TrxnID] = 353 /* @EntityKeyValue1 */",1.02,2342.92,15.74],"SELECT rn[Extent1].[TrxnNoteID] AS [TrxnNoteID],rn[Extent1].[NoteText] AS [NoteText],rn[Extent1].[NoteNumber] AS [NoteNumber],rn[Extent1].[SendToInvoice] AS [SendToInvoice]rnFROM [Activity].[Trxn_Notes] AS [Extent1]rnWHERE [Extent1].[TrxnID] = 353 /* @EntityKeyValue1 */",1.19,4689.34,21.92]

]},"name":"SQL"}

解决方法

好吧,我明白了.但首先,请看一下为解决问题需要采用的确切使用方案.

使用场景
只有在您:
一个.为上下文启用了延迟加载.
湾直接将您的EF模型传递给视图,不要使用视图模型(这不是好的做法,但这是遗留代码所做的).

我学到的是
1)事实证明,HUD显示的更高的查询数是正确的 – SQL Server Profiler揭示了这一点.

2)Glimpse本身似乎触发了额外的查询.当我打开元数据选项卡时,它似乎以某种方式访问??导航属性,导致延迟加载.如果我关闭Glimpse,或者打开Glimpse但禁用Metadata选项卡,则不会发生额外的查询.

说明
我花了一些时间来解决这个问题,因为我搜索了代码并构建了一个测试场景来隔离问题.在其中,我检索了一条记录,之后没有触及任何导航属性.单步执行它,我确信在我的代码中没有访问导航属性导致它 – 但仍然存在所有这些额外的查询由应用程序生成,我对它们来自哪里感到困惑.

我终于放弃了搞清楚,禁用了上下文的延迟加载(这会阻止额外的调用),但随后在其中一个导航属性上抛出了NullReferenceException.这个特殊的导航属性我已经急于加载,所以我更加困惑为什么它是null.在该nav属性上设置一个断点,我发现它被击中了两次 – 一次当我调用它时(当时它不是null),但是在我的View / Razor代码完成编译之后第二次,它神秘地是再次打.调用堆栈似乎指向它来自Glimpse.果然,我能够继续完成异常并加载页面(没有错误或缺少数据),但Glimpse在引用该属性的Metadata选项卡中显示错误.我把两个和两个放在一起并尝试打开/关闭Glimpse,然后禁用Metadata选项卡.在任何一种情况下,额外的查询都会停止,并且在Glimpse打开但禁用了“元数据”选项卡的情况下,HUD和SQL选项卡查询计数会匹配.问题解决了.

现在只是为了清楚,我并不是说这是我上述性能问题的原因 – 当性能问题开始时,甚至没有安装Glimpse,据我所知,Glimpse默认情况下在Release模式下是关闭的.性能问题是由代码中发生的一些明显的延迟加载引起的.但是,当我修复代码中发生的延迟加载时,HUD选项卡中的查询计数没有减少太多,性能没有增加 – 现在这是有道理的.对于我从代码中删除的每个延迟加载的查询,Glimpse通过访问“元数据”选项卡的导航属性在后台生成一个查询.

底线/ TLDR:禁用Glimpse元数据选项卡为我解决了这个问题.减少查询次数和在调试模式下性能更好,并且Glimpse的HUD与其SQL选项卡之间的查询计数没有差异.

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读