-----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: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
