Just changed the topic to better describe what is really discussed in this thread now.
And, no, limiting the number of versions has no impact on performance of the activation per se. It has the impact on the total size of the database and therefore it might indirectly impact the performance of the Magnolia instance as a whole, but there is no direct correlation between number of versions and speed of activation. If the versioning is slowing you down and you are more interested in versions as a snapshots of the content at given time, rather then to trace what exactly have been done, you can disable versioning on activation all together and run the scheduled task that would version the whole site each time it is executed (say once a month). HTH, Jan On Wed, 2009-10-07 at 12:01 -0400, Garima Parakh wrote: > > > 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]> > ---------------------------------------------------------------- ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
