☰

本地unix套接字-吞吐量的粗略想法

tag-icon • tag-icon performance socket
本地unix套接字-吞吐量的粗略想法

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

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

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

我知道性能会因给定系统上的内存吞吐量或其他硬件特性等因素而有所不同，但只需要一个粗略的想法。

这并不是指本地 TCP 性能或与之进行比较。

答案1

您可以使用索卡特用于简单的 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

内存到磁盘 (SSD)，通过 UNIX 套接字

>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

/dev/zero 到 /dev/null，通过 UNIX 套接字

>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，甚至不考虑任何协议开销）。

聚苯乙烯

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

答案2

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

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

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

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

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

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

仅供参考：对于许多应用程序来说，RTT 差异可以忽略不计，但对于为应用程序执行 10-100 条或数千条小消息的应用程序，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 port 80 对于“远程”时间 tcpdump -I en1 -n -ttt port 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 不是 25 毫秒 RTT，而是 250 微秒 - 并且您有 50 万个事务（与本地相比，仅多出 120 到 125 秒，并且吞吐量是可比的。但是50M 事务（正如我在现实生活中的情况一样）您将获得额外的 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 的另一件事是它是一个普遍可用的程序。不需要安装任何额外的东西。

相关内容