You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Julien Vermillard <jv...@archean.fr> on 2008/05/02 09:21:22 UTC
Re: MINA CPU scaling evaluation
Hi,
I'm trying to make a little perf test with MINA (and grizzly) using the
echo protocol.
I placed two things in my sandbox : an echoclient and a grizlly echo
client.
https://svn.apache.org/repos/asf/mina/sandbox/jvermillard/
The echoclient can be ran using few arguments :
[number of connection] [hostname] [tcp port] [duration in seconds]
It will use 1 Connector to connect X sessions to an echo client and send
data waiting for the associated replies, looping for X seconds.
I hope it can help you and it would be nice to see the result on your
machine :)
Julien
On Wed, 30 Apr 2008 14:23:34 -0500
DS <pu...@peapod.net> wrote:
>
> Hello,
>
> I am evaluting MINA for a project and I need to evaluate scaling
> on a multi-processor system.
>
> My MINA application is a simple proxy application:
>
> Machine A Machine B Machine C
>
> Test Driver <-----> MINA Application <-----> Echo Server
>
> A test driver establishes one or more connections to the MINA
> application.
>
> The MINA application accepts the connections. Each IoSession
> will receive a message and then forward it via a client
> connection to the echo server. The echo server simply echos the
> message back to the MINA application, which then responds back
> to the test driver.
>
> MINA establishes 32 connections to the echo servers. To ensure
> there is no contention in the echo server, we are starting 32
> instances of the echo server. So one connection to each of 32
> echo servers.
>
> MINA selects an echo server based upon which session received
> the inbound message. This simple session selection ensures
> there is no contention in the test application itself, as there
> is no shared data between sessions.
>
> The test driver starts with one connection, then 2, 4, 8, 16, and
> 32.
>
> For each set, it ramps up transactions until the rate at which
> requests are received deviate from the rate at which requests
> are being sent by 5%.
>
> Questions:
>
> o Does anyone know of existing test drivers that can be used
> here? The test driver must scale and aggregate results with
> up to 32 threads, and be capable of out-performing MINA.
>
> o Are there any things we need to do other than use out-of-the-box
> MINA with NioSocketAcceptor and NioSocketConnector? We are
> testing on a 32 core Solaris T1000 (Niagara architecture) with
> Sun's JRE 1.6.
>
> Thanks in advance,
> David Sundstrom
>
>
Re: MINA CPU scaling evaluation
Posted by D Sunds <su...@peapod.net>.
On Fri, 2008-05-02 at 09:21 +0200, Julien Vermillard wrote:
> Hi,
> I'm trying to make a little perf test with MINA (and grizzly) using the
> echo protocol.
>
> I placed two things in my sandbox : an echoclient and a grizlly echo
> client.
> https://svn.apache.org/repos/asf/mina/sandbox/jvermillard/
>
> The echoclient can be ran using few arguments :
>
> [number of connection] [hostname] [tcp port] [duration in seconds]
>
> It will use 1 Connector to connect X sessions to an echo client and send
> data waiting for the associated replies, looping for X seconds.
>
> I hope it can help you and it would be nice to see the result on your
> machine :)
Salut Julien,
Thank you for making this available to me.
I haven't used it yet because I developed the following test
in the meantime:
Driver System Response
Machine <-> Under Test <-> Machine
Sparc T200 Sparc T1000 Sparc T200
The driver machine is running between 1 and 32 driver processes.
The requester machine has 32 "echo" processes that just echo back
whatever is received on their connection.
The driver and response processes are little perl scripts. I
benchmarked these in advance to ensure they are capable of driving
the system under test with greater loads than it can handle.
The system under test is a single MINA application process acting
as a simple proxy. Requests received from the driver system are
forwarded to the response system. The response from the response
system is routed back to the driver system on the original connection.
I use a fixed routing scheme based upon a session id so that I don't
need to have any shared data between sessions for this test. In
other words, no contention among threads in my application code.
The test works by sending a fixed message rate from all drivers
for a period of 60 seconds. The test stops when the receive rate
diverges from the send rate by more than 5%, or any messages are
lost, or there are send or recv errors. The test uses a binary
search pattern, but allows the system to drain between runs.
Running a linear search yields the same results at the expense
of a longer search time.
Running the test for 1,2,4,8,16,and 32 connections (threads)
gives the following performance for small messages:
1 2 4 8 16 32
5566 11132 20848 32968 42416 37856
I see scaling up to 16 threads. I did not try 17-31 threads yet.
I experienced one error when I had my response connection mis-configured
such that message could not be sent:
>
> 110544 [NioProcessor-166] WARN org.apache.mina.common.DefaultExceptionMonitor - Unexpected exception.
> java.io.IOException: Invalid argument
> at sun.nio.ch.DevPollArrayWrapper.registerMultiple(Native Method)
> at sun.nio.ch.DevPollArrayWrapper.updateRegistrations(DevPollArrayWrapper.java:220)
> at sun.nio.ch.DevPollArrayWrapper.poll(DevPollArrayWrapper.java:163)
> at sun.nio.ch.DevPollSelectorImpl.doSelect(DevPollSelectorImpl.java:68)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
> at org.apache.mina.transport.socket.nio.NioProcessor.select(NioProcessor.java:65)
> at org.apache.mina.common.AbstractPollingIoProcessor$Worker.run(AbstractPollingIoProcessor.java:672)
> at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
> at java.lang.Thread.run(Thread.java:619)
This error was mentioned in the threads for MINA 1.x, and appears to
be still lurking out there.
A+,
David
> Julien
>
> On Wed, 30 Apr 2008 14:23:34 -0500
> DS <pu...@peapod.net> wrote:
>
> >
> > Hello,
> >
> > I am evaluting MINA for a project and I need to evaluate scaling
> > on a multi-processor system.
> >
> > My MINA application is a simple proxy application:
> >
> > Machine A Machine B Machine C
> >
> > Test Driver <-----> MINA Application <-----> Echo Server
> >
> > A test driver establishes one or more connections to the MINA
> > application.
> >
> > The MINA application accepts the connections. Each IoSession
> > will receive a message and then forward it via a client
> > connection to the echo server. The echo server simply echos the
> > message back to the MINA application, which then responds back
> > to the test driver.
> >
> > MINA establishes 32 connections to the echo servers. To ensure
> > there is no contention in the echo server, we are starting 32
> > instances of the echo server. So one connection to each of 32
> > echo servers.
> >
> > MINA selects an echo server based upon which session received
> > the inbound message. This simple session selection ensures
> > there is no contention in the test application itself, as there
> > is no shared data between sessions.
> >
> > The test driver starts with one connection, then 2, 4, 8, 16, and
> > 32.
> >
> > For each set, it ramps up transactions until the rate at which
> > requests are received deviate from the rate at which requests
> > are being sent by 5%.
> >
> > Questions:
> >
> > o Does anyone know of existing test drivers that can be used
> > here? The test driver must scale and aggregate results with
> > up to 32 threads, and be capable of out-performing MINA.
> >
> > o Are there any things we need to do other than use out-of-the-box
> > MINA with NioSocketAcceptor and NioSocketConnector? We are
> > testing on a 32 core Solaris T1000 (Niagara architecture) with
> > Sun's JRE 1.6.
> >
> > Thanks in advance,
> > David Sundstrom
> >
> >