On Wed, Jun 30, 2010 at 9:37 AM, Blower, Andy <andy.blo...@proquest.co.uk> wrote: >> -----Original Message----- >> From: Howard Lewis Ship [mailto:hls...@gmail.com] >> Sent: 29 June 2010 18:20 >> To: Tapestry users >> Subject: Re: Tapestry using 1.3Gb of heap space after capacity testing >> >> It may be time to return to a more radical idea, one that is more >> technically feasible now (in release 5.2) than it was in the past. > > Why more feasible in 5.2? We're using 5.1.0.5, and are now too close to > release to upgrade. I was hoping to move to 5.2 when I thought it would be > released in H1 2010, but we'll need to stick with 5.1 now I think. We launch > in August. > >> Get rid of page pooling. >> >> I'm not saying to re-create each page for each request; I don't think >> that would scale. >> >> However, it may be possible to change Tapestry so that you need only >> ONE instance of a given page (per locale). All transient (per-request) >> state for the page could be accessed indirectly, stored in a >> per-thread object (or inside the Request, as attributes). >> >> I can envision some small amount of extra overhead per request (due to >> extra levels of indirection). >> >> However, you could then process any number of threads against the >> same, single page object with no extra memory consumption: for >> example, no more duplicated Binding objects, and no more extra Maps to >> hold them all. >> >> Some parts of the Tapestry's internal implementation >> (InternalComponentResourcesImpl and ComponentPageElementImpl) would >> need some changing, i.e., a bit more synchronization around some >> critical sections. >> >> It's an exciting idea ... when will I have time to investigate it? > > It certainly is an exciting idea, out of curiosity How long do you think it > would take you to implement this - it sounds like a pretty big overhaul to me.
It's not so large an overhaul as you might think. My big concern is that the change in semantics (not the change in API) might cause existing ComponentClassTransformationWorkers (contributed by 3rd party libraries) to no longer operate correctly. > > Anything else that I could look into? Am I on the right track? > > >> -----Original Message----- >> From: Christophe Cordenier [mailto:christophe.corden...@gmail.com] >> Sent: 29 June 2010 19:35 >> To: Tapestry users >> Subject: Re: Tapestry using 1.3Gb of heap space after capacity testing >> >> Holy grail ! but is it really feasible... >> >> @Andy Sorry i didn't follow all the thread but if i understand well, you >> have page instance of 7.5Mb for one single instance ? This is only due to >> page and component structure ? > > That's correct I believe - it used to be 14Mb. Our largest page is 10Mb and > we have 13 pages with over 4Mb retained size from their PageImpl's. > > I'm not sure how this compares with the average, but I suspect they are a bit > on the large size. > > Andy > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
