Spring / Hibernate应用性能调优

标签: 基础技术 教程 Hibernate Spring 性能优化 | 发表时间:2014-09-15 08:00 | 作者:陈 晓舜
出处:http://www.importnew.com

对大部分典型的Spring/Hibernate企业应用来说,应用的性能大部分由持久层的性能决定。

这篇文章会重温一下怎么去确认我们的应用是否是”数据库依赖(data-bound)”( 译者注:即非常依赖数据库,大量时间花在数据库操作上),然后会大概过一下7个常用的提升应用性能的速效方案。

怎么确定应用是否是“数据库依赖”

确认一个应用是是否是数据库依赖,首先通过在一些开发环境中做基本的运行,可以使用 VisualVM来进行监控。VisualVM是一个和JDK一起发布的Java性能调优器,可以通过命令行jvisualvm运行。

执行Visual VM后,尝试下面的步骤:

  1. 双击你正在运行的应用
  2. 选择抽样器(Sampler)
  3. 点击设置复选框
  4. 选择只调优包,并且限定如下的包类型:
    • 你的应用程序包
    • org.hibernate.*
    • org.springframework.*
    • 你的数据库jar包名,如oracle.*
    • 点击抽样(Sample) CPU

CPU抽样一个典型的“数据库依赖”应用将会得到类似下面的结果:

我们可以看到Java客户端进程花费了56%的时间在等待数据库从网络中返回结果。

这是一个很好的标志,表示正是数据库查询造成了应用的缓慢。Hibernate反射调用占了32.7%是正常,而且我们对此也无能为力。

性能调优第一步 —— 得到基准运行值(baseline run)

性能调优的第一步是为程序定义一个基准运行值。我们需要一系列可以使程序运行的有效输入数据,它必须跟在生产环境运行类似。

最主要的区别是基准运行需要在更短的时间内运行完成,比较理想的指导值是执行时间为5-10分钟。

什么是好的基准(baseline)?

一个好的基准需要有下面的特性:

  • 保证功能正确
  • 输入数据在可变性上和生产环境类似
  • 在短时间内可以完成
  • 在基准运行中做的优化可以直接影响到完整运行

取一个好的基准可以解决一大半的问题。

什么是不好的基准

例如,在一个批处理运行的执行电话数据记录的电信系统中,取得前10000条记录会是一个 错误的做法。

原因是:前10000条有可能大部分是语音电话,但未知的性能问题却是在处理短信通道(SMS traffic)。在一个大批量执行的过程中获取前面的一些记录不是一个好的基准,有可能会得到错误的结论。

收集SQL日志和查询时间

SQL查询和执行时间可以使用如 log4jdbc来进行收集。可以看这篇博客关于如何使用log4jdbc来收集SQL查询 —— 通过log4jdbc来改进Spring/Hibernate的SQL日志.

查询执行时间是在Java客户端进行计算的,它包含了到数据库的网络往返请求耗时。SQL查询日志看起来就像这样:

    16 avr. 2014 11:13:48 | SQL_QUERY /* insert your.package.YourEntity */ insert into YOUR_TABLE (...) values (...) {executed in 13 msec}

Prepared statements自己也是很好的信息源——它允许识别经常执行的查询类型。根据这篇博客,可以很简单地记录—— Hibernate在哪里,为什么做这个SQL查询

SQL日志可以得到什么数据

SQL日志可以回答这些问题:

  • 最慢的查询是什么?
  • 最频繁的查询是什么?
  • 生成主键花了多少时间?
  • 是否有数据可以通过缓存受益?

怎么转换SQL日志

也许对于大日志文件最可行的方案就是使用命令行工具。这个方法的优点是比较灵活。

只需要耗费点时间写一小段脚本或命令,我们可以抽取大部分任何需要的数据。任何命令行都可以按你喜欢的方式去使用。

如果你使用Unix命令行,bash会是一个很好的选择。Bash也可以在Windows工作站中使用,使用例如 CygwinGit这些包含bash命令行的工具。

常用的速效方案

下面的速效方案可以识别Spring/Hibnerate应用中的常见性能问题和对应的解决方案。

速效方案1 —— 减少主键提前生成

在一些插入密集(intert-intensive)的处理中,主键生成策略的选择有很大的影响。一个常见的生成ID的方法是使用数据库的序列(sequences),通常每个表一个,以避免插入不同表时的冲突。

问题在于,如果插入50条记录,我们希望可以避免50次通过数据库获取50个ID的网络往返,而不使Java进程在大部分时间内等待。

Hibernate通常是怎么处理这个的?

Hibernate提供了新优化的ID生成器可以避免这个问题。对于sequences,会默认使用一个HiLo id生成器。HiLo序列生成器的工作过程如下:

  • 调用一次sequence返回1000(最大值)
  • 如下计算50个ID:
    • 1000 * 50 + 0 = 50000
    • 1000 * 50 + 1 = 50001
    • 1000 * 50 + 49 = 50049, 达到小值 (50)
    • 调用sequence获取更大的值1001 …依此类推…

