ItEr76S18CacheTuning
TWiki>
LibrePlan Web>ItEr76S18CacheTuning (20 Aug 2012, ManuelRego)EditAttach
| Story summary | Cache Tuning |
| Iteration | ItEr76Week01To33 |
| FEA | ItEr76S18CacheTuning |
| Story Lead | |
| Next Story | |
| Passed acceptance test | No |
- 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
-- 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.orgItEr74S08DeployFramework
Here are the results:
- without-cache-tunning.csv: Without cache tunning (commit: 7c91d)
- with-cache-tunning.csv: With cache tunning
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.orgItEr74S08DeployFramework, 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
%RPSHOWGITCOMMITS%
| 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 |
| User | Spent in XpTracker | Spent in phpReport | Ok? |
|---|---|---|---|
| DiegoPino | 32 | 0 |  |
| Total | 32 | 0 | |
Attachments
Attachments| I | Attachment | Action | Size | Date | Who | Comment |
|---|---|---|---|---|---|---|
 csv |
after-cache-tunning.csv | manage | 1.2 K | 18 Apr 2012 - 16:09 | DiegoPino | With cache tunning |
|
csv |
before-cache-tunning.csv | manage | 1.2 K | 18 Apr 2012 - 16:08 | DiegoPino | Without cache tunning (7c91d) |
Copyright (c) by the contributing authors. All material on this collaboration platform is the property of the contributing authors.