Thanks for the insight into versioning issues. I have a related questions. Does limiting the number of versions increase the performance of activation? Thanks Garima
2009/10/6 Jan Haderka <[email protected]> This is a question which is nearly impossible to answer generally. There is no "silver bullet" settings. It depends on your exact configuration, performance of the system you are running Magnolia on, amount of content, editors, updates, size of the content, and so on. The versioning feature is not meant for the backup of the content, but for a possibility to re-trace the changes and rollback of individual content. If your business requirements do not mandate versioning of the content and if you have straight publishing process you are nearly always better of without versioning. Not only does it impact the performance, but also the total size of the backend storage. On the other hand even if you need versioning you have some options by structuring the content properly. The versioning of the website content happens automatically on activation, which is what you have noticed, but for example for DMS you can set versioning upon saving of the content rather then during activation so you will version only and only when you actually upload new version of the content. The time necessary for versioning is a function of the size of the content. Think about it when deciding on your content structure. Try to separate as much of the long living rarely changing values from those changing frequently (for example by making use of inheritance and storing rarely changing common values in parent pages, even when rendering then only in child pages). Another strategy you can put in the mix, if the content is not changing rapidly in your environment and if you use workflow is to move versioning into the activation command chain. This way versioning will not happen interactively, so the AdminCentral will respond much faster to the activation request, but there will be tiny window (less then second) in which content could be modified after you click "activate" and before the versioning of the content actually happens. If that is acceptable risk (which should be fine if the content is not changing rapidly or if your editorial process ensures that each editor is responsible for different part of the site and they in general do not meddle with each others content) you can use this to improve perceived activation speed. ... you see there are many ifs and maybes in the above because it really depends on exact setting and environment and other imposed limitations ... still I hope it gives you at least some insights in what and how can be improved. Cheers, Jan On Tue, 2009-10-06 at 08:27 +0200, Andrea Castelli wrote: > Thank you very much. I disabled versioning and the gain factor is > about 100 and Magnolia now is "Supersonic". > But who should use these feature (versioning)? In a context where > there are 20-50 person in the same moment connected to Magnolia is > very hard to work with the admin interface, also browse the tree. > > My question is: what are your recommendations or the best practices to > mantain the versioning enabled? Or is versioning a feature that in my > environment should stay turned off and regular export of the only > important data is better? > > Thank you. > Andrea > > You can reply in another thread to do not overlap the Denis' > question. > > 2009/10/5 Jan Haderka <[email protected]> > > > > Yes, I made a mistake. > > I'm reading the debate because I'm very interested. > > I noticed low performance when I use the command "activate > this page", > > and the page has other subpages. My question is similar: > what does JR > > do in this operation? Maybe does it made lock on the > subpages so > > performance goes down? > > > If you have enabled the versioning, what happens is that the > page (and > all the sub-pages, if selected) has to be versioned at that > point. The > activation then happens on the versioned content, to make sure > that the > what gets activated is what you actually selected and not any > possible > modifications made by others later. The versioning (among > other things) > means that value of each node has to be copied so it involves > intensive > reading and writing, hence the impact on the performance. > Whether you are using workflow or now, the copying of the node > from the > author instance to the public instance happens later. Again, > this means > that value for each property in the activated content has to > be read > from the repository, the content is converted in the xml and > sent over > to the public instance (together with all other relevant info, > such as > ordering of that content, etc.). The public instance has to > process such > incoming content and import it in the repository. In case of > transactional information, it needs also backup the previous > version of > the content in case there is a rollback request issued later > during the > transaction. Again it involves both reading and writing > from/to repo for > each property of the activated content. > Each of those things are expensive and have negative impact on > performance. > > HTH, > Jan > > > > > > Thank you, sorry for my mistake. > > Best regards. > > Andrea > > > > > > > > > > > > > > 2009/10/5 Jan Haderka <[email protected]> > > > > I believe Andrea meant to forward your mail to > someone else > > (Marco) and > > just hit the "send" button too early :D > > > > > > > > On Mon, 2009-10-05 at 09:48 -0400, Denis Demichev > wrote: > > > Hello > > > > > > I'm not a big expert in Italian - sorry. Is that a > question > > for me? > > > If I interpreted it right, that means do I know > what exactly > > these > > > tomcat parameters mean? > > > > > > If so, I can say that these parameters stand for > how much > > threads will > > > be created by tomcat to handle incoming user > requests. As > > soon as I'm > > > planning 800-1000 concurrent users I thought it > makes sense > > to > > > increase default thread number. > > > > > > > > > Regards, > > > Denis > > > > > > > > > On Mon, Oct 5, 2009 at 9:29 AM, Andrea Castelli > > > <[email protected]> wrote: > > > Ciao Marco sul forum di Magnlia ho letto > questo post > > che > > > sembra interessante: > > > > > > Noi conosciamo questi i valori di questi > parametri > > di Tomcat > > > nella configurazione attuale? > > > > > > > > > Tomcat: maxThreads="800" > minSpareThreads="25" > > > maxSpareThreads="75" > > > Tomcat startup params: > > > JAVA_OPTS=%JAVA_OPTS% -Xms2G -Xmx2G > > -XX:MaxPermSize=1024M -XX: > > > +UseConcMarkSweepGC -XX: > +CMSIncrementalMode > > > -Djava.net.preferIPv4Stack=true -XX: > > +DoEscapeAnalysis > > > > > > > > > Andrea > > > > > > 2009/10/5 Denis Demichev > <[email protected]> > > > > > > > > > Hello All, > > > > > > I've been playing with Magnolia > for a while > > trying to > > > asses its stability. Eventually I > put it > > under the > > > stress on previous week - 800 > concurrent > > users on a > > > single box. > > > > > > Server: Windows Server 2007(?) SP1 > 64 bit, > > Intel Xeon > > > 2 Cores, 4Gb RAM > > > JDK 1.6.0_16 64-bit version > > > Magnolia 4.1 Community Edition > (STK > > Installed, Debug > > > log is disabled) + MySQL 5.1.39 > > > Tomcat: maxThreads="800" > > minSpareThreads="25" > > > maxSpareThreads="75" > > > Tomcat startup params: > > > JAVA_OPTS=%JAVA_OPTS% -Xms2G > -Xmx2G > > > -XX:MaxPermSize=1024M -XX: > > +UseConcMarkSweepGC -XX: > > > +CMSIncrementalMode > > -Djava.net.preferIPv4Stack=true > > > -XX:+DoEscapeAnalysis > > > Client - J-Meter, 800 Concurrent > threads, 5 > > static > > > links + 1 search link, Gaussian > timer set > > for 1000ms > > > +-1500ms > > > Response time 954ms, Errors 17% > > > Avg. CPU utilization ~85%, RAM > Utilization > > ~2Gb > > > > > > Now the strange behavior I noticed > is > > following: > > > Magnolia is responding to incoming > requests > > normally > > > for about 2-5 minutes (more or > less) and > > then just > > > freezes. CPU usage = 0%, RAM is > the same (GC > > is > > > obviously not running). No > responses at all. > > > After removing the stress from > Magnolia it > > starts > > > responding in 30-40 seconds. > > > 500 Concurrent users will produce > the same > > effect with > > > the only exception it might take > 50-100 > > minutes (maybe > > > more) to reproduce. > > > Tried to look at MySQL connection > stack > > using remote > > > admin - 8 connections all of them > are idle. > > Seems like > > > all the content was cached by JCR > > previously. > > > > > > Question: What exactly might cause > this > > strange > > > freezing? It looks like tomcat has > enough > > maximum > > > threads, connection pool to MySQL > is not > > that busy... > > > Could it be some internal cache of > > jackrabbit? Not > > > sure but it looks like JVM is not > the > > rootcause in > > > this case. > > > > > > Would appreciate your thoughts on > this > > point. > > > Thank you in advance! > > > > > > Regards, > > > Denis > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > For list details see > > > http://www.magnolia-cms.com/home/community/mailing-lists.html > > To unsubscribe, E-mail to: > > <[email protected]> > > > ---------------------------------------------------------------- > > > > > > > > > ---------------------------------------------------------------- > For list details see > http://www.magnolia-cms.com/home/community/mailing-lists.html > To unsubscribe, E-mail to: > <[email protected]> > ---------------------------------------------------------------- > > > ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ---------------------------------------------------------------- ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
