Chris, great feedback. 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.
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. Speaking of, what are your basic -X params to pull this off? Re: DBCP and per user per request connection handle, yes, not well thought out, am putting the pieces together component-wise; most in the know suggest connection pooling vs. per request connections. Correct me if I am wrong here, but as I see it, there are 2 basic approaches for database connectivity on the JVM: 1) low traffic app = non-pooled, connection per request >> this is the single tomcat instance, many virtual hosts model (low budget hosting) 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. 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. 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 ;--) Noah On Wed, 2011-03-16 at 18:26 -0400, Christopher Schultz wrote: > -----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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
