Hi there, as requested I repost this here. our teams have been suffering from the bad performance of the Continuum-UI for a long time . I found now the time to profile one of our servers running 3 Continuum-1.2.2-instances (webapps) on a single Tomcat6, JDK6, RHEL4 and Oracle-RAC as database-backend.
The tomcat-JVM is consuming between 150 and 200 % of our dual-core Xeon-server. This is just the tomcat-JVM, not any maven-process running aside. And I am not talking about peaks, the load is as high like that for hours. This is a snapshot taken by Jprofiler at a time without any user-activity on one of the UI's. the 3 threads causing the highest load are: 37,3% - 54.415 ms - 5 inv. org.jpox.AbstractPersistenceManager.detachCopyAll 13,6% - 19.842 ms - 14 inv. org.codehaus.plexus.jdo.PlexusJdoUtils.getObjectById 34,5% - 50.362 ms - 4.480 inv. edu.emory.mathcs.backport.java.util.concurrent.BlockingQueue.poll (100% = total load caused by the JVM) The first 2 threads are caused by the JDO-impl. Is it possible that Continuum has an extremely "bad" fetching stragety, e. g. doing all kinds of unnecessary loading cascades? This is my first impression. About the 3rd thread, I have no idea why this BlockingQueue is causing such a tremendous load. What is the purpose of this thread? Can it be optimized. The slow performance is not only while adding new project groups. There is a high CPU-load almost constantly between 100 and 200 % (on dual core): 12795 tomcat 16 0 171 7238:01 40.9 12.0g 6.3g 10m S java thanks Marc -- View this message in context: http://www.nabble.com/Profiling-results-for-Continuum-tp24142787p24142787.html Sent from the Continuum - Dev mailing list archive at Nabble.com.
