You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2011/08/23 22:37:21 UTC
Choosing an AJP Connector
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
All,
I've been using Tomcat fronted by Apache httpd (terminating SSL I
might add) for years and I've never given any thought to which flavor
of AJP connector I've been using. We don't build APR as part of our
standard build process and it's unclear from the docs but I suspect
you don't get NIO unless you specify that you want it.
I guess that means I've been stuck in BIO-ville all this time.
We're looking to upgrade to TC7 soon so I will have 3 options, now.
I'm wondering which one would be best for us.
- From my perspective, the most useful thing you get from both APR and
NIO is the ability to service more simultaneous requests than you
actually have threads, because of their polling capabilities. That
also means that a slow client won't tie-up a thread for a long time.
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.
So, what does either AJP or NIO buy me in an AJP environment?
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?
Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5UD4EACgkQ9CaO5/Lv0PALqgCdFwCB4A5LAEnsXHkxfiGBpcYp
I/UAnjfmzAlqhTq5XMOWY9nOUvrJe4bd
=VQJI
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Choosing an AJP Connector
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark,
On 8/23/2011 4:59 PM, Mark Thomas wrote:
> [The NIO code is ]not really [any less robust]. The code between
> all the connectors is getting more similar as I reduce the
> duplication. That should mean fewer bugs/inconsistencies and
> simpler fixes when a bug is discovered.
I've been seeing all that code merge and it's nice to have it happen.
Thanks for your great (but probably relatively un-rewarding) work in
this area.
> Better to test NIO or APR while you can go back to BIO and get any
> issues fixed now. Easier than waiting until you need NIO or APR to
> find out there is a bug that breaks things for your site.
Sure. Testing with NIO is as simple as changing the protocol
attribute. Can't beat that for plug-and-play configuration.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5UGvYACgkQ9CaO5/Lv0PAIfgCeKXNPZ/B2NqHTYnNs/OtbV48y
EPwAnRuMgeVV6C0zKlQNKzm92Bc6J+3s
=uNY+
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Choosing an AJP Connector
Posted by Mark Thomas <ma...@apache.org>.
On 23/08/2011 21:50, Christopher Schultz wrote:
> 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.
Exactly.
>>> 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.
Not really. The code between all the connectors is getting more similar
as I reduce the duplication. That should mean fewer bugs/inconsistencies
and simpler fixes when a bug is discovered.
Given the monthly release cycle of 7.0.x (assuming it continues) then
any bug that can be reproduced is going to get fixed pretty quickly.
>>> 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.
Better to test NIO or APR while you can go back to BIO and get any
issues fixed now. Easier than waiting until you need NIO or APR to find
out there is a bug that breaks things for your site.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Choosing an AJP Connector
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Choosing an AJP Connector
Posted by Mark Thomas <ma...@apache.org>.
On 23/08/2011 21:37, Christopher Schultz wrote:
> All,
>
> I've been using Tomcat fronted by Apache httpd (terminating SSL I
> might add) for years and I've never given any thought to which
> flavor of AJP connector I've been using. We don't build APR as part
> of our standard build process and it's unclear from the docs but I
> suspect you don't get NIO unless you specify that you want it.
>
> I guess that means I've been stuck in BIO-ville all this time.
>
> We're looking to upgrade to TC7 soon so I will have 3 options,
> now. I'm wondering which one would be best for us.
>
> From my perspective, the most useful thing you get from both APR
> and NIO is the ability to service more simultaneous requests than
> you actually have threads, because of their polling capabilities.
> That also means that a slow client won't tie-up a thread for a long
> time. 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).
> So, what does either AJP or NIO buy me in an AJP environment?
In short, NIO & APR will scale better.
> 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...
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org