Ổ cắm unix cục bộ - ý tưởng sơ bộ về thông lượng

Có ai biết về các tiêu chuẩn / phép đo thông lượng để sử dụng ổ cắm unix cục bộ để liên lạc giữa các quá trình không?

Tôi muốn minh họa lợi ích hiệu năng của việc có một cá thể cơ sở dữ liệu cục bộ trên cùng một máy chủ với phần mềm yêu cầu dữ liệu từ cơ sở dữ liệu so với việc phải giao tiếp qua một liên kết mạng, đặc biệt là một mạng như gigabit Ethernet mà tôi dự kiến ​​sẽ khá chậm nói tương đối.

Khi tìm kiếm trực tuyến tôi đã tìm thấy một số điểm chuẩn hiển thị số lượng hoạt động mỗi giây, nhưng không phải thông lượng mỗi giây (tức là 12GB / giây).

Tôi hiểu rằng hiệu suất sẽ thay đổi do những thứ như có lẽ thông lượng bộ nhớ trên một hệ thống nhất định hoặc các đặc điểm phần cứng khác, nhưng chỉ cần một ý tưởng sơ bộ.

Điều này không đề cập đến hiệu suất TCP cục bộ hoặc so sánh với điều đó.

Bạn có thể sử dụng socat cho một bài kiểm tra tốc độ ổ cắm UNIX đơn giản.

Dưới đây là kết quả tôi nhận được trên máy tính xách tay của mình:

#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

Bộ nhớ vào đĩa (SSD), thông qua ổ cắm 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

Bộ nhớ vào bộ nhớ, thông qua ổ cắm 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

Bộ nhớ tới / dev / null (loại bỏ), thông qua ổ cắm 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, thông qua ổ cắm 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

Như bạn có thể thấy thông lượng kiểm tra "bộ nhớ vào đĩa" thậm chí là 545MB / s (tức là ~ 4360MiB / s), vượt xa thông lượng lý thuyết tối đa cho kết nối ethernet 1GB (tức là ~ 1000/8 = 125MB / s, thậm chí không xem xét bất kỳ chi phí giao thức nào).

PS

Xin lưu ý rằng đây chỉ là một thử nghiệm đơn giản sử dụng một số công cụ đơn giản và không phải là điểm chuẩn thực sự, phù hợp .

"Câu trả lời" của tôi rất dài - chìa khóa của họ là không nhầm lẫn giữa 'thông lượng' với 'băng thông' - mặc dù 'băng thông' có thể là một yếu tố hạn chế

Nói tóm lại, thông lượng của bạn có thể bị giới hạn mặc dù băng thông của bạn không bão hòa.

Tôi đã phải giúp mọi người hiểu tác động của ngăn xếp ứng dụng nhiều tầng.

Đối với khía cạnh truyền thông TCP, tôi sử dụng các khác biệt trong RTT (khứ hồi).

Đối với một lớp, bạn có thể so sánh địa chỉ IP cục bộ (trên một NIC) với lo0 (loopback).

Đối với nhiều tầng, bạn so sánh / tính toán các địa chỉ "xa hơn", ví dụ, nhiều tầng có thể là hai VM trong cùng một máy chủ hoặc có thể là các máy chủ khác nhau trong cùng một trung tâm dữ liệu hoặc chúng có thể ở các trung tâm dữ liệu khác nhau (có thể chỉ khoảng cách 500 mét, nhưng vẫn khác nhau).

FYI: đối với nhiều ứng dụng, sự khác biệt RTT là không đáng kể, nhưng đối với các ứng dụng thực hiện 10 - 100 trong số hàng ngàn tin nhắn nhỏ cho thời gian RTT của ứng dụng có thể trở thành nút cổ chai.

(Tôi đã thấy các tình huống trong đó "đợt này mất nhiều hơn 6 giờ trong nhiều tầng khi RTT dài hơn 0,25 millisec, so với một tầng)

Vì vậy, giường thử nghiệm đơn giản:

Các

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

Và chương trình giám sát của tôi là tcpdump - với tùy chọn -ttt

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

Một phần triệu giây là một đơn vị thời gian SI bằng một phần triệu (0,000001 hoặc 10−6 hoặc 1 / 1.000.000). Tức là, 1000 micro giây == 1 mili giây.

Vì vậy, trong hai cửa sổ khác nhau, tôi có chạy tcpdump:

Đối với thời gian "cục bộ": tcpdump -i lo0 -n -ttt port 80 Và cho "tcpdump" từ xa -I en1 -n -ttt port 80

Trong dữ liệu dưới đây - mục tiêu không phải là thực hiện bất kỳ phân tích nào, mà là cho thấy cách bạn có thể xác định 'sự khác biệt' trong thời gian cần thiết để giao dịch hoàn tất. Khi thông lượng ứng dụng là các giao dịch nối tiếp - thông lượng trên mỗi "giây | phút | giờ" bị ảnh hưởng bởi tổng thời gian cần thiết cho "phản hồi". Tôi đã tìm thấy điều này dễ nhất để giải thích bằng cách sử dụng khái niệm RTT - khứ hồi.

Đối với một phân tích thực sự có những điều bổ sung để xem xét. Vì vậy, các dòng duy nhất tôi sẽ hiển thị là bắt tay TCP ban đầu và gói gửi đi đầu tiên và ACK trả về. Để so sánh so sánh thời gian delta của khoảng thời gian trước khi "trả lời" trở lại.

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

lưu ý 01.XXXXXX - trong một giây ngủ trên giao diện "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

máy ảo trong cùng một máy chủ - lưu ý thời gian bắt đầu lúc 00.000000 - gói đầu tiên được hiển thị (và 01.XXXXXX cho hai địa chỉ khác bên dưới)

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

bộ định tuyến của tôi - bên ngoài máy chủ, không phải máy ảo.

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

cùng kết nối với 192.168.129.72, nhưng đây là 'bận' trong khi '72' không hoạt động. Tôi hy vọng rằng những cái bắt tay ban đầu gần như giống hệt nhau

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>

nhiều bước nhảy

đây là cùng một máy chủ, cùng một kết quả apache, nhưng bây giờ thông qua giao diện bên ngoài (6 bước IP, thay vì trực tiếp) - bây giờ bạn có thể tạo ra hiệu ứng của RTT đường dài. (ps, tôi đã sửa đổi địa chỉ IP một chút). Quan trọng hơn - lưu ý rằng có hai gói đi sau khi bắt tay ban đầu trước ACK đầu tiên sau khi bắt tay trở lại.

Vì vậy, thay vì RTT 25msec, hãy nghĩ rằng RTT là 250 micro giây, so với 25 micro giây - và bạn có 500k giao dịch (chỉ tăng thêm 120 đến 125 giây so với cục bộ và thông lượng là, imho, có thể so sánh được. 50 triệu giao dịch (như tôi đã có trong một tình huống thực tế) bạn có thêm 12500 giây - thêm khoảng 3,5 giờ nữa cho "nghĩa đen" cùng một công việc. (Và một phần của giải pháp cho trường hợp này là làm cho các gói lớn hơn - kích thước trung bình ban đầu là 400-450 byte).

Xin nhắc lại, những gì tôi muốn trình bày ở đây là một cách khá đơn giản để tính đến sự khác biệt về thời gian tổng thể cho một ứng dụng (công việc hàng loạt) hoàn thành khi so sánh kiến ​​trúc nhiều tầng với kiến ​​trúc một tầng.

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>

Một điều nữa tôi "thích" về việc sử dụng tcpdump là chương trình thường có sẵn. Không có gì cần phải cài đặt thêm.