本地Unix套接字-吞吐量的粗略概念

是否有人知道使用本地unix套接字进行进程间通信的吞吐量基准/测量？

我想说明在与从数据库请求数据的软件相同的服务器上拥有本地数据库实例的性能优势，而不必通过网络链接进行通信，尤其是像千兆以太网这样的网络链接，我预计它会比较慢相对而言。

在线搜索时，我发现一些基准显示每秒的操作数量，但没有每秒的吞吐量（即12GB / s）。

我了解性能会因诸如给定系统上的内存吞吐量或其他硬件特性之类的因素而有所不同，但是仅需要一个大概的想法。

这不是指本地TCP性能或与之相比。

performance socket

— sa289
source

你是，实际上指的是本地网络与TCP性能。在您的情况下衡量也是错误的事情。

— 佐藤桂

@SatoKatsura我指的是en.wikipedia.org/wiki/Unix_domain_socket

— sa289 2016年

对。您如何看待UNIX域套接字的实际实现？

— 聪桂

@SatoKatsura不确定，但是即使我没有白天和黑夜的差异，根据我所读的内容也会有所不同。此外，还有一些基准测试将本地unix域套接字与本地TCP套接字进行了比较，显示出明显的性能差异。

— sa289

此外，还有一些基准测试将本地unix域套接字与本地TCP套接字进行了比较，显示出明显的性能差异。-您能指出一个这样的基准吗？

— 佐藤桂

您可以使用socat进行简单的UNIX套接字速度测试。

以下是我在笔记本电脑上得到的结果：

#Generate 1GB random file in the "shared memory" (i.e. RAM disk) 
>dd if=/dev/urandom of=/dev/shm/data.dump bs=1M count=1024

通过UNIX套接字的内存到磁盘（SSD）

>socat -u -b32768 UNIX-LISTEN:/tmp/unix.sock ./data.dump &
>socat -u -b32768 "SYSTEM:dd if=/dev/shm/data.dump bs=1M count=1024" UNIX:/tmp/unix.sock
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 1.96942 s, 545 MB/s

内存到内存，通过UNIX套接字

>socat -u -b32768 UNIX-LISTEN:/tmp/unix.sock /dev/shm/data.dump.out &
>socat -u -b32768 "SYSTEM:dd if=/dev/shm/data.dump bs=1M count=1024" UNIX:/tmp/unix.sock
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.927163 s, 1.2 GB/s

通过UNIX套接字将内存存储到/ dev / null（丢弃）

>socat -u -b32768 UNIX-LISTEN:/tmp/unix.sock /dev/null &
>socat -u -b32768 "SYSTEM:dd if=/dev/shm/data.dump bs=1M count=1024" UNIX:/tmp/unix.sock
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.720415 s, 1.5 GB/s

通过UNIX套接字将/ dev / zero更改为/ dev / null

>socat -u -b32768 UNIX-LISTEN:/tmp/unix.sock /dev/null &
>socat -u -b32768 "SYSTEM:dd if=/dev/zero bs=1M count=1024" UNIX:/tmp/unix.sock
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.491179 s, 2.2 GB/s

如您所见，甚至“内存到磁盘”测试的吞吐量为545MB / s（即〜4360MiB / s），远远超出了1GB以太网连接的最大理论吞吐量（即〜1000/8 = 125MB / s，甚至不考虑任何协议开销）。

聚苯乙烯

请注意，这只是使用一些简单工具的简单测试，而不是真实，适当的基准测试。

— 齐柏林飞艇
source

就像我在下面说的-不要混淆带宽和吞吐量。socat会告诉您“理想”条件下的带宽，会告诉您是否未达到理论上的带宽-但它不会告诉您有关导致应用程序速度下降的延迟。比较8Gbit的磁盘I / O-压力测试。那是您可以获得的最大值-不管X是多少。如果应用程序达到目标，“媒体”可能就是您的瓶颈。如果应用程序未达到该级别，则“瓶颈”不是媒体。如果socat的最大速度为1Gbit，但该应用程序却没有-socat不会告诉我什么限制了“吞吐量”。

— Michael Felt

我的“答案”很长-他们的关键是不要将“吞吐量”与“带宽”混淆-尽管“带宽”可能是一个限制因素

简而言之，即使带宽未饱和，吞吐量也可能受到限制。

