Andrew, I'm not saying that something in Tapestry can't be improved to make scalability better. I for one don't have a thousand concurrent users in my app (yet).
If, by profiling, you can help identify the bottleneck then you are doing a great service to the community. Besides, once the bottleneck is identifed it *will* be eliminated - which is what you need anyways. Geoff On 2/15/06, Shannon, Andrew <[EMAIL PROTECTED]> wrote: > 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] > > -- 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]
