tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jilles van Gurp <>
Subject tld processing performance at startup
Date Fri, 23 Sep 2005 14:46:30 GMT

I have a large site running on tomcat with some tag libs. Restarting 
tomcat can take up to 30-40 seconds which is not that bad except that 
we'd prefer to minimize this time because apache can queue a lot of 
incoming requests in this 30 seconds. We need to restart often because 
we are still tinkering with the site even though it already went live. 
In general, shorter startup times would be really nice anyhow.

Some analysis of what is taking up most of this time has shown that 
tomcat is spending a lot of time (>40-50%) processing all the files in 
the web application looking for tld descriptors. In this particular web 
application there a few thousand small files (e.g. xml descriptors, 
jsps, some static stuff, lots of scripts, etc). Only a small subset is 
jar files (about 20) and only about ten of the files are actually tlds, 
all conveniently located in a subdirectory of WEB-INF. The whole thing 
is deployed as an unzipped directory rather than a war file so we can 
update stuff faster (copy some jar files, stop/start). Auto reload is 
not compatible with our web app so we don't have that enabled.

This web log post: suggests that 
the reason for the poor performance may be a design flaw in the jsp spec 
which makes it necessary to do a lot of work. The ideal way would be for 
the tld descriptors to always be in the META-INF directory. However, the 
spec doesn't require this and tlds may be located anywhere in the 
webapplication. Is this analysis of the problem still correct for tomcat 

On the other hand the web.xml does specify explicitly where the tlds are 
so I don't fully understand the need to look through the whole web 
application directory.

Is there a way to optimize this problem away (even partially) by e.g. 
telling tomcat explicitly what tlds to process?


Jilles van Gurp

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message