Re: APR connector questions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Daniel,
On 5/9/20 12:34, daniel@dell.com wrote:
> We want to use APR to call openssl also do with native to support
FIPS mode in tomcat.
>
> Software info Tomcat/9.0.34 libtcnative-1-0-1.2.23-15.30.x86_64
Where did you get that? Is it tcnative-1.2.23?
What about your APR version?
> configuration as below:
>
> connectionTimeout="6" maxKeepAliveRequests="150"
> SSLCertificateFile="*" SSLCertificateChainFile=""
> SSLCertificateKeyFile="*" compression="on"
>
compressibleMimeType="text/html,text/xml,text/css,text/javascript,applic
ation/javascript"
> port="${bio.https.port}"
> protocol="org.apache.coyote.http11.Http11AprProtocol"
> scheme="https" secure="true" sslProtocol="TLS"
> sslEnabledProtocols="TLSv1.2" URIEncoding="UTF-8"/>
>
>
> When enable debug info in tomcat will see
>
> 09-May-2020 00:51:35.358 FINE [https-openssl-apr-8443-exec-1]
org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper.doClose
Calling
[org.apache.tomcat.util.net.AprEndpoint@4275c20c].closeSocket([org.apach
e.tomcat.util.net.AprEndpoint$AprSocketWrapper@1efb5c3e:139622944367568]
)
> 09-May-2020 00:51:35.367 FINE [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint$Poller.removeFromPoller
Attempting to remove [139,622,944,367,568] from poller
Woah, that looks super weird.
> 09-May-2020 00:51:35.367 FINER [https-openssl-apr-8443-Poller]
org.apache.tomcat.util.net.AprEndpoint.destroySocketInternal
Destroying socket [139,622,944,367,568]
> java.lang.Exception at
org.apache.tomcat.util.net.AprEndpoint.destroySocketInternal(AprEndpoint
.java:758)
> at
org.apache.tomcat.util.net.AprEndpoint.access$200(AprEndpoint.java:81)
> at
org.apache.tomcat.util.net.AprEndpoint$Poller.run(AprEndpoint.java:1338)
> at java.base/java.lang.Thread.run(Thread.java:834)
Anything before that in the logs? I mean ... anything relevant?
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl63KogACgkQHPApP6U8
pFjbuQ/+OZN86zV/0GY0KWYuEABogZi7JIhAOf+OWzyM12f55ka0fdVkO3PeAeQy
yoxqdfvWIswgghNFkXivr3gzsjou1rHbSoCHEDJdBHxU/iuz5BxWjrJcibX2Bejh
OKFNwvp3mq9lxSM/hActSATxXRJJ9p8CPph5qsjaFPmVB4Xnl6rn3295/rJ00kJ/
og4M7RfD4zaftcV9qWyqHTxgJ1xxYIr32Qmh6dVoL6nn/K0uiQeXIBseJAV8wZvs
7QBr3cAq+MSkGacP+64zAVYld/w0wpQt3a2+FiQbT1dNzUxoYG6B0SbJtHbda9on
rT00MSTY1aNxZvc/h+zjuOdd9YmeM7iyeOfHkHymFtmZY/TnJv0Y9mQoA+8u5W9o
/cFR69s1nRKqwLyEQss6MqeaDMbXPiycrz2xPJqqCr7SyzfmNetpOnBvyDuGRZuS
U+rSDopVvFkyugm9HvoJkhCMqBTWaUZ53kwYuQysgObfJZTITuht+iOcidjRQZPC
5sM2dhUpgx6g0ClX6rVUlBzBEJneG/c0pRhA4nNcd90ymQkirti+du9DdLLVy6Sq
UYOYOq2HJk0qQhOEDXjDI/Kx5S4KbaWLxIQH4131kS3QSA7rw123DRRH58fmFQrM
7m1felpLgCscMJqRkMOAr4o54yw7kUteq98hoMCL8s+E06KDiGs=
=dWlU
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: APR connector questions
We want to use APR to call openssl also do with native to support FIPS mode in tomcat. Software info Tomcat/9.0.34 libtcnative-1-0-1.2.23-15.30.x86_64 configuration as below: When enable debug info in tomcat will see 09-May-2020 00:51:35.358 FINE [https-openssl-apr-8443-exec-1] org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper.doClose Calling [org.apache.tomcat.util.net.AprEndpoint@4275c20c].closeSocket([org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper@1efb5c3e:139622944367568]) 09-May-2020 00:51:35.367 FINE [https-openssl-apr-8443-Poller] org.apache.tomcat.util.net.AprEndpoint$Poller.removeFromPoller Attempting to remove [139,622,944,367,568] from poller 09-May-2020 00:51:35.367 FINER [https-openssl-apr-8443-Poller] org.apache.tomcat.util.net.AprEndpoint.destroySocketInternal Destroying socket [139,622,944,367,568] java.lang.Exception at org.apache.tomcat.util.net.AprEndpoint.destroySocketInternal(AprEndpoint.java:758) at org.apache.tomcat.util.net.AprEndpoint.access$200(AprEndpoint.java:81) at org.apache.tomcat.util.net.AprEndpoint$Poller.run(AprEndpoint.java:1338) at java.base/java.lang.Thread.run(Thread.java:834) BRs Dan -Original Message- From: Christopher Schultz Sent: Friday, May 8, 2020 10:37 PM To: users@tomcat.apache.org Subject: Re: APR connector questions -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel, On 5/8/20 04:25, daniel@dell.com wrote: > We are changing from Nio connector to APR connector to enable FIPS > mode in tomcat. But we hit tomcat hang issue, ssl handshake no > response when run long time. So many close_wait in netstat output. > Do you have any advises about that issue? Can you please post your configuration? Remember to remove any secrets that may be in there. You may be interested to know that FIPS is available through Java, though not through Sun's JSSE provider. https://stackoverflow.com/questions/5046482/which-jce-providers-are-fips - -140-2-compliant You may also be interested in the fact that FIPS mode doesn't really offer any additional security. In certain cases, it may reduce your security because of the various required-supported algorithms which, honestly, should never be used in production. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl61bnAACgkQHPApP6U8 pFjf2Q/+K/kHIF36pSJ3gzU1gkrRnmDOqLtNX4rAzJVguZrOqSDjVNyFjYlYPcDD A9szjfgdwd8PlTdgXJISpvdSqdvjGSadKbNswcN731VDptMlUz979R54+kRHeoWU lYdwZuNp/ACj+UXJnSDcxK0Q15UewlRLuTrtpFfoCkteS1uAXAH1OMStsZYFXrSt Jc3XmrmidTfAl8P24W8xNFxCTDPhkcnO7nJaNPKlGwdtjtxVfOaxyK9UtoKJW+te lANt3Fi8r5QlLbZIofK9A0BTyHsk17SmUseeETDPCUcqlEZ1z8KWN6NVlLl0O4Rk P/i3JUrsD8ZuCMghj1Jw6s4B4aWolLoSvxFYGLmNitqGNPGQnuUid5RV6LWLW7nH kMFDE6yGXHagZ/34GIWcPVJOmcobOdFGtGXb4SWRsf9xOU8U5g2ljpSIYA0xT4J+ lCWZLxkcxW0YdppfPWU7t7uKO8GPnCjBmBUgx7fSHRvNefrgof6CRSAjyKlMsU1w WSW8ZPblXSBToHy98JoT27wTrYUkhfDGzCDopkMxGH4QZZtvIVH+MNsBpWUWMhMc h/yo2ubKWwsrmPBhkd+Jjkon3FGsuBRpUdNQJx0+5G5CKGuDNFIIZYV5MDK0ovCu wmBN/6ZSwUj7ZqpOFekGHhM4DUee8R0kXmScDXd1nogkoIGIO20= =JFpT -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: APR connector questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel, On 5/8/20 04:25, daniel@dell.com wrote: > We are changing from Nio connector to APR connector to enable FIPS > mode in tomcat. But we hit tomcat hang issue, ssl handshake no > response when run long time. So many close_wait in netstat output. > Do you have any advises about that issue? Can you please post your configuration? Remember to remove any secrets that may be in there. You may be interested to know that FIPS is available through Java, though not through Sun's JSSE provider. https://stackoverflow.com/questions/5046482/which-jce-providers-are-fips - -140-2-compliant You may also be interested in the fact that FIPS mode doesn't really offer any additional security. In certain cases, it may reduce your security because of the various required-supported algorithms which, honestly, should never be used in production. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl61bnAACgkQHPApP6U8 pFjf2Q/+K/kHIF36pSJ3gzU1gkrRnmDOqLtNX4rAzJVguZrOqSDjVNyFjYlYPcDD A9szjfgdwd8PlTdgXJISpvdSqdvjGSadKbNswcN731VDptMlUz979R54+kRHeoWU lYdwZuNp/ACj+UXJnSDcxK0Q15UewlRLuTrtpFfoCkteS1uAXAH1OMStsZYFXrSt Jc3XmrmidTfAl8P24W8xNFxCTDPhkcnO7nJaNPKlGwdtjtxVfOaxyK9UtoKJW+te lANt3Fi8r5QlLbZIofK9A0BTyHsk17SmUseeETDPCUcqlEZ1z8KWN6NVlLl0O4Rk P/i3JUrsD8ZuCMghj1Jw6s4B4aWolLoSvxFYGLmNitqGNPGQnuUid5RV6LWLW7nH kMFDE6yGXHagZ/34GIWcPVJOmcobOdFGtGXb4SWRsf9xOU8U5g2ljpSIYA0xT4J+ lCWZLxkcxW0YdppfPWU7t7uKO8GPnCjBmBUgx7fSHRvNefrgof6CRSAjyKlMsU1w WSW8ZPblXSBToHy98JoT27wTrYUkhfDGzCDopkMxGH4QZZtvIVH+MNsBpWUWMhMc h/yo2ubKWwsrmPBhkd+Jjkon3FGsuBRpUdNQJx0+5G5CKGuDNFIIZYV5MDK0ovCu wmBN/6ZSwUj7ZqpOFekGHhM4DUee8R0kXmScDXd1nogkoIGIO20= =JFpT -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: APR connector questions
Dear experts: Nowadays, we are changing from Nio connector to APR connector to enable FIPS mode in tomcat. But we hit tomcat hang issue, ssl handshake no response when run long time. So many close_wait in netstat output. Do you have any advises about that issue? BRs Dan
Re: APR Connector questions
Ok, thanks for the advice. If it means removing one more layer of complexity, I'm all for it. Best, Alec On Fri, Sep 20, 2013 at 11:57 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Alec, On 9/20/13 2:03 PM, Tomcat Random wrote: Chris, Thanks for correcting the misdirected reply. Do you mean it's not working under load, or you haven't yet tried it under load? I mean I haven't tested it under load yet. One of the main reasons for choosing APR is is that I was under the impression it's good at serving large static files. My site has some large swf files - one is ~8mb (it's a game site). The docs on APR say, When APR is enabled, the HTTP connector will use sendfile for handling large static files (all such files will be sent asynchronously using high performance kernel level calls), and will use a socket poller for keepalive, increasing scalability of the server. The NIO connector also supports sendfile, and avoids blocking I/O for keepalives. Your recommendation is NIO is comparable to APR in non-ssl performance (as above for large static files) and more stable, and it would be better to switch to that? I'm suggesting that NIO might be a comparable choice to APR with the added benefit of removing some complexity (that of installing a native library) to your deployment. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSPRk7AAoJEBzwKT+lPKRYv5oP/1JZhzlnNfhPI7LLPJKegf5T Nk1Hd5DDPLoa58ihhnntQ0le0dOK6x+6LcktoIr1qvP9q2IiBupwF2HRnW4okW9O Db3p4vr0/9IioRPCkHpEcG6J+JR0L93SEDucqFpLQCAaR6x9Yc/ziGqO241sPhJD 5BmEBPBi+Kl+OD+UNhrMpyzNKf/zdmzjJu7oMl97DS6kNmx6gf2rvEwBS2Iec6xV NgfzqQ/6faSIsFv5AseHIXmYkZcifyegUYemQt+ZtNs7z9C0rx7Gd1Hh6ls2mjlG WD4Y2yILg8WouDZXJXEhGU5Pq65iVCoYPTWTF4tvJS0aU4AYVx5opiSZNeZy6vGl UAsX7lpTDgQ/VXfEOHmslvZsHorkOnh6z9CcVDtjcZYf+mFouGy3CXJROTcUizJg pzwghiT4jX9xcUWaf13CjuqBMo5SwsSqkkf4HY2vFDBDfn70bIG8k+FdjjTjKjv1 hZwkGc4Ysc0h0b2vKCYgI78fwydDvdnoNEJ50IONP6coxo4fSdaFCaFCQ/gXKVLG puMVkbE5WAkgxFBcM0zms5U9oqAQ2ZnwlGMB6tM1/GvnIQYgAiqqDVgEwm/wbWct XYxPIHakMXtJZRPY5lECQzmbHMZX4HnJ/si53lKQ2JeT79JC+Pesox0fNobU2eD1 K5Wu5Y96NL5F+Frl3wOE =9/4N -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: APR Connector questions
Chris, Thanks for correcting the misdirected reply. Do you mean it's not working under load, or you haven't yet tried it under load? I mean I haven't tested it under load yet. One of the main reasons for choosing APR is is that I was under the impression it's good at serving large static files. My site has some large swf files - one is ~8mb (it's a game site). The docs on APR say, When APR is enabled, the HTTP connector will use sendfile for handling large static files (all such files will be sent asynchronously using high performance kernel level calls), and will use a socket poller for keepalive, increasing scalability of the server. Your recommendation is NIO is comparable to APR in non-ssl performance (as above for large static files) and more stable, and it would be better to switch to that? Thanks again, Alec On Thu, Sep 19, 2013 at 1:56 PM, Jeffrey Janner jeffrey.jan...@polydyne.com wrote: -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, September 19, 2013 12:38 PM To: Tomcat Users List Cc: Tomcat Random Subject: Re: APR Connector questions -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Alec, Please keep discussions on the mailing lists so others can benefit from them. On 9/19/13 12:01 PM, Tomcat Random wrote: The answer for am I going to be using SSL is maybe. It's not mandatory, but would be nice for an admin area of the site. I already built the tcnative stuff and APR is working, but not under load. Do you mean it's not working under load, or you haven't yet tried it under load? I'm using APR because it was my understanding there was a big performance increase when using Tomcat without a proxy/web server in front of it. I just have Tomcat with my IP tables redirecting 80-8080. APR and NIO performance are comparably to each other, SSL excepted. If you are talking about using SSL only for admin access (which is usually fairly limited in scope/traffic), then I wouldn't worry about the performance difference. One could argue that any site that requires login should be 100% SSL- protected, but I know nothing about your requirements. +1 2500 users might not require 2500- simultaneous connections. True, and it occurs to me, sort of noobishly, where would you look for reporting simultaneous connections? You can use JMX to get lots of information about the connectors. You'll have to probe periodically and build-up a trend graph to understand your actual traffic. http://wiki.apache.org/tomcat/FAQ/Monitoring And once you know that number, back to my original question, how many maxthreads/acceptCounts? The acceptCount is just the TCP backlog. Setting this higher than the default is only helpful if you have huge transaction volume bursts and your transactions are fairly short. If you can't handle 200 transactions waiting in the TCP accept queue pretty quickly, it's not going to help to raise that number to 1000. If you experience huge bursts of traffic that your app can handle with a short delay -- AND if you absolutely don't want to give any clients connection refused errors -- then raising the acceptCount is appropriate. I haven't seen a normal webapp that has ever required changing from the default, but my experience may not match the type of business you are in. As for maxThreads, that depends upon your load, the type of hardware you have, the length of your transactions, and the CPU load you expect will be required for your webapp. If your webapp is fairly CPU-bound (which I've found to be fairly rare) and you have a limited number of physical CPUs, raising the maxThreads limit buys you nothing: it may be worse than lowering it because you just end up running many threads at once and thrash the CPU. If you have a primarily I/O-bound app (most that I've seen... e.g. stuff that uses back-end databases for most requests) than raising the maxThreads can serve more requests... but then remember that your database must be able to handle the load as well. Having 1000 worker threads with a DB connection pool of size=10 means lots of waiting threads. Just how rare are the APR catastrophes? I don't have much data on frequency of occurrences just what I can see in BZ for the Tomcat Connectors project. Let's just say that over the past 8 or so years, I've yet to have it happen to me, and I am supporting dozens of Tomcat instances across a half-dozen systems with each Tomcat having 5 or 6 hosts each. Then again, I'm running under Windows and the tcnative is built for me by the good guys on the Tomcat Dev Team. Is it something a tomcat restart can fix? You don't have a choice: the JVM goes down immediately and you *must* restart Tomcat. That's what I meant by catastrophic. Yes, unfortunately, anything that causes a crash at the native code level
Re: APR Connector questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Alec, On 9/20/13 2:03 PM, Tomcat Random wrote: Chris, Thanks for correcting the misdirected reply. Do you mean it's not working under load, or you haven't yet tried it under load? I mean I haven't tested it under load yet. One of the main reasons for choosing APR is is that I was under the impression it's good at serving large static files. My site has some large swf files - one is ~8mb (it's a game site). The docs on APR say, When APR is enabled, the HTTP connector will use sendfile for handling large static files (all such files will be sent asynchronously using high performance kernel level calls), and will use a socket poller for keepalive, increasing scalability of the server. The NIO connector also supports sendfile, and avoids blocking I/O for keepalives. Your recommendation is NIO is comparable to APR in non-ssl performance (as above for large static files) and more stable, and it would be better to switch to that? I'm suggesting that NIO might be a comparable choice to APR with the added benefit of removing some complexity (that of installing a native library) to your deployment. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSPRk7AAoJEBzwKT+lPKRYv5oP/1JZhzlnNfhPI7LLPJKegf5T Nk1Hd5DDPLoa58ihhnntQ0le0dOK6x+6LcktoIr1qvP9q2IiBupwF2HRnW4okW9O Db3p4vr0/9IioRPCkHpEcG6J+JR0L93SEDucqFpLQCAaR6x9Yc/ziGqO241sPhJD 5BmEBPBi+Kl+OD+UNhrMpyzNKf/zdmzjJu7oMl97DS6kNmx6gf2rvEwBS2Iec6xV NgfzqQ/6faSIsFv5AseHIXmYkZcifyegUYemQt+ZtNs7z9C0rx7Gd1Hh6ls2mjlG WD4Y2yILg8WouDZXJXEhGU5Pq65iVCoYPTWTF4tvJS0aU4AYVx5opiSZNeZy6vGl UAsX7lpTDgQ/VXfEOHmslvZsHorkOnh6z9CcVDtjcZYf+mFouGy3CXJROTcUizJg pzwghiT4jX9xcUWaf13CjuqBMo5SwsSqkkf4HY2vFDBDfn70bIG8k+FdjjTjKjv1 hZwkGc4Ysc0h0b2vKCYgI78fwydDvdnoNEJ50IONP6coxo4fSdaFCaFCQ/gXKVLG puMVkbE5WAkgxFBcM0zms5U9oqAQ2ZnwlGMB6tM1/GvnIQYgAiqqDVgEwm/wbWct XYxPIHakMXtJZRPY5lECQzmbHMZX4HnJ/si53lKQ2JeT79JC+Pesox0fNobU2eD1 K5Wu5Y96NL5F+Frl3wOE =9/4N -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: APR Connector questions (was: ARP Connector questions)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Alec, Changed subject: it's APR (Apache Portable Runtime), not ARP (which is something different). On 9/19/13 11:39 AM, Tomcat Random wrote: Tomcat 7.0.42, RHEL6 I've installed the APR connector and have my service.xml configured with the only enabled connector being: !--APR connector native installed -- Connector port=8080 maxHttpHeaderSize=8192 maxThreads=150 enableLookups=false disableUploadTimeout=true acceptCount=100 scheme=http secure=false SSLEnabled=false/ 1. I'm expecting about 2500 simultaneous visitors. Any thoughts on how much I might want to bump up the maxThreads and acceptCount? The better question is how many simultaneous /requests/ you expect. 2500 users might not require 2500- simultaneous connections. 2. Does the APR connector work within the Executor thread pools? I'm a little unclear on this. Currently the Executor node is commented out. Do I want a shared executor for the ARP connector? Yes, you can use an executor. If you don't specify one, a Connector will create a default Executor for itself. If you expect to have multiple connectors and you want them all to share a pool of worker threads, then you'll want to configure a single Executor and then reference that from each of your Connectors. Are you going to be using SSL? If not, you might have slightly better luck with the NIO connector (APR/OpenSSL has a performance advantage over JSSE), plus you won't have to build and babysit tcnative, etc. Problems that occur at the NIO level will likely throw exceptions while APR can bring-down the whole JVM. It's rare, but when it happens, it's catastrophic. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSOxwzAAoJEBzwKT+lPKRY2M8QAMqvN5KpOzmhBJbSlzQ770tr xP8WiIrtloormFI9+XpT6ZJ2c1v5fx/MjlhSjhXKQd6M54pC9MKIXmM4zrpaOtPh 6amiRh7dNJXnYsUXKylw5O8lI4frsxbCnBS5wtXL1zywXL7uXbj37w4GbEzaYkql 5hL7z65/pBIhk9QTCfeUE7gvk1MQNMhkfDgGEHanWmwH3rCBucNjF7O8aUn8OlZy 3guTpvfo2TpPiSA6tpEgTliqR7ZTg19KN8flXtiN1+M/L+OGips1ihOPRYxj4Osc A51pltqdEyv1cSR3oVyb4xYXCYHjO0kxoDNIpDr+HZp4Xw7bdb+VvXZamyffvOyP dgs8zRRGsmKpVaPXnKcjdhNlbtCGKppQFuMeYxz975/dVxpHXcr3xmPKg33H31Jd OnrYvyTjxeP6Y/cj1AYUZYwr+yzg3FBPv8S/O2POy1eZDTPVwr0uKfIlNYl6bzrr PiEizoq/UYuIK+wst9NZsztAIf70VWmCbN1lW5oz090tXR0yU2xxdFhh3P7yUV/j LxvQqGshX5uHW1sySGeznluof9t/RPd1938Sx0ML94EHmi+U7Mb+Y7u+jxy4skxT m58Q3vxTYZrv78ayEfXP7KTdDXGItNwVwbILMpLopQ6oJe0N7ay8bbO5tj29/aR4 oOuFKKtVOXjWpZ+nC1Om =AjzT -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: APR Connector questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Alec, Please keep discussions on the mailing lists so others can benefit from them. On 9/19/13 12:01 PM, Tomcat Random wrote: The answer for am I going to be using SSL is maybe. It's not mandatory, but would be nice for an admin area of the site. I already built the tcnative stuff and APR is working, but not under load. Do you mean it's not working under load, or you haven't yet tried it under load? I'm using APR because it was my understanding there was a big performance increase when using Tomcat without a proxy/web server in front of it. I just have Tomcat with my IP tables redirecting 80-8080. APR and NIO performance are comparably to each other, SSL excepted. If you are talking about using SSL only for admin access (which is usually fairly limited in scope/traffic), then I wouldn't worry about the performance difference. One could argue that any site that requires login should be 100% SSL-protected, but I know nothing about your requirements. 2500 users might not require 2500- simultaneous connections. True, and it occurs to me, sort of noobishly, where would you look for reporting simultaneous connections? You can use JMX to get lots of information about the connectors. You'll have to probe periodically and build-up a trend graph to understand your actual traffic. http://wiki.apache.org/tomcat/FAQ/Monitoring And once you know that number, back to my original question, how many maxthreads/acceptCounts? The acceptCount is just the TCP backlog. Setting this higher than the default is only helpful if you have huge transaction volume bursts and your transactions are fairly short. If you can't handle 200 transactions waiting in the TCP accept queue pretty quickly, it's not going to help to raise that number to 1000. If you experience huge bursts of traffic that your app can handle with a short delay -- AND if you absolutely don't want to give any clients connection refused errors -- then raising the acceptCount is appropriate. I haven't seen a normal webapp that has ever required changing from the default, but my experience may not match the type of business you are in. As for maxThreads, that depends upon your load, the type of hardware you have, the length of your transactions, and the CPU load you expect will be required for your webapp. If your webapp is fairly CPU-bound (which I've found to be fairly rare) and you have a limited number of physical CPUs, raising the maxThreads limit buys you nothing: it may be worse than lowering it because you just end up running many threads at once and thrash the CPU. If you have a primarily I/O-bound app (most that I've seen... e.g. stuff that uses back-end databases for most requests) than raising the maxThreads can serve more requests... but then remember that your database must be able to handle the load as well. Having 1000 worker threads with a DB connection pool of size=10 means lots of waiting threads. Just how rare are the APR catastrophes? I don't have much data on frequency of occurrences just what I can see in BZ for the Tomcat Connectors project. Is it something a tomcat restart can fix? You don't have a choice: the JVM goes down immediately and you *must* restart Tomcat. That's what I meant by catastrophic. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSOzZ/AAoJEBzwKT+lPKRYL+0QAKMQIlr2crCQ35nbop8BvSGl GpxfNiVhmNdVLwzNIp68xoQQhpYHMcg/ukFLjwaGG6AORlxf39PLFizd0TMKJNtO EK2ZCRq6X4WXIwTPIaCb0ovbVp3HxIXPs+VxPVaDcxiHSCQN0FoaQFgP35E91rDR ymgATcj+XXbc8rH5DyRMSPExbzO/5SeBWM65uQLfa2iA/qLCFq8NsrZgvi6QxZjR O9JX+hWogL1nTPmgyyyXqY1YtIzTpB7F35itCCcccAkbmt4YePb7joQ4pPPX2jvT aAggfHg9YUWoUuRA4IwCRRBkZiWSc8vkQhwV6vBN7Bw7/pK7x0SmwsBtBeZFkYa2 kxP8BOAVbsZu7ahnqGVIY17ul8FF4lslfRWN2YY4qqNdShUXkcTMiOoQcCU8Y4FL zPgmIlqUQ2KRP8F9+9/66RCMCv+RS4bxo6Aq+IeEoz0B7peWVLDMLORNc5D6Y2s8 P/0ImtczB/wvEPdKpRVqB2uuDJfOBUD0vFGv3/TH8WXHIJyIiwK+Up3vtFlAEJjm DLgO7W18mmEum81hrfvt4JXFFCV9kqHhVpFHXXDcARL4qEwp4fI2DaEitj1e5fGk FIIA/EIx3gU0vjy3yjqccO9WjvHkbotgrJuWgrdPz25VA5ceGqqUaSWxKP4mEooy nZAhl1oF5Glv3rIyNkjN =7erg -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: APR Connector questions
-Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, September 19, 2013 12:38 PM To: Tomcat Users List Cc: Tomcat Random Subject: Re: APR Connector questions -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Alec, Please keep discussions on the mailing lists so others can benefit from them. On 9/19/13 12:01 PM, Tomcat Random wrote: The answer for am I going to be using SSL is maybe. It's not mandatory, but would be nice for an admin area of the site. I already built the tcnative stuff and APR is working, but not under load. Do you mean it's not working under load, or you haven't yet tried it under load? I'm using APR because it was my understanding there was a big performance increase when using Tomcat without a proxy/web server in front of it. I just have Tomcat with my IP tables redirecting 80-8080. APR and NIO performance are comparably to each other, SSL excepted. If you are talking about using SSL only for admin access (which is usually fairly limited in scope/traffic), then I wouldn't worry about the performance difference. One could argue that any site that requires login should be 100% SSL- protected, but I know nothing about your requirements. +1 2500 users might not require 2500- simultaneous connections. True, and it occurs to me, sort of noobishly, where would you look for reporting simultaneous connections? You can use JMX to get lots of information about the connectors. You'll have to probe periodically and build-up a trend graph to understand your actual traffic. http://wiki.apache.org/tomcat/FAQ/Monitoring And once you know that number, back to my original question, how many maxthreads/acceptCounts? The acceptCount is just the TCP backlog. Setting this higher than the default is only helpful if you have huge transaction volume bursts and your transactions are fairly short. If you can't handle 200 transactions waiting in the TCP accept queue pretty quickly, it's not going to help to raise that number to 1000. If you experience huge bursts of traffic that your app can handle with a short delay -- AND if you absolutely don't want to give any clients connection refused errors -- then raising the acceptCount is appropriate. I haven't seen a normal webapp that has ever required changing from the default, but my experience may not match the type of business you are in. As for maxThreads, that depends upon your load, the type of hardware you have, the length of your transactions, and the CPU load you expect will be required for your webapp. If your webapp is fairly CPU-bound (which I've found to be fairly rare) and you have a limited number of physical CPUs, raising the maxThreads limit buys you nothing: it may be worse than lowering it because you just end up running many threads at once and thrash the CPU. If you have a primarily I/O-bound app (most that I've seen... e.g. stuff that uses back-end databases for most requests) than raising the maxThreads can serve more requests... but then remember that your database must be able to handle the load as well. Having 1000 worker threads with a DB connection pool of size=10 means lots of waiting threads. Just how rare are the APR catastrophes? I don't have much data on frequency of occurrences just what I can see in BZ for the Tomcat Connectors project. Let's just say that over the past 8 or so years, I've yet to have it happen to me, and I am supporting dozens of Tomcat instances across a half-dozen systems with each Tomcat having 5 or 6 hosts each. Then again, I'm running under Windows and the tcnative is built for me by the good guys on the Tomcat Dev Team. Is it something a tomcat restart can fix? You don't have a choice: the JVM goes down immediately and you *must* restart Tomcat. That's what I meant by catastrophic. Yes, unfortunately, anything that causes a crash at the native code level is going to stop everything. A restart may not fix the problem, but you can usually at least recover to a normal state for a time. At least until whatever specific circumstances that caused the crash occur again. Jeff - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
