네트워크 대기 시간 : 100Mbit 대 1Gbit

현재 100Mbit로 연결된 웹 서버가 있으며 공급자가 1Gbit로 업그레이드를 제공합니다. 처리량과 관련이 있지만 패킷이 클수록 전송 속도도 빨라지므로 응답 시간 (예 : 핑)이 약간 줄어들 것으로 예상합니다. 아무도 이것을 벤치마킹 한 적이 있습니까?

30 바이트로드의 예 (100mbit ~ 100mbit 서버) :

> ping server -i0.05 -c200 -s30
[...]
200 packets transmitted, 200 received, 0% packet loss, time 9948ms
rtt min/avg/max/mdev = 0.093/0.164/0.960/0.093 ms

300 바이트로드 (MTU 미만)의 예 (100mbit ~ 100mbit 서버) :

> ping server -i0.05 -c200 -s300
[...]
200 packets transmitted, 200 received, 0% packet loss, time 10037ms
rtt min/avg/max/mdev = 0.235/0.395/0.841/0.078 ms

따라서 평균 30에서 300 사이입니다. 대기 시간이 0.164에서 0.395로 증가-1 기가비트에서 1 기가비트 연결의 경우 속도가 느려질 것으로 예상합니다. 연결이 전체 패킷을 수신 할 때까지 기다리는 스위치를 통해 연결하는 경우 100mbit에서 1gbit가 더 빠를 것으로 기대합니다.

업데이트 : 답변에 대한 의견을주의 깊게 읽으십시오! 연결이 포화되지 않았 으므로이 속도 증가가 한 번의 요청으로 사람에게 중요하다고 생각하지 않지만 많은 요청 (Redis, Database 등)이 발생합니다.

@LatinSuD의 답변과 관련하여 :

> ping server -i0.05 -c200 -s1400
200 packets transmitted, 200 received, 0% packet loss, time 9958ms
rtt min/avg/max/mdev = 0.662/0.866/1.557/0.110 ms

현재 100Mbit 링크가 포화 상태 인 경우 대기 시간이 눈에 띄게 줄어드는 유일한 방법입니다. 포화 상태가 아닌 경우 아무런 변화가 없습니다.

또한 1Gbit 링크가 더 큰 패킷을 지원할 수 있다는 가정은 올바르지 않습니다. 최대 패킷 크기는 서버의 NIC부터 고객 컴퓨터의 MTU까지 패킷이 이동하는 경로를 따라 다양한 장치의 MTU에 의해 결정됩니다. 내부 LAN 응용 프로그램 (경로를 따라 모든 장치를 제어 할 수있는 경우)에서 MTU를 늘릴 수는 있지만이 상황에서는 기본 MTU 1500이 거의 고정되어 있습니다. 결국 조각화되어 실제로 성능이 저하됩니다.

예 gbit는 다음과 같은 이유로 대기 시간이 짧습니다.

• 더 빠른 시간에 같은 수의 바이트를 전송할 수 있습니다

그러나 패킷의 크기가 특정 크기 인 경우 에만 개선이 가능 합니다.

• 56 바이트 패키지 => 사실상 더 빠른 전송 없음
• 1000 바이트 패키지 => 20 % 더 빠른 전송
• 20000 바이트 패키지 => 80 % 더 빠른 전송

따라서 대기 시간에 매우 민감한 응용 프로그램 (4ms 대 0.8ms, 왕복 20kb)이 더 큰 패키지를 전송 해야하는 경우 100mbit에서 gbit로 전환하면 대기 시간이 줄어 듭니다. 평균 100mbit / s보다 훨씬 적습니다 (= 링크가 영구적으로 포화되지 않음).

서버 (100mbit)-> 스위치 (gbit)-> 서버 (100mbit) :

size: 56 :: rtt min/avg/max/mdev = 0.124/0.176/0.627/0.052 ms
size: 100 :: rtt min/avg/max/mdev = 0.131/0.380/1.165/0.073 ms
size: 300 :: rtt min/avg/max/mdev = 0.311/0.463/2.387/0.115 ms
size: 800 :: rtt min/avg/max/mdev = 0.511/0.665/1.012/0.055 ms
size: 1000 :: rtt min/avg/max/mdev = 0.560/0.747/1.393/0.058 ms
size: 1200 :: rtt min/avg/max/mdev = 0.640/0.830/2.478/0.104 ms
size: 1492 :: rtt min/avg/max/mdev = 0.717/0.782/1.514/0.055 ms
size: 1800 :: rtt min/avg/max/mdev = 0.831/0.953/1.363/0.055 ms
size: 5000 :: rtt min/avg/max/mdev = 1.352/1.458/2.269/0.073 ms
size: 20000 :: rtt min/avg/max/mdev = 3.856/3.974/5.058/0.123 ms

서버 (gbit)-> 스위치 (gbit)-> 서버 (gbit) :

