Thank you, of course a better knowledge of alternatives and processes lead everyone to make a better choice.
Cheers, Andrea 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]> ----------------------------------------------------------------
