This discussion is archived
3 Replies Latest reply: Jun 12, 2012 12:00 PM by 817264 RSS

Next-Generation Java 7 Plugin Performance on Windows 7 and IE 8

934852 Newbie
Currently Being Moderated
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.

To capture Java Applet load times, I've simply been marking the start time in Javascript from the HTML onLoad() event, and then calling out to a similar Javascript function to mark the end time from the bottom of the init() method in the Java Applet. I subtract the two times to get a general idea of how long it takes to load the applet.

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).

Thanks!
  • 1. Re: Next-Generation Java 7 Plugin Performance on Windows 7 and IE 8
    817264 Journeyer
    Currently Being Moderated
    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
    - "reload"
    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
  • 2. Re: Next-Generation Java 7 Plugin Performance on Windows 7 and IE 8
    934852 Newbie
    Currently Being Moderated
    Thanks Igor.

    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.

    JAR1.jar -> 11077 bytes
    JAR2.jar -> 14207 bytes
    JAR3.jar -> 5093 bytes
    JAR4.jar -> 22233 bytes
    JAR5.jar -> 18722 bytes
    JAR6.jar -> 17578 bytes
    JAR7.jar -> 722237 bytes
    JAR8.jar -> 90688 bytes
    JAR9.jar -> 17521 bytes
    JAR10.jar -> 50686 bytes

    JSP Page is used to render the following HTML tags for loading the applet:

    <object classid="clsid:${UID}" name="preview" width="100%" height="300" id="poc">
    <PARAM name="java_code" value="com.loadfast.Applet.class"/>
    <param name="codebase" value="/www/applet"/>
    <PARAM name="cache_option" value="Plugin"/>
    <PARAM NAME="cache_archive" VALUE="
    JAR1.jar,
                        JAR2.jar,
                        JAR3.jar,
                        JAR4.jar,
                        JAR5.jar,
                        JAR6.jar,
                        JAR7.jar,
                        JAR8.jar,
                        JAR9.jar,
                        JAR10.jar
    "/>
    <PARAM NAME="cache_version" VALUE="
                        1.0.0.11,
                        1.0.0.11,
                        1.0.0.11,
                        1.0.0.11,
                        1.0.0.11,
                        1.0.0.11,
                        1.0.0.11,
                        1.0.0.11,
                        1.0.0.11,
                        1.0.0.11"/>
    <PARAM name="type" value="application/x-java-applet"/>
    ...
    </object>

    Here's a brief synopsis of my test methodology:

    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.

    To test, I unchecked the 'Enable Next-Gen' plugin option in the Java Plugin. I updated the cache_version values for all JARs. I 'touched' all JAR files in the WAR (I use cygwin) and redeployed the WAR. I have a cli script that launches IE and points it at my applet. When the applet loads, a Javascript Alert box displays showing the number of milliseconds it took to load the applet. I document the time, quit the browser, and re-execute my script. I do this 10 times for each test scenario and take the average.

    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:

    Not Using Next-Gen Plugin (milliseconds):

    run1 run2 run3 run4 run5 run6 run7 run8 run9 run10
    1761 474 535 495 500 505 502 267 693 513

    Avg: 625ms

    Using Next-Generation Plugin (milliseconds):

    run1 run2 run3 run4 run5 run6 run7 run8 run9 run10
    5382 1529 983 1545 1622 1575 1544 1544 1545 1529

    Avg: 1880ms

    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.
  • 3. Re: Next-Generation Java 7 Plugin Performance on Windows 7 and IE 8
    817264 Journeyer
    Currently Being Moderated
    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.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points