在這篇文章中：

• 關(guān)于吞吐量對延遲的影響的討論
• 如何使用JLBH測量TCP回送
• 添加探針以測試TCP往返的兩半
• 觀察增加吞吐量對延遲的影響
• 了解必須降低吞吐量才能在高百分位數(shù)時獲得良好的延遲。

在帖子中，我們看到了考慮協(xié)調(diào)遺漏的影響或測量延遲一次迭代的影響將對后續(xù)迭代產(chǎn)生影響。

直觀上我們了解吞吐量會影響延遲。 很自然
如果我們提高吞吐量，我們還將提高延遲。

進(jìn)入一個非常擁擠的商店將影響您選擇和購買商品的速度。 另一方面，考慮一個很少見的商店。 可能是因?yàn)樵谶@樣的商店中，店主遠(yuǎn)離茶歇，直到您等待他放下自己的茶并前往柜臺為您服務(wù)時，您的購買才會被延遲。 。

這正是運(yùn)行基準(zhǔn)測試并改變吞吐量時的結(jié)果。

通常，當(dāng)您提高吞吐量時，延遲會增加，但在吞吐量下降到某個閾值以下時，延遲也會增加。

下面的代碼對通過環(huán)回的往返TCP調(diào)用進(jìn)行計(jì)時。

我們添加了兩個探針：

• client2server –完成往返前半部分所花費(fèi)的時間
• server2client –完成行程的下半部分所花費(fèi)的時間

這些探查沒有考慮到協(xié)調(diào)的遺漏，只有端到端的時間才考慮到協(xié)調(diào)的遺漏。

這是基準(zhǔn)測試的代碼：

package org.latency.tcp;import net.openhft.affinity.Affinity; import net.openhft.chronicle.core.Jvm; import net.openhft.chronicle.core.jlbh.JLBHOptions; import net.openhft.chronicle.core.jlbh.JLBHTask; import net.openhft.chronicle.core.jlbh.JLBH; import net.openhft.chronicle.core.util.NanoSampler;import java.io.EOFException; import java.io.IOException; import java.net.InetSocketAddress; import java.nio.ByteBuffer; import java.nio.ByteOrder; import java.nio.channels.ServerSocketChannel; import java.nio.channels.SocketChannel;public class TcpBenchmark implements JLBHTask {private final static int port = 8007;private static final boolean BLOCKING = false;private final int SERVER_CPU = Integer.getInteger("server.cpu", 0);private JLBH jlbh;private ByteBuffer bb;private SocketChannel socket;private NanoSampler client2serverProbe;private NanoSampler server2clientProbe;public static void main(String[] args) {JLBHOptions jlbhOptions = new JLBHOptions().warmUpIterations(50000).iterations(50000).throughput(20000).runs(5).jlbhTask(new TcpBenchmark());new JLBH(jlbhOptions).start();}@Overridepublic void init(JLBH jlbh) {this.jlbh = jlbh;client2serverProbe = jlbh.addProbe("client2server");server2clientProbe = jlbh.addProbe("server2clientProbe");try {runServer(port);Jvm.pause(200);socket = SocketChannel.open(new InetSocketAddress(port));socket.socket().setTcpNoDelay(true);socket.configureBlocking(BLOCKING);} catch (IOException e) {e.printStackTrace();}bb = ByteBuffer.allocateDirect(8).order(ByteOrder.nativeOrder());}private void runServer(int port) throws IOException {new Thread(() -> {if (SERVER_CPU > 0) {System.out.println("server cpu: " + SERVER_CPU);Affinity.setAffinity(SERVER_CPU);}ServerSocketChannel ssc = null;SocketChannel socket = null;try {ssc = ServerSocketChannel.open();ssc.bind(new InetSocketAddress(port));System.out.println("listening on " + ssc);socket = ssc.accept();socket.socket().setTcpNoDelay(true);socket.configureBlocking(BLOCKING);System.out.println("Connected " + socket);ByteBuffer bb = ByteBuffer.allocateDirect(8).order(ByteOrder.nativeOrder());while (true) {readAll(socket, bb);bb.flip();long time = System.nanoTime();client2serverProbe.sampleNanos(time - bb.getLong());bb.clear();bb.putLong(time);bb.flip();writeAll(socket, bb);}} catch (IOException e) {e.printStackTrace();} finally {System.out.println("... disconnected " + socket);try {if (ssc != null)ssc.close();} catch (IOException ignored) {}try {if (socket != null)socket.close();} catch (IOException ignored) {}}}, "server").start();}private static void readAll(SocketChannel socket, ByteBuffer bb) throws IOException {bb.clear();do {if (socket.read(bb) < 0)throw new EOFException();} while (bb.remaining() > 0);}@Overridepublic void run(long startTimeNs) {bb.position(0);bb.putLong(System.nanoTime());bb.position(0);writeAll(socket, bb);bb.position(0);try {readAll(socket, bb);server2clientProbe.sampleNanos(System.nanoTime() - bb.getLong(0));} catch (IOException e) {e.printStackTrace();}jlbh.sample(System.nanoTime() - startTimeNs);}private static void writeAll(SocketChannel socket, ByteBuffer bb) {try {while (bb.remaining() > 0 && socket.write(bb) >= 0) ;} catch (IOException e) {e.printStackTrace();}}@Overridepublic void complete() {System.exit(0);} }

