Re: [xwiki-devs] Improve performance with new sun hotspot optimizations for Java 6u14?

On Thu, Aug 13, 2009 at 11:21 PM, Vincent Massol <vincent(a)massol.net> wrote: 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=… 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… ) . 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.