Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Hibernate Performance Tuning (JEEConf 2012)

12,761 views

Published on

Hibernate Performance Tuning, presented on JEEConf 2012, Kiev, Ukraine.

Also see: http://branchandbound.net/blog/conferences/2012/05/jeeconf-tripreport/

Adaptation of presentation at http://www.slideshare.net/SanderMak/hibernate-performance-tuning

Published in: Technology, Business
  • Hi, is slide 16 correct? I thought @OneToOne was by default EAGER as well.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Hibernate Performance Tuning (JEEConf 2012)

  1. 1. Performance Tuning@Sander_Makbranchandbound.net
  2. 2. Hibernate sucks! ... because it’s slow
  3. 3. 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)
  4. 4. ‘Most of the performance problems we have comeup against have been solved not by codeoptimizations, but by adding new functionality.’ - Gavin King (creator)
  5. 5. ‘You cant communicate complexity,only an awareness of it.’ - Alan J. Perlis (1st Turing Award winner)
  6. 6. Outline Optimization Lazy loading Examples ‘from the trenches’ Search queries Large collections Batching Odds & Ends
  7. 7. Optimization
  8. 8. Optimization is hard Performance blame Framework vs. You When to optimize? Preserve correctness at all times Unit tests ok, but not enough Automated integration tests
  9. 9. Optimization is hard Performance blame Framework vs. You When to optimize? Preserve correctness at all times Unit tests ok, but not enough Automated integration tests Premature optimization is the root of all evil - Donald Knuth
  10. 10. Optimization guidelinesMeasurement 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 IO statistics (hot cache or disk thrashing?) Query plans Make many measurements -> automation
  11. 11. Optimization guidelinesPractical Profiler on DAO/Session.query() methods VisualVM etc. for heap usage many commercial tools also have built-in JDBC profiling Hibernate JMX <property name="hibernate.generate_statistics">true </property> RDBMS monitoring tools
  12. 12. Analyzing HibernateLog SQL: <property name="show_sql">true</property> <property name="format_sql">true</property>Log4J configuration: org.hibernate.SQL -> DEBUG org.hibernate.type -> TRACE (see bound params)Or use P6Spy/Log4JDBC on JDBC connection
  13. 13. Analyzing Hibernate 2011-07-28 09:57:12,061 DEBUG org.hibernate.SQL - insert into BASKET_LINE_ALLOC (LAST_UPDATED, QUANTITY, CUSTOMER_REF, NOTES, BRANCH_ID, FUND_ID, TEMPLATE_ID, BASKET_LINE_ALLOC_ID) values (?, ?, ?, ?, ?, ?, ?, ?)Log SQL: 2011-07-28 09:57:12,081 DEBUG org.hibernate.type.TimestampType - binding 2006-07-28 09:57:12 to parameter: 1 2011-07-28 09:57:12,081 DEBUG org.hibernate.type.IntegerType - binding 3 to parameter: 2 <property name="show_sql">true</property> 2011-07-28 09:57:12,082 DEBUG org.hibernate.type.StringType - binding to parameter: 3 2011-07-28 09:57:12,082 DEBUG org.hibernate.type.StringType - binding to parameter: 4 <property name="format_sql">true</property> 2011-07-28 09:57:12,082 DEBUG org.hibernate.type.LongType - binding 511 to parameter: 5 2011-07-28 09:57:12,082 DEBUG org.hibernate.type.LongType - binding 512 to parameter: 6 2011-07-28 09:57:12,082 DEBUG org.hibernate.type.LongType - binding null to parameter: 7 2011-07-28 09:57:12,082 DEBUG org.hibernate.type.LongType - binding 180030 to parameter: 8 Hibernate: INSERT INTO mkyong.stock_transaction (CHANGE, CLOSE, DATE, OPEN, STOCK_ID, VOLUME)Log4J configuration: VALUES (?, ?, ?, ?, ?, ?) 2011-07-28 13:33:07,253 DEBUG FloatType:133 - binding 10.0 to parameter: 1 2011-07-28 13:33:07,253 DEBUG FloatType:133 - binding 1.1 to parameter: 2 2011-07-28 13:33:07,253 DEBUG DateType:133 - binding 30 December 2009 to parameter: 3 org.hibernate.SQL -> DEBUG 2011-07-28 13:33:07,269 DEBUG FloatType:133 - binding 1.2 to parameter: 4 2011-07-28 13:33:07,269 DEBUG IntegerType:133 - binding 11 to parameter: 5 2011-07-28 13:33:07,269 DEBUG LongType:133 - binding 1000000 to parameter: 6 2011-07-28 09:57:12,061 DEBUG org.hibernate.SQL - insert into BASKET_LINE_ALLOC (LAST_UPDATED, QUANTITY, CUSTOMER_REF, NOTES, BRANCH_ID, FUND_ID, TEMPLATE_ID, org.hibernate.type -> TRACE (see bound params) BASKET_LINE_ALLOC_ID) values (?, ?, ?, ?, ?, ?, ?, ?) 2011-07-28 09:57:12,081 DEBUG org.hibernate.type.TimestampType - binding 2006-07-28 09:57:12 to 2011-07-28 09:57:12,081 DEBUG org.hibernate.type.IntegerType - binding 3 to parameter: 2 parameter: 1 2011-07-28 09:57:12,082 DEBUG org.hibernate.type.StringType - binding to parameter: 3 2011-07-28 09:57:12,082 DEBUG org.hibernate.type.StringType - binding to parameter: 4 2011-07-28 09:57:12,082 DEBUG org.hibernate.type.LongType - binding 511 to parameter: 5 2011-07-28 09:57:12,082 DEBUG org.hibernate.type.LongType - binding 512 to parameter: 6 2011-07-28 09:57:12,082 DEBUG org.hibernate.type.LongType - binding null to parameter: 7Or use P6Spy/Log4JDBC on JDBC connection 2011-07-28 09:57:12,082 DEBUG org.hibernate.type.LongType - binding 180030 to parameter: 8 Hibernate: INSERT INTO mkyong.stock_transaction (CHANGE, CLOSE, DATE, OPEN, STOCK_ID, VOLUME) VALUES (?, ?, ?, ?, ?, ?) 2011-07-28 13:33:07,253 DEBUG FloatType:133 - binding 10.0 to parameter: 1 2011-07-28 13:33:07,253 DEBUG FloatType:133 - binding 1.1 to parameter: 2 2011-07-28 13:33:07,253 DEBUG DateType:133 - binding 30 December 2009 to parameter: 3 2011-07-28 13:33:07,269 DEBUG FloatType:133 - binding 1.2 to parameter: 4 2011-07-28 13:33:07,269 DEBUG IntegerType:133 - binding 11 to parameter: 5 2011-07-28 13:33:07,269 DEBUG LongType:133 - binding 1000000 to parameter: 6
  14. 14. Lazy loading
  15. 15. Lazy loadingOne entity to rule them all RequestMostly sane defaults: 1..1@OneToOne,@OneToMany, User@ManyToMany: LAZY 1..* *..1@ManyToOne : EAGER(Due to JPA spec.) AuthorizationExtra-lazy: Hibernate *..1specific Global Company 1..* Company
  16. 16. LazyInitializationException
  17. 17. Lazy loading N+1 Selects problemSelect list of N users HQL: SELECT u FROM UserAuthorizations necessary: SQL 1 query: SELECT * FROM User N select queries on LEFT JOIN Company c Authorization executed! WHERE u.worksForCompany = c.idSolution: FETCH JOINS @Fetch(FetchMode.JOI N) @FetchProfile (enable per session don’t call .size()
  18. 18. Lazy loading N+1 Selects problemSelect list of N users HQL: SELECT u FROM UserAuthorizations necessary: SQL N queries: SELECT * FROM Authorization N select queries on WHERE userId = N Authorization executed!Solution: FETCH JOINS @Fetch(FetchMode.JOI N) @FetchProfile (enable per session don’t call .size()
  19. 19. Lazy loading N+1 Selects problem HQL: SELECT u FROM User OUTERSelect list of N users JOIN FETCH u.authorizationsAuthorizations necessary: SQL 1 query: N select queries on SELECT * FROM User Authorization executed! LEFT JOIN Company c LEFT OUTER JOIN AuthorizationSolution: ON .. WHERE u.worksForCompany = c.id FETCH JOINS @Fetch(FetchMode.JOI N) @FetchProfile (enable per session don’t call .size()
  20. 20. Lazy loadingSome 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 reverted exception: Session.load()/EntityManager.getReference()
  21. 21. Search queries
  22. 22. Search queries Search User Result list 1..* *..1Authorization *..1 Global 1..* Company Company Detail
  23. 23. Search queriesObvious solution:Too much information!Use summary objects:UserSummary = POJO not attached, only necessary fields (no relations)
  24. 24. Search queriesObvious 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
  25. 25. Search queriesAlternative:Taking it further:Pagination in queries, not in app. codeExtra count query may be necessary (totals) Ordering necessary for paging!
  26. 26. 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 withPagination in queries, not in app. code collection fetch; applying in memory!Extra count query may be necessary (totals) Ordering necessary for paging!
  27. 27. Analytics & reporting ORM less relevant: no entities, but complex aggregations Simple sum/avg/counts possible over entities Specialized db calls for complex reports: Partitioning/windowing etc. Integrate using native query Or create a database view and map entity
  28. 28. Large collections
  29. 29. Large collections Frontend: Request CompanyGroup 1..* Backend: Company CompanyGroup 1..* Meta-dataCompany read-only entity, CompanyInGroupbacked by expensive view *..1 Company
  30. 30. Large collections Frontend: Request CompanyGroup 1..* Backend: Company CompanyGroup 1..* Meta-data CompanyInGroup *..1 Company
  31. 31. Large collections Frontend: Request CompanyGroup 1..* Backend: Company CompanyGroup 1..* Meta-data CompanyInGroup *..1 Company
  32. 32. Large collections Opening large groups sluggish Improved performance: Fetches many uninitialized collections in 1 query Also possible on entity: Request CompanyGroup 1..* Company
  33. 33. 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
  34. 34. Large collections Extra lazy collection fetching Efficient: companies.size() -> count query companies.contains() -> select 1 where ... companies.get(n) -> select * where index = n
  35. 35. 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>
  36. 36. Large collections Frontend: Request CompanyGroup 1..* Backend: Company CompanyGroup 1..* Meta-data CompanyInGroup *..1 Company
  37. 37. Large collections Backend: CompanyGroup 1..* Meta-data CompanyInGroup *..1 Company
  38. 38. Large collectionsProcess CreateGroup (Soap) BusinessService Service CreateGroup: ~10 min. for thousands of 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
  39. 39. Large collectionsProcess CreateGroup (Soap) BusinessService 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
  40. 40. Large collectionsProcess CreateGroup (Soap) BusinessService 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
  41. 41. Large collectionsProcess CreateGroup (Soap) BusinessService Service Now <1 min., everybody happy! CompanyGroup 1..* Meta-data CompanyInGroup *..1 Company
  42. 42. Large collectionsProcess CreateGroup (Soap) BusinessService Service Now <1 min., everybody happy! Data loss detected! CompanyGroup 1..* Meta-data CompanyInGroup *..1 Company
  43. 43. Large collectionsProcess CreateGroup (Soap) BusinessService Service Data loss detected! StatelessSession and JDBC batch_size bug HHH-4042: Closed, won’t fix : CompanyGroup 1..* Meta-data CompanyInGroup *..1 Company
  44. 44. Odds & Ends
  45. 45. Dirty little secret validated(item) performs read-only queries select currentItem from Catalog where .. Dirty collection after select spendingLimit from User where .. each iteration insert into Item values (?, ?, ?) select currentItem from Catalog where .. select spendingLimit from User where .. Batching fails insert into Item values (?, ?, ?) Flushmode.AUTO Loops always suspect: relational, set-based thinking
  46. 46. Dirty little secret validated(item) performs read-only queries Dirty collection after each iteration Batching fails Flushmode.AUTO Loops always suspect: relational, set-based thinking
  47. 47. Query hintsSpeed up read-only service calls:Hibernate Query.setHint():Also: never use 2nd level cache just ‘because we can’
  48. 48. Query hintsSpeed up read-only service calls:Hibernate Query.setHint():Also: never use 2nd level cache just ‘because we can’ @org.hibernate.annotations.Immutable
  49. 49. Large updatesNaive approach:Entities are not always necessary:Changes are not reflected in persistence contextWith optimistic concurrency: VERSIONED keyword
  50. 50. Large updatesNaive approach:Entities are not always necessary:Changes are not reflected in persistence contextWith optimistic concurrency: VERSIONED keyword Consider use of stored procedures
  51. 51. Cherish your databaseData and schema outlive your applicationGood indexes make a world of differenceStored procedures etc. are not inherently evilDo not let Hibernate dictate your schema Befriend a DBA instead!There are other solutions (there I said it) MyBatis Squeryl (Scala)
  52. 52. Thanks for listening!@Sander_Mak Join me later today: Elevate your webapps with Scala & Lift! 17:00 Room Cbranchandbound.net

×