question about performance of FrameDecoder and ChannelBuffer

Trustin Lee tlee at redhat.com
Fri Nov 21 02:31:21 EST 2008


Hi Christian,

On Thu, Nov 20, 2008 at 06:38:35PM +0900, Christian Migowski wrote:
> Hi,
> 
> I want to implement a protocol decoder with Netty for a protocol that
> hasn't fixed length nor fixed delimiter delimited messages (until I
> look at it that is: XML fragments).
> I think I am going to use the FrameDecoder for this, what do you think
> is the most efficient approach with Netty:
> - in the decode(...) method, should I:
> 
> (a) read all readableBytes() from the ChannelBuffer, try to find the message
> disadvantage: I may (quite certainly) read much more than one message
> from the Buffer, but for the sake of simple processing I want to
> decode only one message at a time; i.e. I read messages multiple times
> from the ChannelBuffer until they are "first"

This is perhaps what FrameDecoder is already doing?  You might want to
take a look into the source code of FrameDecoder to understand how it
works (it's pretty simple actually):

  * http://tinyurl.com/5mcwnd

> (b) read a certain amount of bytes (I can make a guess how long an
> average message is), see if there is a complete message in it, if read
> in the next call twice as much and so on
> disadvantage: I may have useless calls to decode(...) and everything
> in it if the fixed buffer size is too small for a message.

You don't need to do this by yourself.  Netty's I/O engine will manage
the size of the receive buffer automatically.  If the buffer gets full,
the new read buffer will have more capacity.  If the buffer is far from
being full, the next read buffer will have less capacity.  Plus, you can
configure it.  Plase take a look at the Javadoc of
NioSocketChannelConfig:

  * http://tinyurl.com/6e282b

Also, you might want to look into the default buffer size prediction
algorithm:

  * http://tinyurl.com/5877hv

> What do you think will be more performant with Netty's FrameDecoder
> and ChannelBuffer?

I think it should perform just fine even if you don't apply the two
techniques you've mentioned above.

> Btw, why are the method names for the readIndex and writeIndex in
> ChannelBuffer not named get..()/set...() ?

In respect of NIO ByteBuffer.  For example, ByteBuffer.position()
has the same naming convention.  Wanted for users to be comfort when
they transit from NIO BB to Netty CB.  AND less keystrokes? :)

HTH,
Trustin

-- 
Trustin Lee, Principal Software Engineer, JBoss, a division of Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20081121/9d69591f/attachment.bin 


More information about the netty-users mailing list