所以从第一次sequence调用时,就已经生成了50个key了,减少了大量的网络往返耗时。

这些新优化的主键生成器在Hibernate4中是默认开启的,在需要时,可以通过设置hibernate.id.new_generator_mappings为false进行关闭。

为什么主键生成仍然是个问题?

问题在于,如果你定义主键生成策略为AUTO,优化生成器仍然是关闭的,你的应用仍然还是会进行很大数量的sequence调用。

为了保证新的优化生成器被启用,确保使用SEQUENCE策略而不是AUTO:

    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "your_key_generator")
    private Long id;

有了这个小改变,’插入密集’的应用会有10%-20%的提升,而并不需要做其他的代码修改。

速效方案2 —— 使用JDBC批量插入/修改

对于批量的程序,JDBC驱动通常会提供称之为’JDBC批量插入/修改’的优化方案用于减少网络往返消耗。在使用它们时,插入/修改在发送到数据库前会在驱动层排队(译者注:达到一定的数量后会一次性发送多条SQL进行执行)。

当指定的阀值达到后,队列中的批量语句将会被一次性发送到数据库。这防止了驱动一个接一个的发送请求,浪费多个网络请求。

下面是用于启用批量插入/更新的entity manager factory的配置:

    <prop key="hibernate.jdbc.batch_size">100</prop>
    <prop key="hibernate.order_inserts">true</prop>
    <prop key="hibernate.order_updates">true</prop>

只是设置JDBC batch size 不会生效。这是因为JDBC驱动只有在具体某个相同的表接收到插入/更新时才会把插入当成批量处理。

如果接收到对一个新表的插入命令,JDBC驱动会在执行新表的批量语句前先送出上一个表的批量的语句。

使用Spring Batch时也有隐晦地使用到一个类似的功能。这个优化可以很简单地为你的“插入密集”应用节省30%到40%的时间,而不需要修改一行代码。

速效方案3 —— 定期刷新和清空Hibernate session

当添加/修改数据库数据时,为了防止它们在session关闭后被重新修改,Hibnerate会在session中保持已经持久化的实体的版本。

但很多时候,在插入数据库完成后,我们可以安全地丢弃实体。这可以在Java客户端释放内存,防止由于长时间运行Hibernate session造成的性能问题。

这种长时间运行的session 应该被尽量避免,但如果由于某些原因确实需要使用,下面的代码展示了怎么继续保存内存引用:

    entityManager.flush();
    entityManager.clear();

这个flush会触发发送操作,新实体的插入操作会被立刻发送到数据库。clear会从session中释放新实体。

速效方案4 —— 减少Hibernate提前的dirty-check

Hibernate使用称之为dirty-checking的内部的机制来跟踪修改的实体。这个机制并不基于实体的equals和hashcode方法。

Hibnerate竭尽所能使dirty-checking的性能损耗降到最小,只有在需要的时候才进行dirty-check,但这个机制依然是会有损耗的。在有大量字段的表时尤其需要注意。

在执行任何优化前,最重要的就是使用VisualVM计算一下dirty-check的损耗。

怎么避免dirty-check

在Spring中,我们所知的业务方法是只读的,dirty-check可以通过下面的方法进行关闭:

    @Transactional(readOnly=true)
    public void someBusinessMethod() {
    ....
    }

另外一个可选的避免dirty-check的方法就是使用Hibnerate无状态Session(Stateless Session),在 文档中有详细描述。

速效方案5 —— 查找“坏”查询方案

检查一下在最慢查询列表中的查询,看看它们是否有好的查询方案。最常见的“坏”查询方案是:

  • 全表查询(Full table scans):它发生在当表由于缺失索引或过期的表数据而被全量扫描。
  • 完全笛卡尔连接(Full cartesian joins):这意味着多个表计算完全笛卡尔积。检查一下是否缺少连接条件,或是否可以通过分割语句来避免。

速效方案6 —— 检查错误的提交间隔

如果你正在做批量处理,提交的间隔在性能结果中可以造成巨大的差别,可以达到10-100倍。

确认一个提交的间隔是所期望的(Spring Batch一般是100-1000)。它通常是因为这个参数没有正确配置。

速效方案7 —— 使用二级和查询缓存

如果发现某些数据很适合缓存,那么看一下这篇文章怎么去配置Hibernate缓存: Hibernate二级/查询缓存的陷阱

结论

要解决应用的性能问题,要做的最重要的就是收集一些可以找到当前瓶颈所在的数据。没有一些数据,基本上不可能在有效的时间内猜到问题在哪里。并且,虽然不是所有,但很多的典型的“数据库依赖”的应用性能陷阱都可以通过使用Spring Batch框架在第一时间避免。

