We have a larger number of diverse java based web sites and a standard XP SP3 build for all the user PCs, which number in the thousands. All PCs have the same JRE installation which is controlled and distributed centrally and they all use Internet Explorer 6. We use the JRE security manager and force all applets running outside the java sandbox to have alias, codebase and list of permissions entries in a single policy file.
For a number of years we have successfully used this arrangement using JRE 1.5.0_05. This year we have rolled out JRE 1.6.0_14 as a replacement. However, the startup times of the web apps has increased dramatically. For example, on 1.5 there was a startup time of 1 minute 20 seconds, now on 1.6 we have over 3 minutes 40 seconds.
We have the same single policy file, located on each PC, containing 108 code base entries. The file has 2118 lines of text, but is only 118 kbytes large.
We have found, by experiment, that if we remove all the code base entries, except those for the web app under test, we can cut the startup time down to 30 seconds. Which suggests the file size is the issue, but I just can't believe reading 118kbytes should take so long. The PCs are high spec dual processor with not much going on.
We have made sure that all the applets have been downloaded to the PC before doing the test, so download time is not the issue.
Can anyone suggest anything to help decrease the startup time?
Thanks in advance
Unfortunitly our test and release cycle are long and complex so to upgrade would need some justification. One other aspect we are thinking about is what processing is done to the JAR files cached on the PC. Assuming the JAR files are the latest, so the server would not resend them, what processing does the JRE initially with the cached JAR files, remembering we sign the JAR files and have a policy file.
The other angle is that the anti virus software is causing a massive delay by scanning the JAR files or some other set of files. Has anyone had issues in this area?
Need to make an adjustment to the explanation, as we have some more information. We thought the issue was with the upgrade to 1.6.0_14, however, the upgrade coincided with a 25% increase in web sites using JRE, causing a corresponding increase to the content of the policy file. The increase was caused by the web sites moving from Jinitiator to JRE. So we rebuilt a PC using JRE 1.5.0_05, but with the large policy file we released with 1.6.0_14; we found the problem exists in 1.5.0_05 just as it does in 1.6.0_14.
We tried increasing the memory allocations (-Xss, -Xms, -Xmx & -Xmn) but with no improvements. We have also pretty much knocked on the head any adverse anti-virus scanning.
Any ideas would be appreciated.
Yeah, I already gave it. Try a newer version than release 14 as it is still ancient software you are using which is bound to have many flaws that have been fixed already. If the problem persists, report it (if you can, the bug parade is very unstable at the moment unfortunately).
We have now tried the tests with JRE 1.6.0_29 with no change in performance, the issue is still there.
We now have an Oracle SR open, number 3-4964457421. I'll push out the findings when we have some although any other ideas are welcome.