Re: Some more benchmarks
Hi, On Mon, Apr 29, 2013 at 10:17 AM, Lukas Eder wrote: > Are there any test results available with respect to ACL, comparing > Jackrabbit with Oak? Not yet. See the o.a.j.oak.benchmark package in oak-run for some of the existing benchmarks I've been using so far. It should be fairly straightforward to use one of the existing classes as a baseline for building a simple ACL benchmark. BR, Jukka Zitting
Re: Large flat commit problems
Hi, On Mon, Apr 29, 2013 at 10:17 AM, Lukas Eder wrote: > Do comparisons with Jackrabbit exist? Not for this particular benchmark, since Jackrabbit 2.x is unable to deal with such a large transaction (~400MB of non-binary content) or the flat hierarchy (170k child nodes). Some Jackrabbit comparisons are included in the other benchmark thread. BR, Jukka Zitting
Re: Some more benchmarks
Hello, I'm interested in estimating performance (and load) impacts of ACL checking on read access. I'm specifically interested in a comparison where paths like /a, /a/b, /a/b/c, /a/.../y/z are accessed, and ACL has to be evaluated "upwards" on the path. Since such a test is more high-level and may suffer from many side-effects, it's probably more of a load test than a performance test. Are there any test results available with respect to ACL, comparing Jackrabbit with Oak? Are there any load test results available comparing Jackrabbit with Oak? Can you point me to the code of these benchmarks? Cheers Lukas On 4/26/13 1:12 PM, "Jukka Zitting" wrote: >Hi, > >On Wed, Mar 27, 2013 at 11:41 AM, Jukka Zitting >wrote: >> Here's a few more simple benchmark results to show where we are: > >Updated numbers with latest Oak: > ># ReadPropertyTest min 10% 50% 90% max > N >Jackrabbit34 35 37 60 110 > 1333 >Oak-Default8 9 9 20 76 > 4972 >Oak-Mongo 10 10 11 34 38 > 4501 >Oak-Segment 13 13 14 37 44 > 3482 ># SmallFileReadTest min 10% 50% 90% max > N >Jackrabbit50 52 76 117 622 > 764 >Oak-Default 51 53 77 390 496 > 483 >Oak-Mongo159 160 184 517 657 > 259 >Oak-Segment 15 16 17 40 86 > 2813 ># SmallFileWriteTest min 10% 50% 90% max > N >Jackrabbit 181 200 250 4691088 > 105 >Oak-Default 169 180 232 429 923 > 107 >Oak-Mongo698 727 88610511066 >26 >Oak-Segment 221 247 262 337 651 >77 > >Overall that's pretty nice progress. Apart from a few exceptions, >we're now better (sometimes significantly so) or on par with >Jackrabbit 2.x in these benchmarks. > >BR, > >Jukka Zitting
Re: Large flat commit problems
Hi, On 4/26/13 2:15 PM, "Jukka Zitting" wrote: >Hi, > >On Wed, Feb 27, 2013 at 12:24 PM, Jukka Zitting >wrote: >> Added 167000 pages in 467 seconds (2.80ms/page) >> Imported 167404 pages in 1799 seconds (10.75ms/page) > >Here's an update on the latest status with the Wikipedia import benchmark: > >$ java -Xmx1500m -jar oak-run/target/oak-run-0.7-SNAPSHOT.jar \ > benchmark --wikipedia=simplewiki-20130414-pages-articles.xml \ > --cache=200 WikipediaImport Oak-Segment >[...] >Added 171000 pages in 166 seconds (0.97ms/page) >Imported 171382 pages in 355 seconds (2.07ms/page) >[...] >Traversed 171382 pages in 27 seconds (0.16ms/page) > >Pretty good progress here. Those are impressive numbers. Do comparisons with Jackrabbit exist? Cheers Lukas >> There are still a few problems, most notably the fact the index update >> hook operates directly on the plain MemoryNodeBuilder used by the >> current SegmentMK, so it won't benefit from the automatic purging of >> large change-sets and thus ends up requiring lots of memory during the >> massive final save() call. Something like a SegmentNodeBuilder with >> similar internal purge logic like what we already prototyped in >> KernelNodeState should solve that issue. > >This is still an issue, see the -Xmx1500m I used for the import. > >> The other big issue is the large amount of time spent processing the >> commit hooks. The one hook approach I outlined earlier should help us >> there. > >The work we've done here with the Editor mechanism is clearly paying >off as the commit hooks are now taking some 53% of the import time, >down from 74% two months ago, even when we've been adding more >functionality there. > >BR, > >Jukka Zitting