我不得不帮助人们了解多层应用程序堆栈的影响。

对于TCP通信，我利用了RTT（往返时间）的差异。

对于单层，可以将本地IP地址（在NIC上）与lo0（回送）进行比较。

对于多层，您可以比较/计算“更远”的地址，例如，多层可以是同一主机中的两个VM，也可以是同一数据中心中的不同主机，或者它们可以在不同的数据中心中（也许只有500米的距离，但仍然有所不同）。

仅供参考：对于许多应用程序而言，RTT差异可以忽略不计，但是对于那些为应用程序执行10到10万条小消息的应用程序而言，RTT时间可能会成为瓶颈。

（我见过一种情景，“与单层相比，当RTT长0.25毫秒时，多层中的批处理花费了将近6个小时）

因此，简单的测试台：

的

for host in 127.0.0.1 192.168.129.63 192.168.129.72 192.168.129.254 192.168.129.71 p5.aixtools.net
do
    wget -q http://${host}/ -O - >/dev/null
    sleep 1
done

我的监控程序是tcpdump-选项-ttt

   -ttt
        Prints a delta (in microseconds) between current and previous line on each dump line.
微秒是一个SI时间单位，等于百万分之一（0.000001或10-6或1 / 1,000,000）。也就是说，1000微秒== 1毫秒。

因此，在两个不同的窗口中，我正在运行tcpdump：

对于“本地”时间：tcpdump -i lo0 -n -ttt端口80对于“远程” tcpdump -I en1 -n -ttt端口80

在下面的数据中，目标不是进行任何分析，而是显示如何识别完成交易所需的时间“差异”。当应用程序吞吐量是串行事务时，每“秒|分钟|小时”的吞吐量受“响应”所需的总时间影响。我发现使用RTT的概念-往返时间最容易解释。

对于真正的分析，还有其他事情需要考虑。因此，我将仅显示的行是初始TCP握手，第一个传出数据包和返回的ACK。为了进行比较，比较“回复”返回之前多长时间的增量时间。

127.0.0.1

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo0, link-type 0, capture size 96 bytes
00:00:00.000000 IP 127.0.0.1.42445 > 127.0.0.1.80: S 1760726915:1760726915(0) win 65535 <mss 16856,nop,wscale 2,nop,nop,timestamp 1482096651 0>
00:00:00.**000035** IP 127.0.0.1.80 > 127.0.0.1.42445: S 3339083773:3339083773(0) ack 1760726916 win 65535 <mss 16856,nop,wscale 2,nop,nop,timestamp 1482096651 1482096651>
00:00:00.000013 IP 127.0.0.1.42445 > 127.0.0.1.80: . ack 1 win 33688 <nop,nop,timestamp 1482096651 1482096651>
00:00:00.**000014** IP 127.0.0.1.80 > 127.0.0.1.42445: . ack 1 win 33688 <nop,nop,timestamp 1482096651 1482096651>

192.168.129.63

注意01.XXXXXX-在“ lo0”界面上一秒钟的睡眠

00:00:01.006055 IP 192.168.129.63.42446 > 192.168.129.63.80: S 617235346:617235346(0) win 65535 <mss 16856,nop,wscale 2,nop,nop,timestamp 1482096653 0>
00:00:00.**000032** IP 192.168.129.63.80 > 192.168.129.63.42446: S 1228444163:1228444163(0) ack 617235347 win 65535 <mss 16856,nop,wscale 2,nop,nop,timestamp 1482096653 1482096653>
00:00:00.000014 IP 192.168.129.63.42446 > 192.168.129.63.80: . ack 1 win 33688 <nop,nop,timestamp 1482096653 1482096653>
00:00:00.**000010** IP 192.168.129.63.80 > 192.168.129.63.42446: . ack 1 win 33688 <nop,nop,timestamp 1482096653 1482096653>

192.168.129.72

同一主机中的虚拟机-注意时间开始于00.000000-显示第一个数据包（下面的其他两个地址为01.XXXXXX）

