tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Tomcat 7 Per Instance Memory Footprint in Hello World App.
Date Thu, 17 Mar 2011 01:35:29 GMT
Hash: SHA1


On 3/16/2011 7:48 PM, Noah Cutler wrote:
> the Tomcat Groovy app will do nothing but serve up dynamic content
> (httpd will handle ssl as well), so whichever method (ajp or mod_proxy)
> peforms the best/is-most-reliable, I'll go with.

I have a preference for mod_jk since it is more mature, has a separate
release cycle, and has more configuration options than mod_proxy_ajp.
I'm biased though since I've used mod_jk since before mod_proxy_ajp was
available. I had never considered mod_proxy_http but given the options
mod_jk has, I haven't re-considered it.

> Love that 128mb JVM, I am very much interested in lean & mean.  Coming
> from LAMP stack where memory usage is minimal for non-enterprise
> trafficked apps, the JVM seems a bit heavy handed, but power comes at a
> cost (memory) it seems. I'll need to analyze existing apache logs and
> see how many concurrent users we have on average, and then tweak Java -X
> accordingly per Tomcat instance. Assume with low traffic apps that you
> can effectively starve the JVM, giving it just enough memory to start
> (plus a small cushion), which is probably what you are doing with the
> 128mb JVM.

If you are using a framework like JGroovy, you are adding a somewhat
thick layer on top of Java already... are you also using any other
libraries that might be either caching a lot of data or building large
object trees in memory?

> Speaking of, what are your basic -X params to pull this off?

Right now a simple "-Xms384M -Xmx384M". No special PermGen options, no
GC options, no nuthin'.

> 1) low traffic app = non-pooled, connection per request
>>> this is the single tomcat instance, many virtual hosts model (low
> budget hosting)

I would always use a connection pool, even if the pool is shallow. We
run with a mere 20 connections in production and serve hundreds of
simultaneous users (not simultaneous requests, of course).

> 2) mid-to-high traffic app = pooled, connection per tomcat instance
>>> application has dedicated tomcat instance; connection handle is
> singleton, created on tomcat startup and shared by all users.

I would use a pool per webapp. That allows you to size each one
appropriately for the load and one busy webapp won't starve the other
webapps out of their connections.

> One thing I may not have mentioned is that each component will be
> running in its own virtual machine; i.e. VM1 Apache/PHP; VM2 MySQL; VM3
> Tomcat/Groovy.

Interesting, but not doesn't really change anything.

> Probably will not get same performance as a bare metal setup, but the
> server has 2X 6-core 12mb cache CPU, 6X 146GB SCSI, and 16GB RAM, so I
> should be able to allocate sufficient resources to each VM and get
> decent performance -- either way, will be fun to find out ;--)

One would hope ;)

Good luck,
- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


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

View raw message