Eric,
On 12/29/21 16:04, Eric Robinson wrote:
We want to run a large number of tomcat instances on the same server
without virtualization or containerization. Each instance is executed
from its own folder tree and listens on its own unique TCP port. Each
instance will run code that connects to a backend database server to
send queries that are triggered by JSP calls from users. We’ve done this
successfully with up to 120 instances of tomcat running on the same
server while avoiding the overhead of virtualization and the complexity
of containers. Based on our experience over the past decade, we know
that we could potentially host 500 or more separate tomcat instances on
the same server without running into performance problems. So now we
want to make it 500 parallel instances.
Here’s the problem. When tomcat initiates an outbound connection (for
example, with Connector/J to query a backend database) it establishes a
socket, and the socket has a client port. With thousands of users making
requests that require the tomcat services to query back end databases,
the OS can easily run out of available client ports to allocate to
sockets. To avoid that problem, we can assign multiple IPs to the server
and use the localSocketAddress property of Connector/J to group tomcats
such that only a subset of them each use the same source IP. Then each
group will have its own range of 64,000-ish client ports. I’ve tested
this and it works.
My question is, is there a better way?
Stupid question: can your database (meaningfully) handle the number of
connections you are making to it? Let's say you have 5000 connections
per Tomcat instance to your database, and you want 500 Tomcat instances.
That means 2500000 database connections. If every single one of those is
executing a query, will your database melt or are you okay?
Are you pooling database connections? Are you sure you need
thousands-at-a-time for each Tomcat instance?
I'm not saying that you absolutely /do not/ need this kind of thing, but
"most people" don't need that kind of concurrency.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
