struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Optimal Heap Size for my Struts-Application
Date Fri, 03 Nov 2006 13:42:24 GMT
Hash: SHA1

Jorge Martín,

Jorge Martín Cuervo wrote:
> It's a realy cool question, i've a complex webapp with a lot of
> differents diciplines:
> - xstl
> - xsl-fo
> - very large objects in session

These three are going to kill you. XSLT uses a ton of memory during
processing, depending on how your templates are written. I would imagine
that the processor could really work like a SAX pipeline should and be
fairly lean and mean, but as soon as you start running xpath expressions
like '/root//something' you can require that entire XML documents be
cached in memory; not just the text itself, but tons and tons of
associated objects.

> The tests with jmeter using 10 concurrents users don't cause an memory
> exception (i use 256M for heap)

That's good.

> there is some guide to view what we have to check to see what's
> happening behind the scenes?

I would turn on verbose GC in your VM and watch the memory usage during
your load tests. Run it for a few hours with a load of 10 users, and
then take the GC output and graph it. If you get a nice curve that looks
like this: /\/\/\/\/\/\/\/\/\/\/\ then you are probably okay in terms of
application memory leaks (meaning that you have few or none). If it goes
steadily upward, you might want to look into what those objects are.

If your load test doesn't run out of memory, you'll have a memory
baseline for 10 users. Ramp that up to 15 or 20 users and repeat the
entire process. Make sure that the memory curve still looks like
/\/\/\/\/\ and then you'll have a measurement for 15 (or 20) users. Try
this again with another step (maybe 25 or 30) and check the numbers.

- From those 3, you ought to be able to predict how much memory you need
for a certain number of users. Determine the peak load that you want to
support, and set the heap to that size. Then, sit back and watch. It
might be good to know the number of users logged-into your system at all
times. If you get an OOM, you might be able to see that you got more
users than you predicted (maybe you planned for 50, and had 58 instead).
In that case, you are free to increase the heap size accordingly.

If there were only 10 users on during the OOM, then you either have a
special case where a ton of memory is required (very possible) or a
problem like a memory leak.

Hope that helps,
- -chris

Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message