On 14/04/2013 21:53, Howard W. Smith, Jr. wrote:
On Sun, Apr 14, 2013 at 6:51 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Howard,
On 4/11/13 10:38 PM, Howard W. Smith, Jr. wrote:
On Thu, Apr 4, 2013 at 2:32 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
Your heap settings should be tailored to your environment and
usage scenarios.
Interesting. I suppose 'your environment' means memory available,
operating system, hardware. Usage scenarios? hmmm... please clarify
with a brief example, thanks. :)
Here's an example: Let's say that your webapp doesn't use HttpSessions
and does no caching. You need to be able to handle 100 simultaneous
connections that do small fetches/inserts from/into a relational
database. Your pages are fairly simple and don't have any kind of
heavyweight app framework taking-up a whole bunch of memory to do
simple things.
Thanks Chris for the example. This is definitely not my app. I am
definitely relying on user HttpSessions, and I do JPA-level caching
(statement cache and query results cache). pages are PrimeFaces and
primefaces = xhtml, html, jquery, and MyFaces/OpenWebBeans to help with
speed/performance. And right now, the app handles on a 'few' simultaneous
connections/users that do small and large fetches/inserts from/into
relational database. :)
Hopefully one day, my app will be support 100+ simultaneous
connections/users.
For this situation, you can probably get away with a 64MiB heap. If
your webapp uses more than 64MiB, there is probably some kind of
problem. If you only need a 64MiB heap, then you can probably run on
fairly modest hardware: there's no need to lease that 128GiB server
your vendor is trying to talk you into.
Understood, thanks. I have Xms/Xmx = 1024m, and I rarely see used memory
get over 400 or 500m. the production server has 32GB RAM.
I'll summarize a number of JavaOne sesisons I've been to on GC and
performance (caveat - this was a couple of years ago and GC design has
moved on since then).
- GC pause time
- throughput
- small memory footprint
You can optimise for any two of the above at the expense of the third.
Assuming you opt for min GC pause time and max throughput the question
then becomes how much heap do you need? If you look at your steady state
heap usage graph (it should be a saw-tooth) then take the heap usage at
the bottom of the saw-tooth and multiply it by 5 - that is the heap size
you should use for the GC to work optimally.
HTH,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
