On 29/10/18 08:00, Ahmed, Tarek wrote: > Hi all, > > TLDR? Do you deploy one web application per tomcat instance or several?
No firm opinion one way or the other, just some commentary. > ----------------------- > > The long story: > > I'd like to sound out your opinion regarding the number of web > applications deployed in one tomcat instance. The reason is, that at my > place of work the developers prefer one webapp per tomcat, the admins > would rather have as many webapps as possible in one tomcat instance > (yeah, that's devops at its finest ;-) ). As a developer I'm probably > prejudiced, but the argument goes as follows: > > > OPS (one tomcat, many webapps): > > - Saves memory (each tomcat has a memory footprint even without a web > application running) The Tomcat overhead is <20MB. Apps are typically a lot more. This doesn't look like a strong argument to me. > - Saves extra file systems for each tomcat (logs, tomcat installation, > temp directory) The resources in question are small in number and size. Again, this doesn't look like a strong argument to me. > - Saves nagios monitoring configuration This is an interesting one. How well can the monitoring distinguish one app from another. Given shared memory, shared thread-pools etc., per app details could be tricky to determine. > - Saves separate ports (security considerations) I don't follow the argument here. > - Saves work distributing security patches A split CATALINA_HOME / CATALINA_BASE approach can help a lot with this issue. https://tomcat.apache.org/tomcat-9.0-doc/introduction.html#CATALINA_HOME_and_CATALINA_BASE > DEV (one webapp per tomcat) > > - Start-up time of "fat tomcats" multiplies, which leads to worsened > availablity (e.g., our fattest tomcat contains 32 web services. It takes > 4 minutes to start) You can configure Tomcat to load applications in parallel to reduce this impact. > - If one webapp goes haywire, it may crash the rest of them (OOM, no > more threads, etc.) Fair point. > - For bug fixes in one application, you may need to restart the complete > tomcat instance. Auto (re)deploy takes you only so far, since loaded > classes may not always be unloaded cleanly, threads not closed etc. This > is not always something that can be solved in your own code, third party > libraries may cause problems, too (we had some issues with quartz and > infinispan here). These issues usually are solvable but you need to know about them in advance to code the necessary workarounds / protections. > - If you ever need to profile your application in production, there is > much less noise when analysing heap, thread dumps, cpu usage etc. Fair point. > - I might even think there is some improved security if webapps are > isolated in several processes vs. being deployed in one VM (security > arguments always work well with OPS :-) ) Possibly. The strength of the security argument depends on the circumstances. I suspect OPS can construct an equally strong security based argument for single instances. > So, I want to get away from the one-tomcat-multiple-webapps scenario. > One thing I started doing to subvert this policy is using spring boot > with embedded tomcats which is cool in a lot of ways but not always > feasible. > > What are your practices? Are there further pros and cons for one way or > the other? Thanks so much for any input, I've configured Tomcat instances both ways in the past depending on circumstances. Generally, the more resources an app uses, the more likely I am to have an app per instance the more business critical the app is, the more likely I am to use a dedicated instance. Otherwise, I tend to opt for a single instance for ease of management. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
