Tapestry does allocate a good number of temporary objects when processing a request (i.e., the nodes in the DOM tree). These are very short lived and are quickly (and very efficiently ) reclaimed by the GC on the next collection. Objects in Tapestry tend to either be very short lived, or eternal (i.e., service implementations) with pages being long lived, if actively used.
Ben Gidely did the performance analysis that Thiago mentions. On Tue, Feb 9, 2010 at 3:20 AM, Jim O'Callaghan <jc1000...@yahoo.co.uk> wrote: > Thiago, > > Thanks for the quick reply. I haven't configured the tapestry.page-pool.* > symbols so am using the defaults for them. I'm not at the stage yet where I > am profiling with some load testing software - this is just something I > noticed when visually monitoring the relevant java process. It is probably > an unanswerable question - to find out whether the increase per request is > down to sloppy coding within the application, or an expected allocation by > Tapestry that will be reclaimed / managed as necessary. > > It is good to hear that previous posters have found that after significant > load the memory usage has returned to an expected level. I'll have a look > through the archive and see what tools they were using and try to get some of > my own figures for a realistic load test. > > Regards, > Jim. > > -----Original Message----- > From: Thiago H. de Paula Figueiredo [mailto:thiag...@gmail.com] > Sent: 09 February 2010 10:57 > To: Tapestry users > Subject: Re: Memory Leaks > > > What are your values for the tapestry.page-pool.* symbols? Have you tested > making 1k or 10k request and then taking another used memory reading? > > Some time ago, someone here (sorry, I forgot the name) posted a test like > the one I'm suggesting above (a load test). It found out that Tapestry, > after a large load, had its performance back to normal (i.e. before the > large load). > > On Tue, 09 Feb 2010 08:48:57 -0200, Jim O'Callaghan > <j...@peritussolutions.com> wrote: > >> Looking at the memory (private working set) used by the java process my >> Tapestry 5 app is running under, I notice that when running through the >> same >> request cycle with PRODUCTION_MODE set to true, I am getting an increase >> of >> approx 4K per repeated request. Is this typical or something to be >> concerned about in the context of an application with >50 <100 concurrent >> users, or is Tapestry reasonably aggressive in reclaiming resources? If >> it >> is not typical, any pointers on areas to look for leaks, or is this a >> needle >> in a haystack? >> >> Thanks, >> Jim. > > > -- > Thiago H. de Paula Figueiredo > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, > and instructor > Owner, software architect and developer, Ars Machina Tecnologia da > Informação Ltda. > Coordenador e professor da Especialização em Engenharia de Software com > Ênfase em Java da Faculdade Pitágoras > Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate > Sócio, Ars Machina Tecnologia da Informação Ltda. > http://www.arsmachina.com.br > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > > --------------------------------------------------------------------- > 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