root@x063:[/]tcpdump -i en1 -n -ttt port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en1, link-type 1, capture size 96 bytes
00:00:00.000000 IP 192.168.129.63.42447 > 192.168.129.72.80: S 865313265:865313265(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 1482096655 0>
00:00:00.**000125** IP 192.168.129.72.80 > 192.168.129.63.42447: S 916041515:916041515(0) ack 865313266 win 65535 <mss 1460,nop,wscale 2,nop,nop,timestamp 1481318272 1482096655>
00:00:00.000028 IP 192.168.129.63.42447 > 192.168.129.72.80: . ack 1 win 32761 <nop,nop,timestamp 1482096655 1481318272>
00:00:00.**000055** IP 192.168.129.72.80 > 192.168.129.63.42447: . ack 1 win 65522 <nop,nop,timestamp 1481318272 1482096655>

192.168.129.254

我的路由器-在主机之外，而不是虚拟机。

00:00:01.005947 IP 192.168.129.63.42448 > 192.168.129.254.80: S 2756186848:2756186848(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 1482096657 0>
00:00:00.**000335** IP 192.168.129.254.80 > 192.168.129.63.42448: S 2327415811:2327415811(0) ack 2756186849 win 5792 <mss 1460,nop,nop,timestamp 44854195 1482096657,nop,wscale 2,nop,opt-14:03>
00:00:00.000022 IP 192.168.129.63.42448 > 192.168.129.254.80: . ack 1 win 32761 <nop,nop,timestamp 1482096657 44854195>
00:00:00.**000090** IP 192.168.129.63.42448 > 192.168.129.254.80: P 1:142(141) ack 1 win 32761 <nop,nop,timestamp 1482096657 44854195>

192.168.129.71

与192.168.129.72相同的连接，但这在“ 72”空闲时处于“繁忙”状态。我希望最初的握手几乎相同

00:00:01.005093 IP 192.168.129.63.42449 > 192.168.129.71.80: S 249227688:249227688(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 1482096659 0>
00:00:00.**000072** IP 192.168.129.71.80 > 192.168.129.63.42449: S 1898177685:1898177685(0) ack 249227689 win 65535 <mss 1460,nop,wscale 2,nop,nop,timestamp 1482096104 1482096659>
00:00:00.000022 IP 192.168.129.63.42449 > 192.168.129.71.80: . ack 1 win 32761 <nop,nop,timestamp 1482096659 1482096104>
00:00:00.**000050** IP 192.168.129.71.80 > 192.168.129.63.42449: . ack 1 win 65522 <nop,nop,timestamp 1482096104 1482096659>

多跳

这是相同的主机，相同的apache结果，但是现在通过外部接口（6个IP跃点，而不是直接的）-现在您可以实现远程RTT的效果。（ps，我稍微修改了IP地址）。更重要的是-请注意，在初始握手之后，在握手返回后的第一个ACK之前，有两个传出数据包。

因此，而不是25毫秒的RTT，请认为RTT是250微秒，而不是25微秒-并且您有500k事务（与本地相比，仅增加了120到125秒，吞吐量令人难以置信。） 5000万笔交易（就像我在现实生活中遇到的情况一样）将获得额外的12500秒-这对于“逐字地”执行相同的工作会增加大约3.5个小时的时间（这种情况的部分解决方案是使数据包变大-平均大小原为400-450字节）。

回想一下，我想在这里展示的是一种相当简单的方法，可以在比较多层架构与单层架构时解决应用程序（批处理作业）完成的总体时间差异。

00:00:01.162974 IP 192.168.129.63.42450 > XX.85.86.223.80: S 1331737569:1331737569(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 1482096661 0>
00:00:00.**023962** IP XX.85.86.223.80 > 192.168.129.63.42450: S 3130510306:3130510306(0) ack 1331737570 win 65535 mss 1460,nop,wscale 2,nop,nop,timestamp 1482096106 1482096661,nop,opt-14:03>
00:00:00.000025 IP 192.168.129.63.42450 > XX.85.86.223.80: . ack 1 win 32761 <nop,nop,timestamp 1482096661 1482096106>
00:00:00.000062 IP 192.168.129.63.42450 > XX.85.86.223.80: P 1:142(141) ack 1 win 32761 <nop,nop,timestamp 1482096661 1482096106>
00:00:00.**024014** IP XX.85.86.223.80 > 192.168.129.63.42450: . ack 1 win 65522 <nop,nop,timestamp 1482096107 1482096661>

我对使用tcpdump的另一点“喜欢”是通常可用的程序。无需额外安装。

— 迈克尔·费尔特
source

以及与unix套接字有什么关系？

— nonchip