Autovue Performance Tuning | Oracle

We basically hit with performance issues with autovue on loading a file or viewing a complex doc in some clients desktop. We can follow below steps to diagnose and complete the Autovue Performance Tuning.

This issue is seen mainly because of below one or more reasons

1. Older version of JRE
2. File size
3. Caching problem
4. Plugin problem.
5. Permissions Issue
6. 404 errors while loading
7. High Load on server and sockets timing out or a network problem

Before we go for debugging an autovue performance issue we shall know how it works at client side and what it processes to let the user view and work on the file.

When the applet starts below are the gross paths and steps it does to reach the final display

1. It needs the JVM plugin started
2. The jars gets downloaded
3. Then the jars gets validated
4. Then classes gets unpacked and validated
5. AutoVue initializes – more classes gets loaded depending upon requirement and autovue version and filetype
6. AutoVue connects to server
7. Server initiates session with VueLink i.e get user name and authenticates
8. File is set on the client
9. Server receives the file to set, verifies if available in the cache(doc id/doc name/multicontent/date/size/metafile queries)
8. Initiates download (Involves multiple queries, the download query and/or metafile download)
10. Server opens the file
11. Server notifies the client
12. Client loads the file and renders
13. Markups queried, loaded and rendered

So in executing all above steps it might come to some point where there is a glitch which makes the performance issue

Depending on the OS and plugin there are multiple caching mechanism that are triggered

– WINDOWS caches DLLS, so intiializing a VM the first time takes longer than subsequent times

– Jar download is not always done if file is available
– JARs validation is always done so web server will answer faster to timestamp/size requests if they are on its cache.
– Classes are pre-processed when an applet was opened once.
– Autovue session initialization will benefit if socket are already created (on the VueServlet, since it mantains a pool)
– Autovue session init will also be faster if the backend replies faster
– File download times are also faster if thery are on the app server cache.
– Need to check incase some 404 file not found errors comes in loading VueServlet as webtop is known to have issues with handling 404 cases
– Sometimes the issue might be just the applet initializing all the classes it needs, maybe there is a network issue
– Sometimes we need to check if there is some redirection going on while loading, this comes when the server is not properly configured
– Few times we have seen clients using very old java like, JRE 1.4.2 had a bug as it did not cache class queries properly. Latest JRE is always good.

If anything mentioned above not available, will cause a delay
The better way of finding an issue like above is to enable verbose logging like setting -Djavaplugin.trace=true -Djavaplugin.logging=true and below debugs in server side : Debug Mode Autovue

1. Make sure the client has both of the following parameters set in their JRE runtime parameters through Java Control Panel

-Djavaplugin.trace=true -Djavaplugin.logging=true

Note: Use it exactly as listed above, with a space in between

2. Before testing the issue again, make sure they close their browser windows (so that the JRE can shutdown & restart), and clear all .trace and .log files from their folder C:\Documents and Settings\<USERNAME>\Application Data\Sun\Java\Deployment\log.

3. Make sure all browser cache is cleared before testing. CCleaner tool is good for cleaning the cache.

4. Once you’ve re-run the test case, you should find 2 new files in the folder C:\Documents and Settings\<USERNAME>\Application Data\Sun\Java\Deployment\log
pluginxxxxxxxxxxxxxxx.trace
pluginxxxxxxxxxxxxxxx.log

4. The .log file contains the timestamps in the following format (in the <millis> tag):

<record>
<date>2012-03-14T14:22:20</date>
<millis>1219322140130</millis>
<sequence>21</sequence>
<logger>sun.plugin</logger>
<level>FINE</level>
<class>com.sun.deploy.util.LoggerTraceListener</class>
<method>print</method>
<thread>10</thread>
<message>network: Connecting http://malicong.locals.nert.net/jVue/jvue.jar with proxy=DIRECT
</message>
</record>

5. You can then analyze the timestamps to have a clear picture of any performance bottlenecks recorded on the client side.

So if you follow above steps it will be very easy to narrow down the issue and fix it. If that also does not work then you might need to raise a SR.

In case of any ©Copyright or missing credits issue please check CopyRights page for faster resolutions.