You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Afkham Azeez <af...@gmail.com> on 2011/02/17 15:56:03 UTC
Advantage of using HTTP NIO Connector
Hi folks,
What is the advantage of using this connector as opposed to the default one?
In which scenarios would we tend to use the default connector, and in which
scenarios will it be more appropriate to use the NIO connector?
Thanks
Azeez
*
*
Re: Advantage of using HTTP NIO Connector
Posted by Afkham Azeez <af...@gmail.com>.
Thanks Mark.
On Thu, Feb 17, 2011 at 8:41 PM, Mark Thomas <ma...@apache.org> wrote:
> On 17/02/2011 14:56, Afkham Azeez wrote:
> > Hi folks,
> > What is the advantage of using this connector as opposed to the default
> one?
> > In which scenarios would we tend to use the default connector, and in
> which
> > scenarios will it be more appropriate to use the NIO connector?
>
> NIO and APR use one thread per currently processing request.
> BIO uses one thread per connection. Since usually connections >>
> currently processing request, NIO and APR scale better.
>
> BIO has slightly better raw performance than NIO (excluding sendfile).
>
> APR and NIO support sendfile.
>
> APR has much better SSL performance.
>
> NIO and APR support Comet, BIO does not.
>
> As with anything performance related, YMMV. The only way to be sure is
> to test it.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Advantage of using HTTP NIO Connector
Posted by Mark Thomas <ma...@apache.org>.
On 17/02/2011 16:09, Filip Hanik - Dev Lists wrote:
> On 02/17/2011 08:11 AM, Mark Thomas wrote:
>> On 17/02/2011 14:56, Afkham Azeez wrote:
>>
>>> Hi folks,
>>> What is the advantage of using this connector as opposed to the
>>> default one?
>>> In which scenarios would we tend to use the default connector, and in
>>> which
>>> scenarios will it be more appropriate to use the NIO connector?
>>>
>> NIO and APR use one thread per currently processing request.
>> BIO uses one thread per connection. Since usually connections>>
>> currently processing request, NIO and APR scale better.
>>
>> BIO has slightly better raw performance than NIO (excluding sendfile).
>>
> It used to be only when nr-of-clients<nr-of-threads-in-pool.
> However, in tomcat trunk, BIO can handle keep alive on a large set of
> connections as well.
To a point. The Tomcat 7 BIO connector does scale better than the Tomcat
6 BIO but the NIO connector still has better scalability.
In Tomcat 7 the BIO connector sockets are put in a queue and processed
in turn. Processing includes waiting for data to turn up. Once a request
has been processed, a socket using keep-alive goes to the back of the
queue. It is possible for a socket with data to process to be in the
queue whilst all the threads are sat waiting for data to turn up for
sockets in the keep-alive state.
(Tomcat 6 had no queue - once a thread started processing a socket it
was dedicated to that socket until the socket was closed)
In the NIO connector the poller only passes a socket to a processing
thread when there is data to process.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Advantage of using HTTP NIO Connector
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
On 02/17/2011 08:11 AM, Mark Thomas wrote:
> On 17/02/2011 14:56, Afkham Azeez wrote:
>
>> Hi folks,
>> What is the advantage of using this connector as opposed to the default one?
>> In which scenarios would we tend to use the default connector, and in which
>> scenarios will it be more appropriate to use the NIO connector?
>>
> NIO and APR use one thread per currently processing request.
> BIO uses one thread per connection. Since usually connections>>
> currently processing request, NIO and APR scale better.
>
> BIO has slightly better raw performance than NIO (excluding sendfile).
>
It used to be only when nr-of-clients<nr-of-threads-in-pool.
However, in tomcat trunk, BIO can handle keep alive on a large set of
connections as well.
> APR and NIO support sendfile.
>
> APR has much better SSL performance.
>
NIO supports non blocking SSL handshake, and thus can yield a better
performance.
> NIO and APR support Comet, BIO does not.
>
> As with anything performance related, YMMV. The only way to be sure is
> to test it.
>
There is a test to make each and every connector perform better. So as
Mark said, the use case you're dealing with will determine what
connector you use.
If the application uses a lot of async javascript, then a non blocking
connector may be preferred.
Filip
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Advantage of using HTTP NIO Connector
Posted by Mark Thomas <ma...@apache.org>.
On 17/02/2011 14:56, Afkham Azeez wrote:
> Hi folks,
> What is the advantage of using this connector as opposed to the default one?
> In which scenarios would we tend to use the default connector, and in which
> scenarios will it be more appropriate to use the NIO connector?
NIO and APR use one thread per currently processing request.
BIO uses one thread per connection. Since usually connections >>
currently processing request, NIO and APR scale better.
BIO has slightly better raw performance than NIO (excluding sendfile).
APR and NIO support sendfile.
APR has much better SSL performance.
NIO and APR support Comet, BIO does not.
As with anything performance related, YMMV. The only way to be sure is
to test it.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org