以下是以20,000次迭代/秒的吞吐量運(yùn)行時的結(jié)果：

Warm up complete (50000 iterations took 2.296s) -------------------------------- BENCHMARK RESULTS (RUN 1) ---------Run time: 2.5s Correcting for co-ordinated:true Target throughput:20000/s = 1 message every 50us End to End: (50,000) 50/90 99/99.9 99.99 - worst was 34 / 2,950 19,400 / 20,450 20,450 - 20,450 client2server (50,000) 50/90 99/99.9 99.99 - worst was 16 / 26 38 / 72 287 - 336 server2clientProbe (50,000) 50/90 99/99.9 99.99 - worst was 16 / 27 40 / 76 319 - 901 OS Jitter (26,960) 50/90 99/99.9 99.99 - worst was 9.0 / 16 44 / 1,340 10,220 - 11,800 -------------------------------------------------------------------- -------------------------------- BENCHMARK RESULTS (RUN 2) --------- Run time: 2.5s Correcting for co-ordinated:true Target throughput:20000/s = 1 message every 50us End to End: (50,000) 50/90 99/99.9 99.99 - worst was 42 / 868 4,590 / 5,110 5,370 - 5,370 client2server (50,000) 50/90 99/99.9 99.99 - worst was 20 / 27 38 / 92 573 - 2,560 server2clientProbe (50,000) 50/90 99/99.9 99.99 - worst was 19 / 27 38 / 72 868 - 1,740 OS Jitter (13,314) 50/90 99/99.9 99.99 - worst was 9.0 / 16 32 / 96 303 - 672 -------------------------------------------------------------------- -------------------------------- BENCHMARK RESULTS (RUN 3) --------- Run time: 2.5s Correcting for co-ordinated:true Target throughput:20000/s = 1 message every 50us End to End: (50,000) 50/90 99/99.9 99.99 - worst was 34 / 152 999 / 2,160 2,290 - 2,290 client2server (50,000) 50/90 99/99.9 99.99 - worst was 17 / 26 36 / 54 201 - 901 server2clientProbe (50,000) 50/90 99/99.9 99.99 - worst was 16 / 25 36 / 50 225 - 1,740 OS Jitter (14,306) 50/90 99/99.9 99.99 - worst was 9.0 / 15 23 / 44 160 - 184 ---------------------------------------------------------------------------------------------------- SUMMARY (end to end)--------------- Percentile run1 run2 run3 % Variation var(log) 50: 33.79 41.98 33.79 13.91 90: 2949.12 868.35 151.55 75.92 99: 19398.66 4587.52 999.42 70.53 99.9: 20447.23 5111.81 2162.69 47.62 99.99: 20447.23 5373.95 2293.76 47.24 worst: 20447.23 5373.95 2293.76 47.24 -------------------------------------------------------------------- -------------------------------- SUMMARY (client2server)------------ Percentile run1 run2 run3 % Variation 50: 16.13 19.97 16.90 10.81 90: 26.11 27.14 26.11 2.55 99: 37.89 37.89 35.84 3.67 99.9: 71.68 92.16 54.27 31.76 99.99: 286.72 573.44 200.70 55.32 worst: 335.87 2555.90 901.12 55.04 -------------------------------------------------------------------- -------------------------------- SUMMARY (server2clientProbe)------- Percentile run1 run2 run3 % Variation 50: 16.13 18.94 16.13 10.43 90: 27.14 27.14 25.09 5.16 99: 39.94 37.89 35.84 3.67 99.9: 75.78 71.68 50.18 22.22 99.99: 319.49 868.35 225.28 65.55 worst: 901.12 1736.70 1736.70 0.00 --------------------------------------------------------------------

應(yīng)該發(fā)生的是：

client2server + server2client?= endToEnd

而且，這少得多的是在第50個百分點(diǎn)發(fā)生的情況

為了演示的目的，進(jìn)行第二次運(yùn)行：

19.97 + 18.94?= 41.98

如果這只是您要測量的全部，您可能會說通過我的機(jī)器運(yùn)行20k / s消息沒有問題。

但是，我的筆記本電腦顯然無法處理該音量，如果我們再次查看第二個90％百分位數(shù)的運(yùn)行情況。

27.14 + 27.14！?= 868.35

隨著百分位數(shù)的增加，它變得越來越糟……

但是，如果我將吞吐量更改為每秒5k條消息，我會在第90個百分位數(shù)上看到這一點(diǎn)：

32.23 + 29.38?= 62.46

因此，我們看到，如果要在高百分位數(shù)上實(shí)現(xiàn)低延遲，則必須將吞吐量降低到正確的水平。

這就是為什么如此重要，以至于我們能夠使用JLBH改變吞吐量。

翻譯自: https://www.javacodegeeks.com/2016/04/jlbh-examples-3-affects-throughput-latency.html

總結(jié)

以上是生活随笔為你收集整理的JLBH示例3 –吞吐量对延迟的影响的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。