tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Choosing an AJP Connector
Date Tue, 23 Aug 2011 20:50:22 GMT
Hash: SHA1


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.


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
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message