size: 56 :: rtt min/avg/max/mdev = 0.073/0.144/0.267/0.038 ms
size: 100 :: rtt min/avg/max/mdev = 0.129/0.501/0.630/0.074 ms
size: 300 :: rtt min/avg/max/mdev = 0.185/0.514/0.650/0.072 ms
size: 800 :: rtt min/avg/max/mdev = 0.201/0.583/0.792/0.079 ms
size: 1000 :: rtt min/avg/max/mdev = 0.204/0.609/0.748/0.078 ms
size: 1200 :: rtt min/avg/max/mdev = 0.220/0.621/0.746/0.080 ms
size: 1492 :: rtt min/avg/max/mdev = 0.256/0.343/0.487/0.043 ms
size: 1800 :: rtt min/avg/max/mdev = 0.311/0.672/0.815/0.079 ms
size: 5000 :: rtt min/avg/max/mdev = 0.347/0.556/0.803/0.048 ms
size: 20000 :: rtt min/avg/max/mdev = 0.620/0.813/1.222/0.122 ms

= 평균 20kb 핑에서 여러 서버에 걸쳐 80 % 대기 시간 단축

링크 중 하나만 gbit 인 경우 20kb 핑에 대해 대기 시간이 5 % 줄어 듭니다.

대역폭 지연과 "속도"에 대한 근본적인 오해가 있다고 생각합니다. 속도는 대역폭과 대기 시간의 함수입니다. 예를 들어, 도착하는 데 3 일이 걸리는 전국 DVD 배송 데이터를 고려하십시오. 인터넷을 통해 데이터를 보내는 것과 비교해보십시오. 인터넷은 대기 시간 연결이 훨씬 낮지 만 발송물의 연결 속도와 일치하려면 초당 9.6MB ( 이 소스의 참조 예)를 수신해야합니다 .

귀하의 경우 더 높은 대역폭으로 업그레이드하면 더 많은 동시 사용자에게 서비스를 제공 할 수 있지만 개별 사용자의 대기 시간은 개선되지 않습니다.

당신은 핀홀을 통해 세상을보고 있습니다. 서로 다른 속도에서의 대기 시간 차이에 대한 유효한 테스트는 교차 연결 케이블로 연결된 두 개의 동일한 NIC 사이입니다. NIC 계산 속도를 10mb, 100mb 및 1000mb로 설정하십시오. 이것은 다른 속도에서 대기 시간의 차이가 거의 없음을 보여줍니다. 사용되는 최대 대역폭에 관계없이 모든 패킷이 동일한 회선 속도로 이동합니다. 저장 및 전달 캐싱으로 스위치를 추가하면 모든 것이 변경됩니다. 스위치를 통한 테스트 대기 시간은 스위치에 두 번만 연결하여 수행해야합니다. 다른 트래픽은 테스트 대기 시간에 영향을 줄 수 있습니다. 이 경우에도 스위치가 롤오버 로그, 패킷 유형 카운터 조정, 내부 시계 업데이트 등을 수행 할 수 있습니다. 모든 것이 대기 시간에 영향을 줄 수 있습니다.

예. 하드웨어 변경, 다른 NIC, 다른 스위치, 다른 드라이버로 인해 100mb에서 1gb로 전환하는 것이 더 빠를 수 있습니다 (대기 시간 단축). 다른 변경 사항보다 드라이버 차이로 인해 핑 대기 시간이 크게 변경되었습니다. 대역폭, 스위치, 오프로드 NIC 등

이 스위치는 단일 전송 테스트의 저장 및 전달보다 컷-스루가 훨씬 빠른 다음으로 가장 큰 변화입니다. 그러나 잘 설계된 저장 및 전달 스위치는 높은 부하에서 전체 성능에서 컷 스루 스위치를 능가 할 수 있습니다. 기가비트 초기에는 저렴한 기가비트 스위치보다 대기 시간이 짧은 10MB 고성능 백플레인 스위치가 나타났습니다.

Ping 테스트는 인터넷을 사용할 때 성능 분석에 실제로 관련이 없습니다. 그들은 시험 순간에 운송에 무슨 일이 일어나고 있는지에 대한 야구장 아이디어를 얻기 위해 빠른 시험입니다. 생산 성능 테스트는 단순한 Ping보다 훨씬 복잡합니다. 고성능 스위치는 컴퓨터이며 고부하 상태에서 다르게 동작합니다 (지연 시간의 변화).

NIC 속도가 느리거나 NIC 속도가 느리면 스위치 캐시를 사용하여 서버에 대한 입력을 조절하여 동시 버스트가있는 서버를 실제로 도울 수 있습니다. 단일 재전송은 대기 시간 감소를 무효화 할 수 있습니다. 일반적으로 단일 핑 테스트가 아닌 중간 수준에서 높은 수준의 트래픽 수준이 중요합니다. 예를 들어 오래된 느린 Sun Ultrasparc (단일 핑의 대기 시간 증가)은 70 % 100mb 대역폭 미만에서 dev 서버로 사용되는 저렴한 새 기가비트 데스크탑보다 성능이 뛰어납니다. 데스크탑은 더 빠른 gb NIC, 더 빠른 연결 gb-gb, 더 빠른 메모리, 더 많은 메모리, 더 빠른 디스크 및 더 빠른 프로세서를 갖지만 튜닝 된 서버급 하드웨어 / 소프트웨어만큼 작동하지 않습니다. 이것은 gb-gb를 실행하는 현재 튜닝 된 서버가 이전 하드웨어보다 빠르지 않으며 더 큰 처리량 부하를 처리 할 수 ​​있다는 것입니다. "의 문제는 더 복잡합니다

