You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Roger Kapsi (JIRA)" <ji...@apache.org> on 2008/02/23 17:49:20 UTC

[jira] Closed: (DIRMINA-532) Slow writing compared to MINA 1.1.x

     [ https://issues.apache.org/jira/browse/DIRMINA-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Roger Kapsi closed DIRMINA-532.
-------------------------------

    Resolution: Invalid

Turns out it was a bad combination of locking, logging and a general slowness of the small Amazon EC2 instances. I don't know why MINA 1.1.6 and 2 react so differently but after resolving the issues and giving it a shot on the extra large boxes everything went very smoothly.

> Slow writing compared to MINA 1.1.x
> -----------------------------------
>
>                 Key: DIRMINA-532
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-532
>             Project: MINA
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.0.0-M2
>         Environment: Linux with 2.6.16-xenU Kernel, Java 1.6.0_02-b05, 18 small instances on Amazon EC2 (1 Server, 17 clients), 3600 TCP connections to the Server
>            Reporter: Roger Kapsi
>         Attachments: MINA-116-vs-M2.tar.bz2
>
>
> Hi,
> we have a system built on top of MINA. Let's say it's an application server built a bit like a P2P system. We're currently focusing on the server side to get the most out of it and the client side is experimental (we use something else in production which is not based on MINA). From time to time I'm testing the latest MINA builds to check if we can start using it. I don't know how previous builds of MINA 2 behaved as our client side of the code is relatively new but MINA 2 seems to be slower than MINA 1.1.x.
> It seems to have problems with writing the messages as soon as I put some load on the Server and the number of Threads from the ExecutorFilter shoots through the roof.
> Configuration for MINA 1.1.6 & M2
> ThreadModel: MANUAL
> Send Buffer Size: 256k
> Receive Buffer Size: 256k
> Backlog: 200
> ExecutorFilter's position is right after ProtocolCodecFilter in the IoFilterChain.
> I'm going to attach some JMX screenshots. Feel free to make suggestions regards the setup and I'll try to test 'em ASAP.
> Thanks
>  Roger

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.