-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark,
On 8/23/2011 4:43 PM, Mark Thomas wrote: > On 23/08/2011 21:37, Christopher Schultz wrote: >> But, since I'm using AJP, there is a one-to-one relationship >> between request processors at the httpd level and in Tomcat, so >> being able to handle "more" requests doesn't sound like it's >> buying me anything. I'm not sure how HTTP keepalives fit into >> all this, but I suspect that mod_jk takes care of this and Tomcat >> has little to no control over any of it. > > Not quite correct. With BIO it is one thread/processor per > connection. With NIO/APR it is one thread per currently processing > request (i.e connections in keep-alive (HTTP or AJP) do not require > a thread or processor). Aah, that's a not-so-subtle detail that I seem to have missed: I can (might be able to) handle more connections from httpd with fewer threads on the Tomcat side. >> So, what does either AJP or NIO buy me in an AJP environment? > > In short, NIO & APR will scale better. Gotcha. Any opinions on APR versus NIO? APR can do more damage if it dies by taking-down the JVM but the NIO connector is less mature and might be (slightly) buggier. >> We have no notable performance problems that do not involve >> obvious application slowness, so BIO has been working fine for >> us. I'm inclined to stick with it unless there are some >> compelling reasons to switch. >> >> Any thoughts? > > If it ain't broke... I'm kinda thinking that way. It's not like I'm having to serve so much traffic that I'm thrashing my threads or anything. On the other hand, it might not be a bad idea to avoid such problems in the future by planning for them, now. Our usage is only increasing over time. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5UEo4ACgkQ9CaO5/Lv0PD+qQCgsYpC+QcnB/EGZ+s+b5JsM/FJ 4k8An37vHuJe1mNkFsco7uBHiJU/VQAk =Wi/m -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
