On Thu, Aug 13, 2009 at 11:21 PM, Vincent Massol <[email protected]> wrote:
If you come to conclusive results it might be great to creata a "JVM Tuning" section on http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Performances with the result of your findings.
I'd be happy to update "Performances" with my results. However, before recommending more widely, I'd like to hear results from others who try out the optimization in a "real world" environment. I'm testing it now with a "clone" of a 6-way virtual-wiki setup on a computer on my network at home. My impressions from running it for over 24 hours is that it works well and "feels" faster -- noticeably faster -- than prior without the optimization. However, "feel' can be deceiving, and I have no numbers, nor am I running in a high-volume/high-load situation that would be a more appropriate test. When 2.0 final is released, I'll upgrade various "live" sites and add the optimization -- at that point I'll have a better idea if this helps, or if there are any "real world" downsides. The bottom line is that the application seems to run fine using "-XX:+DoEscapeAnalysis -XX:+UseBiasedLocking -XX:+AggressiveOpts": no new problems or bugs were noticed by adding the compilation optimizations. I think it would be a good idea to try it out on http://xwiki.org (which could use a "free" perf boost) or http://myxwiki.org and get some real world results. :-) My tomcat process looks like: F S UID PID PPID C PRI NI ADDR SZ WCHAN RSS PSR STIME TTY TIME CMD 0 S tomcat 8804 1 0 80 0 - 462172 futex_ 469116 1 Aug13 ? 9:04 /usr/java/default/bin/java -server -Xms160m -Xmx1024m -XX:PermSize=160m -XX:MaxPermSize=320m -XX:+DoEscapeAnalysis -XX:+UseBiasedLocking -XX:+AggressiveOpts -Djavax.servlet.request.encoding=UTF-8 -Dfile.encoding=UTF-8 -DjavaEncoding=UTF-8 -Djava.awt.headless=true -Djava.library.path=/usr/lib64 -classpath :/usr/share/tomcat6/bin/bootstrap.jar:/usr/share/tomcat6/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/usr/share/tomcat6 -Dcatalina.home=/usr/share/tomcat6 -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat6/temp -Djava.util.logging.config.file=/usr/share/tomcat6/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start Using: XWiki 2.0M2, Sun's jdk-1.6.0_14-fcs.x86_64, Fedora's tomcat6-6.0.18-6.2.fc10.noarch, tomcat-native-1.1.16-1.fc10.x86_64, tomcat6-lib-6.0.18-6.2.fc10.noarch, tomcat6-servlet-2.5-api-6.0.18-6.2.fc10.noarch, on "Linux 2.6.27.29-170.2.78.fc10.x86_64 #1 SMP Fri Jul 31 04:16:20 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux" All running on a $500 AMD Opteron 1220 2.80GHz Dual Core "server" http://www.tigerdirect.com/applications/SearchTools/item-details.asp?EdpNo=4... Niels http://nielsmayer.com PS: also, needing revisiting, Sun HotSpot's G1 Garbage collector, which IMHO may have major performance impact on an application like Xwiki, which probably spends a lot of time creating and garbage-collecting lots of "young" objects. ( http://n2.nabble.com/Does-JDK6u14-"Garbage-First-garbage-collector-(G1)"-work-and-or-improve-Xwiki-performance-size-mem-locality--td2344358.html#a2344358<http://n2.nabble.com/Does-JDK6u14-%22Garbage-First-garbage-collector-(G1)%22-work-and-or-improve-Xwiki-performance-size-mem-locality--td2344358.html#a2344358> ) . As volume increases, the time to collect young objects doesn't increase anywhere close to linear in a real-world system, so optimizations on short-lived memory objects can have significant performance impact in a real world system. Last time I tried the G1 collector, (in an early-access release from Sun, not the "customer ship" version) it had a sergmentation fault after about an hour of being pounded by search-engine hits from all over the planet.