Hi again!<br><br><div class="gmail_quote">On Wed, Jul 8, 2009 at 9:47 AM, "이희승 (Trustin Lee)" <span dir="ltr"><<a href="mailto:trustin@gmail.com">trustin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I increased the number of acceptor threads like the following:<br>
<br>
for (int i = 0; i < 2; i ++) {<br>
bossExecutor.execute(new IoWorkerRunnable(<br>
new ThreadRenamingRunnable(<br>
new Boss(channel),<br>
"New I/O server boss #" + id + '-' + i +<br>
" (channelId: " + channel.getId() +<br>
", " + channel.getLocalAddress() + ')')));<br>
}<br>
</blockquote><div><br>Did I miss something obvious here? But how would I make two threads (processes) bind to the same address?<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
and was indeed able to get much better result. However, increasing the<br>
number of acceptor threads to 3 or 4 did not help much. Do you have the<br>
same experience with your workaround? Could you apply this modification<br>
to see how the modified Netty performs comparing to your workaround?<br><div class="im"></div></blockquote><div><br>Yeah, tried listening on two ports and using the example HTTP server.<br>Ran two tests simultaneously with ApacheBench, yielding the same results in both processes (in terms of req/s and response time).<br>
I essentially doubled the performance by doing this.<br>However, increasing it to 3 ports the response time started dropping. Perhaps have something to do with that accept lock in Java NIO? Another thing worth noticing was that I was unable to saturate my CPUs fully.<br>
Tried this on RHEL5 (8 cores) and Mac OS X (2 cores). <br> <br></div></div>- Carl<br>