教你如何优化Spring/Hibernate应用性能

admin

对于大多数典型的 spring/hibernate 企业应用而言，其性能表现几乎完全依赖于持久层的性能。此篇文章中将介绍如何确认应用是否受数据库约束，同时介绍七种常用的提高应用性能的速成法。本文系 OneAPM 工程师翻译整理。
, S: M  `/ w! p: p

- \& i4 b2 ?# U; I4 f如何确认应用是否受限于数据库
确认应用是否受限于数据库的第一步，是在开发环境中进行测试，并使用 VisualVM 进行监控。VisualVM 是一款包含在 JDK 中的 java 分析器，在命令行输入 jvisualvm 即可调用。


启用 Visual VM 之后，尝试以下步骤：

  u0 o/ [7 n+ y4 ~# r: T0 v5 m
$ s3 B1 e8 ?4 I4 M: [# g1.双击你正在运行的应用
2.选择 Sampler
3.点击 Settings 复选框
4.选择Profile only packages，然后输入下列包：
5 s( J8 f5 i) |8 |% b1 vyour.application.packages.*
* R) H  y- ?- z; i" A8 n5 L
+ q$ E) j1 w6 q# b1 U/ ]0 {* z
7 F. j$ u6 j6 u& {4 a$ H2 b9 ~org.hibernate.*

% [& k- A% ?, ^0 a2 F% v
3 `+ {0 o+ w4 R+ }org.springframework.*


your.database.driver.package, 比如 oracle.*

* V+ h- ^0 w; T* q# n2 t
点击 Sample CPU
- B. P/ K$ C) a3 P% t' ?

如果应用性能受限于数据库，其 CPU 分析结果会非常恐怖


Spring/Hibernate 应用性能优化


5 p5 u  g# Q' _! B我们看到，客户端 Java 进程花在等待数据库从网络中返回结果的时间占56%。


