Glassfish/Payara:为什么将大型Web应用程序部署到Glassfish-4.1.1(或Payara Server 4.1.1.163)所花费的时间比Glassfish-4.1长5倍? [英] Glassfish/Payara: why might deployment of a large web app to Glassfish-4.1.1 (or Payara Server 4.1.1.163) take 5 times longer than to Glassfish-4.1
问题描述
Mac OS X: Yosemite 10.10.5
直到最近我一直在使用:
Until recently I have been using:
NetBeans8.1beta
Glassfish4.1
Mojarra 2.2.7
我最近使用以下方法进行了调查:
I have recently investigated using:
NetBeans8.1
Glassfish4.1.1
Mojarra 2.2.12.
使用一个非常大的JSF Web应用程序(使用ObjectDB作为JPA持久性提供程序)，与Glassfish4.1(大约2分钟)相比，我对Glassfish4.1.1(超过10分钟)的部署时间要长得多.慢了大约5倍.
With a very large JSF web app (with ObjectDB as JPA persistence provider) I am experiencing massively longer deployment times to Glassfish4.1.1 (over 10 minutes) than to Glassfish4.1 (around 2 minutes). That's about 5 times slower.
我无法在此处复制或提供大型Web应用程序的示例.
问题1:有人在Glassfish-4.1和Glassfish-4.1.1之间遇到过类似的区别吗?差异点?
(我已经在尝试使用NetBeans Profiler进行调查，但事实证明，找到问题的原因还不那么容易.)
(I am already trying to investigate it by using the NetBeans Profiler, but it is not turning out to be so easy yet to find the cause.)
我已经使用截屏录制进行了仔细的并排比较，并与日志中的计时进行了比较.
I have performed careful side-by-side comparison using screencast recording and comparing with timings in the log.
在Payara41(4.1.1.163)和Glassfish4.1.1中，它被卡住"，如下所示，持续了大约10分钟，并且我没有发现任何日志设置可以在此处出现问题并在运行时提供单行输出处于调试模式的服务器似乎也没有提供任何其他信息.
In Payara41 (4.1.1.163) and Glassfish4.1.1 it gets "stuck" as shown below for about 10 minutes, and I have not found any log setting that gives a single line of output here where the problem occurs, and running the server in DEBUG mode also does not seem to give any additional information.
[2016-09-14T23:02:53.450+1000] [Payara 4.1] [INFO] [NCLS-LOGGING-00009] [javax.enterprise.logging] [tid: _ThreadID=19 _ThreadName=RunLevelControllerThread-1473858173343] [timeMillis: 1473858173450] [levelValue: 800] [[
Running Payara Version: Payara Server 4.1.1.163 #badassfish (build 215)]]
...在所有步骤中都可以正常运行，然后通过许多这些EJB JNDI名称声明运行:
... runs ok through all steps and then through dozens of these EJB JNDI name declarations:
[2016-09-14T23:03:48.823+1000] [Payara 4.1] [INFO] [AS-EJB-00054] [javax.enterprise.ejb.container] [tid: _ThreadID=74 _ThreadName=admin-thread-pool(2)] [timeMillis: 1473858228823] [levelValue: 800] [[
Portable JNDI names for EJB BeanName: [java:global/app-name/BeanName!com.example.BeanName, java:global/app-name/BeanName]]]
给出以下WELD版本消息:
Gives this WELD version message:
[2016-09-14T23:03:48.875+1000] [Payara 4.1] [INFO] [] [org.jboss.weld.Version] [tid: _ThreadID=74 _ThreadName=admin-thread-pool(2)] [timeMillis: 1473858228875] [levelValue: 800] [[
WELD-000900: 2.3.5 (Final)]]
...然后大约需要8秒钟，然后才会显示此消息..
... then takes about 8 seconds before this message ..
[2016-09-14T23:03:56.666+1000] [Payara 4.1] [INFO] [] [org.jboss.weld.Event] [tid: _ThreadID=74 _ThreadName=admin-thread-pool(2)] [timeMillis: 1473858236666] [levelValue: 800] [[
WELD-000411: Observer method [BackedAnnotatedMethod] private org.glassfish.jersey.ext.cdi1x.internal.CdiComponentProvider.processAnnotatedType(@Observes ProcessAnnotatedType) receives events for all annotated types. Consider restricting events using @WithAnnotations or a generic type with bounds.]]
...然后花费很多分钟(通常约10分钟)，然后恢复这些原本无害的警告..
... Then take many minutes (typically about 10 minutes) before resuming these otherwise harmless warnings ..
[2016-09-14T23:11:33.387+1000] [Payara 4.1] [INFO] [] [org.jboss.weld.Bootstrap] [tid: _ThreadID=74 _ThreadName=admin-thread-pool(2)] [timeMillis: 1473858693387] [levelValue: 800] [[
WELD-001125: Illegal bean type java.util.Comparator<javax.persistence.metamodel.EntityType<?>> ignored on [EnhancedAnnotatedTypeImpl] public static class com.example.ElementManager$EntityTypeSorter]]
[2016-09-14T23:11:59.736+1000] [Payara 4.1] [WARNING] [] [org.glassfish.jersey.internal.Errors] [tid: _ThreadID=74 _ThreadName=admin-thread-pool(2)] [timeMillis: 1473858719736] [levelValue: 900] [[
The following warnings have been detected: WARNING: Parameter 1 of type T from public void com.example.NumberProperty.setDefaultValue(T) is not resolvable to a concrete type.
]]
Glassfish4.1日志中会出现类似的警告消息，但是没有长时间的暂停/保持.
Similar warning messages happen in the Glassfish4.1 log, but there is no long pause/holdup.
第二季度:我还能做些什么来弄清楚为什么它在那里暂停/停留了很久?
推荐答案
Thanks to detailed help from the Payara team I have an answer.
在我的旧Glassfish4.1安装(-Xmx2048m)与新的Glassfish4.1.1和Payara41安装(-Xmx512m)之间，最大堆设置有所不同.在启动时构建我的Web应用程序项目的数据库模型时，它已达到512m的堆限制并导致过多的垃圾收集(如JVisualVM所示)，这极大地降低了部署速度.
The max heap settings were different between my old Glassfish4.1 install (-Xmx2048m) and the new Glassfish4.1.1 and Payara41 install (-Xmx512m). On building my web app project's database model on startup, it was hitting the 512m heap limit and causing excessive garbage collection (as revealed by JVisualVM), which massively slowed the deployment.
我已经将它们作为NetBeans Web应用程序项目的运行时VMargs:
I already had these as run-time VMargs for the NetBeans web app project:
-Xms2048m -Xmx2048m
但是在安装NetBeans8.1(带有Glassfish4.1.1)和Payara41时，我忽略了在新服务器上也匹配它以为其腾出空间.随着最大堆的增加和固定最小值的增加，Glassfish4.1.1和Payara41的部署时间现在约为2分钟.
But on installing NetBeans8.1 (with Glassfish4.1.1), and then Payara41, I had neglected to also match this on the new servers to make room for it. With the increased max heap and fixed minimum the deployment time is now about 2 mins on both Glassfish4.1.1 and Payara41.
这篇关于Glassfish/Payara:为什么将大型Web应用程序部署到Glassfish-4.1.1(或Payara Server 4.1.1.163)所花费的时间比Glassfish-4.1长5倍?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
