-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/25815/#review53988
-----------------------------------------------------------

Ship it!


Ship It!

- Maxim Khutornenko


On Sept. 19, 2014, 6:42 p.m., Bill Farner wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25815/
> -----------------------------------------------------------
> 
> (Updated Sept. 19, 2014, 6:42 p.m.)
> 
> 
> Review request for Aurora, Maxim Khutornenko and Zameer Manji.
> 
> 
> Bugs: AURORA-730
>     https://issues.apache.org/jira/browse/AURORA-730
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> This patch enables the MyBatis "2nd level" cache [1] for the AttributeMapper 
> namespace.  Based on some ad-hoc local benchmarking, this improves 
> performance by about 50x (when the cache is primed).  MyBatis flushes these 
> caches on insert/update, so it's important we don't unnecessarily write to 
> the table.  For this reason,  I've also suppressed no-op writes.
> 
> [1] http://mybatis.github.io/mybatis-3/sqlmap-xml.html#cache
> 
> 
> Diffs
> -----
> 
>   src/main/java/org/apache/aurora/scheduler/storage/db/DbAttributeStore.java 
> 1b18ad5ab8e640d64f5de0aebdc98d0f8dc411c2 
>   
> src/main/resources/org/apache/aurora/scheduler/storage/db/AttributeMapper.xml 
> 53017c8806d2a5cdd1d181fd156afc9afca2faf7 
>   
> src/test/java/org/apache/aurora/scheduler/storage/db/DbAttributeStoreTest.java
>  4a31999559dce4cfe50b22fc97d1500c9528a242 
> 
> Diff: https://reviews.apache.org/r/25815/diff/
> 
> 
> Testing
> -------
> 
> ./gradlew build -Pq
> 
> Lacking a story for performance testing, i failed to come up with a good way 
> to prove that these help.  Best answer i have is local testing (creating a 
> store with ~20k attributes and issuing 1M random queries is repeatably ~50x 
> faster), and 100% line/branch test coverage to prove we hit the no-op exit.
> 
> 
> Thanks,
> 
> Bill Farner
> 
>

Reply via email to