Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Message-ID: <4113BB21.4030800@apache.org>
Date: Fri, 06 Aug 2004 19:08:49 +0200
From: Remy Maucherat <remm@apache.org>
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
MIME-Version: 1.0
To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
Subject: Re: StandardClassLoader ?
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> <cf07ev$2fo$1@sea.gmane.org>
In-Reply-To: <cf07ev$2fo$1@sea.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Costin Manolache wrote:

> 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 ??

Try it without ;)

> 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 ?

I know, but it doesn't work right now (it's Struts' fault :( ). If you 
have ideas to make it work, then I'm obviously +1 for removing the 
load-on-startup thing.

> 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.

I don't think we can have that. It doesn't fit the way the other stuff 
works (deployer, mapper).

>
>> 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 ).

Yes, but the first time, it hurts ;)

>
>> 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.

DOM is for server.xml. I don't think we need to save web.xml, right ?

>
>
>>
>>> 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.

Yes, it should be added. This must be why the old StdCL performed worse 
than the UCL.

>
>> 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.

Yes, it should, but I thought maybe we could get a little something here 
(and with all the funky URL stuff the URL CL does).

>
> 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.

I agree. I'm kinda running out of optimization ideas, though (I don't 
know if you profiled the regular request processing lately, but there's 
really nothing left). There doesn't seem to be too much which is doable 
with the startup overall.

R�my


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