Chris, will likely go with mod_jk, but I did notice that Jetty folks strongly recommend mod_proxy (may be that their container works better with mod_proxy)
I am not using a framework per se, one that I have written, so definitely not something like Grails with Spring + Hibernate for example. Groovy itself is memory hungry, dynamic language features such as closures, duck typing and runtime MOP come with a cost for sure. In other words, not expecting to run on 128mb as you have been attempting ;--) I'll need to sort out DBCP, java singletons are nothing like php where a singleton exists for lifetime of the request, vs. lifetime of the application. Thanks for the clarification on these issues! Noah On Wed, 2011-03-16 at 21:35 -0400, Christopher Schultz wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Noah, > > 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 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk2BZWEACgkQ9CaO5/Lv0PCq0wCgnHkDm0aTMDNzvrj/Zazg5poi > LzoAoLEa5viGxb0FbXkX41r1NIZ3tDWS > =ES1m > -----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
