<div>Thanks to Frederic for the overview. It's very helpful for me.</div>
<div> </div>
<div>I have come up with an approach to replace my multi-thread model with Netty's HttpClient. It's pretty much based on the snoop example. I just added 3 loops to achieve the concurrency (multiple http requests at the same time). The first loop was around the call to bootstrap.connect(new InetSocketAddress(host, port)). The second loop was waiting for each connection attempt to succeed and then send the request. The third loop was using the handler to retrieve each http response by using a LinkedBlockingQueue. I used ArrayList to maintain a list for ChannelFuture, a list for Channel and a list for HttpResponseHandler among these 3 loops.</div>
<div> </div>
<div>Everything worked well for me with the approach. However, my test result didn't seem to show this approach out-perform my multi-thread model, i.e. one thread (java.util.concurrent) for each http request which was done by Apache Commons HttpClient (a synchronous model). My performance was measured by timing the total time spent in making n http requests and retrieving this n http responses end-to-end.</div>
<div> </div>
<div>With requests below 50, the multi-thread model performed a little better. I was hoping Netty's way can catch up for better scaling because I was concerned about the current muti-thread model may not scale well when getting hundreds requests at the same time. But I still failed to observe any increased performance relative to the multi-thread model beyond serving 50, 100, 200...800 concurrent requests.</div>
<div> </div>
<div>One thing I need to understand more (Frederic already touched some basics here) is about the connection management. I felt that Apache Commons HttpClient seemed to manage the connection with possible reuse. Not exactly sure about how Netty does that.</div>
<div> </div>
<div>One more question about Netty's HttpClient. In its HttpResponseHandler.java, messageReceived() method only receives a portion of response at a time and has a dependence on server's responding with "chunked' Transfer-Encoding header and content for an end of response condition. This raised 2 questions: (1) is there a way to receive response in one shot, like Apache's HttpClient; and (2) do all Http server required to respond with "chunked" content? In my case, I need to retrieve online responses from different web sites.</div>
<div> </div>
<div>Cheers,</div>
<div>Jason</div>
<div><br><br> </div>
<div class="gmail_quote">On Thu, Sep 10, 2009 at 6:45 AM, Frederic Bregier <span dir="ltr"><<a href="mailto:fredbregier@free.fr">fredbregier@free.fr</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote"><br>Hi,<br><br>I will not talk about the specific Http part of Netty but about its main<br>interest, the NIO of Netty.<br>
Of course, Trustin or others can be more precised than me. It is just my<br>general comprehension (I'm not a Nio expert neither a Netty expert, so it is<br>just my comprehension as an end user).<br><br>To compare to a standard Blocking IO, Netty uses less threads to manage the<br>
same behaviour.<br>For instance, if you think about Apache or Tomcat, one connection will be<br>handled by at least one thread through the full life of the connection. So<br>if you have 1000 connections, you will have at least 1000 threads.<br>
In Netty, a thread will be active when data arrives into the server (the<br>general idea is greatly simplified here, it is not to take it as the<br>reality). For instance, for those 1000 connections, maybe at most 100 are<br>
really sending something on the same time to the server, so around 100<br>threads will be used. Netty does something like reusing threads, whatever<br>the connection is.<br><br>Another point of course is the non blocking way. Once you send something,<br>
you have the choice to continue the job without waiting that the data is<br>really sent (of course, you have to take care about it for instance before<br>closing the channel). So you can overlap sending data with other<br>
computations (for instance for next packet to be sent).<br>Compares to blocking IO, of course, there you wait for the data to be really<br>sent (or at least buffered).<br><br>So in many points, Netty approach should have more performance than blocking<br>
IO. I said "should" since there exist some counter examples where blocking<br>IO are faster, since NIO introduces some extra computing comparing to<br>blocking IO. However most of the time, these extra are masked by the<br>
implementation of Netty and are quicker than blocking IO. But I recall some<br>examples however.<br><br>Also, Netty can have different kind of transport (nio, oio, ...), so the<br>behaviour can be different according to one or another low network transport<br>
framework.<br><br>This is not the full idea of Netty, but a start of answer to your question.<br>For more information, either other people can continue this thread (or<br>correct where I a wrong), and of course you can read the examples that are<br>
in Netty (even those not about Http) and the documentation of Netty.<br><br>HTH,<br>Cheers,<br>Frederic<br>
<div>
<div></div>
<div class="h5"><br>J. Mi wrote:<br>><br>> Hi all,<br>><br>> I guess my fundamental question here is if, in theory at least, Netty<br>> provides a better asynchronous mechanism than the concurrent java package<br>
> from java.util.concurrent.* in terms of performance. Does internally Netty<br>> use multi-threading, java.nio, or both, or neither?<br>><br>> If Netty does better than java.util.concurrent.* for performance, is there<br>
> any example, tutorial, which can guide me a little for replacing my<br>> current<br>> multi-threading process which I described in that previous email?<br>><br>> Many thanks to you for sharing your expertise,<br>
> Jason<br>><br>> On Wed, Sep 2, 2009 at 12:11 PM, J. Mi <<a href="mailto:jmi258@gmail.com">jmi258@gmail.com</a>> wrote:<br>><br>>> Hi folks,<br>>><br>>> Currently, my application's process flow logic is like this:<br>
>><br>>> -> A controlling process receives one request for data which will be<br>>> fetched from multiple online sources.<br>>> -> The controlling process spawns multiple threads. Each of these threads<br>
>> will (1) use Apache synchronous commons httpclient to fetch the data; (2)<br>>> parse the data; and (3)<br>>> return the data to the controlling process.<br>>> -> The controlling process joins all threads and return the combined data<br>
>> to the requestor.<br>>><br>>> So basically, each thread uses a synchronous httpclient to fetch the data<br>>> and then parse it.<br>>><br>>> In reading org.jboss.netty.example.http.snoop package, I have the<br>
>> following question:<br>>> If I just replace the Apache's synchronous httpclient with Nettty's<br>>> org.jboss.netty.handler.codec.http.* as the example does, will I be<br>>> benefited performance-wise? I heard something about blocking I/O hurts<br>
>> multi-threading. If so, should Netty's package work better for me?<br>>><br>>> Or should I actually get ride of the existing multi-threading by using<br>>> Netty's framework? If so, which of your examples can be better referenced<br>
>> for my purpose?<br>>><br>>> Thanks for your in advance,<br>>> Jason<br>>><br>>><br>>><br>><br></div></div>> _______________________________________________<br>> netty-dev mailing list<br>
> <a href="mailto:netty-dev@lists.jboss.org">netty-dev@lists.jboss.org</a><br>> <a href="https://lists.jboss.org/mailman/listinfo/netty-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/netty-dev</a><br>
><br>><br><br><br>-----<br>Hardware/Software Architect<br><font color="#888888">--<br>View this message in context: <a href="http://n2.nabble.com/A-question-about-your-HttpClient-example-and-beyond-tp3568879p3617420.html" target="_blank">http://n2.nabble.com/A-question-about-your-HttpClient-example-and-beyond-tp3568879p3617420.html</a><br>
Sent from the Netty Developer Group mailing list archive at Nabble.com.<br>_______________________________________________<br>netty-dev mailing list<br><a href="mailto:netty-dev@lists.jboss.org">netty-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/netty-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/netty-dev</a><br></font></blockquote></div><br>