전송 창에 필요한 유용한 전송 속도를 계산한 다음 전체 경로를 측정하십시오. 포트 용량, 왕복 시간, TCP 동작, 스토리지 및 애플리케이션 처리가 모두 결과에 영향을 미칩니다. 현실적인 동시성을 가진 통제된 테스트를 사용하고 네트워크 등급을 선택하기 전에 실제 애플리케이션을 통해 반복하십시오.
전송 창을 속도로 전환합니다.
유용한 애플리케이션 데이터의 양과 이를 전송할 수 있는 시간으로 시작하십시오. 십진 단위를 사용하여 2 TB을 2시간 내에 전송하려면 프로토콜 오버헤드와 중단을 고려하기 전에 대략 278 MB/초의 페이로드, 즉 2.22 Gbps가 필요합니다. 이 계산은 계획 예시이며 측정된 서비스 결과가 아닙니다.
겹치는 전송을 포함하십시오. 예약된 내보내기, 고객 다운로드 및 백업 업로드는 월간 총계가 적당해 보여도 리소스를 공유할 수 있습니다. 월간 평균만이 아니라 혼잡 기간 모델을 작성하십시오. 어느 방향이 중요한지, 실패한 전송이 재시작해야 하는지 재개할 수 있는지 명시하십시오. 그 동작은 시스템이 수행하는 작업량에 영향을 미칩니다.
포트 용량과 유용한 처리량을 분리합니다.
서버 포트는 링크 용량을 나타냅니다. 유용한 처리량은 관찰된 간격 동안 애플리케이션이 전달한 데이터를 나타냅니다. 암호화, 프로토콜 프레이밍, 재전송, 스토리지 활동 및 수신기에서의 작업이 해당 경로의 일부를 차지합니다. 따라서 나열된 10 Gbps 포트가 애플리케이션이 지속적으로 10 Gbps의 페이로드를 전달할 것이라는 것을 입증하지 않습니다.
IETF RFC 6349는 네트워크 경로 테스트와 TCP 성능 검사를 구체적으로 구분합니다. 자체 진단에서 이 분리를 사용하십시오. 먼저 엔드포인트와 경로가 적절한지 확인한 다음 전송 및 애플리케이션을 조사하십시오. 구매한 포트를 늘리는 것은 데이터를 느리게 쓰는 수신기나 한 번에 하나의 요청을 처리하는 애플리케이션을 바로잡지 않습니다.
왕복 시간이 중요한 이유를 이해합니다.
TCP는 승인이 반환되기 전에 얼마나 많은 데이터가 전송 중일 수 있는지 제어합니다. 대역폭-지연 곱이 이에 유용한 척도를 제공합니다. 속도에 왕복 시간을 곱한 값입니다. 왕복 지연이 40밀리초인 가상의 10 Gbps 경로는 약 50 MB가 전송 중임을 나타냅니다. 이 계산은 지연 시간과 전송 동작이 고속 계획에 포함되어야 하는 이유를 설명합니다.
결과는 임의의 소켓 설정을 적용하라는 지시가 아닙니다. 운영 체제, 혼잡 제어, 협상된 창 및 실제 경로가 동작에 영향을 미칩니다. 조정하기 전에 현재 소프트웨어 문서를 확인하고 측정값을 검사하십시오. 더 많은 병렬 연결이 일부 상황에서 총 처리량을 개선할 수 있지만, 애플리케이션이 의존하는 개별 전송의 동작을 숨길 수도 있습니다.
통제된 테스트 매트릭스를 구축합니다.
소유하고 있거나 테스트 권한이 있는 엔드포인트만 사용하십시오. 정상 서비스를 방해하지 않도록 테스트 시간과 속도를 합의하십시오. iperf3 같은 도구는 방향, 지속 시간, 병렬 스트림을 설정할 수 있으며, 공식 문서에서 이러한 제어 항목을 정의합니다. 다른 운영자가 재현할 수 있도록 버전, 엔드포인트, 경로 컨텍스트, 설정을 결과와 함께 기록하십시오.
단일 플로우로 시작한 다음 대표적인 동시성을 추가하십시오. 애플리케이션이 양방향에 의존한다면 양방향 모두 실행하십시오. 이 예시 매트릭스는 단일 대표 결과로는 뒤섞이게 될 질문들을 분리합니다. 원시 결과가 내부 주소나 운영 세부 정보를 노출할 경우 비공개로 보관하고, 의사 결정에 필요한 측정값만 공개하십시오.
| 테스트 | 조사 대상 | 증명하지 않는 것 |
|---|---|---|
| 단일 전송 플로우 | 단일 플로우 경로 동작 | 집계 애플리케이션 전달 |
| 여러 병렬 플로우 | 동시성 및 집계 한도 | 한 고객의 전송 속도 |
| 애플리케이션 전송 | 스토리지, 프로토콜, 소프트웨어 동시 적용 | 모든 데이터셋의 성능 |
| 혼잡 시간대 반복 | 현실적 활동 하의 변동 | 영구 처리량 보장 |
테스트 중 엔드포인트를 확인합니다.
양쪽 끝에서 CPU 사용량, 메모리 압박, 스토리지 활동, 오류 카운터를 기록하십시오. 엔드포인트 관찰이 없는 전송 결과는 실제 제약을 보이지 않게 남길 수 있습니다. 하나의 프로세스나 CPU이 포화 상태인데 다른 것들은 유휴 상태인지 확인하십시오. 여러 설정을 한 번에 변경하면 어떤 조정이 도움이 되었는지 파악하기 어려우므로 피하십시오.
메모리 기반 테스트와 실제 데이터를 읽고 쓰는 테스트를 분리하십시오. 전자는 전송 경로를 조사하는 데 도움이 될 수 있고, 후자는 애플리케이션 작업의 더 많은 부분을 반영합니다. 결과가 크게 다르다면 메모리 기반 수치를 전달 보장으로 취급하지 말고 스토리지와 처리를 점검하십시오. 범위가 명확하다면 두 측정값 모두 유용할 수 있습니다.
현실적인 페이로드로 애플리케이션을 테스트합니다.
HTTP 내보내기, 암호화된 복제 스트림, 파일 전송 세션은 처리 패턴이 다릅니다. 대표적인 파일 크기, 요청 속도, 암호화 설정을 사용하십시오. 사용자가 기다리는 단계라면 첫 바이트가 전송되기 전 데이터 준비에 소요된 시간을 포함하십시오. 첫 응답 지연과 완료 시간을 구분하고, 하나를 다른 것으로 보고하지 마십시오.
변동을 확인할 수 있을 만큼 충분한 간격으로 테스트를 반복하고, 구성을 변경하기 전에 기준선을 유지하십시오. 가상의 2 TB 내보내기의 경우 실제 완료 시간을 2시간 창과 비교하고 중단에 대비한 여유를 두십시오. 근거 없이 포트 용량을 늘리기보다 관찰된 병목에 대응하는 개선을 선택하십시오.
결과를 사용하여 구성을 선택합니다.
유용한 결과물은 근거가 있는 자원 요구사항입니다. 즉 측정된 페이로드 속도, 허용 가능한 완료 시간, 예상 동시성, 알려진 제한 단계입니다. 트래픽 허용량과 CPU 및 스토리지 사양을 포함하여 SwissOctet 네트워크 변형을 이 요구사항과 비교하십시오. 위치만으로는 모든 수신자까지의 경로나 종단 간 지연이 결정되지 않습니다.
배포 후에도 테스트 절차를 유지하십시오. 데이터셋이 커지거나, 소프트웨어가 변경되거나, 사용자가 다른 네트워크로 이동할 때 재사용하십시오. 반복 가능한 기준선은 성능 사고를 더 쉽게 진단하게 하고, 단일 속도 테스트나 광고된 최대치보다 구성 변경에 더 타당한 근거를 제공합니다.
실용 체크리스트.
- 볼륨과 기한으로 페이로드 속도를 계산하십시오.
- 중첩 전송과 방향을 모델링하십시오.
- 승인된 테스트 엔드포인트와 한도를 합의하십시오.
- 단일 플로우, 동시성, 애플리케이션 테스트를 비교하십시오.
- 테스트 중 양쪽 엔드포인트를 관찰하십시오.
- 반복 가능한 기준선과 유용한 여유를 유지하십시오.
중요한 세부 사항.
더 큰 TCP 윈도우가 느린 전송을 항상 해결합니까?+
아니요. 먼저 경로와 엔드포인트를 진단하십시오. 스토리지, CPU, 손실, 애플리케이션 동작이 지배적일 수 있으며, 전송 튜닝은 실제 시스템에 맞아야 합니다.
단일 플로우와 여러 플로우를 왜 테스트합니까?+
서로 다른 질문에 답하기 때문입니다. 집계 용량은 단일 전송 속도보다 높을 수 있으며, 애플리케이션의 동시성이 어떤 결과가 중요한지를 결정합니다.
공용 서버를 대상으로 용량 테스트를 실행할 수 있습니까?+
직접 제어하거나 테스트 권한이 있는 엔드포인트를 사용하십시오. 측정이 무관한 서비스를 방해하지 않도록 지속 시간, 속도, 시점을 합의하십시오.
출처로 이동하세요.
이 참고 자료는 이 가이드의 기술 개념을 뒷받침합니다. 프로덕션 시스템을 변경하기 전에 최신 문서를 확인하세요.
- IETF RFC 6349: TCP 처리량 테스트 프레임워크 datatracker.ietf.org
- ESnet: iperf3 호출 software.es.net
SwissOctet의 편집 지침. 예시는 설명용입니다. 서비스 사양, 사용 가능한 옵션 및 계약 조건은 별도로 확인해야 합니다.