WebSphere 9 启动时间过长答案

【问题标题】：WebSphere 9 excessive startup timeWebSphere 9 启动时间过长
【发布时间】：2017-10-09 06:34:52
【问题描述】：

我正在测试驱动 WebSphere Application Server 9，完整配置文件，我对启动配置文件所需的时间很感兴趣。我已经安装了一个应用程序，理论上，这可能是罪魁祸首，但日志没有显示任何证据。日志文件的相关部分：

[14-07-2016 9:15:06:955 BST] 0000005b ApplicationMg A   WSVR0221I: Application started: isclite
[14-07-2016 9:15:06:956 BST] 0000005b CompositionUn A   WSVR0191I: Composition unit WebSphere:cuname=isclite in BLA WebSphere:blaname=isclite started.
[14-07-2016 9:16:14:410 BST] 0000005a InternalGener I   DSRA8225I: DataSource JNDI name : jdbc/DefaultEJBTimerDataSource
[14-07-2016 9:16:14:413 BST] 0000005a InternalGener I   DSRA8203I: Database product name : Apache Derby
[14-07-2016 9:16:14:413 BST] 0000005a InternalGener I   DSRA8204I: Database product version : 10.11.1.1 - (1616546)
[14-07-2016 9:16:14:413 BST] 0000005a InternalGener I   DSRA8205I: JDBC driver name  : Apache Derby Embedded JDBC Driver
[14-07-2016 9:16:14:414 BST] 0000005a InternalGener I   DSRA8206I: JDBC driver version  : 10.11.1.1 - (1616546)
[14-07-2016 9:16:14:414 BST] 0000005a InternalGener I   DSRA8218I: JDBC driver specification level  : 4.2
[14-07-2016 9:16:14:773 BST] 0000005a WASSchedulerC I   SCHD0100I: Scheduler tables verified successfully.

正如您在第 2 行和第 3 行看到的，服务器等待了超过一分钟。没有异常或任何其他可能表明存在问题的信息被记录。

有谁知道可能是什么问题？

编辑#1：

按照 XSurgent 的建议，我已禁用应用程序的自动启动并重新启动服务器。启动时间正常，但指示 Apache Derby 正在启动的行不再可见，这似乎表明 Derby 启动一直在消耗这些时间。我的推理有意义吗？

编辑 #2：

我已更改 EJB 计时器以使用不同的数据库（Oracle 而不是嵌入式 Derby），但 1 分钟的延迟仍在发生。

【问题讨论】：

一些事情：1) 'isclite' 是与 WAS 捆绑在一起的管理控制台应用程序。 2）您可以禁用您的应用程序在服务器启动时启动，看看它是否有所作为。 3) 性能很大程度上取决于您的系统，因此请确保您满足并超过 WAS 9 的系统要求以获得良好的性能。
您可以尝试对管理控制台进行跟踪。按照this technote中的说明进行操作
既然延迟已缩小到应用程序，请考虑使用跟踪来分析启动。延迟可能与 Derby 启动无关。上面显示的日志是在数据源访问数据库时打印的。因此，Derby DB 应该在日志中的这一点之前启动并运行。
不应为任何系统应用程序运行 CDI 处理步骤。 CDI 处理被编码为跳过/忽略系统应用程序。

标签： websphere

【解决方案1】：

对于包含大型 Web 模块的应用程序，应用程序启动时间可能会增加。（“大”的意思是有很多类，通常是因为许多 JAR 文件被打包在 web 模块中。）增加的一个原因是对类信息的新扫描以检测 CDI 内容。例如，检测@Inject 注解。

扫描是必需的——即使是不包含 CDI 内容的模块——以符合新的 CDI 1.2 功能的规范。扫描的成本与被扫描的模块中的类数量成正比。

为了提高启动性能，引入了两个属性来禁用不包含 CDI 内容的应用程序的 CDI 处理。有关属性和使用说明的说明，请参阅此技术说明：

http://www-01.ibm.com/support/docview.wss?uid=swg21983564

这两个属性是：

As a java custom property: "com.ibm.ws.cdi.enableImplicitBeanArchives"
As a filter property: "Enable-Implicit-Bean-Archive"  

As a java custom property: "com.ibm.ws.cdi.enableCDI"
As a filter property: "Enable-CDI"

