每次Java更新时，web启动jar验证都会变慢 [英] web start jar validation getting slower with each Java update

问题描述

我们有一个90MB的（Eclipse RCP）应用程序，带有139个自签名jar，在没有Web Start的情况下从8s开始，在Java7的旧版本中以10s开始。我们将Java配置为不使用浏览器代理，即 deployment.proxy.type = 0 。

We have an (Eclipse RCP) application of 90MB with 139 self-signed jars which starts in 8s without Web Start and in 10s in an older version of Java 7. We configured Java to not use the browser proxy, i.e. deployment.proxy.type=0.

每次更新Oracle的Java启动性能都会下降。完全启动需要花费越来越多的时间：

With each update of Oracle's Java startup performance drops. It takes more and more time to fully start up:

• 7u60 / 7u65 / 8u25：13s（在网络启动处理5s后开始）


• 7u75：23s


• 8u31：20s


• 8u40：29s


• 8u51 / 8u60ea：32s

• 7u60/7u65/8u25: 13s (starts after 5s of web start processing)
• 7u75: 23s
• 8u31: 20s
• 8u40: 29s
• 8u51/8u60ea: 32s

我该怎么办才能解决这个问题？

What can I do to solve this issue?

从trace / logs中我可以看到，这种减速很可能完全是由于验证缓存的jar需要花费更多时间。请注意，这个问题类似但不是不提供以下详细信息：

From the trace/logs I can see that it is very probable that this slowdown is completely due to validating the cached jars taking much more time. Note that this question is similar but doesn't provide the following details:

诊断：

• 缓存时，更新检查仅运行0.5秒（服务器返回304 Not
  Modified），但即使完全下载，千兆网络也只需几秒钟。


• 更新检查后，每个jar XXX都有一个日志条目：

验证缓存的jar XXX.jar

validating cached jar XXX.jar

完成后，com.sun.javaws.Main在启动之后启动相同的验证似乎再次发生并花费大约相同的时间，然后应用程序启动。

When this is done, com.sun.javaws.Main is started after which the same validation seems to happen again and takes about the same amount of time, then the application starts.

• 验证时间所花费的时间缓存的jar似乎对应于
  应用程序启动前所需的额外时间。


• Web启动启动画面总是显示对应于更新检查的约2秒，然后隐藏。几乎20秒后，Java控制台终于出现，我的应用程序实际启动了。


• 在延迟期间，jp2launcher.exe在具有超线程的四核上使用大约16％的处理器时间（8个逻辑核心） ）。所以看起来它完全使用了一个逻辑处理器。

我已经尝试但没有做任何事情差异：

• 清除网络启动缓存（无数次）


• 配置部署。使用版本下载禁用证书吊销检查的属性（以及blacklist.check和validation.ocsp，validation.crl）


• 离线运行


• 协议


• 添加到站点例外列表


• 检查Web服务器日志中的问题。没有找到，所有138个罐子的更新检查大约500毫秒。


• 使用其他网络服务器


• 检查证书到期日期2016年2月17日


• 使用JaNela验证了我的jnlp并发现没有严重问题


• 创建一个部署规则集，允许应用程序运行unsigned以加快验证速度。这应该是可能的，看起来像是一种很有前途的方法来解决这个问题，但我无法让它发挥作用。另见我的回答在这篇文章中。


• 将Java配置为不启动控制台

• clearing web start cache (countless times)
• configure deployment.properties to disable certificate revocation check (as well as blacklist.check and validation.ocsp, validation.crl)
• running offline
• using the version download protocol
• add to site exceptions list
• check web server logs for problems. None found, update check runs in about 500ms for all 138 jars.
• use another web server
• checked certificate expiration date 17 feb 2016
• validated my jnlp with JaNela and found no serious issues
• create a deployment rule set to allow the application to run unsigned in order to speed up validation. This should be possible and looks like a promising way to solve this, but I could not get it working. See also my answer on this post.
• configured Java to "do not start the console"

详细信息：7u60上的一些奇怪的行为
在7u60中，应用程序在大约5秒后启动，之后Java控制台将在应用程序启动时在后台执行jar验证。但是.log文件报告在完成所有验证后应用程序启动。它将此报告为25秒，然后显示我的应用程序的第一个System.out，它实际上仅在5秒钟后发生。它还显示服务器的jar更新检查时间是服务器报告的10倍。所以我想这是日志框架滞后的问题！还没有在8u51上看过这个。

Detail: some weird behavior on 7u60 In 7u60 the application is started after about 5 seconds, after which the Java console APPEARS to be doing the jar validation in the background while the application is already started. HOWEVER the .log file reports that the application gets started AFTER all the validations are done. It reports this as 25 seconds and then shows the first System.out of my application which actually happened after only 5 seconds or so. It also shows the jar update check with the server taking 10 times as long as reported by the server. So I guess this is an issue with the logging framework lagging behind! Haven't seen this on 8u51.

推荐答案

本身不是答案（但是），但我在追踪时发现了Java 8u25已启用，仅生成单个跟踪文件。 8u51生成两个文件，一个来自用于更新应用程序的JVM，另一个用于运行它。这是新的（两个JVM初创公司），我认为这与使用本机Windows沙箱功能的新设置有关。问题是它不应该在第二个JVM上再次验证签名。无论是否禁用使用本机沙箱的设置（默认设置），都会发生两个JVM实例的分离。

Not an answer per se (yet), but I found that Java 8u25 when tracing is enabled, only generate a single trace file. 8u51 generates two files, one from the JVM used to update the application and other to run it. This is new (two JVM startups) and I think is related to the new setting for using native Windows sandbox capabilities. The problem is that it shouldn't have to validate the signatures again on the second JVM. The separation on two JVM instances always happen no matter if the setting for using native sandbox is disabled (the default).

我报告了一个回归错误，如果报告回答错误，将编辑答案我从Oracle那里得到了答案。

I reported a regression bug, will edit the answer if I get an answer from Oracle.

注意：Java 8u31仍在一个JVM上运行所有内容，但问题规定的启动时间加倍。

Note: Java 8u31 still runs everything on one JVM but have the same doubled startup time the question stated.

这篇关于每次Java更新时，web启动jar验证都会变慢的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！