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/

Reply via email to