-----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
