This content has been marked as final. Show 6 replies
if we make the applet run from NetBeans(as standalone Java application), it takes less than 30 seconds to complete document generation.So maybe Netbeans already has a JVM primed and ready to run.
However if we make it run on browser, it takes more than 53 seconds. Any body knows why the applet is much slower than standalone application?Does it matter? Do you have any users who are in a position to make the comparison?
So, we've put JVM option, "-Xms512m -Xmx1024m" and we got a better performance which is less than 30 seconds.That puzzles me. The amount of free heap space shouldn't impact performance at all. Yet it does according to you. The only thing I can think of is really poor garbage collection performance, with more heap space it would have more breathing space.
even with this option in JVM and putting "-Xms512m -Xmx1024m" to java_arguments property in Applet tag in web page, the performance of applet running on browser doesn't change at all and it took more than 53 seconds.How old is the installed Java plugin I wonder? You can only change the heap size through the applet tag when running the "new" Java plugin (Java 6 update 10 and up).
Another thing you can try is in Netbeans to make the heap space small on purpose, like max=128m. Does that make the application slower when running under Netbeans? And while were on that topic, is Netbeans using the exact same JDK/JRE as the browser plugin?
For our testing, we've beeing using JRE 220.127.116.11.
If we set heap size to max=128m in Netbeans, we can see that the application is getting slower and slower and finally almost hanged when it generate the document. but with max=256m, it works ok even though it is slower.
we've been using same JDK/JRE for both Netbeans and browser plugin at same PC.
actually, we have active X version of the this application, and the performance is much better than Java applet version. we understand that Java application/applet could be slower than native application, but we'd like to achieve reasonable performance for Java applet version too.
again, it would be appreciated if proper solution/tip is provided....
0. I assume you are using "new generation plugin" with 6u26 (not old plugin that works inside the browser process)
1. Use jVisualVM or jconsole to observe heap consumption by standalone app, webstart app or applet
Do you observe same memory consumption patern? same heap settings?
(For applet make sure to attach to out of browser process)
2. Enable full tracing as described here http://docs.oracle.com/javase/7/docs/webnotes/tsg/TSG-Desktop/html/plugin.html#gcexdf
and post trace here. At least details on what is result JNLP file in case of applet and what are JVM parameters.
(I assume you use JNLP applet and duplicate parameters in the JNLP file and html page tag)
3. You may attach profile to applet/webstart and get some data on what is slower comparing to standalone launch.
Given that it never fails with OOM it seem you might have some caches based on weak/soft references that
grow too big. Or may be your app is filling internal deployment memory caches.
Heap dump or heap analysis may give you hints what occupies most of the heap. Then you can think how to reduce heap consumption.
Thanks for your help and sorry for late response. I've been in holidays...
I've posted the files you've asked here, https://skydrive-df.live.com/?cid=C7E677B8EC24DCC1&id=C7E677B8EC24DCC1%21376
For memory consumption, please find attachment, memory consumption comparison.zip. Look JNLP version uses more memory than Plugin version
For tracing result, please find the attachements, trace.zip one with JNLP and the other with Plugin.
Thanks for your help in advance.