Tags:
create new tag
view all tags

ItEr76S18CacheTuning

Story summary Cache Tuning
Iteration ItEr76Week01To33
FEA ItEr76S18CacheTuning
Story Lead  
Next Story  
Passed acceptance test No

Acceptance Criteria

  • Activate Second-Level Cache
    • Measure perfomance improvements (check if there are cache hits)
  • Activate Batch-Fetching
    • Check if there are less SQL queries
    • Check with fetch strategies: size = 2 and subselect

Additional Specification Comments

Implementation Notes

-- DiegoPino - 19 Mar 2012

Caches

Entidades que tienen cachés activadas:

  • AdvanceType:nonstrict-read-write
  • AdvanceType:nonstrict-read-write
  • BaseCalendar:read-write
  • TypeOfWorkHours:nonstrict-read-write
  • Label:nonstrict-read-write
  • LabelType:nonstrict-read-write
  • labels:nonstrict-read-write
  • UnitType:nonstrict-read-write
  • Resource:read-write
  • criterionSatisfactions:read-write
  • Criterion:nonstrict-read-write
  • CriterionSatisfaction:read-write
  • CriterionType:nonstrict-read-write
  • criterions:nonstrict-read-write
  • WorkReportType:nonstrict-read-write

Did:

  • Read about second-level cache and batch fetching (read Hibernate's bible chapter about caches and batch fetching, plus several blogs).
  • Wrote the analysis story with all the information collected.
  • Created a project with several entities which were set to be cached.

-- DiegoPino - 26 Mar 2012

  • I managed to configure Hibernate for using second-level cache and logging the second cache activity to a file.
  • There are cache-hits for BaseCalendar.
  • TODO: Try other entities and find a way to measure the performance improvement.

Cache hits

  • AdvanceType:checked
  • BaseCalendar:checked
  • TypeOfWorkHours:checked
  • Label:checked
  • LabelType:checked
  • labels:checked
  • UnitType:checked
  • Resource:checked
    • criterionSatisfactions:checked
  • Criterion:checked
  • CriterionSatisfaction:checked
  • CriterionType:checked
    • criterions:checked
  • WorkReportType:checked

I checked that all the entities that have second-level cached configured are being cached and there are cache hits for all of them.

-- DiegoPino - 27 Mar 2012

  • Identify which entities could benefit the most from batch fetching.
  • Identify entities that have sets.
  • Activate batch-size=10 for all one-to-many sets in all Entitites.
  • When I opened my current project I got the following error in the Gantt view: "Failed to process invoke W[V] is undefined (TypeError)".
  • I had to fix a coding error in liquibase in order to launch LibrePlan.

-- DiegoPino - 28 Mar 2012

It seems batch-size="10" is not working for sets. I get a LazyInitializationException. Things to try:

  • Configurate batch_fetch_size at global level. hibernate.default_batch_fetch_size.
  • Configure batch_fetching for only one entity OrderElement.

-- DiegoPino - 28 Mar 2012

It seems batch-size="10" is not working for sets. I get a LazyInitializationException. Things to try:

  • Configurate batch_fetch_size at global level. hibernate.default_batch_fetch_size.
  • Configure batch_fetching for only one entity OrderElement.

-- DiegoPino - 18 Apr 2012

I did some benchmarking of the cache-tunning branch. I used Jmeter, following the instructions at:

http://wiki.libreplan.org/twiki/bin/view/LibrePlan/ItEr74S08DeployFramework

Here are the results:

I executed the tests twice and the results are identical. I notice a big improvement on the MAX value and Standard Deviation with cache-tunning, the other values improve only a bit or are almost identical.

The results are apparently better using cache-tunnning and batch-fetching, specially the standard deviation, but I don't fully understand what each parameter means. I was reading about it here: Some thoughts on stress testing with JMeter

-- DiegoPino - 16 May 2012

I have been reading about JMeter, how to understand the results, etc. What puzzled me a bit was that with the given results I couldn't understand if the performance improved or not. I was looking for something like response time but couldn't find it.

The columns average, aggregate_report_min and aggregate_report_max are a measure of the response time for each use case. With the caches the average of these results improve a bit but what improves the most is the max value. As the max value decreases significantly the standard deviation (varianza) decreases a lot too.

In conclusion, with the adjustments done the results are much better and is worth to push these patches to master.

Summary

Summary of the results without cache and with cache.

aggregate_report_count average aggregate_report_min aggregate_report_max aggregate_report_stddev aggregate_report_error% aggregate_report_rate aggreg_report_bandwidth average_bytes
520 2 1 34 2.7873014828347897 1.0 2.0230156939332873 2.934934241048156 1485.5903846153847
521 2 0 9 0.9711978332274673 1.0 1.9918338634695378 2.8898175199661273 1485.6525911708254
- 0% 100% 75% 65% - - - -

Explanation:

  • Aggregate report count. It's the number of use cases executed. According to http://wiki.libreplan.org/twiki/bin/view/LibrePlan/ItEr74S08DeployFramework, Oscar recommended to execute 60 samples for each use case. Both tests, executed a similar number of samples (520 vs 521, a difference of 1).
  • Average. It's the average response time. On average there is no gain.
  • Aggregate_report_min. It's the min response time. With cache the min is 0, without cache 1.
  • Aggregate_report_max. It's the max response time. With cache the max is 9, without cache 34, so there's a 75% gain (34 - 9 / 34)
  • Aggregate_report_stddev. Standard deviation. Without cache was high because the the average is 2 and the min and max are 1 and 34 respectively.
As with caches the max value is considerably reduced, the standard deviation is reduced too. There's a 65%.

Times are in milliseconds. More info here: JMeter Aggregate Report

-- DiegoPino - 16 May 2012

Delay Causes

Final or Pending Considerations

Commits

%RPSHOWGITCOMMITS%

Tasks in this story

Tasks Est Spent To do Risk Reviewer Developer Task Name Start Date Est End Date End Date
Task 35 32 0 Low ManuelRego DiegoPino Implementation 12/03/2011 23/03/2011 24/05/2012

Total Hours in this Story

%RPSHOWTOTALHOURS%


Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatcsv after-cache-tunning.csv r1 manage 1.2 K 18 Apr 2012 - 16:09 UnknownUser With cache tunning
Unknown file formatcsv before-cache-tunning.csv r1 manage 1.2 K 18 Apr 2012 - 16:08 UnknownUser Without cache tunning (7c91d)
Edit | Attach | Watch | Print version | History: r14 < r13 < r12 < r11 < r10 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r14 - 20 Aug 2012 - mrego
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback