> 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]> ----------------------------------------------------------------
