Test configuration: <Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol" acceptCount="10240" numThreads="1024" connectionTimeout="20000" redirectPort="8443" />
I have increased somaxconn. The error has become very consistent. I can trigger it by restarting tomcat and then running the test. Typically it takes <5s for ab to terminate. (Though ab states that several thousand requests have completed by that point, which appears true from the access logs). The high (10240) acceptCount seems to be the reason for the consistent error. Decreasing it seems to make things more stable. In fact, setting acceptCount="5" and connectionTimeout="-1" seems to delay the error by a huge amount, but it still occurs. Also, the connectionTimeout resolves "length" and "exception" errors occasionally reported by ab. I presume this is related more to how the client (ab) operates and not tomcat itself. The acceptCount is counter-intuitive to me. Was this the intended solution you had in mind. Thanks for the insight! ________________________________ From: Christopher Schultz <ch...@christopherschultz.net> To: Tomcat Users List <users@tomcat.apache.org> Sent: Tuesday, July 24, 2012 2:34 PM Subject: Re: Default configuration; Connection reset by peer -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Phineas, On 7/24/12 4:59 PM, Phineas Dole wrote: > I am currently benchmarking tomcat to see what sort of performance > I can expect. > > I setup tomcat with the default configuration and then run "ab -c > 1000 -n 1000000 > http://localhost:8080/examples/servlets/servlet/HelloWorldExample"; Note that the default configuration of Tomcat's Connector has maxThreads=200 and acceptCount=100 meaning that Tomcat will only actively process 200 simultaneous connections and the OS is expected to accept 100 connections and queue them until Tomcat is ready to actively handle them. I suspect you will very quickly fill-up the accept queue and start getting connections dropped, unless your test servlet runs very quickly. > Occasionally, ab will terminate prematurely with error such as > "apr_socket_recv: Connection reset by peer (104)" > > This happens with bio, nio, and apr connectors. > > How do I configure tomcat or my OS to handle this workload? I have > not experienced this problem with other webservers or Jetty... > what is happening? What was their configuration in terms of request processors, etc.? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAPFNYACgkQ9CaO5/Lv0PC0LACgrUikOLHu3LBmwZap9ZzwG0Ap B6IAnA+ze3YX2a4elffzB3cHsxLmwKgY =UKxo -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
