특정 혼잡 알고리즘이 귀하에게 적합한지 테스트하는 방법은 무엇입니까? 대부분의 알고리즘에 대한 대표적인 작업 부하를 쉽게 재현할 수 없는 것 같아서 이 질문을 드립니다.
현재 고려 중인 두 가지 사항이 있지만 더 많은 제안을 받고 싶습니다.
- 출력의 "재전송된 세그먼트"
netstat -s
현재 내 생각은 정체로 인해 일정 비율의 시간 동안 패킷이 삭제될 수 있다는 것입니다. 따라서 삭제된 패킷과 정체 이벤트에 대한 알림을 받는 서버 사이에 1:1 관계가 없을 수도 있지만 느슨한 상관 관계가 있을 수 있습니다. 알고리즘으로 전환하면 패킷 손실이 줄어듭니다.
그래프에는 혼잡으로 인해 재전송되는 세그먼트가 표시됩니까, 아니면 손실이 있는 링크로 제한됩니까? 만일 그것이 사실이라면(내 생각에 그럴 수도 있다), 상황은 아마도 이것이 아주 좋은 척도가 아닐 정도로 더욱 혼란스러울 것이다.
- TCP 연결의 평균 수명을 측정하는 데 사용할 수 있는 측정항목이 있나요?
내 생각에는 TCP 연결이 더 일찍 완료되면(오류 급증이나 패킷 삭제 없이) 데이터가 더 짧은 대기 시간으로 푸시되고 있음을 나타낼 수 있습니다.
답변1
그래프에는 혼잡으로 인해 재전송되는 세그먼트가 표시됩니까, 아니면 손실이 있는 링크로 제한됩니까? 만일 그것이 사실이라면(내 생각에 그럴 수도 있다), 상황은 아마도 이것이 아주 좋은 척도가 아닐 정도로 더욱 혼란스러울 것이다.
segments retransmittednetstat -s귀하의 질문에 나열된 것을 포함하여 어떤 이유로든 모든 커널 TCP 재전송을 포함합니다 . 이러한 이유에는 다음이 포함될 수도 있습니다.
- 링크 오류
- 이더넷 스위치 정체
- Qos 또는 리소스 고갈로 인해 로컬 호스트가 오프라인 상태가 되었습니다.
- 원격 호스트가 오프라인 상태가 됩니다(원격 호스트의 qos/리소스 고갈로 인해 발생했을 수 있음).
성능 테스트 엔지니어는 일반적으로 이러한 모든 변수를 처리하고 적절하게 측정할 수 있는지 확인합니다. 가장 먼저 수행해야 할 테스트 중 하나는 케이블링/네트워크가 관련 패킷 크기 및 트래픽 속도에서 제대로 실행되고 있는지 확인하는 것입니다. 이는 일반적으로 Ixia 또는 Spirent의 장비와 같은 특수 테스트 장비를 사용하여 수행됩니다.
네트워크 성능 기준을 설정한 후에는 필요한 테스트를 실행할 수 있습니다. 네트워크 테스트가 깨끗하더라도 호스트 TCP 테스트 중에 스위치 인터페이스 오류/삭제를 모니터링하여 결과가 왜곡되지 않도록 해야 합니다.
혼잡 조건 생성에 대한 귀하의 생각은 TCP 트래픽을 실행하기 전에 qos 클래스 대기열 임계값 바로 아래에서 iperf UDP 백그라운드 트래픽을 의도적으로 생성하는 것이 도움이 될 수 있습니다. 기존 링크를 포화시킬 수 없는 경우 NIC를 1GE 또는 100M로 낮추는 것도 도움이 될 수 있습니다.
이 모든 것이 복잡하게 들릴 수도 있고 어떤 면에서는 그럴 수도 있습니다. 그러나 모든 시스템 구성 요소에 대한 적절한 주의와 이해를 통해 QoS 테스트는 전적으로 가능합니다.
답변2
간결한 버전:
@ninjalj가 지적했듯이 워크로드 애플리케이션은 특정 조정이 워크로드 성능에 도움이 될지 여부에 대한 권위 있는 소스로 간주되어야 할 것입니다. 요구 사항이 대기 시간인지 시스템의 전체 처리량인지에 따라 동작 변경이 성능 요구 사항을 더 잘 충족하는지 여부를 결정할 수 있습니다.
이 경우 변경을 수행하고 httpd전체 대기 시간이 떨어지는지 관찰합니다.
구체적인 예가 포함된 더 긴 버전:
자세히 설명하기 위해 맥락에 맞게 설명하겠습니다. 아파치를 살펴보자 httpd. 및 지시어를 사용하여 LogFormat요청을 완료하는 데 걸리는 시간(마이크로초)과 각 요청의 크기를 기록 할 수 있습니다 CustomLog. 예를 들어:
LogFormat "%h %m %D %b" perflog
CustomLog /var/log/httpd/performance.log perflog
다음과 유사한 출력이 생성됩니다.
xxx.xxx.28.20 GET 41140 86
xxx.xxx.28.20 GET 34468 28
xxx.xxx.28.20 GET 47612 1434
xxx.xxx.28.20 GET 54860 868
xxx.xxx.28.20 POST 97055 6283
xxx.xxx.28.20 GET 33754 53
xxx.xxx.28.20 GET 68964 8416
xxx.xxx.28.20 GET 1143827 11528
xxx.xxx.28.20 GET 38055 61
xxx.xxx.64.208 HEAD 6255 -
xxx.xxx.28.20 GET 36922 142
xxx.xxx.28.20 GET 51871 5581
나는 GET다음과 같은 요청에만 관심이 있습니다.
root@xxxxxxvlp14 /tmp $ grep GET /var/log/httpd/performance.log > work.log
root@xxxxxxvlp14 /tmp $ sed -i 's/-$/0/g' work.log
root@xxxxxvlp14 /tmp $
(어떤 이유로든 httpd정수 0 대신 하이픈을 제공합니다.)
그런 다음 프로그래밍 방식으로 분리할 수 있습니다.
#!/bin/bash
totalRequests=$(cat /tmp/work.log | wc -l )
totalTime=$(awk 'BEGIN{ count=0 } {count = count + $3} END { print count }' /tmp/work.log)
averageTime=$( printf "%.2f" $(bc -l <<< "$totalTime / $totalRequests "))
minTime=$(sort -nk 3 work.log | head -1 | awk '{print $3}')
maxTime=$(sort -rnk 3 work.log | head -1 | awk '{print $3}')
totalBytes=$(awk 'BEGIN{ count=0 } {count = count + $4} END { print count }' /tmp/work.log)
minBytes=$(sort -nk 4 work.log | head -1 | awk '{print $4}')
maxBytes=$(sort -rnk 4 work.log | head -1 | awk '{print $4}')
echo "Total Requests In Sample: $totalRequests"
echo
echo "Total Time Taken: $totalTime ms (average: $averageTime ms)"
echo "Longest Request: $maxTime ms"
echo "Shortest Request: $minTime ms"
echo
echo "Total Data Moved: $totalBytes bytes"
echo "Largest Request: $maxBytes bytes"
echo "Smallest Request: $minBytes bytes"
스크립트에 대해 언급하지 마십시오. 효율성보다는 명확성을 위해 작성되었습니다. 위의 결과는 다음과 같습니다.
Total Requests In Sample: 207
Total Time Taken: 15138613 ms (average: 73133.40 ms)
Longest Request: 1143827 ms
Shortest Request: 1788 ms
Total Data Moved: 409825 bytes
Largest Request: 20476 bytes
Smallest Request: 0 bytes
위의 내용은 긴 샘플을 얻는 것이 왜 중요한지 분명히 보여줍니다. 하지만 숫자는 정확합니다(이 1분 30초 요청은 누군가가 호기심을 충족시키기 위해 이미지/차트를 포함하여 Word 형식으로 보고서를 생성하도록 요청한 것입니다).
따라서 Apache가 정상적인 활동의 긴 샘플(아마 하루 동안)을 제공하도록 유도하고, 변경하고, 로그를 회전한 다음, 다시 로그 수집을 시작합니다(예: 24시간 더 대기).
각 서비스(NFS, 기타 HTTP 서버, Samba, FTP 서버 등)에는 고유한 정보 수집 방법이 있지만 일반적으로 다음과 같은 방법이 있습니다.일부시간과 처리량을 기록하는 방법.