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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
