With the delayed start-up of the webapps default boots now in 30secs for me. First hit on the admin console takes 30secs (!) to get to the logging page.

After logging, it takes another 10 secs to get to the resources screen.

Did a quick round of profiling. Now that the admin-console deployment is lazy and separate from the server bootup, it was easier to find out what's taking time. For first access (*not* the login), turns out, the WARAnnotationDeployer spends almost 41 % percent of the time processing the war - mainly in getClasses() which starts looking for classes in the war file for annotation scanning. The admin-console.war/WEB-INF/lib has jar totaling to10 MB in size. I remember, there was discussion to add metadata-complete, to the web.xml of this war. I don't see it in the web.xml. Also, adding that hadn't shown any performance improvements. Looking at the WarAnnotationMetaDataDeployer.deploy(...), or other methods in there, i don't see any check for metadata-complete.

On Thu, Feb 11, 2010 at 3:54 PM, Jaikiran Pai <jpai(a)redhat.com&gt; wrote: > Did a quick round of profiling. Now that the admin-console deployment is > lazy and separate from the server bootup, it was easier to find out > what's taking time. > > For first access (*not* the login), turns out, the WARAnnotationDeployer > spends almost 41 % percent of the time processing the war - mainly in > getClasses() which starts looking for classes in the war file for > annotation scanning. The admin-console.war/WEB-INF/lib has jar totaling > to10 MB in size. I remember, there was discussion to add > metadata-complete, to the web.xml of this war. I don't see it in the > web.xml. Also, adding that hadn't shown any performance improvements. > Looking at the WarAnnotationMetaDataDeployer.deploy(...), or other > methods in there, i don't see any check for metadata-complete. As previously discussed, metadata-complete cannot be used for this usage. Rémy _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Is some kind of blunt filtering mechanism useful? A la what we do with JBossCustomDeployDUFilter and GenScanDeployer beans in metadata-deployer-jboss-beans.xml.

