Netty optimization and Protocol help.

["이희승 (Trustin Lee)"]

Hi Bantai,

Welcome to the Netty community first of all. :)

On 08/15/2009 07:17 AM, bantai wrote:
> 
> Hi,
> 
> I am currently working on a project where I need to handle many thousand
> unique requests per second and have therefore chosen to create a server
> based on a thin framework like Grizzly or Netty. I have currently tested
> Netty HTTP successfully but since the communication is highly defined I was
> thinking of creating a simpler protocol than relying on HTTP since I'm not
> using much of the HTTP protocol. Defaulting to HTTP was the simplest start.
> 
> All the requests are final so no session state etc is necessary.
> 
> The protocol I have in mind will send text messages that are in the form of
> JSON objects and only a few bytes in size.
> 
> I've tried creating a server from looking at the examples provided by Netty
> and used the LocalTime example as my initial source of inspiration.
> 
> Some of the questions I have are:
> 
> 1.) With the current implementation, I'm getting worse performance than I
> did using a Grizzly http server. I must have missed something vital since
> I've seen tests where Netty outperforms Grizzly. So I'm wondering if I am
> not reusing the connection/channel correctly or if I can pool something?

Looking from the source code, it will not work under load as
StringDecoder does not assemble fragmented buffers.  You will need to
implement your own FrameDecoder or use something like
DelimiterBasedFrameDecoder.  Please refer to the Factorial example that
shows how to write your own decoder / encoder.

> 2.) In my test client I am currently creating a JsonClient per thread. Is
> this correct or should I rather create one JsonClient in my TestRunner which
> is shared among the TestThreads?

A ChannelFactory is an expensive resource.  You need to share it across
the whole application.  Other objects such as Bootstrap are fine to
create for every connection attempt as they are just a wrapper.

> 3.) From another thread I saw the recommendations to use the properties
> keepAlive, tcpNoDelay and reuseAddress. I've tried playing around with them
> but not seen much of a change so Im not sure I'm using them correctly or
> whether I would benefit from using other properties?

I don't think you need to configure them unless you really need it.  You
might need to configure the socket recv/send buffer size for better
throughput, but Netty should perform fine even without those parameters.

> 4.) Tips in general. If I would get better performance rewriting my code
> following other guidelines please let me know as I've only started playing
> with Netty.

My principle when I design Netty API is to make it just work without
much caveat.  If you find something difficult to understand or you made
a mistake and took quite a while to figure out why, then it means Netty
needs improvement.  Please post your trials and errors if you don't mind
- such a contribution will be significantly helpful to the community and
make Netty more robust to user errors.

But, please read the user guide carefully. ;)

> 5.) How should i reformat my Server code to implement the Server interface
> I'm currently using with Grizzly:
> 
> public interface Server {
> 	public void start();
> 	
> 	public void stop();
> }

I think you need to read the user guide, that explains how to shut down
your Netty application.

> 6.) Am I wrong in thinking that I should be able to get better performance
> using a dedicated protocol for this task instead of relying on HTTP?

Yes, of course.  Replacing JSON with something more compact will result
in even better performance.  However, premature optimization is not
usually a good idea, so I'd recommend you to write an HTTP-based
implementation on top of Netty first instead of trying non-HTTP option.

HTH,
Trustin