Applet performance has historically been a black eye, to say the least, for Java Applets. Slow load times over today's networks are simply not tolerated by today's network standards. I'm currently supporting an Applet that is forced to move to the Java 7 Platform. As such, we are particularly sensitive to anything new that may further hinder applet performance. To that end, I've been doing quite a bit of benchmarking lately of Applet load times using various configurations with the Java 7 Plugin on Windows 7 using IE 8.
The best load times, so far, (when loading the JARs from the web server) occur when caching is employed (e.g., cache_option, cache_archive, cache_version). What I've noticed though, is that when everything else is the same, the performance is degraded by at least half when I check the 'Enable the next-generation Java Plug-in' in the Plugin Control Panel. Applet load times slow down by at least half when this option is enabled. When loading JAR files from the web server, with caching in effect, the applet load time performance is comparable to loading JAR files from the file system only when the next-generation plugin is not enabled. I assume this is because of the associated overhead of spinning-up this external JVM process, but I'm not certain.
Does anyone know if this is a correct assumption? And if I'm correct, are there ways to speed up the loading of an applet when caching is used with the next-generation plugin? Is this another cold-start vs. warm-start issue for the JVM?
My goal is to have applet load times for JARs loaded from the web server, using the next-generation plugin, as fast as when the JARs could be loaded from the local file system (which apparently is no longer possible using the next-generation plugin, sadly).
There are many factors that may impact startup performance.
To better understand what you are observing please provide more details:
a) define what scenario you are looking to
- "cold cache" launch
very first launch of test applet (not cached on disk) and this is first java applet in the current browser session
- "cold" launch
applet had been run previously (in the disk cache) but this is first time java is used in the current browser session
- "warm" launch
java had been used to load some other applet, test applet is in the cache
same applet was already run in the same browser (e.g. you press reload button)
b) describe how exactly you deploy your test applet (how applet/object tag looks like, etc).
How many jars you use and how big are they? Is applet signed? Do you use jar index?
c) what JRE version you are using exactly? 32 or 64 bit? what browser version?
General perf advice:
a) consider using JNLP applets with background update check
b) use Wireshark or any other http sniffer tool to see if there is any network traffic on applet launch.
Unless it is cold start your goal is to have 0 network requests on the critical path
Web Browser: IE 8.0.76
Java Plugin: 7u3 (1.7.0_03-b05)
OS: Windows 7 Enterprise (32-bit)
Server: Websphere 7
Java Applet is in O&M phase and been around a while. Rich Internet Application with file system access requirements. Currently compiled with JDK 1.5. 10 JAR files total, 6 of which are third-party JARs. 4 JARs are custom and are signed.
Assuming caching is the fastest performance I'm going to get by putting JARs on web server, goal was to determine if browser plugin and next-gen plugin will offer the same performance in terms of time to load the Applet.
The two basic test scenarios are using the Browser Plugin (not next-gen) and using the Next-Gen Plugin. That is the only variable I change between test scenarios. Here is the raw data I collected for each test scenario:
The time it takes to load for each first run indicates caching is happening as subsequent runs are faster. I verified that the JVM is not making http requests for cached JAR files by proxying these requests with Tcpmon just to confirm this was the case.
I'm basically just looking for a logical explanation to account for the significant time difference that occurs from this Plugin configuration change. It seems to make logical sense to me that this can be explained by JVM Process start up time, but I'm looking for corroboration on that or another explanation.
Thanks for any advice, help, etc. I'll start looking into JNLP and JAR index as well.
Thanks for the data.
I am not really recommending use of jar index as there were known perf issues because of this.
Try JNLP applets. And latest 7u6 beta from jdk7.java.net
Also, use hints from http://docs.oracle.com/javase/7/docs/webnotes/tsg/TSG-Desktop/html/plugin.html
to enable tracing on browser and client JVM side.
Every JVM spawned will create trace file. This way you can easily find out how many JVMs were spawned.
1s difference can hardly be explained by single JVM launch. I'd expect this to contribute about 100ms.