tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: svn commit: r1095367 - in /tomcat/trunk: java/org/apache/catalina/startup/ java/org/apache/jasper/compiler/ java/org/apache/tomcat/util/scan/ webapps/docs/
Date Wed, 20 Apr 2011 16:07:37 GMT
On 20/04/2011 17:02, Konstantin Kolinko wrote:
> 2011/4/20 Mark Thomas <>:
>>>> +            // JarURLConnection#getJarFile() creates temporary copies of
the JAR
>>>> +            // if the underlying resource is not a file URL. That can be
slow so
>>> What URLs are there? Why aren't they file ones?
>> Resources obtained via the context are jndi URLs.
> Isn't it possible access the actual files?

If they exist - which they may not.

The new code is better than the old. You are welcome to try and improve
it further although I don't think there is much more scope for
improvement given the performance figures I am seeing.


> AFAIK, even if we run with expandWARs=false the jar files are
> extracted and copied to app's workdir.
>>> A zip file has "central directory" i.e. master index at the end of the
>>> file. IIRC when you are using random-access methods of Zip file, that
>>> index is loaded into memory once.  Scanning the file sequentially does
>>> not use the index and I think it will be slower.
>> Old code:
>> - read entire file (sequentially)
>> - write entire file to temp location
>> - read required data from file
>> New code:
>> - read file sequentially until we find the bit we want.
>> On a reasonably complex app with quite a few JARs the start-up time went
>> from ~30s to ~12s with these changes with most of the 12s now being app
>> init code. Copying the file was killing performance.
> Best regards,
> Konstantin Kolinko
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message