☰

ローカルUnixソケット - スループットのおおよそのアイデア

tag-icon • tag-icon performance socket
ローカルUnixソケット - スループットのおおよそのアイデア

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

データベースからデータを要求するソフトウェアと同じサーバーにローカルデータベースインスタンスを置くことと、ネットワークリンク、特にギガビットイーサネットなどのネットワークリンクを介して通信する必要がある場合のパフォーマンス上の利点を説明したいと思います。比較的遅いです。

オンラインでの検索中に、1秒あたりのジョブは表示されますが、1秒あたりのスループット（例：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

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) です。これは、1 GB イーサネット接続の理論上の最大スループット（例: ~ 1000/8 = 125MB/s）よりはるかに高いです。 、プロトコルのオーバーヘッドも考慮しません）。

ポリスチレン

これは、実際のテストではなく、いくつかの簡単なツールを使用した単純なテストにすぎないことに注意してください。適切基準。

答え2

私の「答え」は長いです。核心は「処理量」と「帯域幅」を混同しないことだ。 「帯域幅」が制限要因になる可能性がありますが、

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

人々が多層アプリケーションスタックの影響を理解するのに役立ちます。

TCP通信の面ではRTT（往復時間）の違いを活用しました。

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

多層の場合は、「追加」アドレスを比較/計算できます。たとえば、複数のレイヤは、同じホスト上の2つのVM、同じデータセンターにある別のホスト、または異なるデータセンターにある場合があります（500メートルだけ離れている可能性がありますが、まだ異なります）。

注：多くのアプリケーションではRTTの違いは無視できますが、アプリケーションに対して10〜100個または数千の小さなメッセージを実行するアプリケーションの場合、RTT時間はボトルネックになる可能性があります。

（私はこれを見ました：「シングルレイヤーに比べてRTTが0.25ms長い場合、マルチレイヤー配置はほぼ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.

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

したがって、2つの異なるウィンドウで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"インターフェイスで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つの発信パケットがあることです。

したがって、RTTは25マイクロ秒に比べて25ミリ秒のRTTではなく、250マイクロ秒です。そして、500,000個のトランザクションがあり（ローカルと比較して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の使用について私が「好きな」もう一つのことは、これが普遍的に利用可能なプログラムであるということです。さらに何もインストールする必要はありません。

関連情報