Re: Throughput test of OpenHFT networking

[Wojciech Kudla]

It's probably not the response that you were hoping to see but I'd avoid testing for performance using loopback interface. 

There are whole parts of the network stack omitted by the Linux kernel in such scenarios. 

Not mentioning that open HFT may employ socket mechanics different from what's available in jdk. 

On Sat, 12 May 2018, 19:03 John Hening, <goci...@gmail.com> wrote:

Hello,
I am trying to examine a throughput of OpenHFT networking in version 1.12.2 to compare it with my toy.

My test works in the following way:

I have few concurrent clients that send (by loopback) to the server (written with OpenHFT networking) 131`072 messages of size 4KB and blocking-wait for a (1-byte) response that confirms that message was processed by the server.

I've run a test with -DServerThreadingStrategy=CONCURRENT, MULTI_THREADED_BUSY_WAITING  and SINGLE_THREADED.

    number of clients                                    OpenHFT: avg. Messages per second:             my toy
(run on different threads)    CONCURRENT  SINGLE_THREADED     MULTI_THREADED_BUSY_WAITING             CONCURRENT (no single threaded strategy)
          1                   52.47         50.4                     49.95                           41.4                              
          2                   40.21         48.57                    39.54                           44.65
          4                   21.92         23.68                    21.51                           32.04
          8                   10.78         12.83                    10.91                           23.06
         16                   5.53          6.02                     5.57                            11.77 
         32                   2.68          2.79                     2.76                            6.46

________________________________________________________________________________________________________________________________________________________________

I suppose that the problem is with my usage of that library, but I cannot figure out what is wrong- it is not so easy to write a test because of lack/obsolete documentation/examples.

The server is run as follows: (I skipped not important details to make it shorter)

    private static EventLoop eg;

    public static void starServer() {
        eg = new EventGroup(true);
        eg.start();
        TCPRegistry.createServerSocketChannelFor(desc);
        AcceptorEventHandler eah = new AcceptorEventHandler(desc, LegacyHanderFactory.legacyTcpEventHandlerFactory(nc -> new Confirmer()), VanillaNetworkContext::new);
                                                                                                                         // Confirmer send one-byte message to a client to confirm processing of message
        eg.addHandler(eah);
    }

    class Confirmer implements TcpHandler<NetworkContext> {
        @Override
        public void process(@NotNull final Bytes in, @NotNull final Bytes out, NetworkContext nc) {
            if (in.readRemaining() == 0){
                return;
            }
            out.write(in, in.readPosition(), 1); // send a confirmation
            in.readSkip(Math.min(in.readRemaining(), out.writeRemaining()));
        }
    }
}

A client code (run on different threads):
 

private void sender(long numberOfMessage, int sizeOfMessage) {
    SocketChannel sc = TCPRegistry.createSocketChannel(desc);
    sc.configureBlocking(true);
    ByteBuffer buffer = ByteBuffer.allocateDirect(sizeOfMessage);
    ByteBuffer recv = ByteBuffer.allocateDirect(1);
    buffer.putInt(64); // required bytes. To be frankly, I don't understand exactly why 64.
    buffer.put(bytes.getBytes()); // nearly 4KB-text-message

    long start = System.nanoTime();
    for(int i = 0; i < numberOfMessage; i++){
        buffer.clear();
        recv.clear();
        sc.write(buffer);
        sc.read(recv);
    }
    times.add(System.nanoTime() - start); // use it to compute an average after
    sc.close();
}

And I use times to get an average throughput.

P.S. I see that system is loaded (in the sense of threads and kernel network stack) but results seems to be low though. I don't have an experience and I cannot decide whether that results are normal.

P.S.2 I also know that my test is primitive

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Greg Young]

Will your production system be running over loopback? 

On Sun, May 13, 2018 at 1:59 AM, John Hening <goci...@gmail.com> wrote:

I know that testing by loopback isn't the best idea (and that it omits a part of the network stack) but it is the simplest and I have just a laptop with one physical network interface so I don't see a possibility to test it without a second physical host.

 Not mentioning that open HFT may employ socket mechanics different from what's available in jdk.

AFAIK (perhaps I am wrong) OpenHFT uses networking available in jdk,

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Studying for the Turing test

[Greg Young]

That's fair but I have dealt with team members who have "optimized" code over loopback only to find its slower over an actual network :) Hence the question. 

On Sun, May 13, 2018 at 3:04 AM, John Hening <goci...@gmail.com> wrote:

Why do you think that I have a production system? I do it for learning purpose.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscribe...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Studying for the Turing test

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.