> -----Original Message----- > From: Brian Wolfe <wolfebrian2...@gmail.com> > Sent: Monday, June 28, 2021 12:23 PM > To: Tomcat Users List <users@tomcat.apache.org> > Subject: Re: 500 instances of tomcat on the same server > > I tend to agree with the initial assessment from Mark, your only issue would > be on the OS level. # of file descriptors for connections. That many tomcat > servers and your gonna start using a lot of ports and push the OS limits on > file > read/write capabilities. >
Those are some of my concerns as well, which is why I asked the question. I can work around the limitation on ephemeral client ports by adding additional IPs to the box and using the localSocketAddress property of Connector/J. I can set the max file descriptors to something like half a million. Are there other potential limitations you can think off? > From an architecture perspective you should probably work on moving to a > more modern deployment model of containerization of these apps. You > would be better served by containerizing each customer deployment and > running them on a kubernetes cluster. you can avoid the need for having > large machines and scale more appropriately. and moving between hardware > would be as simple as adding/removing nodes to your cluster. It is 2 cents well spent. I have also considered Kubernetes and containerization, but I don't yet understand it well enough to know exactly how it benefits me. >It sounds like > the apps must be simple to be able to scale it to different clients like that. > just my 2 cents. > Not simple, but predictable. We've been hosting it for over decade, and we have a good feel for its resource utilization. -Eric > On Mon, Jun 28, 2021 at 1:12 PM Eric Robinson <eric.robin...@psmnv.com> > wrote: > > > > > > > > > > > > -----Original Message----- > > > From: Mark Thomas <ma...@apache.org> > > > Sent: Monday, June 28, 2021 9:04 AM > > > To: users@tomcat.apache.org > > > Subject: Re: 500 instances of tomcat on the same server > > > > > > On 28/06/2021 14:53, Christopher Schultz wrote: > > > > Eric, > > > > > > > > On 6/25/21 22:58, Eric Robinson wrote: > > > >> We can run 75 to 125 instances of tomcat on a single Linux server > > > >> with > > > >> 12 cores and 128GB RAM. It works great. CPU is around 25%, our > > > >> JVMs are not throwing OOMEs, iowait is minimal, and network > > > >> traffic is about 30Mbps. We're happy with the results. > > > >> > > > >> Now we're upping the ante. We have a 48-core server with 1TB RAM, > > > >> and we're planning to run 600+ tomcat instances on it simultaneously. > > > >> What caveats or pitfalls should we watch out for? Are there any > > > >> hard limits that would prevent this from working as expected? > > > > If you have the resources, I see no reason why this would present > > > > any problems. > > > > > > > > On the other hand, what happens when you need to upgrade the OS > on > > > > this beast? You are now talking about disturbing not 72-125 > > > > clients, but 600 of them. > > > > > > > > If I had a beast like this, I'd run VMWare (or similar) on it, > > > > carve it up into virtual machines, and run fewer clients on > > > > each.... just for the sheer flexibility of it. > > > That just moves the goal posts. You'll have the same issue when the > > > hypervisor needs updating (which admittedly may need a reboot less > > > often than the OS). > > > > > > > If this is already a virtualized/cloud environment, then I think > > > > you're doing it wrong: don't provision one huge instance and use > > > > it for multiple clients. Instead, provision lots of small > > > > instances and use them for fewer (or even 1) at a time. > > > > > > But it adds the overhead of an OS for each instance. And costs if > > > you > > have to > > > pay for that OS instance. > > > > > > > The overhead issue is an important factor. The other is the fact that > > it's a canned app, supported by the publisher, and doing it our way > > pays big dividends in terms of that workflow. > > > > > As always there are trade-offs to be made and the "right" answer > > > will > > vary > > > based on circumstances and what you are trying to optimize for. I do > > agree > > > that, generally, more smaller instances will be a closer fit to more > > > use > > cases > > > but that is only a general answer. > > > > > > > Generally, I'd agree too. We are considering using containers, but I'm > > not yet sure what that buys us in terms of stability. > > > > > Mark > > > > > > -------------------------------------------------------------------- > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > Disclaimer : This email and any files transmitted with it are > > confidential and intended solely for intended recipients. If you are > > not the named addressee you should not disseminate, distribute, copy or > alter this email. > > Any views or opinions presented in this email are solely those of the > > author and might not represent those of Physician Select Management. > > Warning: Although Physician Select Management has taken reasonable > > precautions to ensure no viruses are present in this email, the > > company cannot accept responsibility for any loss or damage arising > > from the use of this email or attachments. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > -- > Thanks, > Brian Wolfe > https://www.linkedin.com/in/brian-wolfe-3136425a/ Disclaimer : This email and any files transmitted with it are confidential and intended solely for intended recipients. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physician Select Management. Warning: Although Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
