Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4D813915.80206@christopherschultz.net>
Date: Wed, 16 Mar 2011 18:26:29 -0400
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Tomcat 7 Per Instance Memory Footprint in Hello World App.
References: <1300166720.2524.109.camel@localhost.localdomain>
	 <4D7F0AAC.8090805@freit.ag>
	 <1300174047.2524.122.camel@localhost.localdomain>
	 <20110315090936.GD15372@darkwhole.de>
	 <1300212348.2524.139.camel@localhost.localdomain>
	 <4D7FCB62.6020105@christopherschultz.net>
 <1300230150.2524.168.camel@localhost.localdomain>
In-Reply-To: <1300230150.2524.168.camel@localhost.localdomain>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Noah,

On 3/15/2011 7:02 PM, Noah Cutler wrote:
> However, some of the LAMP stack apps will have legacy/archived
> functionality that I have zero interest/time in porting over to
> JVM/Groovy framework. So, the plan is to mod_rewrite archived requests
> to php, along with static files (css,jss,html,etc.), and use Tomcat to
> serve up non-legacy dynamic content, connecting via AJP or mod_proxy.

Sounds reasonable: you you've already got Apache httpd in the mix, so
multiplexing between multiple backend Tomcats isn't a big deal, then.
FYI mod_proxy will also do AJP if you want. The protocol is slightly
more optimized than HTTP proxying, but does not (directly) include any
options for encryption and is a tiny bit harder to debug when problems
arise.

> Amazed that you have been able to tweak JVM memory usage down to as
> little as 128mb, incredible.

We have a very lean and mean webapp: small transactions and very little
stored in the session. We only have to increase the heap size as the
number of concurrent users grows. We've had to do this twice in
production, and the first time it was growing from a 64MiB heap up to
192MiB (just for good measure). Our last release had a huge problem with
it that was bringing way too many rows back from the db and caching them
in the user's session and we've had to temporarily grow up to 385MiB to
keep that under control before a fix can be put in place.

We use Struts 1 as our app framework and use our own hand-written JDBC
queries to fetch data from our RDBMS, so there's not a whole lot of junk
laying around.

> The OOME issue is a real one given my lack
> of experience in Java -- have @5 months Groovy under my belt and am
> enjoying it far too much to return to php -- so "important" client sites
> will have their own dedicated Tomcat instance; the rest, I'll virtual
> host in a single instance.

Sounds like a plan.

If you have any more questions, definitely come back to the list.

> Am interested in Tomcat 7's new DBCP model as well.  Coupled with Groovy
> per request singleton (unlike per instance/application lifetime), I
> should be able create a db connection handle on request start and
> thereafter have all queries in the request run against this cached
> connection (could also do a true singleton, the most efficient, but as I
> understand, singletons are specific to the entire instance, and
> therefore will not work for a virtual hosts setup).

I don't think that's what you want to do. Typically, a connection pool
will have a fixed number of connections for a (somewhat) unlimited
number of users. If you assign a db connection to each user, you are
tying-up resources on the db server for a user who may disappear and
never explicitly log out, freezing that connection until some timeout
occurs. Worse, you have to have potentially thousands of connections to
the back-end which may kill your db: all of those connections require a
non-trivial amount of memory to manage.

It's usually sufficient to grab a connection from the pool, use it, then
put it back. If you have a use case where some other strategy makes
sense, I'd be glad to hear it.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2BORUACgkQ9CaO5/Lv0PAEhQCfZkOUFQ7r80Jp/7a2q1RJeeGg
sw8An2vtc0DnZ4oj56JN+xEv39aaVi78
=bKzA
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org