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.
>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 sounds like the apps must be simple to be able to scale it to different clients like that. just my 2 cents. 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/