(Unverified assumption: WARAnnotationMetaDataDeployer doesn't need to process admin-console.war)

On 02/11/2010 10:24 AM, Rémy Maucherat wrote: > On Thu, Feb 11, 2010 at 4:46 PM, Brian Stansberry > <brian.stansberry(a)redhat.com&gt; wrote: >> Is some kind of blunt filtering mechanism useful? A la what we do with >> JBossCustomDeployDUFilter and GenScanDeployer beans in >> metadata-deployer-jboss-beans.xml. > I heard there was something, but I don't know it. And it's not > metadata-complete (it will only disable select Servlet 3.0 > annotations). > >> (Unverified assumption: WARAnnotationMetaDataDeployer doesn't need to >> process admin-console.war) > Most likely it does not. > > But it's pretty much pointless, we use a nasty SCI from JSF (which > would also need a flag to avoid scanning the war). > > So I think we might be needing a number of flags added to > jboss-web.xml (disable-annotations - if needed - and > disable-handlestypes), but I'd argue we should target that for M3. M2 > boots pretty fast so we have an improvement already for the most > visible item. > As a quick way to experiment, I changed deploy() for WARAnnotationMetaDataDeployer and ServletContainerInitializerDeployer to add if ("admin-console.war".equals(unit.getSimpleName())) return; That cut the boot time of "default" with on-demand disabled from 38s to 30s. I get 22s with on-demand enabled. I agree that the M2 boot improvement is already enough. Only reason to think about any 1) quick 2) simple 3) safe stuff for M2 is to cut the time it takes to serve the first admin-console request, which for me is a) 12 secs before I get any response at all (i.e. deployment time) b) 5 secs looking at the "Redirecting to..." page until login screen comes up (i.e. mostly ServletContextListener stuff) c) 5 secs to get response after submitting login form (console initially processes managed objects) a) is the worst part since there's no feedback. Still, I'm quite OK with leaving this alone. TBH the only 1) quick 2) simple 3) safe stuff for M2" is the hack above, which is pretty lame.

As discussed here: * http://community.jboss.org/message/525544#525544 we're about to switch entire MC trunk (all sub-projects) to new VFS3: * http://repository.jboss.com/maven2/org/jboss/jboss-vfs/3.0.0.CR1/ OK, the important info is that any changes made to MC (sub)projects (that depend on VFS) *should* be done till *Tue 16th February 6pm CET*. After that John takes over and changes the MC sub-projects trunk(s) with the branches that depend on VFS3 which he was blue-collar keeping up to date. Thanks John! Mostly the issue here is if there is any ongoing work on CL and Deployers? (Adrian, Thomas, ... ?) List of all depending VFS projects * http://community.jboss.org/wiki/VFS3MigrationStatus

> Will everything be set to begin the VFS3 integration in MC at 6PM CET? Since no-one complained about it, I would expect we're ready. > The order of integration is listed at http://community.jboss.org/wiki/VFS3MigrationStatus. > > Should we plan to get through the bulk of the projects right away, or just plan to get through the first couple projects on day one, and see how it goes? I think we should plan to get the trunks back on line as soon as possible. The first 5 should be done in a single shot ("atomic" :-) the rest can be done later (tomorrow, ...) - in group per project. CL * https://jira.jboss.org/jira/browse/JBCL-151 * https://jira.jboss.org/jira/browse/JBCL-152 McAnn * just create new 1.0.0.Alpha2 --> needs to be generalized anyway Deployers: * https://jira.jboss.org/jira/browse/JBDEPLOY-238 * https://jira.jboss.org/jira/browse/JBDEPLOY-239 * https://jira.jboss.org/jira/browse/JBDEPLOY-240 > Let me know when we are ready to go. We're ready. ;-) > > I will send updates with the progress and keep the above document up to date with the status. OK.

Let me know if you have any questions or issues with the integration.

Yeah. This is a problem with on the Mac with VFS3. I am putting in the fix and writing a test case to cover it. We will need another VFS release to get this in. John On Feb 17, 2010, at 6:58 AM, Ales Justin wrote: >> Let me know if you have any questions or issues with the integration. > > OK, managed to play around a bit. > > Stumbled upon this code: > * http://anonsvn.jboss.org/repos/jbossas/projects/vfs/trunk/src/main/java/o... > > Which was root of failures on Mac: > * https://jira.jboss.org/jira/browse/JBCOMMON-106 > > I'll check if this might be causing some issues again with VFS3. > -- John Bailey JBoss by Red Hat --

A big chunk of this time is the copy overhead since this war is huge. Another chunk is seam + vfs scanning overhead, which is also compounded by the war being large. And then we have RHQ& EMBJOPR initialization time. So this definitely needs major changes. I would love a tiny lightweight console just using servlets, even if it wasn't pretty :)

David M. Lloyd wrote: > On 02/11/2010 01:38 PM, Jason T. Greene wrote: >> A big chunk of this time is the copy overhead since this war is huge. >> Another chunk is seam + vfs scanning overhead, which is also compounded >> by the war being large. And then we have RHQ& EMBJOPR initialization >> time. So this definitely needs major changes. I would love a tiny >> lightweight console just using servlets, even if it wasn't pretty :) > You mean like jmx-console? :-) Yes, except that our management interfaces are now in the Profile Service, not all in JMX, and jmx is TOO dumb.

On Thu, Feb 11, 2010 at 8:38 PM, Jason T. Greene <jason.greene(a)redhat.com&gt; wrote: > A big chunk of this time is the copy overhead since this war is huge. Did you actually put in some measurements ? Because it is highly unlikely unzipping 10MB takes a long time.

Dimitris Andreadis wrote: > With the delayed start-up of the webapps default boots now in 30secs for me. > > First hit on the admin console takes 30secs (!) to get to the logging page. Not surprising actually, because that's what we were seeing (an addition of 25-30 seconds to boot time) when the admin-console was deployed without this lazy loading feature. > After logging, it takes another 10 secs to get to the resources screen. Yeah, this has always been the case. Don't know if it took this long earlier, but in AS 5.1.0, i used to see the login take around 5 seconds on my system. I think, the admin-console needs to be tuned after a round of profiling. I think there was a EMBJOPR JIRA for this.