tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Hokin <...@ims.net>
Subject Re: very slow class loading on initial JSP/servlet request after restart
Date Wed, 25 Feb 2009 23:14:24 GMT
Caldarale, Charles R wrote:
> 
> The key lines have a 3+ second response time:
> 
> 2498  15:24:35 stat64("/net/ims/jcms/Object.class", 0x7b6b9c20) = -1 ENOENT (No such
file or directory) <3.020996>
> 
> Most of the calls return in much less than a millisecond, but there are a few ENOENT
(not all) responses that hit this 3-second delay.  All of the slow ones are looking at the
/net/ims/jcms directory; what is that?  Why is it in this webapp's classpath?  (It might be
in the jar's META-INF entries.)

Wow, good eye, Chuck, and those add up to at least 35 seconds of the delay - the bulk of it.
 I have absolutely no idea
why it's looking there.  I certainly didn't put /net/ims/jcms in the classpath, and the jar
file that contains
net.ims.jcms just has a stub MANIFEST.MF entry, nothing else, in META-INF.  I don't have a
META-INF directory under the
web app ROOT.  The only place classes are stored under /net/ims/jcms is within WEB-INF/lib/jcms.jar.
 But this is
clearly where the bulk of the time is spent, and one can see how this could scale up really
poorly, since Tomcat is
looking for random core classes like Object.class and Throwable.class under /net/ims/jcms.

For comparison, here is the strace output from a test JSP that imports all of the net.ims.jcms
classes explicitly (no
wildcird import), and responds in three seconds:

http://ims.net/media/strace-test-explicit.txt

You can see the read/GET near the top and the write HTTP 200 response near the bottom.  There
is only ONE attempt to
find a file under /net/ims/jcms, and that only takes .025 sec.

It looks like we've boiled the problem, at least in this test JSP case, down to the classloader
wasting 3 seconds per
try on stat-ing core Java classes in an imaginary location, /net/ims/jcms, on the server's
filesystem, which actually
corresponds to a path WITHIN a jar file that I wrote, and which doesn't contain any core Java
classes.  This sure seems
like a bug to me, but why it is manifested only on this one server, and primarily when I use
a <%@ page
import="net.ims.jcms.*" %> call, remains a mystery.  I can see how these 3-second errant
lookups can really bog down the
server when it starts up, though, when a ton of classes are being loaded for page requests
on several virtual hosts.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message