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 <[EMAIL PROTECTED]> 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 > > > >
