Spring / Hibernate应用程序的性能调优

时间  2021-01-21 标签 数据库 python mysql java linux

对于大多数典型的Spring / Hibernate企业应用程序，应用程序性能几乎完全取决于其持久层的性能。

这篇文章将讨论如何确认我们是否存在“数据库绑定”应用程序，然后逐步讲解7个经常使用的“快速取胜”技巧，这些技巧可以帮助提高应用程序性能。

如何确认应用程序是“数据库绑定的”

为了确认应用程序是“数据库绑定的”，首先在某些开发环境中使用VisualVM进行监视以进行典型运行。 VisualVM是JDK附带的Java Profiler，可通过调用jvisualvm通过命令行jvisualvm 。

启动Visual VM后，请尝试以下步骤：

  • 双击正在运行的应用程序
  • 选择采样器
  • 单击Settings复选框
  • 选择Profile only packages ，然后输入以下软件包：
    • your.application.packages.*
    • org.hibernate.*
    • org.springframework.*
    • your.database.driver.package ，例如oracle.*
    • 单击Sample CPU

典型的“数据库绑定”应用程序的CPU配置文件应如下所示：

application_profile

我们可以看到，客户端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
    • 1000 * 50 +1 = 50001
    • …
    • 1000 * 50 + 49 = 50049，达到低值（50）
    • 新高值1001的调用顺序…等等…

因此，从单个序列调用中生成了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

联系我们 沪ICP备13005482号-10