这里的“java自定义属性”是指在服务器进程中设置的属性。请注意，这必须在服务器配置中完成：在启动脚本中设置属性只会影响启动进程，而不是服务器进程。

“过滤器属性”是指可以在文件“amm.filter.properties”中设置的属性或可以在 Java EE 存档（EAR/WAR/RAR/JAR 文件）中设置的清单主属性。（技术说明中提供了有关设置过滤器属性的更详细说明。）

以下是属性及其含义的摘要：

Name: com.ibm.ws.cdi.enableImplicitBeanArchives, Enable-Implicit-Bean-Archive
Allowed Values: true, false
Default Value: true
Description: By setting the property to false, CDI-related annotation scanning steps are disabled for archives that do not contain a bean descriptor (beans.xml).

Name: com.ibm.ws.cdi.enableCDI, Enable-CDI
Allowed Values: true, false
Default Value: true
Description: By setting the property to false, all CDI steps are disabled for the archive.

使用哪个属性取决于具体要求：如果要为服务器进程禁用所有 CDI 功能，请设置 java 自定义属性。设置清单主要属性以禁用特定应用程序或模块的 CDI 功能。

判断 CDI 是否导致启动时间增加的一种方法是收集线程转储并查找类似于以下内容的调用堆栈：

4XESTACKTRACE                at com/ibm/ws/jsf/ext/JSFInjectionClassListCollaborator.getInjectionClasses(JSFInjectionClassListCollaborator.java:105)
4XESTACKTRACE                at com/ibm/ws/cdi/classic/CDIArchiveImpl.getInjectionClassList(CDIArchiveImpl.java:77)
4XESTACKTRACE                at com/ibm/ws/cdi/impl/weld/BeanDeploymentArchiveImpl.initializeJEEComponentClasses(BeanDeploymentArchiveImpl.java:349)
4XESTACKTRACE                at com/ibm/ws/cdi/impl/weld/BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:281)
4XESTACKTRACE                at com/ibm/ws/cdi/impl/weld/BeanDeploymentArchiveImpl.scan(BeanDeploymentArchiveImpl.java:255)
4XESTACKTRACE                at com/ibm/ws/cdi/impl/weld/WebSphereCDIDeploymentImpl.scan(WebSphereCDIDeploymentImpl.java:530)
4XESTACKTRACE                at com/ibm/ws/cdi/impl/CDIContainerImpl.applicationStarting(CDIContainerImpl.java:117)
4XESTACKTRACE                at com/ibm/ws/cdi/classic/CDIRuntimeImpl.applicationStarting(CDIRuntimeImpl.java:323)

Thomas Bitonti，IBM 公司，IBM WebSphere Application Server 开发人员

【讨论】：

@tbitoni，如果扫描导致延迟并且我的应用程序有 CDI 内容，是否意味着没有其他方法可以减少延迟？
设置属性 com.ibm.ws.cdi.enableImplicitBeanArchives=false 足以解决问题，感谢您的帮助。
两种选择是为没有 CDI 内容的模块设置属性。但是，这对于具有 CDI 内容的大型 Web 模块没有帮助。在这种情况下，替代方法是使用注释过滤器选项从扫描中删除选定的类和档案。见：ibm.com/support/knowledgecenter/SSEQTP_9.0.0/…
技术说明语言令人困惑。你能举一个WAR文件修改的例子吗？
设置属性 com.ibm.ws.cdi.enableImplicitBeanArchives=false 对我没有影响。在此处查看详细信息：stackoverflow.com/questions/41750154/…

【解决方案2】：

为了更简单：如果您不使用 JEE 注释（例如，您的服务基于 JAX-RS 或 Spring），您可以关闭 CDI 扫描：如果您部署了 WAR 文件，请在 WAR#/META-INF/MANIFEST-MF 中注入这一行： Ignore-Scanning-Packages: org, net, com ,javax 当然，由您决定从 CDI 扫描中排除哪些 Java 包。

我的例子：

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: ti
Build-Jdk: 1.7.0_45
Ignore-Scanning-Packages: org, net, com ,javax

如果您部署了 EAR 文件：在其清单中注入不同的行：Enable-CDI: false

如果您想在不更改 WAR 文件的情况下在服务器上进行全局更改，请编辑（如果缺少则创建）：/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/properties/amm.filter.properties 并添加该行： com.ibm.ws.amm.scan.context.filter.packages=com,org,net,javax

【讨论】：