Optimizing Netty for fast socket accept/creation

[Bo Hu]

I read an article from the author of Grizzly, about using slave selectors to
load balance OP_ACCEPT and OP_READ.
http://weblogs.java.net/blog/jfarcand/archive/2006/07/tricks_and_tips_4.html

Maybe Netty can use the same technology in the future release. I'm still
learning Netty, please forgive me if I'm wrong.

2009/7/7 Carl Byström <cgbystrom at gmail.com>

> Hi Trustin!
>
> I wouldn't call it bad performance, it's just that I need more performance
> :)
> While it's understandable to use one accept (boss thread) for accepting
> connections, I can't help thinking if things could be improved with multiple
> accept threads.
> When using the forking model in Unix and forking after you start listening
> on your port you can get the effect of having multiple processes listening
> on the same socket (file descriptor).
> However, the JVM is inherently single-process so achieving the same thing
> there is harder (impossible?). Maybe there are some OS-specific "hacks" that
> can be used? Relying on certain behaviors, such as fork/accept in Unix etc.
> Also, I know that combining these things with epoll can be tricky. Have had
> some problems with Python with epoll + multiple accept processes.
>
> Think I'll resort to listening on multiple ports (if nothing else comes
> along) to achieve a better socket open/close performance.
> Been using 3.1.0.CR1 for my tests.
>
> - Carl
>
>
>
> On Mon, Jul 6, 2009 at 8:59 AM, "이희승 (Trustin Lee)" <trustin at gmail.com>wrote:
>
>> Hi Carl,
>>
>> Sorry for the late response first of all.
>>
>> On 06/30/2009 11:05 PM, Carl Byström wrote:
>> > Been experimenting some with Netty the last couple of days. As an avid
>> > MINA fan, Netty looks great!
>>
>> Thanks! :)
>>
>> > What's been bothering is the "slow" socket accept, which limits the
>> > throughput of my application. (Request/response based ála HTTP 1.0, so
>> > no keep-alive).
>> > (The socket accept operation isn't "slow", I just feel that it could be
>> > improved thus increasing my throughput)
>> >
>> > After profiling my application I found that accept is taking up most of
>> > the time. While this probably is as expected, I can't help feeling
>> > limited by that fact.
>> > I've tried having the same server listening on multiple ports thus
>> > getting a separate boss thread doing the accept. This actually doubles
>> > the number of req/s while retaining the same response time. I realize
>> > this isn't anything peculiar (multi-core machine with another accept
>> > thread for it to chew on). But it gets me thinking if there's more one
>> > can do to optimize this.
>> >
>> > Is it possible to speed up the socket accept operation
>> > a) by tuning Netty?
>> > b) by tuning the JVM?
>> > c) by tuning the OS/kernel?
>> >
>> > While I fear things like this might be very sensitive to how the OS
>> > implements the TCP stack, I hope at least there are some general advice
>> > or places to start looking.
>> > Appreciate any hints or tips regarding this. (Running on RHEL5 64-bit,
>> > Java 1.6.0_10-b33, Intel Quad-Core Q6600)
>>
>> Which Netty version are you using?  Netty uses only one thread for
>> accepting an incoming channel for each port, and it could be why it's
>> not performing good enough.  If you observe the accept performance issue
>> with 3.1.0.CR1, I'd like to fix it before GA.
>>
>> Thanks!
>> Trusitn
>> >
>> > - Carl
>> >
>> >
>> > ------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > netty-users mailing list
>> > netty-users at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/netty-users
>>
>> _______________________________________________
>> netty-users mailing list
>> netty-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/netty-users
>>
>
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/netty-users/attachments/20090707/0da812f2/attachment.html