You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Schulz-Hildebrandt, Ole" <Ol...@ppimedia.de> on 2015/01/20 12:01:59 UTC
performance (classloader?) problems with signed jars in WEB-INF/lib
Hi,
After moving one of our web applications from Tomcat 7 to Tomcat 8 (latest 8.0.17) the time for deploying and initializing the webapp increased by a factor of 30 (6s vs. 180s). Analyzing the problem we found out that it had to do with a signed jar in the WEB-INF/lib of the webapp. It is a 8mb self-signed jar of the jython-library from which some classes are used in the initializing process of our webapp. When using a non-signed version of the jar the time for deploying and initializing is the same in Tomcat 8 as in Tomcat 7. Has anyone experienced similar problems with signed jars in Tomcat 8?
Profiling and debugging the webapp it turned out that loading a class (and its depending classes) from the signed jar took extremely long with Tomcat 8 in comparison to Tomcat 7. Indeed classloading from the signed jar seems to be responsible for most of the additional time for initializing the webapp in Tomcat 8. Because the performance problems do not occur with a non-signed version of the jar this additional time is probably spent in verifying the signatures of the jar. Because there seems to be no way to disable the verification of jars in general in Tomcat I took a look at the sources of the new WebappClassLoader of Tomcat 8.
The following is just a hypothesis of a "Tomcat source newbie": Could it be that (at least some parts of) the verification process for the whole signed jar is done again and again each time a class from a signed jar is loaded? Looking at org.apache.catalina.webresources.JarResource:47 (http://svn.apache.org/repos/asf/tomcat/tc8.0.x/trunk/java/org/apache/catalina/webresources/JarResource.java) a new instance of java.util.jar.JarFile is created each time a single class-file is read from the jar. Thus the following call of jarFile.getInputStream(jarEntry) in JarResource:50 causes a call of JarFile.initializeVerifier() (cf. JarFile:442ff in http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/java/util/jar/JarFile.java). JarFile.initializeVerifier() seems to do some precalculations (hashing?) for all files listed in the manifest of the signed jar (cf. JarFile:365ff). Thus each time a single class is loaded from a signed jar precalculations for all class files in the signed jar seem to be done. Could this be the reason for our performance problems (especially in connection with a 8mb signed jar ;-))?
Best regards
Ole
+++ ?ber 5.000 Ausgaben t?glich +++
Mehr als 100 Medienh?user weltweit produzieren t?glich Zeitungen
und digitale Angebote mit ppi Media L?sungen
+++ Over 5,000 editions daily +++
More than 100 media companies worldwide produce newspapers
and digital products with ppi Media's solutions.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
AW: performance (classloader?) problems with signed jars in
WEB-INF/lib
Posted by "Schulz-Hildebrandt, Ole" <Ol...@ppimedia.de>.
> That sounds possible. (I haven't looked at the code to check the theory
> though.)
>
> Please open a Bugzilla issue for this so it doesn't get lost.
thanks for your reply. I filed a bug for Tomcat 8:
https://issues.apache.org/bugzilla/show_bug.cgi?id=57472
> I assume your web application is loading a lot of classes from that
> signed JAR when it starts?
Yes. We instantiate (use) only two single classes from that signed jar at startup but that causes many depending classes from that signed jar to be loaded.
Best regards,
Ole
+++ ?ber 5.000 Ausgaben t?glich +++
Mehr als 100 Medienh?user weltweit produzieren t?glich Zeitungen
und digitale Angebote mit ppi Media L?sungen
+++ Over 5,000 editions daily +++
More than 100 media companies worldwide produce newspapers
and digital products with ppi Media's solutions.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: performance (classloader?) problems with signed jars in WEB-INF/lib
Posted by Mark Thomas <ma...@apache.org>.
On 20/01/2015 11:01, Schulz-Hildebrandt, Ole wrote:
> Hi,
>
> After moving one of our web applications from Tomcat 7 to Tomcat 8
> (latest 8.0.17) the time for deploying and initializing the webapp
> increased by a factor of 30 (6s vs. 180s). Analyzing the problem we
> found out that it had to do with a signed jar in the WEB-INF/lib of
> the webapp. It is a 8mb self-signed jar of the jython-library from
> which some classes are used in the initializing process of our
> webapp. When using a non-signed version of the jar the time for
> deploying and initializing is the same in Tomcat 8 as in Tomcat 7.
> Has anyone experienced similar problems with signed jars in Tomcat
> 8?
>
> Profiling and debugging the webapp it turned out that loading a class
> (and its depending classes) from the signed jar took extremely long
> with Tomcat 8 in comparison to Tomcat 7. Indeed classloading from the
> signed jar seems to be responsible for most of the additional time
> for initializing the webapp in Tomcat 8. Because the performance
> problems do not occur with a non-signed version of the jar this
> additional time is probably spent in verifying the signatures of the
> jar. Because there seems to be no way to disable the verification of
> jars in general in Tomcat I took a look at the sources of the new
> WebappClassLoader of Tomcat 8.
>
> The following is just a hypothesis of a "Tomcat source newbie": Could
> it be that (at least some parts of) the verification process for the
> whole signed jar is done again and again each time a class from a
> signed jar is loaded? Looking at
> org.apache.catalina.webresources.JarResource:47
> (http://svn.apache.org/repos/asf/tomcat/tc8.0.x/trunk/java/org/apache/catalina/webresources/JarResource.java)
> a new instance of java.util.jar.JarFile is created each time a single
> class-file is read from the jar. Thus the following call of
> jarFile.getInputStream(jarEntry) in JarResource:50 causes a call of
> JarFile.initializeVerifier() (cf. JarFile:442ff in
> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/java/util/jar/JarFile.java).
> JarFile.initializeVerifier() seems to do some precalculations
> (hashing?) for all files listed in the manifest of the signed jar
> (cf. JarFile:365ff). Thus each time a single class is loaded from a
> signed jar precalculations for all class files in the signed jar seem
> to be done. Could this be the reason for our performance problems
> (especially in connection with a 8mb signed jar ;-))?
That sounds possible. (I haven't looked at the code to check the theory
though.)
Please open a Bugzilla issue for this so it doesn't get lost.
I assume your web application is loading a lot of classes from that
signed JAR when it starts?
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org