Tomcat MaxConnectons

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Tomcat MaxConnectons

Rajendra
What is maxConnections attribute in Tomcat and what is the optimum value in
Unix machine?

Thanks,
Raj
--
Thanks&Regards Rajendra
Reply | Threaded
Open this post in threaded view
|

Re: Tomcat MaxConnectons

Christopher Schultz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Rajendra,

On 1/11/19 10:20, Rajendra Popuri wrote:
> What is maxConnections attribute in Tomcat

It is all but deprecated IMHO.

http://tomcat.apache.org/tomcat-9.0-doc/config/http.html#Standard_Implem
entation

Search for "maxConnections".

Then read about Executors. They are a better idea.

> and what is the optimum value in Unix machine?

There isn't anything UNIX-specific about the optimum value. The
default is 10,000 for NIO/NIO2 and 8192 for APR (I'm not sure why
there is a difference in the defaults; perhaps we should fix that),
which "ought to be enough for anyone".

The proper value for your environment is highly dependent upon your
use-case(s). If you tell us a little more about what you are doing,
perhaps we can give you a better answer.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlw406wACgkQHPApP6U8
pFh/+RAAke9fQiwIvCvp2w3ktrOXr+l56zIE/YJLk50PofEWWIz8LAV31jfmHP/s
w5ROawFomB0UlSuAMJp1dmy43L9ptj7i7BDpwPMU74m8FPwUxWEi7rJ9bC5M2q00
WNuBGcwENZ6zHWXURzZFJqoJTcK7e3U2xv7EMAHuTuJ1qSyrdbxQkDyLmJt0Cbep
XNrtW9RAH++DDW992EL2T1wkRYGrVVdJP7g6D8ncQyf55umH+FWhEKfccTWRzsBX
o2sg0OIfBRDxSilphRKLvhXaXcTDa2B5YBLCsnafNyWS5AGGr90WLvKrRamgZfVU
+r4jQDgiuf94UJdanHOuhLQXBv+ejxeo/OMvCF3TZ2wkBrSEgsv4h74BcGHuK/v5
Clfi+jw6y9EiQI6CTC5pYyNpu3f77zYvBCgRaN4M7qXss8HmNYNMIiLkrubKs1WT
/d2xbjFT4bIPYdcYD+mw/uu/7jU8IubYyvAdEFFAEbCVaIPQAMgfl/ZmarO4o2qO
r9qi+cY/TrNInNqjyrNrAjCEU5zgXJorrO8kDmLryp0TdyGpDll1H3eEIErLiM1W
DJNCB8hq1VRQz8B8mrnOZnc3RvYdz5FDEJIiWPwvlDDjF9YCfUPC5zLiCbaopGEO
UonupLQdtP94mvM3BwnMajnRhuO60kCbBZsZROozXZAtYvydorc=
=kvz+
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tomcat MaxConnectons

Rajendra
Hi Chris,

Thanks for prom response.

Actually I am trying to understand the attributes acceptCount vs
maxConnections. Assuming this is the maximum socket connections tomcat can
handle   In a time and this can be restricted with ulimit -f in linux.
Please advise.

Thanks,
Rajendra

On Fri, Jan 11, 2019 at 12:34 PM Christopher Schultz <
[hidden email]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Rajendra,
>
> On 1/11/19 10:20, Rajendra Popuri wrote:
> > What is maxConnections attribute in Tomcat
>
> It is all but deprecated IMHO.
>
> http://tomcat.apache.org/tomcat-9.0-doc/config/http.html#Standard_Implem
> entation
>
> Search for "maxConnections".
>
> Then read about Executors. They are a better idea.
>
> > and what is the optimum value in Unix machine?
>
> There isn't anything UNIX-specific about the optimum value. The
> default is 10,000 for NIO/NIO2 and 8192 for APR (I'm not sure why
> there is a difference in the defaults; perhaps we should fix that),
> which "ought to be enough for anyone".
>
> The proper value for your environment is highly dependent upon your
> use-case(s). If you tell us a little more about what you are doing,
> perhaps we can give you a better answer.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlw406wACgkQHPApP6U8
> pFh/+RAAke9fQiwIvCvp2w3ktrOXr+l56zIE/YJLk50PofEWWIz8LAV31jfmHP/s
> w5ROawFomB0UlSuAMJp1dmy43L9ptj7i7BDpwPMU74m8FPwUxWEi7rJ9bC5M2q00
> WNuBGcwENZ6zHWXURzZFJqoJTcK7e3U2xv7EMAHuTuJ1qSyrdbxQkDyLmJt0Cbep
> XNrtW9RAH++DDW992EL2T1wkRYGrVVdJP7g6D8ncQyf55umH+FWhEKfccTWRzsBX
> o2sg0OIfBRDxSilphRKLvhXaXcTDa2B5YBLCsnafNyWS5AGGr90WLvKrRamgZfVU
> +r4jQDgiuf94UJdanHOuhLQXBv+ejxeo/OMvCF3TZ2wkBrSEgsv4h74BcGHuK/v5
> Clfi+jw6y9EiQI6CTC5pYyNpu3f77zYvBCgRaN4M7qXss8HmNYNMIiLkrubKs1WT
> /d2xbjFT4bIPYdcYD+mw/uu/7jU8IubYyvAdEFFAEbCVaIPQAMgfl/ZmarO4o2qO
> r9qi+cY/TrNInNqjyrNrAjCEU5zgXJorrO8kDmLryp0TdyGpDll1H3eEIErLiM1W
> DJNCB8hq1VRQz8B8mrnOZnc3RvYdz5FDEJIiWPwvlDDjF9YCfUPC5zLiCbaopGEO
> UonupLQdtP94mvM3BwnMajnRhuO60kCbBZsZROozXZAtYvydorc=
> =kvz+
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
Thanks&Regards Rajendra
Reply | Threaded
Open this post in threaded view
|

