Thanks for the quick response.. You do realize that now I wont bother to read
any documentation and previous posts, but just post a new question every
time I have a problem =)
Anyway, I did what you instructed and indeed I got around 6000 tps (a little
less). With one cpu windows laptop machine, that is.
However, I got another problem.. Now, if I establish two client connections
the other client gets something like 5500 tps, but the other only around
1000 tps? The setup is the same as described below, with your modifications
included. I do not expect it to scale in linear fashion, but I expect that
the service level is about the same on both clients.
Trustin Lee wrote:
>
> Oh, and please don't forget to get back here and tell use how MINA
> performs
> for you. ;)
>
> Trustin
>
> On 3/13/07, Trustin Lee <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> On 3/13/07, mrGibby <[EMAIL PROTECTED]> wrote:
>> >
>> >
>> > Yesterday I did a quick test to check how MINA could be used to
>> > implement a
>> > diameter stack. I also did some initial benchmarks. So far the tests
>> > have
>> > shown that our own IO framework out performs mina quite easily (~4000
>> > tps vs
>> > >6000 tps, one connected client, 10 io threads). Also, the MINA version
>> > of
>> > diameter stack is missing the protocol state machine that exists the
>> > other
>> > framework, that surely adds some overhead to the system. There has
>> > already
>> > been some posts in this forum about diameter protocol. The main
>> > difference
>> > to protocols normally discussed here is that peers use only few
>> physical
>> > connections to serve multiple user sessions (compared e.g. to hundreds
>> > http
>> > connections). Increasing connections to boost performance is not always
>> > possible.
>> >
>> > So here is some of my test code. Basically just used the http example
>> as
>> > basis. Could someone give me some pointers how to do improve
>> > performance?
>> > The actual diameter message parsing is not a bottle neck since both
>> > benchmarked frameworks used the same code (well, I did need to change
>> > the
>> > bytebuffer to mina version). I did read the thread model configuration
>> > and
>> > it did not seem to improve the perforrmance. There has also been
>> > discussion
>> > that the events for each iosession are invoked on handler serially and
>> > the
>> > is no built in support in mina to have parallel processing of messages
>> > in
>> > iohandler (I would need to implement own threadpoolfilter). Is this
>> > still
>> > true or was this old news?
>> >
>> > // main
>> > IoAcceptor acceptor = new SocketAcceptor(10,
>> > Executors.newCachedThreadPool());
>> > // Create a service configuration
>> > SocketAcceptorConfig cfg = new SocketAcceptorConfig();
>> > cfg.setReuseAddress( true );
>> > cfg.getFilterChain().addLast(
>> > "protocolFilter",
>> > new ProtocolCodecFilter( new
>> > DiameterProtocolCodecFactory() ) );
>> > //cfg.getFilterChain().addLast( "logger", new LoggingFilter() );
>> >
>> > acceptor.bind( new InetSocketAddress( port ), new ServerHandler(), cfg
>> > );
>> >
>> >
>> > public MessageDecoderResult decodable( IoSession session, ByteBuffer in
>> > )
>> > {
>> > // Return NEED_DATA if the whole header is not read yet.
>> > try
>> > {
>> > return messageComplete( in ) ? MessageDecoderResult.OK
>> > : MessageDecoderResult.NEED_DATA ;
>> > }
>> > catch( Exception ex )
>> > {
>> > ex.printStackTrace();
>> > }
>> >
>> > return MessageDecoderResult.NOT_OK;
>> > }
>> >
>> > public MessageDecoderResult decode( IoSession session, ByteBuffer
>> > in,
>> > ProtocolDecoderOutput out ) throws Exception
>> > {
>> > // Try to decode body
>> > DiameterMessage m = decodeBody( in );
>> >
>> > // Return NEED_DATA if the body is not fully read.
>> > if( m == null )
>> > return MessageDecoderResult.NEED_DATA;
>> >
>> > out.write( m );
>> >
>> > return MessageDecoderResult.OK;
>> > }
>> > .
>> > .
>> > .
>> > }
>> >
>> > // iohandler, just changes the request to answer and echoes it back
>> > public class ServerHandler extends IoHandlerAdapter
>> > {
>> > .
>> > .
>> > public void messageReceived( IoSession session, Object message )
>> > {
>> > DiameterMessage m = (DiameterMessage) message;
>> > m.setRequest(false);
>> > if( m != null )
>> > session.write(m).join();
>> > }
>> > .
>> > .
>> > }
>>
>>
>> 1. You don't need to call join() after calling write().
>> 2. Please try to disable the thread model and don't add any
>> ExecutorFilter
>> because your business logic uses CPU only. To find out more about
>> configuring your thread model, please refer here:
>> http://mina.apache.org/configuring-thread-model.html
>> 3. Additionally, insert thr following two lines in your main class:
>>
>> ByteBuffer.setUseDirectBuffers (false);
>> ByteBuffer.setAllocator(new SimpleByteBufferAllocator());
>>
>> HTH,
>> Trustin
>> --
>> what we call human nature is actually human habit
>> --
>> http://gleamynode.net/
>> --
>> PGP Key ID: 0x0255ECA6
>
>
>
>
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>
>
--
View this message in context:
http://www.nabble.com/optimal-configuration-for-%22diameter-like%22-protocols-tf3394204.html#a9450713
Sent from the mina dev mailing list archive at Nabble.com.
