Hi Michael, First thank you for your response.
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. (*)" Are you saying there should not be a difference for this test case between oak/jcr? I understand your point that I am testing how fast Oak/JR put's things into a database, but from my perspective I am doing simple JCR operations like creating/updating/moving a reasonable number of nodes and JR seems to be performing significantly better. I also ran the tests at 100 nodes and in general Jackrabbit 2's performance in particular around copy, updates, and moves are generally better (I understand why for moves) . Is this expected? FYI 1000 and 100000 node creation these are realistic use cases as our application generates very large datasets (it is common to see 500gb/1000 files or more get added to a repo in one user session). "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. Can you point me to any test cases where I can see the configuration for something like this? 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. Are there any performance metrics out there for Oak that use DocumentNodestore/Filedatastore that someone could share? If I am understanding correctly, I need to add nodes/horizontally scale for Oak's performance to improve. My overall goal here is to determine whether it benefits us to upgrade from JR, but is it fair to compare the two? FYI our application can be deployed as one or mult nodes on premise or in a cloud. thanks, Domenic On Thu, Apr 7, 2016 at 11:04 AM, Michael Marth <mma...@adobe.com> wrote: > 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 > -- Domenic DiTano ANSYS, Inc. Tel: 1.724.514.3624 domenic.dit...@ansys.com www.ansys.com
