1 2 Previous Next 17 Replies Latest reply on Sep 6, 2013 7:27 AM by kbachl Go to original post
      • 15. Re: ModeShape 3.5: performance
        rhauch

        Is there a way to completely disable transactions for the infinispan part? I tried to disable it, but I failed;

        You can (as Horia describes above), but then updates will not be written correctly. ModeShape is an ACID system, and needs to write to Infinispan within the scope of a transaction, even if your application is not explicitly using transactions.

        • 16. Re: ModeShape 3.5: performance
          rhauch

          ModeShape 3.x is very different than 2.x, and their performance may indeed be similar in some scenarios. After all, they are both implementing the JCR 2.0 specification and have to do all the same validation of changes. However, in other scenarios, 3.x will certainly outperform 2.x in many ways.

          • 17. Re: ModeShape 3.5: performance
            kbachl

            Hi Randall,

             

            yes you are right - modeshape 3 is very different vom v2. However, a new system never should be less performant than the old one its supposed to replace.

             

            Regarding my research it turns out that mode 3 seems to have some problem with parallels, even I'm still investigating, I found a very interesting behaviour today.

             

            Background Info: we are usng brix cms, a JCR based cms system that allows to design pages out of html and tiles where tiles are small programable things that call java code (wicket);

             

            In search for performance I first contentrated by replacing our heavy lifting tiles (e.g: tiles that are compute intensive) in hope to get better number, but the result were very disappointing. After that I desperately kicked out all rest tiles to see raw performance and then I was hit by a bummer.

            It didn't matter what kind of tile I removed, just by removing a tile the system got faster! Even removing the simplest link rendering tile meant nearly the same performance enhancement as a complex, faceted multi search tile (ofc. latter gets the bonus of the pure query + network time added);

             

            So, I basically just replaced about 15 simpleLinkTiles with its resulting html content and speed the dynamic part in by CMS managed variables (systemwide hashmap);

             

            After that the performance of out live system went up by nearly halfing the response time. A number crunching test on our dev machine showed a throughput at 32 parallel threads of over 4800 renderings/ minute!! Thats the double we had before, and a behaviour mode 2 didnt show by that numbers!

             

            So what happens when brix uses a tile?

            The way brix will scan for the tiles and loop over some data there, where it gets the properites for every configured tile. And this is the thing I'm suspecting thats the problem. For every tile he calls the getProperties of that tile and this seems always to take some time, similar to that request: jcr.Node.getProperties() performance issue

             

            That this poblem doenst matter by the other page data is because brix will cache those in memory and not bother the JCR until it gets notified that the node holding that data got modified;

            1 2 Previous Next