Socket unix lokal - ide throughput yang kasar

10

Adakah yang mengetahui benchmark / pengukuran throughput untuk menggunakan soket unix lokal untuk komunikasi antar-proses?

Saya ingin mengilustrasikan manfaat kinerja memiliki contoh basis data lokal pada server yang sama dengan perangkat lunak yang meminta data dari basis data vs. harus berkomunikasi melalui tautan jaringan, terutama yang seperti gigabit Ethernet yang saya harapkan agak lambat relatif berbicara.

Saat mencari online saya menemukan beberapa tolok ukur yang menunjukkan jumlah operasi per detik, tetapi tidak throughput per detik (yaitu 12GB / s).

Saya mengerti bahwa kinerjanya akan bervariasi karena hal-hal seperti mungkin throughput memori pada sistem yang diberikan atau karakteristik perangkat keras lainnya, tetapi hanya gagasan kasar yang diperlukan.

Ini tidak mengacu pada kinerja TCP lokal atau perbandingannya.

performance socket sa289
sumber
Anda adalah , sebenarnya, mengacu pada kinerja jaringan TCP vs lokal. Ini juga hal yang salah untuk diukur dalam skenario Anda.
Satō Katsura
@SatoKatsura yang saya maksud adalah en.wikipedia.org/wiki/Unix_domain_socket
sa289
Ya. Dan bagaimana menurut Anda soket domain UNIX benar-benar diterapkan?
Satō Katsura
@SatoKatsura Tidak pasti, tetapi ada beberapa perbedaan berdasarkan pada apa yang saya baca walaupun itu tidak berbeda siang dan malam. Juga ada tolok ukur yang membandingkan soket domain unix lokal dengan soket TCP lokal yang menunjukkan perbedaan kinerja yang signifikan.
sa289
Juga ada tolok ukur yang membandingkan soket domain unix lokal dengan soket TCP lokal yang menunjukkan perbedaan kinerja yang signifikan. - Bisakah Anda menunjukkan satu tolok ukur seperti itu?
Satō Katsura

Jawaban:

19

Anda dapat menggunakan socat untuk tes kecepatan soket UNIX sederhana.

Di bawah ini adalah hasil yang saya dapatkan di laptop saya:

#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

Memori ke disk (SSD), melalui soket 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

Memori ke memori, melalui soket 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

Memori ke / dev / null (buang), melalui soket UNIX

>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 to / dev / null, melalui socket 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

Seperti yang Anda lihat bahkan "memory to disk" throughput tes adalah 545MB / s (yaitu ~ 4360MiB / s), yang jauh di depan dari throughput teoritis maksimum untuk koneksi ethernet 1GB (yang ~ 1000/8 = 125MB / s, bahkan tidak mempertimbangkan overhead protokol).

PS

Harap dicatat bahwa ini hanyalah tes sederhana menggunakan beberapa alat sederhana, dan bukan tolok ukur yang nyata dan tepat .

zeppelin
sumber
1
Seperti yang saya katakan di bawah ini - jangan bingung bandwidth dengan throughput. socat akan memberi tahu Anda bandwidth dalam kondisi "ideal", akan memberi tahu Anda jika bandwidth teoretis tidak tercapai - tetapi ia tidak akan memberi tahu Anda apa pun tentang penundaan yang menyebabkan aplikasi melambat. Bandingkan disk i / o pada 8Gbit - stress test. Itu adalah maksimum yang bisa Anda dapatkan - apa pun X itu. Jika aplikasi mencapai "media" itu mungkin menjadi hambatan Anda. Jika aplikasi tidak mencapai level itu - "bottleneck" bukanlah media. Jika socat maksimal pada 1Gbit, tetapi aplikasi tidak - socat tidak memberi tahu saya apa yang membatasi "throughput".
Michael Felt
3

"Jawaban" saya panjang - kuncinya adalah untuk tidak membingungkan 'throughput' dengan 'bandwidth' - meskipun 'bandwidth' dapat menjadi faktor pembatas

Singkatnya, throughput Anda mungkin terbatas meskipun bandwidth Anda tidak jenuh.

Saya harus membantu orang memahami dampak tumpukan aplikasi multi-tier.

Untuk aspek komunikasi TCP saya menggunakan perbedaan dalam RTT (round-trip-time).

Untuk single-tier Anda dapat membandingkan alamat IP lokal (pada NIC) dengan lo0 (loopback).

