-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 lb,
lightbulb432 wrote: > In production, for organizations that run multiple web applications, would > they run it on different instances of Tomcat (1 instance per web application > or group of related web applications), or all web applications as different > hosts on one instance of Tomcat? (Not taking into account clustering, where > everything in whatever setup is chosen would be duplicated.) The is completely dictated by the deployment team and includes multiple factors. We prefer the one-Tomcat-instance-per-webapp because we want to insulate them from each other. If one application leaks memory (for instance), then only one JVM will be disabled when that happens. Our current needs are limited, so we can run all our applications on a single physical machine. Moving to multiple machines would be trivial since the applications are already deployed separately. To deploy in this way, with everything running over port 80 (and 443), we need to front these Tomcat instances with a routing web server (we chose Apache httpd). > What are the tradeoffs in terms of performance, resource usage, > maintainability, etc, and what are your comments based on past experience? > What's common in production and what isn't as much? Memory usage is certainly the most significant resource "waste" when considering the above strategy. All of our applications fit comfortably in a quarter gigabyte or so, so running multiple JVMs on the same hardware isn't a big deal for us. I would venture a guess that in terms of CPU performance, the difference is negligible, depending on how your operating system treats threads versus processes. We are deployed on Linux 2.6 which treats them about the same, so I would expect the performance impact to be minimal. I find this setup to be very maintainable, since sometimes Tomcat versions and built-in libraries interfere with each other. In the described setup, each application has its own Tomcat environment that can be separately tested, upgraded, etc. If you need a new XML parser but Tomcat's built-in version is interfering (used to happen... might not after the 4.1 versions), no problem: replace the built-in XML parser, test, deploy. No need to interfere with other applications. In other production environments, I have typically seen large applications clustered. One machine runs one application, and that machine is duplicated for other members in the cluster. Depending on your hardware, more applications per physical server might make more sense. These days, you can get some pretty beefy commodity 64-bit hardware that can handle a lot of traffic. You will quickly find out that SSL traffic is the most expensive thing to manage, not your application ;) - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGf+xs9CaO5/Lv0PARAtOwAJ0RuDEYg6VCMUlFmbLdXPXkYjUTDgCgnFlI oiDNrR4/TcFvcyeVP86XNXE= =aXPJ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]