> -----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

Reply via email to