Thanks a lot.
Actually I fount out Thread.sleep(1) didn't work as what I expected. On
Windows XP, the minimum time Thread Acutally could sleep is 15ms. Which
meant my example didn't really simulate messages as much as expected. What I
tried to do was to generate 5k - 10k messages/sec and send them to the
client.
On Thu, Apr 3, 2008 at 5:55 PM, "이희승 (Trustin Lee) <[EMAIL PROTECTED]>
wrote:
> I was not able to reproduce OOM in my laptop (Intel Core 2 Duo T9300
> 2.5GHz 6MB L2 Cache, 2GB RAM, JDK 1.6.0.10-beta). The following is the
> source code I have used - it was simply ported to MINA 2:
>
> import java.net.InetSocketAddress;
> import java.nio.charset.Charset;
>
> import org.apache.mina.common.IoHandlerAdapter;
> import org.apache.mina.common.IoSession;
> import org.apache.mina.filter.codec.ProtocolCodecFilter;
> import org.apache.mina.filter.codec.textline.TextLineCodecFactory;
> import org.apache.mina.transport.socket.SocketAcceptor;
> import org.apache.mina.transport.socket.nio.NioSocketAcceptor;
>
> public class MyHandler extends IoHandlerAdapter {
> IoSession mySession;
>
> public static void main(String[] args) throws Exception {
> SocketAcceptor acceptor = new NioSocketAcceptor(2);
>
> // Prepare the configuration
> acceptor.getFilterChain().addLast(
> "codec",
> new ProtocolCodecFilter(new TextLineCodecFactory(Charset
> .forName("UTF-8"))));
> acceptor.getSessionConfig().setTcpNoDelay(true);
>
> // Bind
> acceptor.setHandler(new MyHandler());
> acceptor.bind(new InetSocketAddress(8080));
>
> System.out.println("Listening on port 8080");
> }
>
> @Override
> public void exceptionCaught(IoSession session, Throwable cause) {
> cause.printStackTrace();
> // Close connection when unexpected exception is caught.
> session.close();
> }
>
> @Override
> public void sessionCreated(IoSession session) throws Exception {
> mySession = session;
>
> new MyThread().start();
> }
>
> private class MyThread extends Thread {
> @Override
> public void run() {
> String message =
> "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
>
> while (true) {
>
> mySession.write(message);
> mySession.write(message);
> mySession.write(message);
>
> try {
> Thread.sleep(1);
> } catch (InterruptedException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> }
> }
> }
> }
>
> On the client side, I used netcat:
>
> $ nc localhost 8080
>
> Please note my test was run in Linux. I'm not sure about Windows
> unfortunately. There's also netcat for Windows IIRC - you could try
> that instead of Windows telnet, which doesn't seem to perform very well.
>
> HTH,
>
> Steve Johns wrote:
> > I wrote the following testing program. I used one thread to simulate the
> > incoming datafeed. Sleep(1) = 1000messages/sec(I added 3
> > session.write(message)), then 3000 messages / sec roughly sent to
> client.
> > My server CPU reaches 70% with one telnet client on the same machine.
> >
> -----------------------------------------------------------------------------------
> > public class MyHandler extends IoHandlerAdapter {
> > IoSession mySession;
> >
> > public static void main(String[] args) throws Exception {
> > IoAcceptor acceptor = new SocketAcceptor(2,
> > Executors.newCachedThreadPool());
> >
> > ByteBuffer.setUseDirectBuffers(false);
> > ByteBuffer.setAllocator(new SimpleByteBufferAllocator());
> >
> > // Prepare the configuration
> > SocketAcceptorConfig cfg = new SocketAcceptorConfig();
> > cfg.setReuseAddress(true);
> > cfg.setThreadModel(ThreadModel.MANUAL);
> > //cfg.getFilterChain().addLast("logger", new LoggingFilter());
> > cfg.getFilterChain().addLast(
> > "codec",
> > new ProtocolCodecFilter(new
> TextLineCodecFactory(Charset
> > .forName("UTF-8"))));
> > cfg.getSessionConfig().setTcpNoDelay(true);
> >
> > // Bind
> > acceptor.bind(new InetSocketAddress(8080),
> > new MyHandler(), cfg);
> >
> > System.out.println("Listening on port 8080");
> > }
> >
> >
> > public void exceptionCaught(IoSession session, Throwable cause) {
> > cause.printStackTrace();
> > // Close connection when unexpected exception is caught.
> > session.close();
> > }
> >
> > public void sessionCreated(IoSession session) throws Exception {
> > mySession = session;
> >
> > new MyThread().start();
> > }
> >
> > private class MyThread extends Thread {
> > public void run() {
> > String message =
> > "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
> >
> > while (true) {
> >
> > mySession.write(message);
> > mySession.write(message);
> > mySession.write(message);
> >
> > try {
> > Thread.sleep(1);
> > }
> > catch (InterruptedException e) {
> > // TODO Auto-generated catch block
> > e.printStackTrace();
> > }
> > }
> > }
> > }
> > }
> >
> > 2008/4/2 Steve Johns <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>>:
> >
> > Actually I used windows console telnet command to connect to the
> > server.
> >
> >
> > On Wed, Apr 2, 2008 at 8:54 PM, "이희승 (Trustin Lee)
> > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
> >
> > Could you please upgrade to 1.1.6, 1.1.7-SNAPSHOT, 2.0.0-M1 or
> > 2.0.0-M2-SNAPSHOT first?
> >
> > I don't think telnet client can be slow if it's implemented
> > properly.
> >
> > Thanks,
> >
> > Steve Johns wrote:
> > > Thank you very much.
> > >
> > > 1) I used Mina1.1.5 NOT 2.0 M1.
> > > 2) Actually telnet client is on the same machine as my Mina
> > server. Could it
> > > be SLOW?
> > >
> > > In order to test how fast Mina could write, I modified the
> > > ReverseProtocolHandler example. I added following code in the
> > > ReverseProtocolHandler:
> > >
> > > public void sessionCreated(IoSession session) throws Exception
> {
> > > String message =
> > >
> >
> "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
> > >
> > > while (true) {
> > > for (int i = 0; i < 5000; i++)
> > > session.write(message);
> > >
> > > Thread.sleep(500);
> > > }
> > > }
> > >
> > > and I opened a telnet client connect to it. However, when I
> > PrintGCDetails,
> > > i obversed that GC is so busy to collect (take 0.15 sec to
> > collect once, and
> > > keep collecting )and after a while it seems too slow to
> > collect. Eventually
> > > OOM.
> > >
> > > I don't know if my code added was correct or NOT. I was
> > impressed when you
> > > said your server could handle 140k message/sec. How could you
> > possible do
> > > that? ^^
> > > On Wed, Apr 2, 2008 at 11:30 AM, "이희승 (Trustin Lee)
> > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
> > > wrote:
> > >
> > >> Hi Steve,
> > >>
> > >> OOM can be raised when the write request rate is so high.
> > There are two
> > >> possible issues:
> > >>
> > >> 1) MINA NioProcessor is writing slowly.
> > >> 2) Receiving party (i.e. telnet client) is receiving slowly.
> > >>
> > >> If #1 is the case, we need to fix it. However, I was able to
> > achieve
> > >> 140k messages per second for asynchronous messaging and 20k
> > messages per
> > >> second for synchronous messaging in my private performance
> test
> > >> performed in gigabit network recently. Just in case your
> > scenario is
> > >> triggering a hidden bug in MINA, please provide us a simple
> test
> > >> application.
> > >>
> > >> HTH,
> > >>
> > >> Steve Johns wrote:
> > >>> So far Mina does a good job in my recent project until
> > yesterday. I am
> > >>> working a GW server handling 10k - 15k incoming messages/sec
> > with NOT
> > >> very
> > >>> big sizes and send them to clients. The weird thing is the
> > program has
> > >> NO
> > >>> problem to consume the incoming messages(decoding, read).
> > However, when
> > >> a
> > >>> simple telnet client connected to my server(same machine), I
> > observed
> > >> the GC
> > >>> taking 0.5 - 1.0sec to do GC every time and eventually
> > OOM(GC is NOT
> > >>> faster??). I got serveral questions:
> > >>> 1) just wonder if mina is able to write that many of
> > messages? I believe
> > >>> telnet client on the same machine NOT considered to be a
> > SLOW client,
> > >> right?
> > >>> 2) IF 1) Yes, the problem seems GC limitation but NOT Mina
> > problem?
> > >>>
> > >>> Thanks.
> > >>>
> > >> --
> > >> Trustin Lee - Principal Software Engineer, JBoss, Red Hat
> > >> --
> > >> what we call human nature is actually human habit
> > >> --
> > >> http://gleamynode.net/
> > >>
> > >>
> >
> > --
> > Trustin Lee - Principal Software Engineer, JBoss, Red Hat
> > --
> > what we call human nature is actually human habit
> > --
> > http://gleamynode.net/
> >
> >
> >
>
> --
> Trustin Lee - Principal Software Engineer, JBoss, Red Hat
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
>
>
