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