로컬 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
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)입니다. 이는 1GB 이더넷 연결의 이론상 최대 처리량(예: ~ 1000/8 = 125MB/s)보다 훨씬 높습니다. , 프로토콜 오버헤드도 고려하지 않음).
폴리스티렌
이는 실제 테스트가 아닌 몇 가지 간단한 도구를 사용한 간단한 테스트일 뿐이라는 점을 참고하시기 바랍니다.적절한기준.
답변2
내 "대답"은 길다. 핵심은 "처리량"과 "대역폭"을 혼동하지 않는 것이다. "대역폭"이 제한 요소가 될 수 있지만
즉, 대역폭이 포화되지 않은 경우에도 처리량이 제한될 수 있습니다.
사람들이 다중 계층 애플리케이션 스택의 영향을 이해하도록 도와야 합니다.
TCP 통신 측면에서는 RTT(왕복 시간)의 차이를 활용했습니다.
단일 레이어의 경우 로컬 IP 주소(NIC의)를 lo0(루프백)과 비교할 수 있습니다.
다중 계층의 경우 "추가" 주소를 비교/계산할 수 있습니다. 예를 들어 다중 계층은 동일한 호스트에 있는 두 개의 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밀리초입니다.
그래서 두 개의 다른 창에서 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에서 시작됩니다. 표시된 첫 번째 패킷(아래의 다른 두 주소는 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가 돌아오기 전에 초기 핸드셰이크 이후 두 개의 나가는 패킷이 있다는 점입니다.
따라서 RTT는 25마이크로초에 비해 25밀리초 RTT가 아니라 250마이크로초입니다. 그리고 500,000개의 트랜잭션이 있고(로컬에 비해 120~125초 더 많음) 처리량은 비슷하지만 5천만 트랜잭션이 실제 사례와 같습니다. 수명) 추가 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 사용에 대해 제가 "좋아하는" 또 다른 점은 이것이 보편적으로 사용 가능한 프로그램이라는 것입니다. 추가로 아무것도 설치할 필요가 없습니다.