看到数据库查询是导致应用运行缓慢的原因，其实是好兆头。Hibernate 反射调用占比32.7%是正常情况，无法进一步优化。
  l1 ~, O4 e( E3 M- n

性能调优第一步：定义基准运行
4 \( [5 U' w( P) v- b2 O: Q性能调优的第一步是为程序定义基准运行，我们要定义一组能有效执行的输入数据，让程序基准运行与生产环境下的运行差不多。

$ Q; c+ b1 W! v, S1 T) c* ?6 J$ [
( m' q0 q! w6 H% Z7 \" v4 h主要的区别在于基准运行的耗时要小很多。作为参考，5到10分钟的执行时间比较不错。
4 |2 H) W% C6 Y7 u/ x3 o3 s! U

( {/ Y! J' {+ M' r7 r: V9 q3 J6 ~什么是好的基准？
好的基准应该具备以下特征：
% _5 w6 v, E! K5 w- `$ }9 G% l

• 功能正确
• 输入数据的种类与生产环境下相似
• 在短时间内执行完毕
• 基准运行的优化方案可以外推至完整运行
  

定义好的基准是成功解决问题的一半。

0 ~  T. H+ b# _& w9 C$ f
( o7 o8 R, X6 k& L. H8 x) R什么是不好的基准
$ M2 X7 y! ?6 b3 E例如，通过批量运行处理通讯系统的电话数据记录，选取10000条记录就是错误的做法。

& B. y. D& C5 h/ p0 ~2 V
原因是：前10000条记录可能多为语音电话，而未知的性能问题可能发生在短信流量的处理过程中。一开始如果基准不够好，就会导致错误的结论。
6 v* i% v! n; e: ^/ w: R
1 _5 C  Y7 _4 ]
. l2 t& T3 E) p+ Z收集 SQL 日志与查询时间
SQL 查询的执行语句与其执行时间可以通过 log4jdbc等方式收集。详细了解如何使用 log4jdbc 收集 SQL 查询信息，点击文章 使用 log4jdbc 优化 Spring/Hibernate 应用 SQL 日志。

% {: n* E7 ~; e6 {( u
查询的执行时间是从 Java 客户端收集的，该时间包含查询数据库的来回网络调用。SQL 查询的日志如下：


  ^/ j% y+ i8 Y% v5 L16 avr. 2014 11:13:48 | SQL_QUERY /* insert your.package.YourEntity */ insert into YOUR_TABLE (...) values (...) {executed in 13 msec}
预处理语句也是很重要的信息来源，它们常常会透露出常用的查询类型。了解更多的日志讯息，可以查看文章：Hibernate 为什么/在何处使用该 SQL 查询？

$ Z' j7 T# ]+ t/ R! m0 S) f
$ y3 U' |- n0 @9 C' @通过 SQL 日志可以了解哪些指标？
' a* Q! U  g9 rSQL 日志可以回答下列问题：


6 p. ^* p' M7 }3 e1 }5 t

• 哪些是执行过的最慢查询？
• 哪些是最常用的查询？
• 生成主键的耗时是多少？
• 是否有数据适合缓存？
  * v! F( A7 d/ [8 l6 [/ Q

如何解析 SQL 日志
对于大量的日志文件，最可行的解析方式就是使用命令行工具，该方法的好处是非常灵活，只要写一小段脚本或命令，我们可以抽取出几乎大多数指标。只要你喜欢，任何命令行工具都适用。
) x$ ?& _8 P8 d$ _9 j8 c0 \

如何你习惯了 Unix 命令行，bash 或是一个好选择。Bash 也可以在 Windows 工作站使用，Cygwin 或 Git 都包含了 bash 命令行。

6 i: b. Y6 r2 E3 R. p- T* y
: f: v0 x, p* d* j; E常用的速成法
3 g# I. J4 d! o" o下面介绍的速成法能找出 Spring/Hibernate 应用中常见的性能问题，以及对应的解决方案。
4 a& |7 @0 a5 A) D

速成法1——减少生成主键的代价
5 }  L  J5 ]6 E在插入操作频繁的进程中，主键的生成策略很重要。生成 id 的一种常见方法是使用数据库序列，通常一张表一个 id，从而避免在不同表间进行插入时的冲突。


问题在于，如果要插入50条记录，我们希望为了获取这50个 id，可以避免50趟查询数据库的来回网络调用，让 Java 进程不一直等待。

0 m3 B5 e/ Y2 }) \1 T; {) [- V' G
3 _8 e- o4 s+ b  ^, U) V& q* ]5 BHibernate 通常如何解决此问题？
Hibernate 提供了优化的 ID 生成器以避免此问题。也即，对于序列，会默认使用 HiLo id 生成器。以下是 HiLo 序列生成器的工作方式：

) e+ x2 W) e0 }- Y! b' h8 B% i
4 F; J- Y* X' w& s- V+ x/ D8 G

• 调用一次序列，获得 1000 (高值)
• 用以下方式计算50个 id
  

! @7 j1 s4 V% K6 b, g1000 * 50 + 0 = 50000


1000 * 50 + 1 = 50001
& X/ F" l& d; c+ L, c' q( m5 f

...
" j1 ^, ?# j0 Y* `$ r2 K

/ r+ D7 W; Z- v' ~1000 * 50 + 49 = 50049, 达到低值 (50)

! C+ }2 O* o" P. y
% t. N( U8 B$ {% m5 u. ?( `" u1 R为新的高值1001调用序列，依次类推


4 J$ L4 a5 F, V) L3 t因此一次序列调用，可生成50个键，从而减少数次来回网络调用导致的负担。
* V2 L* ?, E7 x5 a9 g; V
$ N/ e8 a9 E+ k' h: |3 _
这些优化的键生成器默认在 Hibernate 4中开启。如要禁用，可将 hibernate.id.new_generator_mappings 设置为 false。

; X1 o: w) p7 r* q- \' n  z* t2 W! q
为什么生成主键仍是一个问题？
7 t, P5 y: \* Y问题在于，如果你声明键生成策略为 AUTO，且未启用优化的键生成器，那么应用最后会面临大量的序列调用。
! g0 v2 S9 H* d- O* S+ n
$ c) F+ M5 l  h2 D  @9 L" D
为了确保启用优化的键生成器，请将键生成策略改为 SEQUENCE 而非 AUTO。
( O( @2 ^# i4 a" d, O* g$ t4 {

@Id
' v2 U4 @  Y3 Z@GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "your_key_generator")
private Long id;
; B* G  j7 H, B7 K改变设定之后，在插入操作频繁的应用中能看到10%到20%的性能提升，而且几乎没有改动代码。
. S8 E2 e  J0 E% x- Q
7 }& {! l, p# _0 F
速成法2——使用 JDBC 批处理 inserts/updates
对于批处理程序，JDBC 驱动程序提供了旨在减少网络来回传输的优化方法：”JDBC batch inserts/updates“。使用该方法后，插入或更新会先在驱动层排队，然后再传送到数据库。
+ c0 N) v6 t! R0 L5 \
/ j6 ~5 p" Z% ~6 u+ V
2 S, `2 ~- g0 i* b. ?当达到阈值后，所有排队的语句都会一次性传给数据库。这可以避免驱动程序逐一传送语句，导致网络来回传送的负担。
7 B3 t7 S, z$ C9 n- X. @$ U/ ?2 I+ a
  p. G  w7 o7 m: Y
, `0 O; c* M/ j经过以下配置，就能激活批处理 inserts/updates：

  ~; Q2 U8 q( A3 P% ?! K( r
) D7 I9 @8 V; s+ C- E! B<prop key="hibernate.jdbc.batch_size">100</prop>  
<prop key="hibernate.order_inserts">true</prop>  
<prop key="hibernate.order_updates">true</prop>  
; n, \! |' e7 {2 n仅设置 JDBC 批处理大小并不够。因为 JDBC 驱动程序只会在收到对同一张表 insert/updates 时批处理这些语句。
4 z: E1 [9 I+ ?4 f' W) {% W1 B1 ]
8 }# T+ Q6 Y2 z/ u! K& [: @. M( j
如果收到对一张新表的插入语句，JDBC 驱动程序会先清除对前一张表的批处理语句，然后开始分批处理针对新表的 SQL 语句。

4 n0 p& Q6 G1 N2 k
Spring Batch 内置了相似的功能。该优化能在插入操作频繁的应用中带来30%到40%的性能提升，而不用改动任何代码行。


4 u4 V. u3 Y5 `; L速成法3——定期清理 Hibernate 会话
# H: o) A5 V$ [0 W. B' d在向数据库添加或修改数据时，Hibernate 会在会话中保留一版已经存在的实体，以防在会话关闭之前这些实体再度被修改。


但是，多数情况下，一旦对应的插入操作已经在数据库中完成，我们就可以安心地丢弃那些实体。这会释放 Java 客户端进程中的内存，避免过久的 Hibernate 会话导致的性能问题。


  X; i, ^0 ]/ j. B' E( C3 y8 H! s这种长久的会话应该尽量避免。但如果出于某种原因不得不使用它们，以下是控制内存消耗的方法：

5 g3 N8 V( r  G% K
entityManager.flush();
entityManager.clear();
flush 会触使新实体中的插入语句传送至数据库。clear 则会释放会话中的新实体。
0 u+ P! p" X9 Q9 A
4 y: y" a  T0 S
速成法4——减少 Hibernate dirty-checking(脏数据检查) 的代价
% f1 Q/ {' q. ^" L; }+ z/ r/ WHibernate 内部使用了一种机制用于追踪被修改的实体，名为 dirty-checking。该机制并不基于实体类中的 equals 和 hashcode 方法。


Hibernate 尽可能将 dirty-checking 的性能成本保持在最低值，只在需要时使用 dirty-check。但是该机制也有成本，在列数很多的表中该成本尤其可观。


在进行任何优化之前，最重要的是使用 VisualVM 测量 dirty-checking 的成本。

; v& e$ K* _* j( b& n9 b2 h
+ w3 \( s6 Z7 \5 o2 C! B如何避免 dirty-checking ？
dirty-checking 可以通过以下方式禁用：
. L9 d3 T/ H( @7 a% k5 K
- Q, r9 E' k7 R) t  x6 d, c
- `8 U- k* Y- C) L# C@Transactional(readOnly=true)
4 s+ q* v/ f, |& A2 l# ~public void someBusinessMethod() {
2 W: A2 V3 `3 D....
}
5 r: @! H0 n( P4 N; p7 L! Y( E/ v1 W禁用 dirty-checking 的另一种方式是使用 Hibernate 无状态会话，预知详情请查看文档。
# |% \% c& g& D- O0 A' v7 y

. \  Z( m' ^% {! l4 C速成法5——搜索”坏“查询计划
4 D/ g3 X; m' o% P3 V: B

检查最慢查询列表，看看有没有好的查询计划。最常见的”坏“查询计划包括：

* f5 i# ~; o1 f+ P. P5 {

• 全表搜索：通常缺少一个索引或表统计过期时进行全表搜索。
• 全笛卡尔连接：意思是计算多张表的全笛卡尔乘积。检查一下缺少的连接条件，或拆分为几个步骤以简化查询。
  

; }, ?# l8 D+ H) F5 t6 i' M
( y) F2 [; N' r# R% F' e
速成法6——检查错误的提交间隔
如果你使用批处理程序，提交间隔会对性能造成十倍甚至百倍的影响。


: E  C. P; v  j: H" v5 [. i请确保提交间隔是符合预期的（对于 Spring 批任务，通常是100到1000之间）。经常，该参数的配置不正确。

" n# C0 l4 j# r/ B, d. t
速成法7—— 使用二级查询缓存
8 b. d: }, i$ e如果一些数据可以缓存，则可以查看本文了解如何设置 Hibernate 缓存：Hibernate 二级/查询缓存的陷阱。


+ |9 S; z6 B7 Z2 @0 q$ N7 C结论
# o* d) W" r- @! J0 y* Q解决应用性能问题的关键，在于通过收集一些指标发现当前的瓶颈。
( w$ p! C! b7 E! B) A( W6 s4 [: C

9 l8 ]: t" a4 z' w! O7 n没有一些测量指标，往往无法在短时间内找到真正的问题根源。
& l& \, h: A: t+ i2 ?8 m) o7 H# k
) T& X- d5 A# J0 C$ l' B# H
5 Q1 z: K( D' k% k! _此外，很多典型的数据库驱动应用的性能陷阱，如果一开始就使用了 Spring Batch，就能够避免。
, f+ ]; Y* l7 h9 j0 H! Y6 C2 |

OneAPM for Java 能够深入到所有 Java 应用内部完成应用性能管理和监控，包括代码级别性能问题的可见性、性能瓶颈的快速识别与追溯、真实用户体验监控、服务器监控和端到端的应用性能管理。想阅读更多技术文章，请访问OneAPM官网