Netty performance question

Trustin Lee tlee at redhat.com
Tue Apr 28 20:33:50 EDT 2009


Hi Matt,

OrderedMemoryAwareThreadPool executes the queued task in the same
thread if an existing thread is running a task associated with the
same channel.  This behavior is to make sure the events from the same
channel are handled in a correct order.  A different thread might be
chosen only when the task queue of the channel is empty.

>From the log, your decoder is faster than your last handler so that
the decoded strings are being queued in the task queue of
OrderedMemoryAwareThreadPool.  You decoded 16 * 8 (128) frames while
the last handler handled 26 frames.

If you don't need the correct order, you could use
MemoryAwareThreadPool, which is not ordered.

If you can discard old message of the same symbol, you could use
MemoryAwareThreadPool, add some sort of sequence ID generated by
AtomicInteger to the decoded message, and discard older one when a
newer one has been processed already.

HTH,

— Trustin Lee, http://gleamynode.net/

On Wed, Apr 29, 2009 at 8:14 AM, omsdw <mgiedt at gmail.com> wrote:
>
> Hi Trustin,
>
> Thanks for the reply -- here's the new aggregated frame decoder taking your
> comments into consideration:
>
>    @Override
>    protected Object decode( ChannelHandlerContext ctx,
>                             Channel channel,
>                             ChannelBuffer buffer )
>        throws Exception
>    {
>        ChannelBuffer frame = nextFrame( ctx, channel, buffer );
>
>        if( null == frame )
>        {
>            return null;
>        }
>
>        final List<ChannelBuffer> frames = new ArrayList();
>        frames.add( frame );
>
>        while( ( frame = nextFrame( ctx, channel, buffer ) ) != null )
>        {
>            frames.add( frame );
>
>            if( frames.size() == 16 )
>            {
>                break;
>            }
>        }
>
>        if( frames.size() > 1 ) log.info( "frame_size: " + frames.size() );
>
>        return frames;
>    }
>
> I limit the size of the list per my understanding of Netty's threading
> model, and to minimize the chance of starved threads.
>
> My test case is the following: create a socket connector to a service on
> another machine that spits out newline delimited strings, of the format
> <NAME>::<SYMBOL>::<PRICE>::<QUANTITY> as absolutely fast as possible.
>
> I moved the creation of the ordered executor outside of the pipeline, am
> giving it 8 threads and 1048576L of memory for both channel and max. I'm
> running the connector on a quad core wintel box.
>
> Apologies up front for the log dump, not sure if there's a better way to do
> this:
>
> 17:28:55,875 [main] INFO  NetworkService -  connected to: 192.168.1.104
> (9898)
> 17:28:55,875 [pool-1-thread-2] INFO  handler.MarketDataHandler - Session
> opened.
> 17:28:55,875 [main] INFO  NetworkService - NetworkService started.
> [New I/O client worker #1-1] INFO
> codec.frame.AggregatedDelimiterBasedFrameDecoder - frame_size: 16
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: PROVIDENT
> FINANCIAL PLC::*PFNG::89.21291681565648::3002
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: SAMSUNG ENG
> CO LTD::*SMENG::40.20711772945576::7808
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: WEBZEN INC
> SPONSORED ADR::WZEN::59.297980973943936::1328
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received:
> HARLEY-DAVIDSON INC::HOG::89.10598424607085::5554
> [New I/O client worker #1-1] INFO
> codec.frame.AggregatedDelimiterBasedFrameDecoder - frame_size: 16
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: NORTHWEST
> NATURAL GAS CO::NWN::7.880818581976313::2816
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: PHARMSTANDARD
> OJSC GDR REGS::*PHSTGDR::19.84352590168874::1606
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: AMYLIN
> PHARMACEUTICALS INC::AMLN::5.733107933259383::5721
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: FAIRPOINT
> COMMUNICATIONS INC::FRP::91.04553986367252::9106
> [New I/O client worker #1-1] INFO
> codec.frame.AggregatedDelimiterBasedFrameDecoder - frame_size: 16
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: PACTIV
> CORP::PTV::79.69568373272925::7769
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: SHIP FINANCE
> INTL LTD (NY)::SFL::72.61685266460003::6422
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: BARD C R
> INC::BCR::85.02849655474907::5340
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: DAITO TRUST
> CONSTRUCTION::*DTCA::67.52378421625104::3574
> [New I/O client worker #1-1] INFO
> codec.frame.AggregatedDelimiterBasedFrameDecoder - frame_size: 16
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: ITRON
> INC::ITRI::3.300601340710613::1313
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: ATMOS ENERGY
> CORP::ATO::52.97884144388059::1637
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: CHIBA BANK
> LTD::*CHIB::63.73125264158283::2442
> [New I/O client worker #1-1] INFO
> codec.frame.AggregatedDelimiterBasedFrameDecoder - frame_size: 16
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: SL GREEN
> REALTY CORP REIT::SLG::14.01862313091981::3615
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: NUVASIVE
> INC::NUVA::32.05571354916585::9153
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: UNITED ONLINE
> INC::UNTD::68.2950589032212::8772
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: CLARCOR
> INC::CLC::85.07751587663417::9202
> [New I/O client worker #1-1] INFO
> codec.frame.AggregatedDelimiterBasedFrameDecoder - frame_size: 16
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: PATTERSON-UTI
> ENERGY INC::PTEN::40.99767197368768::1644
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: AKER KVAERNER
> ASA::*AKVER::5.356799684472896::7161
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received:
> COLGATE-PALMOLIVE CO::CL::53.67058149751621::8011
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: AFFILIATED
> MANAGERS GRP INC::AMG::34.3828136317687::1896
> [New I/O client worker #1-1] INFO
> codec.frame.AggregatedDelimiterBasedFrameDecoder - frame_size: 16
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received:
> INBEV::*INTBR::41.34460141470128::2819
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: GOODRICH
> CORP::GR::45.9417091067221::1476
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: JULIUS BAER
> HLDG AG::*BAERZ::78.71264235165296::1856
> [New I/O client worker #1-1] INFO
> codec.frame.AggregatedDelimiterBasedFrameDecoder - frame_size: 16
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: ANSYS
> INC::ANSS::91.95087848942684::1437
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: NORTHERN
> TRUST CORP::NTRS::72.43511923842306::1380
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: FORTIS
> (BELG)::*FORTS::11.45458657853769::9048
>
> Notice that [pool-1-thread-3] is the only thread servicing the messages in
> both the above snippit and the entire log file.
>
> Here's what I *think* should be happening using the log above:
>
> 1. worker #1-1 thread decodes 16 lines into array list in framer.
> 2. worker #1-1 thread calls fireMessageReceived 16 times in string decoder.
> 3. each individual string in fireMessageReceived is parsed by the handler in
> a unique thread in the executor. We SHOULD see something like:
>
> [pool-1-thread-3] DEBUG handler.MarketDataHandler -  received: ...
> [pool-1-thread-6] DEBUG handler.MarketDataHandler -  received: ...
> [pool-1-thread-2] DEBUG handler.MarketDataHandler -  received: ...
> [pool-1-thread-4] DEBUG handler.MarketDataHandler -  received: ...
> [pool-1-thread-1] DEBUG handler.MarketDataHandler -  received: ...
>
> As always, thanks in advance and really appreciate your help!
>
> Kind regards,
> -Matt
>
>
>
> --
> View this message in context: http://n2.nabble.com/Netty-performance-question-tp2712571p2737589.html
> Sent from the Netty User Group mailing list archive at Nabble.com.
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>




More information about the netty-users mailing list