Hey Geoff, Thanks for the time put into your response. I'm glad to hear that my fears on page/component loading are hopefully not necessary. We've been profiling with Mercury which is great. Our bottleneck definitely appears to be the web tier, so I agree we have more to learn on how to leverage Tapestry better. The interesting thing is our apps run great up to around a few hundred concurrent users. But as I mentioned it crawls at the thousand plus mark. Preliminary results showed us a component or two to optimize, but we're also seeing serious latency in the ApplicationServlet. I'll be interested to see what the data really means and what it can point to in our apps. Thanks again.
- Andrew -----Original Message----- From: Geoff Longman [mailto:[EMAIL PROTECTED] Sent: Thursday, February 09, 2006 9:45 PM To: Tapestry users Subject: Re: Optimization Questions Here's a little bit of info that might help. Each instance of a page, including all of it's component tree is 'constructed' only once. At the end of the request the newly constructed page is put in the pool. Tapestry "cleans" the page, actually it's called 'detach', The page instance that goes into the pool is clean in that no data exists in it that would tie it to one user. Thus a single page instance can service the request of any user in the system. When the next request comes for that page, Tapestry checks the pool. If an instance of the page is in the pool, it's pulled out and reattached to the user session (session is a bad word to use here, there may be no HttpSession involved if the app is running stateless). So on the second request, the page came out of the pool and no page instantiation/tree building happens. You never have to pay that price again (for that instance). Unless, our instance is out of the pool servicing a request when a second request arrives for the exact same page. Rather than wait Tapestry will pay the price to instantiate a second instance of the page. When the first and second requests are done, the page pool now contains two instances of the page. But even then the cost of instantiating the second page is much less the second time as the the cost of building the specification objects (xml or annotations or xml+annotations) has already been paid for the page and all the component in that page's component tree. The specification objects for components are not tied to any single page instance and are only created once. The are the blueprint for instantiating a page/component. If you are the only user of the application, say on your development machine, then the page pool will always remain small and never have more than one instance of each page that you visit. Components themselves are "in the pool" only by the fact that an instance of a component must exist in the component tree of a page instance. Since the pool only caches pages you don't see any components included in the pool size (although there may be many in there, all found in the tree of the page instances of the pool). Some more comments inline.. On 2/9/06, Shannon, Andrew <[EMAIL PROTECTED]> wrote: > We're working to optimize our Tapestry 3.0.3 app that under load (a few > thousand concurrent users in a cluster) slows down significantly. We've > been optimizing our interaction in the middleware and db, however, the > web tier is still the bottleneck. So I have a few comments/questions I > would greatly appreciate insight on. > Invest in a good profiler. JettyLauncher used to be integrated with the Eclipsecolorer profiler but the profiler doesn't seem to work well in Eclipse 3.1.X (you could try an install of Eclipse 3.0 +JettyLauncher + Eclipsecolorer just for profiling). > > > I think I am mostly entendido on how the component tree is built during > page construction, but am concerned about the overuse of a core > component ('X') that conditionally includes 25 or so other components > that are programmatically encapsulated in this same component. > see the first chunk of text I wrote above. The penalty you pay for page instances is well managed by Tapesty for scalibility. > > > One thing I researched but still am not fully clear on is the pool. > Component X is included in form Y, so each time form Y is loaded we need > umptine instances of component X. I seem to think that since X also > includes 25 other component definitions (all referring back to itself) > that this would incur yet umptine more instances of X each time its > parsed. Does this make sense? If so, my concern is on how effective is > the pool. It would seem like the pool is pretty much in a constant > state of exhaustion and that new instances are continuously created. > > > > I printed out the pool.keyCount, pool.pooledCount and pool.window values > but I don't understand the values. keyCount and pooledCount ALWAYS = 3. > The window is its default of 10. > Again, if you are the only user hitting the application, no other simultaneous users, the the page pool will remain quite small. > > > Does the value of 3 indicate that there are only 3 pages/components in > the pool? 3 pages only. > > Is there a max pool size (I haven't found it in the source)? I don't recall the max size > > Can the pool grow? Sure. It grows whenever a request comes in for a page and there isn't already an instance of said page in the pool. > > Do newly created instances get put in the pool after the response, or > are we killing the garbage collector? page instances are put in the pool. The garbage collector deosn't come into play unless you have turned off page caching ... -Dorg.apache.tapestry.disable-caching=true > > It doesn't seem like we have much control over the pool, so should we > override it for our engine definition and create a custom pool? Probably not necessary. The existing pool is well implemented and there are high volume sites out there that (NHL.com and TheServerSide.com) that have not replaced the pool. Somebody correct me if I'm wrong! (I've never heard of anyone replacing the pool implementation). > > Am I even on the right track with these questions? > Sure! what's off track anyways? Sound like you need to learn more about how the guts of Tapestry work! > > > We plan to break out many, if not all, of the 'sub-components' in X and > add them into a library. So if the pool and overuse of component X is a > problem, will this strategy alleviate latency? > Putting component into a library will have no effect on the page instance creation or pool useage/size. Libraries (namespaces really) are part of those specification blueprints I mentioned waaay up near the top of this reply. Constructing pages with Library components has the same cost as any other component. > > Using the library, we would still need to conditionally feed these > components to Form Y (this site is heavy on dynamic forms). I've not > found postings yet on how this can be achieved, yet avoid component > instantiation for components conditionally excluded but seem to get > parsed/instantiated simply because their in the specification. I'm not sure I understand what you are doing. If it's conditionally rendering, the components are always instantiated, they may just not render. If it's Block/RenderBlock for dynamic content - they are still all instantiated regardless if they are rendered or not. But as I said, the minimum number are instantiated and pages containing them are shared via the page pool. Extras are only created when new instances of a page are needed (when multiple, simulataneous, requests for the same page arrive). > > > > Does anyone have a similar situation that you'd be willing to share your > strategy? > > > > What are some of the optimization techniques y'all have done to reduce > load issues in the Tapestry tier? > Frankly, the Tapestry tier has never been the dog performance wise in any of the apps I've built over the last 4 (or is it 5?) years. It's usually a query that is in dire need of optimization or some overzealous fetching of object by a misconfigured ORM framework. I would recommend a good profiler. As always, I happily stand by, ready to be corrected! Geoff > > > Thanks in advance for your help, > > > > Andrew > > [EMAIL PROTECTED] > > > > > > > -- The Spindle guy. http://spindle.sf.net Get help with Spindle: http://lists.sourceforge.net/mailman/listinfo/spindle-user Blog: http://jroller.com/page/glongman Feature Updates: http://spindle.sf.net/updates --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
