Just because there has been some confusion, I'll outline the problem and the solution.
Problem: We have a page that could output 6000+ rows in a datatable, and it was taking up to 20 minutes to load. Obviously this is a performance issue. The page is nested inside 3 Tiles, and each Tile addes a little bit of html/javascript/JSF code. My first check was just to put view the Tile on its own. I wrapped it in <f:view> and <h:form> tags, and it came up quickly. My second exploration was to check that we were quickly generating the HTML code. Naturally, generating 6000 rows of a dataTable took a little bit of time (2.5 seconds), but the whole JSF lifecycle completed in under 4 seconds, so JSF/Tiles code generation wasn't the problem. The led to the hypothesis that the problem had to do either with the generated code (obviously), or with how we were flushing the code to the client. I thought maybe that IE would keep trying to recompute the table's layout every time we passed new rows to it, so maybe we were flushing content before all the content had been generated. I explored all of our tiles and they all had flush="false", so that wasn't the case. Next, I wanted to make sure that Tiles itself wasn't the problem, so I stripped all of the code from the layouts that this page used and pasted them in to the page directly. Success! The page took forever to load, so it wasn't Tiles, it had to be something inside one of the layouts. The culprit turned out to be a javascript function that scans the whole DOM and acts on elements that have their onclick attribute set. Obviously, scanning a DOM that includes a datatable with 6000+ rows takes a little bit of time (I wouldn't have thought 20 minutes, but that looks like the problem). We're changing it so that the individual elements that need processing have to be declared be the developer rather than being searched for by the framework. Thanks for all your helpful responses! On Tue, 11 Jan 2005 09:51:15 -0700, BaTien Duong <[EMAIL PROTECTED]> wrote: > Heath Borders wrote: > > >For some reason, our pages that use Tiles don't perform anywhere near > >as well as those that don't use tiles. > > > >I've been trying to figure out the performance issues, but I'm stuck. > > > >I've basically taken all of the code out of our layouts, so that all > >of the same layouts are getting called, but there is no code in them > >but the includes I need. > > > >The performance problem is really only an issue when we need to render > >large (500+ rows) tables on a particular page. It takes the page up > >to a minute to load in IE 6 using tiles, but the load is almost > >instantaneous without tiles. > > > >Obviously, for developer productivity and maintainability, we really > >love Tiles and want to continue using it, but we can't ignore these > >performance issues. > > > >Does anyone have any ideas? > > > > > > > Due to the creation of Jsp fragments in a page, the first time is slow. > But after that, it is very decent due to cache. We found it is much > better than many other portal page assembling engines (either > proprietary or open sources). Another thing needs to consider for > performance is tried to avoid deep nested tiles. We try to achive 1 tile > level of insertion and attribute processing. This means a large > definition for the base template and all fragments are done with Jsf. > Within each fragment, we try to be simple and do not have too many > layers of tables and tags. This means some work may be required to strip > unneccessagy layer of off-the-shelf UI components. You have to do it > anyway for any serious work. Off-the-shelf components are only used to > demonstrate the technology. > > Hope these tips may help. > > BaTien > DBGROUPS > > -- -Heath Borders-Wing [EMAIL PROTECTED]
