기준 버전: 성능이 매우 낮은 애플리케이션
업데이트를 계산하는 데 사용되는 초기 성능이 저하된 코드 샘플은 다음과 같습니다.
메모
간단히 하기 위해 다음 예제에서는 오류 처리가 없습니다. 모든 프로덕션 애플리케이션은 항상 반환 값을 확인합니다.
경고
애플리케이션의 처음 몇 가지 예제는 코드 변경으로 가능한 성능 향상을 설명하기 위해 의도적으로 성능 저하를 제공합니다. 애플리케이션에서 이러한 코드 샘플을 사용하지 마세요. 설명 용도로만 사용됩니다.
#include <windows.h>
BOOL Map[ROWS][COLS];
void LifeUpdate()
{
ComputeNext( Map );
for( int i = 0 ; i < ROWS ; ++i ) //serialized
for( int j = 0 ; j < COLS ; ++j )
Set( i, j, Map[i][j] ); //chatty
}
BYTE Set(row, col, bAlive)
{
SOCKET s = socket(...);
BYTE byRet = 0;
setsockopt( s, SO_SNDBUF, &Zero, sizeof(int) );
bind( s, ... );
connect( s, ... );
send( s, &row, 1 );
send( s, &col, 1 );
send( s, &bAlive, 1 );
recv( s, &byRet, 1 );
closesocket( s );
return byRet;
}
이 상태에서 애플리케이션에는 최악의 네트워크 성능이 있습니다. 이 버전의 샘플 애플리케이션의 문제는 다음과 같습니다.
- 애플리케이션이 수다스럽습니다. 각 트랜잭션이 너무 작기 때문에 셀을 하나씩 업데이트할 필요가 없습니다.
- 셀을 동시에 업데이트할 수 있더라도 트랜잭션은 엄격하게 직렬화됩니다.
- 송신 버퍼는 0으로 설정되고 애플리케이션은 각 송신에 대해 200밀리초의 지연을 발생합니다( 셀당 세 번).
- 응용 프로그램은 각 셀마다 한 번씩 연결하는 빈도가 매우 높습니다. 애플리케이션은 TIME-WAIT 상태 때문에 지정된 대상에 대한 초당 연결 수로 제한되지만 각 트랜잭션이 600밀리초를 초과하므로 여기서는 문제가 되지 않습니다.
- 애플리케이션이 비효율적입니다. 많은 셀이 업데이트될 때마다 변경되지 않으므로 많은 트랜잭션이 서버 상태에 영향을 주지 않습니다.
- 애플리케이션은 잘못된 스트리밍을 표시합니다. 작은 송신은 많은 CPU 및 RAM을 사용합니다.
- 애플리케이션은 송신 시 리틀 엔디언(little-endian) 표현을 가정합니다. 이는 현재 Windows 플랫폼에 대한 자연스러운 가정이지만 수명이 긴 코드에는 위험할 수 있습니다.
주요 성능 메트릭
다음 성능 메트릭은 RTT(왕복 시간), Goodput 및 프로토콜 오버헤드로 표현됩니다. 이러한 용어에 대한 설명은 네트워크 용어 항목을 참조하세요.
- 단일 셀 업데이트의 셀 시간, 즉 네트워크 시간은 Nagle 알고리즘 및 지연된 ACK 응답 상호 작용에 대해 4*RTT + 600밀리초가 필요합니다.
- Goodput은 6바이트 미만입니다.
- 프로토콜 오버헤드는 99.6%.
관련 항목