Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
To: tomcat-dev@jakarta.apache.org
From: Costin Manolache <cmanolache@yahoo.com>
Subject: Re: StandardClassLoader ?
Date: Fri, 06 Aug 2004 08:17:47 -0700
Lines: 90
Message-ID: <cf07ev$2fo$1@sea.gmane.org>
References: <cesj45$8rm$1@sea.gmane.org> <4111F1C1.7060508@apache.org>
 <cethn8$i5v$1@sea.gmane.org>
 <006401c47b00$e78b50a0$dd01dc0a@Corp.LaQuinta.com>
 <411259F7.7050402@apache.org> <cf059g$s78$1@sea.gmane.org>
 <41139BB5.7080104@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
In-Reply-To: <41139BB5.7080104@apache.org>
Sender: news <news@sea.gmane.org>

Remy Maucherat wrote:

> Costin Manolache wrote:
> 
>> Remy Maucherat wrote:
>>
>>>  From my profile, the bottleneck for the startup time is XML parsing 
>>> and accessing entries in JARs (we can't do anything about that), with a 
>>
>>
>>
>> Did you try a pull parser ? kxml2 is really fast and only 42K :-)
>>
>> The other approach - which I think may have a lot of benefits - is to 
>> use some caches. For XML - you would need to make few of the classes 
>> serializable, or create few wrappers that are serializable.  And 
>> whenver a change is detected - reparse. Not trivial code, but you can 
>> get a lot
>> in cutting server.xml and web.xml parsing.
> 
> 
> The time is mostly parsing web.xml. However, it's nothing when compared 
> to starting certain webapps (such as the admin webapp), where *one* 
> webapp takes more time than starting up the rest of Tomcat (including 
> all the simple webapps, JMX and the modeler descriptors, etc).

Does it really need "load-on-startup" for its ApplicationServlet ??
Do we really need to load /admin on startup ? Most people never use it,
or use it only ocasionally. How many times do you configure the server ?

Having "lazy loaded" webapps as a generic solution will help both admin/ 
but also other infrequently used webapps. BTW - load-on-startup doesn't 
necesarily mean "server startup" ( at least that's my understanding ), 
it means when the webapp is started.


> The other big problem is the (needed) JAR parsing for TLDs during the 
> deployment of a webapp.

I tought we already have some code to cache the tlds and avoid 
reparsing. This could be extended to the entire web.xml, and if we do 
this - probably validation can be on ( since it'll happen only first 
time and on web.xml change ).


> Classloding and XML parsing are negligible when compared to these two 
> things. So why bother ?

You're right.


> If I do the server.xml persistence that I envision, I'm using DOM for 
> everything anyway.

Well, you can use DOM for web.xml - but you need DOM only when changing 
settings, so you can also create the dom lazy, and use the .ser form
on regular startup.


> 
>> The jar index is also quite usefull IMO (  is it implemented in
>> WebappClassLoader ? I can't find any code ).
> 
> 
> No, there's no index. I think it could be useful (mark that some 
> packages are available in some JARs).

I was talking about the JDK1.4 index ( we already have <jar 
index=true...> ). URLClassLoader has this, but not our findResourceInternal.

But as you said - it's not a big priority.


> The thing I was planning to try just in case for StdCL was to load 
> everything on creation of the classloader. Since in the end most classes 
> will be loaded on startup, it would remove the need for syncing.

Do you think syncing is a big problem ? Most of the time it should be a 
free lock, and that is supposed to be reasonably fast.

I'm curious how JDK1.5 support for multiple processes works and if we 
could get some classes shared / cached.

In any case - unless loading classes on startup without sync has a big
perf. improvement, I think it may be better to do the other 
optimizations first.

Costin


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