Mailing-List: contact struts-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <struts-dev@jakarta.apache.org>
Message-ID: <002501c2e75b$e2e14710$6601a8c0@cecilb63compaq>
From: <cwilling@maine.rr.com>
To: "Struts Developers List" <struts-dev@jakarta.apache.org>
Cc: <cedric@apache.org>, <cedric.dumoulin@lifl.fr>
References: <C558E2B738877C41B3D1261EBE72AF7C1D0CA6@nrcw2kexg04.norc.s1.com>
Subject: Re: Tiles excessive memory usage
Date: Mon, 10 Mar 2003 18:22:14 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0022_01C2E731.F99D3B00"

------=_NextPart_000_0022_01C2E731.F99D3B00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Chris,

I'm just now getting to profiling our struts/tiles app and have always =
had some concern about the efficiency of the tiles.  Not that I'm a =
suspecting type of person but I just didn't have any information and =
that caused me to wonder.

Regardles when or if this fix gets placed in a release, would you be =
willing to offer sufficient code snippets that will give me enough =
understanding to implement your fix in my app?  I'm now getting deeper =
into tiles and getting a good feel for what's going on so this would be =
a perfect time for me before we enter client phase.  Also, I'd be =
willing to contribute this efficiency gain to the project(with your help =
or ok) if Cedric and the other powers agree this is something that =
should be done.

But in the meantime, could you supply me with some more detailed =
information and snippets.  This could potentially kill my project since =
performance is the major hot word amoung manager types these days where =
I work.  You can reply to cwilling@maine.rr.com with details that don't =
pertain to the developer's group if you like.

Thanks for posting this!!!!!!!

Chris Willingham
  ----- Original Message -----=20
  From: Christophe Warland=20
  To: 'struts-dev@jakarta.apache.org'=20
  Cc: 'cedric@apache.org' ; 'cedric.dumoulin@lifl.fr'=20
  Sent: Monday, March 10, 2003 4:47 PM
  Subject: Tiles excessive memory usage


  At my company, we have been recently forced to patch Tiles to solve =
some major memory problems where Tiles was eating a lot of memory for no =
apparent reasons. We wish to share our findings with you. And we will be =
happy to send our code change to Cedric if he wishes so.=20

  Here are some quick numbers about our J2EE runtime after complete =
bootup (appserver and EAR file are up, deployed and ready to serve HTTP =
requests):
   - With original Tiles code: 79 MB of RAM is used
   - After our custom code change: 28 MB of RAM is used

  Note that the Tiles version that we use is an old one (our source zip =
shows 09/10/2001). However, a quick analysis of the more recent Tiles =
source found in Struts 1.1 RC1 shows that most the code where the defect =
lies is still in there. But we haven't actually been able to confirm the =
problem at runtime since our app is not compatible with the latest =
Struts and Tiles development.

  Here are a few excerpt of our internal analysis so that you can =
understand the issue.

  --

  Our application does not actually make use of the Tiles template =
mechanism but instead builds on top of Tiles' i18n concept to offer =
localized Web pages based on an individual's language, country, =
personality and channel. We make extensive use of Tiles Component =
definitions and inheritance in XML files, and 667 out of the 668 =
definitions used by our app inherit from another one.

  With the help of a Java profiler, we showed that 64% of the 79 MB of =
memory was used by HashMap entries created by Tiles.  This corresponds =
to 50.5 MB of RAM. After close investigation, it turns out that the very =
useful Tiles' component inheritance has been mis-implemented.=20

  Our application has only one definition that doesn't extend another =
one: the root "pageDefinition", which contains common information such =
as "pageCopyrightLink" for example. Other Component Definitions that =
extend "pageDefinition", such as "disbursementCB", do not need to repeat =
this information. When queried for the "pageCopyrightLink" value, the =
"disbursementCB" component will delegate the processing to its parent =
component, in this case "pageDefinition".

  Unfortunately, this handy conceptual delegation is actually not =
implemented in a similar way in the Tiles source code.

  In our example, when the "disbursementCB" component is instantiated in =
memory, the Tiles source code does not pass it a reference to the parent =
"pageDefiniton" component. Instead, Tiles forces the new =
"disbursementCB" component to make a deep copy of all values defined in =
its parent(s). This means that, ultimately, our application ends up with =
668 copies of the "pageCopyrightLink" value in memory, instead of one.=20

  After modification of the Tiles source code so that true delegation is =
actually happening in memory at runtime, new heap allocation statistics =
showed that the problem with excessive usage of HashMap$Entry has been =
completely solved. The most in-use object in the JVM is now of the type =
"[C", a common and normal trend in typical Java applications.

  The total amount of memory was also down to 28 MB. This is a pleasant =
51 MB gain over the previous result.

  --

  Finally, without being too demanding, we would appreciate if a patched =
version of Tiles could be made available for for both the upcoming =
Struts 1.1 release and the current stabe Strust 1.0.2 one.


  Best Regards,


  Christophe Warland


-------------------------------------------------------------------------=
-----


  ---------------------------------------------------------------------
  To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
  For additional commands, e-mail: struts-dev-help@jakarta.apache.org

------=_NextPart_000_0022_01C2E731.F99D3B00--