ローカルUNIXソケット-スループットの大まかな考え方

プロセス間通信にローカルUNIXソケットを使用する場合のスループットベンチマーク/測定を知っている人はいますか？

データベースからのデータを要求しているソフトウェアと同じサーバー上にローカルデータベースインスタンスを配置することと、ネットワークリンクを介して通信する必要があること（特に、ギガビットイーサネットのように低速であることが予想される場合）のパフォーマンス上の利点を説明したい相対的に言えば。

オンラインで検索したところ、1秒あたりの操作数を示すベンチマークが見つかりましたが、1秒あたりのスループット（12GB /秒）はありませんでした。

特定のシステムのメモリスループットやその他のハードウェアの特性などにより、パフォーマンスが変化することを理解していますが、大まかな考え方が必要です。

これは、ローカルTCPのパフォーマンスやそれとの比較を指すものではありません。

単純なUNIXソケット速度テストにはsocatを使用できます。

以下は私のラップトップで得られた結果です：

#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 /秒（つまり、約4360MiB /秒）であり、1GBイーサネット接続の最大理論スループット（約1000/8 = 125MB /秒）をはるかに上回っています。プロトコルのオーバーヘッドも考慮されていません）。

PS

これは、いくつかの単純なツールを使用した単純なテストであり、実際の適切なベンチマークではないことに注意してください。

私の「回答」は長くなります-「スループット」と「帯域幅」を混同しないようにすることが重要です-「帯域幅」は制限要因になる可能性があります

つまり、帯域幅が飽和していない場合でも、スループットが制限される可能性があります。

私は人々が多層アプリケーションスタックの影響を理解するのを助ける必要がありました。

TCP通信の側面では、RTT（往復時間）の違いを利用します。

単一層の場合、（NIC上の）ローカルIPアドレスをlo0（ループバック）と比較できます。

マルチティアの場合、「より遠い」アドレスを比較/計算します。たとえば、マルチティアは、同じホスト内の2つの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.

マイクロ秒は、1​​00万分の1（0.000001または10-6または1 / 1,000,000）に等しい時間のSI単位です。つまり、1000マイクロ秒== 1ミリ秒です。

したがって、2つの異なるウィンドウで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」インターフェースでの1秒間のスリープ

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から始まることに注意してください-最初のパケットが表示されます（以下の2つのアドレスには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の前に2つの発信パケットがあることに注意してください。

そのため、25ミリ秒のRTTではなく、RTTが25マイクロ秒と比較して250マイクロ秒であると考えてください-そして、500kのトランザクションがあります（ローカルと比べて120〜125秒余分になり、スループットは同等です）。 5,000万回のトランザクション（私が実際の状況で行ったように）により、さらに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を使用することについて私が「気に入っている」もう1つの点は、一般に入手可能なプログラムであることです。余分なものをインストールする必要はありません。