相关文章

相关 [spring hibernate 应用] 推荐:

spring+hibernate多数据源的应用

- - CSDN博客推荐文章
我有两个数据库test,和test1,两个库里都有一张表TEST_ONE. applicationContext.xml的配置如下. //数据库test1配置.   //整合两个数据源,指定数据源管理类.    //数据库test.    //数据库test1. //这个类是用来管理数据源的,配置文件中.

Spring/Hibernate应用性能调优

- - ImportNew
对于大多数典型的Spring/Hibernate 企业应用来说,应用程序的性能几乎完全取决于它的持久层的性能. 这篇文章将会对如何确认在“数据库约束”的应用前,使用7种“快速见效”的技巧来帮助我们提升应用性能. 如何确认一个应用受到“数据库约束”. 为了验证一个应用程序是否受到“数据库约束”,首先在一些开发环境中做一些普遍的行为,即使用 VisualVM来监控.

Spring / Hibernate应用性能调优

- - ImportNew
对大部分典型的Spring/Hibernate企业应用来说,应用的性能大部分由持久层的性能决定. 这篇文章会重温一下怎么去确认我们的应用是否是”数据库依赖(data-bound)”( 译者注:即非常依赖数据库,大量时间花在数据库操作上),然后会大概过一下7个常用的提升应用性能的速效方案. 怎么确定应用是否是“数据库依赖”.

Spring中hibernate配置

- - Oracle - 数据库 - ITeye博客
Hibernate方言(Dialect)的类名 - 可以让Hibernate使用某些特定的数据库平台的特性. 在生成的SQL中,scheml/tablespace的全限定名取值. 自动把创建的SessionFactory以这个名字绑定到JNDI中去.取值. 请使用max_fetch_depth. 对单根联合(一对一,多对一),设置外连接抓取树的最大深度.

Spring/Hibernate 应用性能优化的7种方法

- - IT瘾-geek
【编者按】对于大多数典型的 Spring/Hibernate 企业应用而言,其性能表现几乎完全依赖于持久层的性能. 此篇文章中将介绍如何确认应用是否受数据库约束,同时介绍七种常用的提高应用性能的速成法:. 如何确认应用是否受限于数据库. 确认应用是否受限于数据库的第一步,是在开发环境中进行测试,并使用 VisualVM 进行监控.

在Spring、Hibernate中使用Ehcache缓存

- - BlogJava-首页技术区
前一篇 http://www.blogjava.net/hoojo/archive/2012/07/12/382852.html介绍了Ehcache整合Spring缓存,使用页面、对象缓存;这里将介绍在Hibernate中使用查询缓存、一级缓存、二级缓存,整合Spring在HibernateTemplate中使用查询缓存.

spring+hibernate+atomikos 分布式事务管理

- - 企业架构 - ITeye博客
网上有很多的atomikos的分布式事务管理的配置,但是大多数都是同一类型的数据库,并没有跨数据库类型的配置. 使用的数据库是Oracle和mysql. . .

Struts2、Spring、Hibernate 高效开发的最佳实践

- senyo - IBM developerWorks 中国 : 文档库
Struts2、Spring、Hibernate(SSH)是最常用的 Java EE Web 组件层的开发技术搭配,网络中和许多 IT 技术书籍中都有它们的开发教程,但是通常的教程都会让很多程序员陷入痛苦的配置与修改配置的过程. 本文利用 SSH 中的技术特性,利用 Java 反射技术,按照规约优于配置的原理,基于 SSH 设定编写了一个通用开发框架,这使得开发者可以专注于业务逻辑的开发,而不用随着业务增加而添加或修改任何配置,并且对于权限控制和日志记录也提供了方便的接口.

spring+hibernate+JTA 分布式事务的例子 .

- - 编程语言 - ITeye博客
对于横跨多个Hibernate SessionFacotry的分布式事务,只需简单地将 JtaTransactionManager 同多个 LocalSessionFactoryBean 的定义结合起来作为事务策略. 你的每一个DAO通过bean属性得到各自的 SessionFactory 引用. 如果所有的底层JDBC数据源都是支持事务的容器,那么只要业务对象使用了 JtaTransactionManager 作为事务策略,它就可以横跨多个DAO和多个session factories来划分事务,而不需要做任何特殊处理.

性能优化之Hibernate缓存讲解、应用和调优

- - CSDN博客系统运维推荐文章
    近来坤哥推荐我我们一款性能监控、调优工具——JavaMelody,通过它让我觉得项目优化是看得见摸得着的,优化有了针对性. 而无论是对于分布式,还是非分布,缓存是提示性能的有效工具.     数据层是EJB3.0实现的,而EJB3.0内部也是通过Hibernate实现的,而Hibernate本身提供了很好的缓存机制,我们只需要学会使用它驾驭它就够了.