This presentation explores several common performance pitfalls when using Hibernate for persistence, both from a theoretic and practical perspective.

1. Performance Tuning
Sander Mak

2. Outline
Optimization
Lazy loading
Examples ‘from the trenches’
Search queries
Large collections
Batching
Odds & Ends

3. Optimization

4. Hibernate Sucks!
... because it’s slow

5. Hibernate Sucks!
... because it’s slow
‘The problem is sort of cultural [..] developers
use Hibernate because they are uncomfortable
with SQL and with RDBMSes. You should be
very comfortable with SQL and JDBC before you
start using Hibernate - Hibernate builds on
JDBC, it doesn’t replace it. That is the cost of
extra abstraction [..] save yourself effort,
pay attention to the database at all stages
of development.
- Gavin King (creator)

6. Optimization is hard
Performance blamed on?
Framework <-> You
How to optimize?
When to optimize?
Production vs. development
Preserve correctness at all times
Unit tests ok, but not enough

7. Optimization is hard
Performance blamed on?
Framework <-> You
How to optimize?
When to optimize?
Production vs. development
Preserve correctness at all times
Unit tests ok, but not enough
Premature optimization is the root of all evil
- Donald Knuth

8. Optimization guidelines
Always measure
Establish baseline and measure improvement
Be prepared to detect performance degradation!
Favor obvious over obscure
Even if latter performs better
Know your RDBMS (hook up with a good DBA)
Details do matter
Database is not a dumb ‘bit-bucket’

9. Optimization guidelines
Measurement
Ensure stable, production-like environment
Measure time and space
Time: isolate timings in different layers
Space: more heap -> longer GC -> slower
Try to measure in RDBMS as well
Memory usage (hot cache or disk thrashing?)
Query plans
Make many measurements

10. Optimization guidelines
Measurement
Ensure stable, production-like environment
Measure time and space
Time: isolate timings in different layers
Space: more heap -> longer GC -> slower
Try to measure in RDBMS as well
Memory usage (hot cache or disk thrashing?)
Query plans
Make many measurements
Remember: measurements are relative

11. Optimization guidelines
Practical
Profiler on DAO/Session.query() methods
VisualVM etc. for heap usage
Also: JRockit Mission Control
Hibernate JMX
<property name="hibernate.generate_statistics">true
</property>
RDBMS monitoring tools

12. Optimization guidelines
Practical
Example from BMG tuning session:

13. Analyzing Hibernate
Log SQL: <property name="show_sql">true</property>
<property name="format_sql">true</property>
Log4J configuration:
org.hibernate -> DEBUG
org.hibernate.type -> FINE (see bound params)
Or use P6Spy to snoop on JDBC connection

14. Analyzing Hibernate
Log SQL: <property name="show_sql">true</property>
<property name="format_sql">true</property>
Log4J configuration:
org.hibernate -> DEBUG
org.hibernate.type -> FINE (see bound params)
Or use P6Spy to snoop on JDBC connection

15. Analyzing Hibernate

16. Lazy loading

17. Lazy loading
One entity to rule them all Request
Mostly sane defaults: 1..1
@OneToOne,
@OneToMany, User
@ManyToMany: LAZY 1..* *..1
@ManyToOne : EAGER
Due to JPA spec. Authorization
*..1
Global 1..* Company
Company

18. Lazy loading
Request
1..1
User
1..* *..1
Authorization
*..1
Global 1..* Company
Company

20. LazyInitializationException

21. Lazy loading N+1 Selects problem
Select list of N users HQL: SELECT u FROM User
Authorizations necessary: SQL 1 query:
SELECT * FROM User
N select queries on LEFT JOIN Company c
Authorization executed! WHERE u.worksForCompany =
c.id
Solution:
FETCH JOINS

22. Lazy loading N+1 Selects problem
Select list of N users HQL: SELECT u FROM User
Authorizations necessary: SQL N queries:
SELECT * FROM Authorization
N select queries on WHERE userId = N
Authorization executed!
Solution:
FETCH JOINS

23. Lazy loading N+1 Selects problem
Select list of N users HQL: SELECT u FROM User
JOIN FETCH u.authorizations
Authorizations necessary:
SQL 1 query:
N select queries on SELECT * FROM User
Authorization executed! LEFT JOIN Company c LEFT
OUTER JOIN Authorization
ON .. WHERE
Solution: u.worksForCompany = c.id
FETCH JOINS

24. Lazy loading
Some guidelines
Laziness by default = mostly good
However, architectural impact:
Session lifetime (‘OpenSessionInView’ pattern)
Extended Persistence Context
Proxy usage (runtime code generation)
Eagerness can be forced with HQL/JPAQL/Criteria
But eagerness cannot be revoked
exception: Session.load()/EntityManager.getReference()

25. Search queries

26. Search queries
User
1..* *..1
Authorization
*..1
Global 1..* Company
Company

27. Search queries
Obvious solution:
Too much information!
Use summary objects:
UserSummary = POJO
not attached, only necessary fields (no relations)

28. Search queries
Obvious solution:
Too much information!
Use summary objects:
UserSummary = POJO
not attached, only necessary fields (no relations)
Or: drop down to JDBC to fetch id + fields

29. Search queries
Alternative:
Taking it further:
Pagination in queries, not in app. code
Extra count query may be necessary (totals)
Ordering necessary for paging!

