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