Re: Tomcat MaxConnectons

Christopher Schultz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Rajendra,

On 1/11/19 12:52, Rajendra Popuri wrote:
> Actually I am trying to understand the attributes acceptCount vs
> maxConnections.

They are both limits, but are implemented in different places.

The "acceptCount" is implemented in the TCP/IP stack of your operating
system, and it's a queue of incoming connections that are allowed to
stall and await the application-layer actually accepting the
connection. Once the application "accepts" the connection, it is
considered to be "connected". When it's in the "accept" queue, the
client is blocking on the connection but no useful work will be
accomplished (yet).

The maxConnections is the number of connections that Tomcat (really
Java, or APR in the case of the APR/native connector) is willing to
accept from the OS's TCP/IP queue (above).

If you have the default configuration, you'll have acceptCount=100 and
maxConnections="10000". If you get 100 simultaneous connections (on a
server with no established connections), they will all immediately be
accepted by Tomcat and the requests will be executed.

If those connections remain open (keepalive, additional requests,
etc.) and another 10100 connections are opened by new clients, this
will happen:

1. The first 9900 connections will be accepted by Tomcat
2. The next 100 connections will be queued in the OS's TCP/IP stack
3. The final 100 connections will be refused

Once some of the connections accepted in #1 above have been closed,
the TCP/IP stack's connection queue will empty into the application
(Tomcat will accept those connections) and any new connections being
made will then go into the same queue.

It's interesting that the OS is not actually *required* to maintain
the accept-queue-size requested by the application. The Linux man page
for listen(2) has this to say:

"
If the backlog argument is greater than the value in
/proc/sys/net/core/somaxconn, then it is silently truncated to that
value;  the default value in this file is 128.  In kernels before
2.4.25, this limit was a hard coded value, SOMAXCONN, with the value 128
.
"

BSD (Darwin) says this:

"
The backlog is currently limited (silently) to 128.
"

So it almost doesn't matter what you set this value to. Practically,
it will likely be limited *for you* to some other value.

IMHO, I'd leave acceptCount at the default or even *lower it*. I'd
rather have clients get "connection refused" errors than overwealm my
server or create a backlog of requests that is very long. Google for
"buffer bloat" and you'll get a sense of my reasoning.

If one server can't accept enough connections to support by web
service, then I need more servers, not more queuing.

> Assuming this is the maximum socket connections tomcat can handle.
Tomcat can handle lots of connections. Your application is much more
likely to be the bottleneck, here. It probably doesn't make sense to
accept 1,000,000 connections if your application can really only
handle 1,000 simultaneous requests.

> In a time and this can be restricted with ulimit -f in linux.

ulimit -f changes file-size limits, not network limits. You are more
likely to require a change in the number of open file-descriptors (-n)
per process than anything else.

Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlw44S4ACgkQHPApP6U8
pFiTjBAAyfbmQsHoeBNdhs9QKbot5i7Ik+mn8Cv2wg0y8P6jz7QrlbqB6MDdPUx8
qxDTEKTjz6wB9+PbGUP5XIjEbjkn+G3X4qUray3BCnO9UUW4Zlm4sZsn7vWbIyJ0
tf+T3ZDupiGoFbM1hKhqgZNgoc9XRlAxIGVZF5JAyz8uA6fUYRGICCJjzFxC8IRo
B8YfbNj/RAsgBOsGlIcH1sTVH7bcI1R8YuIt/QYjhl0VWphUFX3o8YaT/OXgsWlX
9fusDgp7P+ngXOSlbUVdatMt4P2s6GaqvL6ddsXoKj7B58Rfi0jhhkSspl0nYs18
jSHl3OXQm7KtCWSqe9BHpr6zHdVr7fiL2cKcnCaXuSfiul9OgoaHnc9MPmlLK2jQ
WJzfwMf23LArRcsv8cg8Zx0iozYP6lGBJbnmaUXZfjm4J90WUQGk/AXcq/ayFoQu
1ARo4dVbSeIYK0+JtiOoNnufSbCKJ5JgviRcPWN4wKVOSv4i6Shah4KuFuyNnAun
7JDyOKmDtp6FaSlxai9G/185JSdF78EPtSrPHYZMAm24KO7CTPydUqqlDSYtf3OD
gOsv46PEZfiAQbIAYnV+w1QBmqpVljxmDp2Tr3bqeQpX9mo0pPVqWcTBWRgCfq4A
BpiECiUaUqTI52zelRBYK+kZ/B+y9HyHzGrNtrhaklRZ2mSevao=
=HLVp
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]