-----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
