[Repost] Re: A question about your HttpClient example and beyond

Frederic Bregier fredbregier at free.fr
Thu Sep 10 09:45:50 EDT 2009


Hi,
 
I will not talk about the specific Http part of Netty but about its main
interest, the NIO of Netty.
Of course, Trustin or others can be more precised than me. It is just my
general comprehension (I'm not a Nio expert neither a Netty expert, so it is
just my comprehension as an end user).
 
To compare to a standard Blocking IO, Netty uses less threads to manage the
same behaviour.
For instance, if you think about Apache or Tomcat, one connection will be
handled by at least one thread through the full life of the connection. So
if you have 1000 connections, you will have at least 1000 threads.
In Netty, a thread will be active when data arrives into the server (the
general idea is greatly simplified here, it is not to take it as the
reality). For instance, for those 1000 connections, maybe at most 100 are
really sending something on the same time to the server, so around 100
threads will be used. Netty does something like reusing threads, whatever
the connection is.
 
Another point of course is the non blocking way. Once you send something,
you have the choice to continue the job without waiting that the data is
really sent (of course, you have to take care about it for instance before
closing the channel). So you can overlap sending data with other
computations (for instance for next packet to be sent).
Compares to blocking IO, of course, there you wait for the data to be really
sent (or at least buffered).
 
So in many points, Netty approach should have more performance than blocking
IO. I said "should" since there exist some counter examples where blocking
IO are faster, since NIO introduces some extra computing comparing to
blocking IO. However most of the time, these extra are masked by the
implementation of Netty and are quicker than blocking IO. But I recall some
examples however.
 
Also, Netty can have different kind of transport (nio, oio, ...), so the
behaviour can be different according to one or another low network transport
framework.
 
This is not the full idea of Netty, but a start of answer to your question.
For more information, either other people can continue this thread (or
correct where I a wrong), and of course you can read the examples that are
in Netty (even those not about Http) and the documentation of Netty.
 
HTH,
Cheers,
Frederic 

J. Mi wrote:
> 
> Hi all,
> 
> I guess my fundamental question here is if, in theory at least, Netty
> provides a better asynchronous mechanism than the concurrent java package
> from java.util.concurrent.* in terms of performance. Does internally Netty
> use multi-threading, java.nio, or both, or neither?
> 
> If Netty does better than java.util.concurrent.* for performance, is there
> any example, tutorial, which can guide me a little for replacing my
> current
> multi-threading process which I described in that previous email?
> 
> Many thanks to you for sharing your expertise,
> Jason
> 
> On Wed, Sep 2, 2009 at 12:11 PM, J. Mi <jmi258 at gmail.com> wrote:
> 
>> Hi folks,
>>
>> Currently, my application's process flow logic is like this:
>>
>> -> A controlling process receives one request for data which will be
>> fetched from multiple online sources.
>> -> The controlling process spawns multiple threads. Each of these threads
>> will (1) use Apache synchronous commons httpclient to fetch the data; (2)
>> parse the data; and (3)
>>     return the data to the controlling process.
>> -> The controlling process joins all threads and return the combined data
>> to the requestor.
>>
>> So basically, each thread uses a synchronous httpclient to fetch the data
>> and then parse it.
>>
>>  In reading org.jboss.netty.example.http.snoop package, I have the
>> following question:
>> If I just replace the Apache's synchronous httpclient with Nettty's
>> org.jboss.netty.handler.codec.http.* as the example does, will I be
>> benefited performance-wise? I heard something about blocking I/O hurts
>> multi-threading. If so, should Netty's package work better for me?
>>
>> Or should I actually get ride of the existing multi-threading by using
>> Netty's framework? If so, which of your examples can be better referenced
>> for my purpose?
>>
>> Thanks for your in advance,
>> Jason
>>
>>
>>
> 
> _______________________________________________
> netty-dev mailing list
> netty-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-dev
> 
> 


-----
Hardware/Software Architect
-- 
View this message in context: http://n2.nabble.com/A-question-about-your-HttpClient-example-and-beyond-tp3568879p3617420.html
Sent from the Netty Developer Group mailing list archive at Nabble.com.


More information about the netty-dev mailing list