Hi Domenic, My POV: You are essentially testing how fast Oak or JR can put nodes into MySQL/Postgres/Mongo. IMO Oak’s design does not suggest that there should be fundamental differences between JR and Oak for this isolated case. (*)
However, where Oak is expected to outperform JR is when 1) the test case reflects realistic usage patterns and 2) horizontal scalability becomes a topic. To explain: Re 1: in reality you would usually have many reading threads for each writing thread. Oak’s MVCC design caters for performance for such test cases. Re 2: If you have many cluster nodes the MVCC becomes even more pronounced (not only different threads but different processes). Also, if you have observation listeners and many cluster nodes then I expect to see substantial differences between Oak and JR. Cheers Michael (*) with the notable exception of TarMK which I expect to outperform anything on any test case ;) On 06/04/16 16:20, "Domenic DiTano" <domenic.dit...@ansys.com> wrote: >Hi Marcel, > >I uploaded all the source to github along with a summary spreadsheet. I >would appreciate any time you have to review. > >https://github.com/Domenic-Ansys/Jackrabbit2-Oak-Tests > >As you stated the move is a non goal, but in comparison to Jackrabbit 2 I >am also finding in my tests that create, update, and copy are all faster >in Jackrabbit 2 (10k nodes). Any input would be appreciated... > >Also, will MySql will not be listed as "Experimental" at some point? > >Thanks, >Domenic > > >-----Original Message----- >From: Marcel Reutegger [mailto:mreut...@adobe.com] >Sent: Thursday, March 31, 2016 6:14 AM >To: oak-dev@jackrabbit.apache.org >Subject: Re: Jackrabbit 2.10 vs Oak 1.2.7 > >Hi Domenic, > >On 30/03/16 14:34, "Domenic DiTano" wrote: >>"In contrast to Jackrabbit 2, a move of a large subtree is an expensive >>operation in Oak" >>So should I avoid doing a move of a large number of items using Oak? >>If we are using Oak then should we avoid operations with a large number >>of items in general? > >In general it is fine to have a large change set with Oak. With Oak you >can even have change sets that do not fit into the heap. > >> As a FYI - there are other benefits for us to move to Oak, but our >>application uses executes JCR operations with a large number of items >>quite often. I am worried about the performance. >> >>The move method is pretty simple - should I be doing it differently? >> >>public static long moveNodes(Session session, Node node, String >>newNodeName) >>throws Exception{ >> long start = System.currentTimeMillis(); >> session.move(node.getPath(), "/"+newNodeName); >> session.save(); >> long end = System.currentTimeMillis(); >> return end-start; >>} > >No, this is fine. As mentioned earlier, with Oak a move operation is not >cheap and is basically implemented as copy to new location and delete at >the old location. > >A cheap move operation was considered a non-goal when Oak was designed: >https://wiki.apache.org/jackrabbit/Goals%20and%20non%20goals%20for%20Jackr >a >bbit%203 > > >Regards > Marcel
