Chr*_*s J 6 nhibernate performance orm entity-framework sql-server-2008
这不是"哪个是最快的ORM"的问题,也不是"如何用ORM编写好代码"的问题.这是另一方面:代码已经编写,它已经上线,数千名用户正在使用该应用程序,但是存在整体性能问题.SQL事件探查器跟踪只能运行很短的时间:5分钟可以产生数十万个结果.
问题很简单:使用SQL事件探查器缩小了许多慢查询(持续时间大于给定时间),有哪些技术和解决方案可以将这些SQL查询追溯到有问题的组件中？一个相关的问题是,如果某个特定区域很慢,我们如何识别该区域正在执行的SQL,以便在SQL事件探查器中对其进行适当过滤？
这背景是我们有一个相当大的应用程序,具有相当复杂的表结构,目前基于存储过程的数据访问.如果出现SQL性能问题,通常情况下是拉出SQL分析器,找出是否有任何缓慢(按持续时间过滤)或者被抱怨的区域是否缓慢(按存储过程过滤),并调整存储过程(或模式 - 通过索引).
现在推动我们的代码从一个主要的sproc解决方案转移到一个主要是ORM的解决方案,但是对这一举措的大力推动是性能问题如果出现,可以追溯到有问题的代码.我已经阅读过,似乎通常情况下,它可能涉及我们需要在服务器上安装的第三方工具(像NHProf或.NET跟踪实用程序,如dottrace的ORM跟踪实用程序).现在是否可以在实时环境中安装其他工具是另一个问题,因此如果可以在没有其他工具的情况下执行此类操作,那么这可能是一个奖励.
我最感兴趣的是使用SQL Server 2008的解决方案,但它对于任何RDBMS都可能是通用的.就ORM技术而言,我没有特别关注当前没有使用的内容,因此有兴趣了解技术如何区别(或常见)twixt nHibernate,fluent-nhibernate和Entity Framework.如果他们提供其他东西,欢迎其他ORM :-)
我已经阅读了如何查找和修复性能问题(...),我认为问题只是那里的"隔离"部分.仅在现场系统上易于重现的问题将难以隔离.我在第2段中引用的数字是我们可以从个人资料中获得的数量类型的数字......
如果你有现场ORM跟踪的实际经验,那就更好了:-)
更新,2016-10-21:为了完整起见,我们最终通过编写代码和重写NHibernate方法为NHibernate解决了这个问题.我问的其他SO问题的全部细节:NHibernate和Interceptors - 测量SQL往返时间.我希望这对于许多不同的ORM来说都是类似的方法.
我们的 Java/Hibernate 应用程序存在问题，因此我们使用具有不同值的 SET CONTEXT_INFO。例如，如果我们在 WTF 查询之前在同一个 SPID 上看到 0x14，我们可以将其范围缩小到模块 x。
作为一个 Java 人员，我不知道他们到底做了什么，当然它可能不适用于 .net。IIRC 当连接打开/关闭时你必须小心
此时我们还可以控制客户端负载，这样就不会产生太多多余的流量。
YMMV 当然，但它可能有用
我刚刚发现这些也可能有用
| 归档时间： |
|
| 查看次数： |
411 次 |
| 最近记录： |