> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Monday, June 28, 2021 8:54 AM
> To: users@tomcat.apache.org
> Subject: Re: 500 instances of tomcat on the same server
> 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.

There are two load-balanced servers, each with adequate power to support the 
whole load. When we want to maintain Server A, we drain it at the load balancer 
and wait for the last active connection to complete. Then we reboot/maintain 
the server and add it back into the rotation gracefully.

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

We considered doing it that way. Performance is top priority, so we ultimately 
decided to run the instances on metal rather than introducing a few trillion 
lines of OS code into the mix.  We might consider containerizing.

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

That makes sense until you know the environment better. It's a canned 
application and we're not the publisher. Breaking it out this way gives us the 
ability to present each customer and a unique entity to the publisher for 
support purposes. When their techs connect, the sandbox allows them to 
troubleshoot and support our mutual customer independently, which puts them in 
an environment their techs are comfortable with, and removed the risk of them 
doing something that impacts everybody on the server (or in the VM, if we used 

All I can tell you is we've been running it this way for 15 years and we've 
never looked back and wished we were doing it differently.

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