Eric,
On 6/26/24 01:43, Eric Robinson wrote:
What is impact on memory utilization if we increase the acceptCount
value? There are 100 tomcat instances on the server. And would
maxThreads have to be increased to accommodate the extra
connections?
After reading more, I guess that's a dumb question.
:)
I'm trying to prevent connections from being rejected. As I
understand it, when the server hits the maxThreads limit, then
additional connections queue up, until the acceptCount value is
finally reached, and then new connections are rejected.
This is correct according to all documentation. But. Java's
documentation is clear that acceptCount/backlog is a "hint" to the OS
about what that value can be. The OS is under no obligation to (a) set
the accept-queue size to anything specific (such as your desired value),
(b) keep the accept-queue size consistent. The documentation for
listen(2) on my Debian Linux system suggests that the backlog is
actually respected but silently capped to the OS's max count which is
4096 is anything remotely recent.
My guess is that Java didn't want to over-promise with the acceptCount
since it's supposed to be cross-platform. While Linux will generally
respect the acceptCount, it CAN be capped silently. Other OSs may always
give a process the same acceptCount or so something else somewhat
unexpected.
Since you are using Linux, I think you can bet on acceptCount working
mostly as you expect, with the caveat that it might be capped at an
environment-specific value (which is likely changeable if necessary).
Since I am seeing connection refusals, then it is possible that the
acceptCount limit is being reached.
I would say "probable".
If so, then it seems there are two ways to address this. I can either
increase acceptCount, which gives the server more time to make
threads are available, or I can increase maxThreads, in which case
more requests can be handled concurrently and the acceptCount may not
be reached.
+1
Both of these settings improve performance, but in different ways.
I wouldn't say that raising acceptCount "improves performance" but maybe
"improves experience". It may effectively /decrease/ performance because
connections accepted (into the accept queue) but that have to wait a few
seconds to be serviced may result in clients hanging up the phone before
they are serviced. Depending upon the details of the situation, your
server may serve a request from a client who has already given-up on the
response... and even re-submitted the same request. So you get to do
double the work in that situation.
Unfortunately, there is no "timeout" for the accept-queue. Once a
connection has been accepted (bad verb, since accept(2) is the call that
the application makes to accept the connection) into the
accept-queue/backlog, it will remain there until the application calls
accept(2) or terminates, even if the client disconnects or 15 minutes
goes by. There is no way to say "put them in the queue but after 5
seconds go ahead and refuse the connection". It's "connect or refuse" at
that point.
maxThreads improves performance by allowing more requests to be
processed concurrently, while acceptCount improves performance by
preventing connections from being refused, which requires requests to
be reissued by the client, and that is an expensive process.
I would argue the opposite: clients receiving "connection refused" go
away quickly and cheaply. It's the ones who wait in the accept queue who
are "expensive".
Which of these approaches is correct? I tend to think increasing
maxThreads is better if the server has enough memory and CPU.
However, since the impact on memory and CPU depend on the
characteristics of the app, that's not a question you can be expected
to answer.
Again, it all depends upon your clients, usage patterns, and the "price"
of a refused connection. If you have (human) clients who get VERY upset
if their connections are refused than you may need to either change
client expectations or change your service configuration with the
understanding that "waiting in line is better than being turned away".
Nobody can answer this question for you: you will need to decide for
yourself which is better.
Hope that helps,
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
