tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: NIO vs APR vs JIO connectors?
Date Thu, 13 Aug 2009 23:15:55 GMT
On 08/13/2009 09:39 AM, Eric B. wrote:
> Hi,
> I've been trying to read all the threads relating to which connector is
> "best" to use  HTTP (no SSL).  I am planning to use Pound as an HTTP load
> balancer in front of Tomcat as I have no need for all the bells and whistles
> that Apache provides and Pound is fast and light.
> > From what I've been reading through all the threads here is that the JIO
> connector is the oldest and the most stable.  The APR connector is basically
> the same connector that is used in Apache httpd, so using the APR connector
> would, in theory, give me the same performance as though I was using httpd.
> Finally, the NIO is the latest addition to the Tomcat family that gives you
> the benefits of a fully java non-blocking connector, and should perform
> similarly to the APR connector for HTTP but be more sluggish on HTTPS.
> Addtionally, given that NIO is the most recent, it doesn't have as much
> "experience" as APR or JIO.
> That being said, I was leaning towards using the NIO connector for my
> installation.  However, I was pretty surprised and shocked when reading
> "Tomcat - The Definitive Guide 2nd Edition" by Jason Brittain (O'Reilly
> Press), that the JIO was the fastest and most responsive when service small
> text files and 9k images.
> (
> pp.138-148).   In fact, their published benchmarks should that the JIO was
> fastest, followed by APR, followed by NIO.  Could that be attributed to
> configuration parameters for the individual connectors?

nope, but one must have very low level understanding on how different 
connectors work in order to properly tune them and to choose the right 
connector for what situation.
There is also a test where the 9k image and JIO is the slowest one :)


> That seems pretty contrary to everything I've read on this list to date.
> Can anyone shed some light on this descrepancy?
> Thanks!
> Eric
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message