这不是一个“哪个是最快的 ORM”问题,也不是关于“如何使用 ORM 编写优秀代码”的问题。这是另一个方面:代码已经编写好了,已经上线,数千个用户正在访问应用程序,但存在一个总体性能问题。SQL Profiler 跟踪只能运行短时间:5 分钟就会产生数十万条结果。
问题很简单:在使用 SQL Profiler 缩小了一些缓慢查询(持续时间大于给定时间)之后,有哪些技术和解决方案可用于将这些 SQL 查询追溯回到具有问题的组件?相关问题是,如果特定区域很慢,我们如何识别该区域执行的 SQL 以便在 SQL Profiler 中适当过滤?
背景是我们有一个相当复杂的表结构的大型应用程序,目前基于存储过程进行数据访问。如果出现 SQL 性能问题,则通常是使用 SQL Profiler,查找是否有任何缓慢的地方(按持续时间过滤)或者被投诉的区域很慢(按存储过程过滤),然后调整存储过程(或架构-通过索引)。
现在有一个推动,将我们的代码从主要的存储过程解决方案转移到主要的ORM解决方案,但是对移动的大力推动是如何追踪性能问题,如果出现问题,可以追溯到有问题的代码。我读了一些资料,似乎往往涉及第三方工具(ORM跟踪实用程序,如NHProf或.NET跟踪实用程序,如dottrace),我们需要在服务器上安装这些工具。现在是否可以在实时环境中安装其他工具是另一个问题,因此,如果可以在没有其他工具的情况下执行此类操作,则可能会有额外的奖励。
我主要对SQL Server 2008的解决方案感兴趣,但它可能足够普遍适用于任何RDBMS。至于ORM技术,在这方面我没有特定的重点,因为目前没有使用任何东西,所以很想听听nHibernate、fluent-nhibernate和Entity Framework之间的技术差异(或者是共同点)。其他ORM如果提供其他功能也是可以接受的 :-)
我已经阅读了如何找到和解决性能问题...,我认为问题仅仅在于其中的“隔离”部分。一个只在实际系统中容易重现的问题将会很难被隔离。我在第二段引用的数字是我们可以从配置文件中获取的数据类型...
问题很简单:在使用 SQL Profiler 缩小了一些缓慢查询(持续时间大于给定时间)之后,有哪些技术和解决方案可用于将这些 SQL 查询追溯回到具有问题的组件?相关问题是,如果特定区域很慢,我们如何识别该区域执行的 SQL 以便在 SQL Profiler 中适当过滤?
背景是我们有一个相当复杂的表结构的大型应用程序,目前基于存储过程进行数据访问。如果出现 SQL 性能问题,则通常是使用 SQL Profiler,查找是否有任何缓慢的地方(按持续时间过滤)或者被投诉的区域很慢(按存储过程过滤),然后调整存储过程(或架构-通过索引)。
现在有一个推动,将我们的代码从主要的存储过程解决方案转移到主要的ORM解决方案,但是对移动的大力推动是如何追踪性能问题,如果出现问题,可以追溯到有问题的代码。我读了一些资料,似乎往往涉及第三方工具(ORM跟踪实用程序,如NHProf或.NET跟踪实用程序,如dottrace),我们需要在服务器上安装这些工具。现在是否可以在实时环境中安装其他工具是另一个问题,因此,如果可以在没有其他工具的情况下执行此类操作,则可能会有额外的奖励。
我主要对SQL Server 2008的解决方案感兴趣,但它可能足够普遍适用于任何RDBMS。至于ORM技术,在这方面我没有特定的重点,因为目前没有使用任何东西,所以很想听听nHibernate、fluent-nhibernate和Entity Framework之间的技术差异(或者是共同点)。其他ORM如果提供其他功能也是可以接受的 :-)
我已经阅读了如何找到和解决性能问题...,我认为问题仅仅在于其中的“隔离”部分。一个只在实际系统中容易重现的问题将会很难被隔离。我在第二段引用的数字是我们可以从配置文件中获取的数据类型...
如果你有ORM追踪实际经验,那就更好了:-)
更新,2016-10-21:为了完整起见,我们最终通过编写代码并覆盖NHibernate方法来解决了这个问题。有关完整详细信息,请参阅我提出的这个其他SO问题:NHibernate和拦截器-测量SQL往返时间。我相信这对许多不同的ORM都是一种类似的方法。