CODEWITHSUNDEEP
javanetwork-programmingcpu-usage
Philipp
Philipp

Reputation: 69703

Avoiding high CPU usage with NIO

I wrote a multithreaded gameserver application which handles multiple simultaneous connections using NIO. Unfortunately this server generates full CPU load on one core as soon as the first user connects, even when that user is not actually sending or receiving any data.

Below is the code of my network handling thread (abbreviated to the essential parts for readability). The class ClientHandler is my own class which does the network abstraction for the game mechanics. All other classes in the example below are from java.nio.

As you can see it uses a while(true) loop. My theory about it is that when a key is writable, selector.select() will return immediately and clientHandler.writeToChannel() is called. But when the handler returns without writing anything, the key will stay writable. Then select is called again immediately and returns immediately. So I got a busy spin.

Is there a way to design the network handling loop in a way that it sleeps as long as there is no data to send by the clientHandlers? Note that low latency is critical for my use-case, so I can not just let it sleep an arbitrary number of ms when no handlers have data.

ServerSocketChannel server = ServerSocketChannel.open();
server.configureBlocking(false);
server.socket().bind(new InetSocketAddress(port));
Selector selector = Selector.open();
server.register(selector, SelectionKey.OP_ACCEPT);
// wait for connections

while(true)
{
     // Wait for next set of client connections
    selector.select();
    Set<SelectionKey> keys = selector.selectedKeys();
    Iterator<SelectionKey> i = keys.iterator();
    while (i.hasNext()) {
        SelectionKey key = i.next();
        i.remove();

        if (key.isAcceptable()) {
            SocketChannel clientChannel = server.accept();
            clientChannel.configureBlocking(false);
            clientChannel.socket().setTcpNoDelay(true);
            clientChannel.socket().setTrafficClass(IPTOS_LOWDELAY);
            SelectionKey clientKey = clientChannel.register(selector, SelectionKey.OP_READ | SelectionKey.OP_WRITE);
            ClientHandler clientHanlder = new ClientHandler(clientChannel);
            clientKey.attach(clientHandler);
        }
        if (key.isReadable()) {
            // get connection handler for this key and tell it to process data 
            ClientHandler clientHandler = (ClientHandler) key.attachment();
            clientHandler.readFromChannel();
        }
        if (key.isWritable()) {
            // get connection handler and tell it to send any data it has cached 
            ClientHandler clientHandler = (ClientHandler) key.attachment();
            clientHandler.writeToChannel();
        }
        if (!key.isValid()) {
            ClientHandler clientHandler = (ClientHandler) key.attachment();
            clientHandler.disconnect();
        }
    }
}

Upvotes: 3

Views: 4332

Answers (2)

user207421
user207421

Reputation: 311031

SelectionKey clientKey = clientChannel.register(selector, SelectionKey.OP_READ | SelectionKey.OP_WRITE);

The problem is here. SocketChannels are almost always writable, unless the socket send buffer is full. Ergo they should normally not be registered for OP_WRITE: otherwise your selector loop will spin. They should only be so registered if:

  1. there is something to write, and
  2. a prior write() has returned zero.

Upvotes: 8

Andrew Mao
Andrew Mao

Reputation: 36940

I don't see any reason why the reading and writing must happen with the same selector. I would use one selector in a thread for read/accept operations and it will always be blocking until new data arrives.

Then, use a separate thread and selector for writing. You mention you are using a cache to store messages before they are sent on the writable channels. In practice the only time a channel would not be writable is if the kernel's buffer is full, so it will rarely not be writable. A good way to implement this would be to have a dedicated writer thread that is given messages, and sleeping; it can be either interrupt()ed when new messages should be sent, or using a take() on a blocking queue. Whenever a new message arrives, it will unblock, do a select() on all writable keys and send any pending messages; only in rare cases will a message have to remain in the cache since a channel is not writable.

Upvotes: 6

Related Questions