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