Untuk multi-tier Anda membandingkan / menghitung alamat "lebih jauh", misalnya, multi-tier dapat berupa dua VM di host yang sama, atau bisa juga host yang berbeda di pusat data yang sama, atau bisa juga di pusat data yang berbeda (mungkin jaraknya hanya 500 meter, tapi masih beda).

FYI: untuk banyak aplikasi, perbedaan RTT dapat diabaikan, tetapi untuk aplikasi yang melakukan 10-100 dari ribuan pesan kecil untuk waktu aplikasi RTT dapat menjadi hambatan.

(Saya telah melihat situasi di mana "batch membutuhkan waktu hampir 6 jam lebih lama di multi-tier ketika RTT 0,25 milidetik lebih lama, dibandingkan dengan single-tier)

Jadi, test bed sederhana:

Itu

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

Dan program pemantauan saya adalah tcpdump - dengan opsi -ttt

   -ttt
        Prints a delta (in microseconds) between current and previous line on each dump line.

Satu mikrodetik adalah satuan waktu SI yang setara dengan satu juta (0,000001 atau 10−6 atau 1 / 1.000.000). Artinya, 1000 mikrodetik == 1 milidetik.

Jadi, di dua jendela berbeda saya menjalankan tcpdump:

Untuk waktu "lokal": tcpdump -i lo0 -n -ttt port 80 Dan untuk "remote" tcpdump -I en1 -n -ttt port 80

Dalam data di bawah ini - tujuannya bukan untuk melakukan analisis apa pun, tetapi untuk menunjukkan bagaimana Anda dapat mengidentifikasi 'perbedaan' dalam waktu yang dibutuhkan untuk menyelesaikan transaksi. Ketika throughput aplikasi adalah transaksi serial - throughput per "detik | min | jam" dipengaruhi oleh total waktu yang diperlukan untuk "respons". Saya telah menemukan ini paling mudah untuk dijelaskan dengan menggunakan konsep RTT - round-trip-time.

Untuk analisis nyata ada hal-hal tambahan yang perlu dilihat. Jadi, satu-satunya baris yang akan saya perlihatkan adalah jabat tangan TCP awal, dan paket keluar pertama dan ACK yang kembali. Sebagai perbandingan, bandingkan waktu delta berapa lama sebelum "balasan" kembali.

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

perhatikan 01.XXXXXX - untuk satu detik tidur pada antarmuka "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

mesin virtual di host yang sama - perhatikan waktu mulai pukul 00.000000 - paket pertama ditampilkan (dan 01.XXXXXX untuk dua alamat lainnya di bawah)

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

router saya - di luar tuan rumah, bukan mesin virtual.

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

koneksi yang sama dengan 192.168.129.72, tetapi ini 'sibuk' sementara '72' menganggur. Saya berharap bahwa jabat tangan awal hampir identik

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>

banyak hop

ini adalah host yang sama, hasil apache yang sama, tetapi sekarang melalui antarmuka eksternal (6 IP hop, bukan langsung) - sekarang Anda dapat efek RTT jarak jauh. (ps, saya sedikit mengubah alamat IP). Lebih penting - perhatikan bahwa ada dua paket keluar setelah jabat tangan awal sebelum ACK pertama setelah jabat tangan kembali.

Jadi, daripada RTT 25 msec, pikirkan bahwa RTT adalah 250 mikrodetik, dibandingkan dengan 25 mikrodetik - dan Anda memiliki transaksi 500 ribu (yang hanya membutuhkan tambahan 120 hingga 125 detik dibandingkan dengan lokal, dan throughputnya adalah, imho, sebanding. Tetapi dengan 50 juta transaksi (seperti yang saya lakukan dalam situasi kehidupan nyata) Anda mendapatkan tambahan 12500 detik - yang menambahkan sekitar 3,5 jam tambahan untuk "secara harfiah" pekerjaan yang sama (dan bagian dari solusi untuk kasus ini adalah membuat paket lebih besar -. ukuran rata-rata awalnya 400-450 byte).

Ingat, apa yang ingin saya tunjukkan di sini adalah cara yang cukup sederhana untuk menjelaskan perbedaan waktu keseluruhan untuk aplikasi (pekerjaan batch) untuk menyelesaikan ketika membandingkan multi-tier dengan arsitektur single-tier.

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>

Hal lain yang saya "sukai" tentang penggunaan tcpdump adalah program yang tersedia secara umum. Tidak ada tambahan yang perlu diinstal.

Michael Felt
sumber
2
dan bagaimana itu ada hubungannya dengan soket unix?
nonchip