tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <r...@apache.org>
Subject Re: autostart for /admin - was Re: StandardClassLoader ?
Date Tue, 10 Aug 2004 07:35:13 GMT
Costin Manolache wrote:

> Remy Maucherat wrote:
>
>>>> 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 ;)
>
>
> I tried.
>
>>
>>> 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.
>
>
>
> One simple solution is to add
>
> <% // Force the initialization of "action" servlet
>    RequestDispatcher 
> actionS=getServletContext().getNamedDispatcher("action").include(request,response); 
>
> %>
>
> in login.jsp

This seems good enough already.

>
> A better solution is to add a small filter that will make sure struts 
> is initialized. However that doesn't seem to work with login.jsp - the 
> filter is not called ( I tried explicit match, by name, etc ).

login.jsp is a forward. Did you try mapping the filter on a forward ?

> BTW, does the spec says that the form login page is excluded from 
> filters ??

That's undefined, as it's some kind of internal dispatching of the 
container. It seemed reasonable trying to do it with a RD forward.

> I can check in both the filter and the small hack to login.jsp, it 
> seems to work fine.
>
>>
>>> 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).
>
>
> Well, the mapper is already able to deal with webapps that are 
> removed/added/reloaded.
>
> A "lazy loaded" app is like an app that has a single mapping, /* - 
> mapped to a lazy-load action that will read web.xml and add the other 
> mappings.
>
> I think it's a very reasonable use case - performance is not only 
> about HelloWorld response time, but also about hosting 1000s small ( 
> and infrequently used ) apps. Apache can handle very large numbers of 
> virtual hosts and apps.
>
>>> 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 ?
>
>
> Well, that's a big discussion, let's leave it for another time :-)
>
>
>
>
>>
>> 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.
>
>
> See above. I ran out of ideas for the basic path long ago ( or at 
> least out of interest :-), it is more than enough for most uses.
>
> Optimizations for the other direction - very larger number of 
> apps/vhosts - are more interesting. So is optimizing the uptime - 
> having tomcat never need a restart is sometimes better than slightly 
> better startup time.

I did a lot already for the "10000 webapps" use case, for example 
removing the need for one backgroud thread per webapp in 5.0.x.

I don't really see what it changes for production servers: if something 
as heavy as the admin webapp starts up, it's going to kill the server 
performance. I agree delaying webapp startup would give a better 
impression of performance, but it would be actually bad for a number of 
configurations.

Rémy


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


Mime
View raw message