java - 字节缓冲区性能

Question

我有一个将接收超过 1000 TPS 的套接字，因此我需要尽可能快地读取，在这个套接字中我读取信息，我需要构建字符串并检查它是否与正则表达式匹配。我需要逐个字符地读取，这样我现在就可以知道新消息的发送位置

但是我遇到了性能问题，我正在使用 JMeter 进行测试，一段时间后吞吐量开始下降。到目前为止，这是我发现的读取元素并对它们进行分类(按字符聊天)的最佳方法，因为我知道消息新消息何时开始/结束的唯一方法是因为 NULL，下面的代码

//Keep reading info from the socket    
while (running) {
    try {
        Future<Integer> readFuture = getWorker().read(buffer);
        Integer option = readFuture.get();
        if (option > 0) {
            buffer.flip();
            //Read all the info from the buffer
            while (buffer.hasRemaining()) {
                char buf = (char) buffer.get();
                if (buf == '/') {
                    continue;
                }
                //If the info has one of those char, it's a new message, so I have to manage and keep reading
                if (buf == '\0' || buf == ' ') {
                    trace=sendMessage(trace);
                } else {
                    trace.append(buf);
                }
            }
            buffer.clear();
        } else {
            trace=sendMessage(trace);
            running = false;
            close();
        }
    } catch (Exception e) {
        //Error management 
    }
}

Answer 1

这里是一个示例，它不是最快但最简单的代码，您可以编写用于发送聊天消息的代码。你可以使用 NIO，事实上我也这样做，但只有当我真正需要时才这样做。

此示例仅使用新行终止文本。对于二进制，我建议在每条消息之前将每条消息的大小写为 32 位值。 (可能是 16 位，如果你知道它们总是很小)

Server side code和 Client side code

public static void main(String[] args) throws IOException {
    ServerSocket ss = new ServerSocket(PORT);
    while (true) {
        Socket s = ss.accept();
        new Thread(() -> {
            System.out.println("Accepted " + s);
            try {
                try (BufferedReader br = new BufferedReader(new InputStreamReader(s.getInputStream(), StandardCharsets.UTF_8));
                     PrintWriter pw = new PrintWriter(new OutputStreamWriter(s.getOutputStream(), StandardCharsets.UTF_8), true)) {
                    for (String line; (line = br.readLine()) != null; )
                        handle(line, pw);
                }
            } catch (IOException e) {
                e.printStackTrace();
            } finally {
                System.out.println("... " + s + " closed");
            }
        }).start();
    }
}

static void handle(String line, PrintWriter pw) {
    pw.println(line);
}

这些打印结果

 Throughput test wrote 44.2 MB/s
 Latency test for 100,000 TPS
 Latency distribution 50/90 99/99.9 (worst) was 528,477/1,069,998 1,163,770/1,173,065 (1,174,106) micro-seconds
 Latency test for 80,000 TPS
 Latency distribution 50/90 99/99.9 (worst) was 276,228/498,628 551,875/556,160 (556,636) micro-seconds
 Latency test for 60,000 TPS
 Latency distribution 50/90 99/99.9 (worst) was 14/22 1,759/3,031 (3,393) micro-seconds
 Latency test for 50,000 TPS
 Latency distribution 50/90 99/99.9 (worst) was 14/21 4,388/5,518 (5,641) micro-seconds
 Latency test for 40,000 TPS
 Latency distribution 50/90 99/99.9 (worst) was 14/15 22/485 (2,071) micro-seconds
 Latency test for 30,000 TPS
 Latency distribution 50/90 99/99.9 (worst) was 14/15 21/921 (3,360) micro-seconds
 Latency test for 20,000 TPS
 Latency distribution 50/90 99/99.9 (worst) was 15/19 24/46 (656) micro-seconds

据此我可以得出结论，一个线程每秒甚至无法处理 80,000 条短消息，但它可以很好地处理每秒 60,000 条短消息，并且在每秒 40,000 条消息时可以获得更稳定的结果。

这些取得了良好的结果因为它们具有非常高的 TPS，事实上，在 100 TPS 或更低的情况下，您会看到低消息速率的副作用，这种副作用是由于由于计时器中断和其他中断，CPU 缓存每 10 毫秒就会受到干扰，这会损害延迟，在这些示例中，延迟不是百分之一左右，而是每条消息。

简而言之，您必须以不同方式优化<100 TPS，因为消息速率如此低，而不是因为如此高。