공급자가 100mb와 1gb 연결에 서로 다른 스위치를 사용하고 있는지 확인하십시오. 이들이 동일한 스위치 백플레인을 사용하는 경우 트래픽 수준이 낮은 대역폭을 초과 한 경우에만 증가 비용을 지불합니다. 그렇지 않으면 단시간에 많은 다른 사용자가 기가비트로 전환하고 이전 스위치에 남아있는 소수의 사용자가 더 높은 성능을 갖습니다. 스위치에 대한 높은 부하 (서버뿐만 아니라 전체 스위치로드 동안 대기 시간 감소) ).

Apples and oranges 예제 : 로컬 ISP는 번들 서비스, DSL 및 전화를위한 새로운 스위치를 제공했습니다. 처음에는 성능이 향상되었습니다. 시스템이 과매도되었습니다. 이제 기존 스위치를 사용하는 사용자는 일관된 성능을 유지합니다. 늦은 밤에는 새 시스템의 사용자가 더 빠릅니다. 저녁에는 고부하 상태에서 기존 스위치 클라이언트가 새로 오버로드 된 시스템보다 성능이 뛰어납니다.

낮은 대기 시간이 항상 빠른 전달과 관련이있는 것은 아닙니다. 단일 페이지를 제공하기위한 20 개의 요청에서 MySQl을 언급했습니다. 해당 트래픽은 페이지 요청과 동일한 NIC에 없어야합니다. 모든 내부 트래픽을 내부 네트워크로 이동하면 발신 NIC의 충돌 및 총 패킷 수를 줄이고 단일 패킷의 .04ms 대기 시간 이득보다 더 큰 이득을 제공합니다. 페이지 당 대기 시간을 줄이려면 페이지 당 요청 수를 줄이십시오. 페이지, html, css, javascript, 이미지를 압축하여 페이지로드 시간을 줄이십시오. 이 세 가지 변경 사항은 0.04ms의 대기 시간 감소에 사용되지 않는 대역폭을 지불하는 것보다 지속적인 전체적인 이점을 제공합니다. 핑은 24 시간 동안 실행되어야하며 실제 대기 시간 변화를보기 위해 평균화되어야합니다. 스마트 스위치는 이제 초기 대역폭이 약간 증가하고 전송이 크게 조정되어 적응 형 RTSP 유형 조절을 수행합니다. 페이지 크기 (그래픽, 큰 html / css / javascript)에 따라 초기 연결 대기 시간 / 대역폭이 큰 페이지 나 전체 페이지 전송보다 훨씬 낮거나 높을 수 있습니다. 페이지의 일부가 스트리밍중인 경우 페이지와 스트림간에 성능이 크게 다를 수 있습니다.

300 바이트 패킷을 가정 해 봅시다 (사용 -s 300하면 헤더 때문에 실제로 더 클 것입니다).

300 bytes = 2400 bits
2400 bits / 100Mbit/sec = 0.024ms

0.024ms는 대략 프레임 전송에 필요한 실제 시간입니다 (매체 액세스 시간이나 헤더는 포함하지 않음).

탁구 시퀀스에서는 두 배 (0.048ms)와 OS가 쿼리를 처리하는 시간이 더 걸립니다.

이는 대기 시간이 여러 오버 헤드 요소의 90 %로 인해 발생한다는 것을 의미합니다. Gb와 큰 차이가 있는지 확실하지 않습니다. 아마도 1ms 미만의 차이는 웹 서버에서 눈에 띄지 않습니다.

어쨌든 1400 바이트와 같은 정말 큰 패킷으로 시도해 볼 수 있습니까?

연결하려는 스위치 유형에 따라 다릅니다. Crisco와 같은 일부 공급 업체 (Cisco를 의미)에서는 ICMP 패킷이 CPU로 다시 흐릅니다 ( gag ).

100Mbps 및 1Gbps 링크를 사용하여 호스트 간 테스트를 수행하는 것이 더 나은 테스트 일 수 있습니다 (즉, 호스트 간 전환 또는 호스트 간 라우팅 테스트가 아님).

하루가 끝나면 대기 시간이 스위치의 전달 속도와 스위치 아키텍처의 특정 사항 (ASIC가 보드에 배치되는 위치, 라인 카드 간 잠금 처리 방법 등)으로 내려갑니다. 당신의 테스트와 함께 행운을 빈다.