30. Search queries
Subtle:
Alternative: effect of applying setMaxResults
“The
or setFirstResult to a query involving
fetch joins over collections is undefined”
Taking it further:
Cause: the emitted join possibly returns
several rows per entity. So LIMIT,
rownums, TOP cannot be used!
Instead Hibernate must fetch all rows
WARNING: firstResult/maxResults specified with
Pagination in queries, not in app. code
collection fetch; applying in memory!
Extra count query may be necessary (totals)
Ordering necessary for paging!

31. Large collections

32. Large collections
Frontend:
Request
CompanyGroup
1..*
Backend:
Company
CompanyGroup
1..*
Meta-data
Company read-only entity, CompanyInGroup
backed by expensive view *..1
Company

33. Large collections
Frontend:
Request
CompanyGroup
1..*
Backend:
Company
CompanyGroup
1..*
Meta-data
CompanyInGroup
*..1
Company

34. Large collections
Frontend:
Request
CompanyGroup
1..*
Backend:
Company
CompanyGroup
1..*
Meta-data
CompanyInGroup
*..1
Company

35. Large collections
Opening large groups sluggish
Improved performance:
Fetches many uninitialized collections in 1 query
Also possible on entity:
Request
CompanyGroup
1..*
Company

36. Large collections
Opening large groups sluggish
Improved performance:
Fetches many uninitialized collections in 1 query
Also possible on entity:
Request
CompanyGroup
1..*
Company
Better solution in hindsight: fetch join

37. Large collections
Saving large group slow: >15 sec.
Problem: Hibernate inserts row by row
Query creation overhead, network latency
Solution: <property name="hibernate.jdbc.batch_size">100
</property>
Enables JDBC batched statements
Caution: global property Request
CompanyGroup
Also: <property name="hibernate.order_inserts">true
1..*
</property> Company
<property name="hibernate.order_updates">true
</property>

38. Large collections
Frontend:
Request
CompanyGroup
1..*
Backend:
Company
CompanyGroup
1..*
Meta-data
CompanyInGroup
*..1
Company

39. Large collections
Backend:
CompanyGroup
1..*
Meta-data
CompanyInGroup
*..1
Company

40. Large collections
Process CreateGroup (Soap) Business
Service Service
CreateGroup took ~10 min. for 1000 companies
@BatchSize on Company improved demarshalling
JDBC batch_size property marginal improvement
INFO: INSERT INTO CompanyInGroup VALUES (?,...,?)
INFO: SELECT @identity
INFO: INSERT INTO CompanyInGroup VALUES (?,...,?)
INFO: SELECT @identity
.. 1000 times CompanyGroup
1..*
Meta-data
Insert/select interleaved: due to gen. id CompanyInGroup
*..1
Company

41. Large collections
Process CreateGroup (Soap) Business
Service Service
Solution: generate id in app. (not always feasible)
Running in ~3 minutes with batched inserts
Next problem: heap usage spiking
Use StatelessSession
✦ Bypass first-level cache
✦ No automatic dirty checking CompanyGroup
✦ Bypass Hibernate event model and interceptors 1..*
Meta-data
✦ No cascading of operations CompanyInGroup
✦ Collections on entities are ignored *..1
Company

42. Large collections
Process CreateGroup (Soap) Business
Service Service
Solution: generate id in app. (not always feasible)
Running in ~3 minutes with batched inserts
Next problem: heap usage spiking
Use StatelessSession
CompanyGroup
1..*
Meta-data
CompanyInGroup
*..1
Company

43. Large collections
Process CreateGroup (Soap) Business
Service Service
Now ~1 min., everybody happy!
CompanyGroup
1..*
Meta-data
CompanyInGroup
*..1
Company

44. Large collections
Process CreateGroup (Soap) Business
Service Service
Now ~1 min., everybody happy!
Data loss detected!
CompanyGroup
1..*
Meta-data
CompanyInGroup
*..1
Company

45. Large collections
Process CreateGroup (Soap) Business
Service Service Data loss detected!
StatelessSession and JDBC batch_size bug
Only ‘full’ batches are performed!
HHH-4042: Closed, won’t fix :
CompanyGroup
1..*
Meta-data
CompanyInGroup
*..1
Company

46. Odds & Ends

47. Query hints
Speed up read-only service calls:
Hibernate Query.setHint():
Also: never use 2nd level cache just ‘because we can’

48. Query hints
Speed up read-only service calls:
Hibernate Query.setHint():
Also: never use 2nd level cache just ‘because we can’
@org.hibernate.annotations.Entity(mutable = false)

49. Large updates
Naive approach:
Entities are not always necessary:
Changes are not reflected in persistence context
With optimistic concurrency: VERSIONED keyword

50. Large updates
Naive approach:
Entities are not always necessary:
Changes are not reflected in persistence context
With optimistic concurrency: VERSIONED keyword
Consider use of stored procedures

51. Dynamic updates
@org.hibernate.annotations.Entity (dynamicInsert =
true, dynamicUpdate = true )
Only changed columns updated/inserted
Beneficial for tables with many columns
Downsides
Runtime SQL generation overhead
No PreparedStatement (caching) used anymore

52. Cherish your database
Data and schema probably live longer than app.
Good indexes make a world of difference
Stored procedures etc. are not inherently evil
Do not let Hibernate dictate your schema
Though sometimes you are forced
There are other solutions (there I said it)
Read the Endeavour JPA Guideline!

53. Questions