对于大多数典型的Spring / Hibernate企业应用程序,应用程序性能几乎完全取决于其持久层的性能。
这篇文章将讨论如何确认我们是否存在“数据库绑定”应用程序,然后逐步讲解7个经常使用的“快速取胜”技巧,这些技巧可以帮助提高应用程序性能。
如何确认应用程序是“数据库绑定的”
为了确认应用程序是“数据库绑定的”,首先在某些开发环境中使用VisualVM进行监视以进行典型运行。 VisualVM是JDK附带的Java Profiler,可通过调用jvisualvm
通过命令行jvisualvm
。
启动Visual VM后,请尝试以下步骤:
- 双击正在运行的应用程序
- 选择采样器
- 单击
Settings
复选框 - 选择
Profile only packages
,然后输入以下软件包:your.application.packages.*
典型的“数据库绑定”应用程序的CPU配置文件应如下所示:
我们可以看到,客户端Java进程花费了56%
的时间来等待数据库通过网络返回结果。
这是一个很好的信号,表明对数据库的查询使应用程序运行缓慢。 Hibernate反射调用中的32.7%
是正常的,对此无能为力。
调整的第一步–获得基线运行
进行调整的第一步是为程序定义基线运行。 我们需要确定一组功能上有效的输入数据,以使程序通过类似于生产运行的典型执行。
主要区别在于基线运行应在更短的时间内运行,作为指导原则,执行时间约为5到10分钟是一个很好的目标。
什么是好的基线?
良好的基线应具有以下特征:
- 在功能上是正确的
- 输入数据类似于生产中的各种数据
- 它在很短的时间内完成
- 基线运行的优化可以推断为完整运行
获得一个良好的基准可以解决一半的问题。
是什么导致基准差?
例如,在用于处理电信系统中的呼叫数据记录的批处理运行中,采用前10000条记录可能是错误的方法。
原因是,前10000个可能主要是语音呼叫,但是未知的性能问题在于SMS流量的处理。 取得大批运行的第一笔记录会导致我们得出错误的基准,从而得出错误的结论。
收集SQL日志和查询时间
可以使用例如log4jdbc来收集执行时间已执行的SQL查询。 请参阅此博客文章,了解如何使用log4jdbc收集SQL查询-Spring / Hibernate使用log4jdbc 改进了SQL日志记录 。
查询执行时间是从Java客户端测量的,它包括到数据库的网络往返时间。 SQL查询日志如下所示:
16 avr. 2014 11:13:48 | SQL_QUERY /* insert your.package.YourEntity */ insert into YOUR_TABLE (...) values (...) {executed in 13 msec}
准备好的语句本身也是很好的信息来源–它们使您可以轻松识别频繁查询的类型 。 可以通过关注此博文来记录它们- 为什么Hibernate在哪里以及在哪里进行此SQL查询?
可以从SQL日志中提取哪些指标
SQL日志可以给出以下问题的答案:
- 什么是执行最慢的查询?
- 最常见的查询是什么?
- 生成主键花费的时间是多少?
- 是否有一些数据可以从缓存中受益?
如何解析SQL日志
对于大日志量,唯一可行的选择可能是使用命令行工具。 这种方法具有非常灵活的优点。
以编写小的脚本或命令为代价,我们几乎可以提取所需的任何度量。 只要您愿意,任何命令行工具都可以使用。
如果您习惯Unix命令行,bash可能是一个不错的选择。 Bash也可以在Windows工作站中使用,例如使用Cybwin或包含bash命令行的Git 。
经常应用的快速获胜
Swift取得成功的波纹管确定了Spring / Hibernate应用程序中的常见性能问题及其相应的解决方案。
快速共赢的技巧1 –减少主键生成开销
在“插入密集型”过程中,主键生成策略的选择可能很重要。 生成ID的一种常见方法是使用数据库序列,通常每个表使用一个序列,以避免不同表上的插入之间发生争用。
问题在于,如果插入了50条记录,我们希望避免对数据库进行50次网络往返以获取50个ID,而使Java进程大部分时间处于挂起状态。
Hibernate通常如何处理?
Hibernate提供了新的优化ID生成器,可以避免此问题。 即,对于序列,默认情况下使用HiLo
id生成器。 这是HiLo序列生成器的工作方式:
- 调用一次序列并获得1000(高值)
- 计算50个id像这样:
- 1000 * 50 + 0 = 50000
因此,从单个序列调用中生成了50个密钥,这减少了开销,导致了我无数次网络往返。
这些新的经过优化的密钥生成器默认在Hibernate 4中处于启用状态,甚至可以通过将hibernate.id.new_generator_mappings
设置为false来关闭。
为什么主键生成仍然是个问题?
问题是,如果您将密钥生成策略声明为AUTO
,则优化的生成器仍然处于关闭状态,并且您的应用程序最终将产生大量的序列调用。
为了确保启用了新的优化生成器,请确保使用SEQUENCE
策略而不是AUTO
:
@Id
@GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "your_key_generator")
private Long id;
通过这种简单的更改,可以在“插入密集型”应用程序中实现10%-20%
的范围内的改进,而基本上无需更改代码。
快速入门技巧2 –使用JDBC批处理插入/更新
对于批处理程序,JDBC驱动程序通常提供一种优化措施,以减少名为“ JDBC批处理插入/更新”的网络往返。 使用这些选项时,插入/更新在发送到数据库之前会在驱动程序级别排队。
当达到阈值时,整批排队的语句将一次性发送到数据库。 这样可以防止驱动程序一个接一个地发送语句,这会导致多个网络往返。
这是激活批量插入/更新所需的实体管理器工厂配置:
<prop key="hibernate.jdbc.batch_size">100</prop><prop key="hibernate.order_inserts">true</prop><prop key="hibernate.order_updates">true</prop>
仅设置JDBC批处理大小将不起作用。 这是因为JDBC驱动程序仅在收到完全相同的表的插入/更新时才批处理插入。
如果收到对新表的插入,则JDBC驱动程序将首先刷新上一个表上的批处理语句,然后再开始对新表上的批处理语句进行处理。
如果使用Spring Batch,则隐式使用类似的功能。 通过这种优化,您可以轻松地购买30%
到40%
来“插入密集型”程序,而无需更改任何代码。
快速共赢的技巧3 –定期刷新并清除休眠会话
当在数据库中添加/修改数据时,Hibernate在会话中保留一个已经存在的实体版本,以防万一在关闭会话之前再次对其进行了修改。
但是很多时候,一旦在数据库中完成了相应的插入操作,我们就可以安全地丢弃实体。 这样可以释放Java客户端进程中的内存,从而避免了由于长时间运行的Hibernate会话而导致的性能问题。
应该尽可能避免这样长时间运行的会话,但是如果出于某种原因需要它们,这就是控制内存消耗的方法:
entityManager.flush();
entityManager.clear();
flush
将触发来自新实体的插入将被发送到数据库。 clear
会从会话中释放新实体。
快速共赢的秘诀4 –减少Hibernate脏检查的开销
Hibernate内部使用一种称为脏检查的机制来跟踪已修改的实体。 此机制不是基于实体类的equals和hashcode方法。
Hibernate尽最大努力将脏检查的性能成本降到最低,并且仅在需要时才进行脏检查,但是该机制的确有成本,这在具有大量列的表中更为明显。
在应用任何优化之前,最重要的是使用VisualVM评估脏检查的成本。
如何避免脏检查?
在我们知道是只读的Spring业务方法中,脏检查可以像这样关闭:
@Transactional(readOnly=true)
public void someBusinessMethod() {....
}
避免进行脏检查的另一种方法是使用Hibernate Stateless Session,在文档中对此进行了详细介绍 。
快速共赢的秘诀5 –搜索“不良”查询计划
检查最慢查询列表中的查询,看看它们是否有好的查询计划。 最常见的“不良”查询计划是:
- 全表扫描:通常由于索引缺失或表统计信息过时而在对表进行完全扫描时发生。
- 完全笛卡尔连接:这意味着正在计算多个表的完全笛卡尔乘积。 检查是否缺少连接条件,或者是否可以通过将步骤分成几个步骤来避免这种情况。
快速共赢的秘诀6 –检查错误的提交间隔
如果您正在执行批处理,则提交间隔可能会对性能结果产生很大的影响,例如快10到100倍。
确认提交间隔是预期的间隔(对于Spring Batch作业,通常约为100-1000)。 经常发生此参数配置不正确的情况。
快速双赢的秘诀7 –使用二级和查询缓存
如果某些数据被认为可以进行缓存,那么请查看此博客文章,了解如何设置Hibernate缓存: Hibernate二级/查询缓存的陷阱
结论
为了解决应用程序性能问题,最重要的措施是收集一些度量标准,以找出当前的瓶颈。
如果没有一些度量标准,通常不可能在有用的时间内猜测出正确的问题原因是什么。
另外,通过使用Spring Batch框架,可以首先避免“数据库驱动”应用程序的许多但不是全部典型性能缺陷。
翻译自: https://www.javacodegeeks.com/2014/06/performance-tuning-of-springhibernate-applications.html