Unreal Engine - Push Model Networking

1. 컴파일 스위치 bWithPushModel#

WITH_PUSH_MODEL 매크로는 Target.cs의 bWithPushModel로 정해진다. 기본값은 Editor 타깃일 때만 true다.

1
[RequiresUniqueBuildEnvironment]
2
public bool bWithPushModel
3
{
4
  get => bWithPushModelOverride ?? (Type == TargetType.Editor);
5
  set => bWithPushModelOverride = value;
6
}

PIE와 에디터 바이너리로 띄운 서버에서는 Push Model 코드가 컴파일돼 있지만, 패키지한 Game이나 Server 타깃에서는 기본적으로 빠진다. 이때 MARK_PROPERTY_DIRTY 계열 매크로는 빈 매크로가 되고 Net.IsPushModelEnabled CVar도 존재하지 않는다. PIE에서 확인한 Push Model 동작이 패키지 빌드에서는 조용히 폴링으로 바뀌는 셈이다. 패키지 빌드에서 쓰려면 해당 타깃에 직접 켠다.

1
bWithPushModel = true;

이 프로퍼티에는 [RequiresUniqueBuildEnvironment]가 붙어 있어서 Unique Build Environment를 쓰는 타깃에서만 바꿀 수 있다. 그리고 Unique Build Environment 타깃은 런처판(설치형) 엔진에서 빌드할 수 없다(Programs/UnrealBuildTool/Configuration/Rules/RulesAssembly.cs). 데디케이티드 서버 타깃은 원래 소스 엔진에서 빌드하므로 서버 쪽에서는 큰 제약이 아니다. 리슨 서버처럼 Game 타깃이 서버 역할을 하는 구성이라면 Game 타깃에도 같은 설정이 필요하다.

2. 런타임 CVar Net.IsPushModelEnabled#

1
bool bIsPushModelEnabled = false;
2
FAutoConsoleVariableRef CVarIsPushModelEnabled(
3
  TEXT("Net.IsPushModelEnabled"),
4
  bIsPushModelEnabled, ...);

기본값이 false이고 엔진 기본 ini에서도 켜지 않는다. 보통 DefaultEngine.ini에 넣는다.

1
[SystemSettings]
2
net.IsPushModelEnabled=1
3
net.PushModelSkipUndirtiedReplication=1

두 번째 줄의 net.PushModelSkipUndirtiedReplication은 Push Model을 켜는 스위치가 아니라, 켠 뒤에 쓸 수 있는 별도 최적화다. 무엇을 건너뛰는지는 아래 절에서 다룬다.

Net.IsPushModelEnabled 값은 클래스의 FRepLayout을 만들 때 읽힌다. FRepLayout은 NetDriver별, 클래스별로 한 번 만들어 캐시하므로 세션 도중에 콘솔로 바꿔도 이미 복제 중인 클래스에는 반영되지 않는다. 실험에서는 조건마다 서버 프로세스를 새로 띄웠다.

3. 프로퍼티 등록 bIsPushBased#

1
void AMyActor::GetLifetimeReplicatedProps(TArray<FLifetimeProperty>& OutLifetimeProps) const
2
{
3
  Super::GetLifetimeReplicatedProps(OutLifetimeProps);
4

5
  FDoRepLifetimeParams Params;
6
  Params.bIsPushBased = true;
7
  DOREPLIFETIME_WITH_PARAMS_FAST(AMyActor, Health, Params);
8
  DOREPLIFETIME_WITH_PARAMS_FAST(AMyActor, Ammo, Params);
9
}

MARK_PROPERTY_DIRTY 계열 매크로는 NetCore 모듈에 있으므로 Build.cs에 의존성을 추가한다. 빠뜨리면 링크 오류가 난다.

등록 매크로는 이름이 비슷하지만 push로 등록할 수 있는 것은 FDoRepLifetimeParams를 받는 계열뿐이다(Engine/Public/Net/UnrealNetwork.h).

DOREPLIFETIME_CONDITION과 DOREPLIFETIME_CONDITION_NOTIFY는 조건을 받지만 내부에서 FDoRepLifetimeParams를 새로 만들어 조건만 채우므로 bIsPushBased는 false로 남는다. 기존 코드를 push로 옮길 때는 이 매크로를 DOREPLIFETIME_WITH_PARAMS_FAST로 바꾸고 Params.Condition과 Params.RepNotifyCondition을 직접 채운다.

1
FDoRepLifetimeParams Params;
2
Params.bIsPushBased = true;
3
Params.Condition = COND_OwnerOnly;
4
DOREPLIFETIME_WITH_PARAMS_FAST(AMyActor, Ammo, Params);

_FAST라는 이름 때문에 복제가 빨라질 것 같지만 차이는 등록할 때만 난다. GetLifetimeReplicatedProps는 FRepLayout을 만들 때 CDO에서 불리므로(RepLayout.cpp의 FRepLayout::InitFromClass) NetDriver별, 클래스별로 한 번 실행된다. 실제로 갈리는 것은 실수가 드러나는 시점이다. _FAST는 RepIndex를 ENetFields_Private enum에서 읽는데, 이 enum에는 복제 프로퍼티만 들어 있어서 Replicated가 빠진 프로퍼티를 넘기면 컴파일 오류가 난다. _FAST가 없는 쪽은 실행 중에 이름으로 프로퍼티를 찾고, Replicated가 아니면 Fatal 로그를 남기고 멈춘다. 이 검사는 Shipping과 Test 빌드에서는 빠진다.

정적 배열은 _FAST로 등록하면 컴파일되지 않는다. UHT가 정적 배열에는 Name_STATIC_ARRAY와 Name_STATIC_ARRAY_END 항목만 만들기 때문이다. 그래서 DOREPLIFETIME_WITH_PARAMS_FAST_STATIC_ARRAY를 써야 한다. _FAST가 없는 매크로는 프로퍼티의 ArrayDim을 읽어 배열 원소 전체를 알아서 등록한다.

부모 클래스가 등록한 프로퍼티를 자식 클래스에서 다른 파라미터로 다시 등록하면 개발 빌드에서 check에 걸린다. 같은 RepIndex로 두 번 등록할 때 조건과 bIsPushBased가 같아야 하기 때문이다(CoreUObject/Public/UObject/CoreNet.h의 FLifetimeProperty::operator==). 등록을 바꾸려면 RESET_REPLIFETIME_WITH_PARAMS를 쓴다. 다만 이 매크로로 ACharacter의 프로퍼티를 push로 바꾸는 것은 캐릭터를 Full 클래스로 만드는 방법이 되지 못한다. ACharacter의 프로퍼티를 쓰는 엔진 코드에는 MARK_PROPERTY_DIRTY 호출이 없으므로, push로 바꾼 프로퍼티는 초기 복제 이후의 변경을 보내지 않게 된다.

bIsPushBased는 프로퍼티별 설정이지만 그 효과는 클래스 단위로도 갈린다. FRepLayout은 부모 클래스에서 물려받은 것까지 포함해 모든 복제 프로퍼티가 push 기반인 클래스에 ERepLayoutFlags::FullPushProperties를 붙이고, 일부만 push 기반이면 PartialPushSupport를 붙인다.

이 글에서는 앞의 경우를 Full 클래스, 뒤의 경우를 Partial 클래스라고 부른다. push가 아닌 프로퍼티가 하나만 섞여도 Partial 클래스다. 뒤에서 볼 skip CVar는 Full 클래스에서만 동작한다.

GetLifetimeReplicatedProps에서 등록을 빠뜨린 복제 프로퍼티도 Partial의 원인이 된다. 엔진은 빠진 프로퍼티를 기본 설정으로 자동 등록하는데, 기본 설정의 bIsPushBased는 false다(CoreUObject/Public/UObject/CoreNet.h의 FLifetimeProperty, RepLayout.cpp의 DefaultLifetimeProp). 기본 설정에서는 경고도 없다.

빠뜨린 프로퍼티를 찾을 때는 CVar 두 개를 함께 켠다(Net/Core/Private/Net/Core/Misc/NetCVars.cpp).

1
[SystemSettings]
2
; 등록하지 않은 복제 프로퍼티를 자동 등록하지 않는다 (기본값 1)
3
Net.AutoRegisterReplicatedProperties=0
4
; 등록하지 않은 복제 프로퍼티마다 ensure를 띄운다 (기본값 0)
5
Net.EnsureOnMissingReplicatedPropertiesRegister=1

ensure는 자동 등록을 끈 경우에만 뜨고, 그 상태에서 빠진 프로퍼티는 COND_Never가 되어 복제되지 않는다. 진단할 때만 잠깐 켜는 설정이다.

켜졌는지 확인하기#

스위치가 빠지면 마킹하지 않은 값도 복제된다. 폴링으로 돌고 있으니 당연한 결과지만, 코드만 보면 Push Model이 고장 난 것처럼 보인다. 포럼에도 bIsPushBased로 등록하고 마킹했는데 마킹과 상관없이 복제된다는 질문이 있었고, 원인은 net.IsPushModelEnabled를 켜지 않은 것이었다(포럼 글). 같은 스레드에는 패키지한 데디케이티드 서버에서 Target.cs의 bWithPushModel = true도 필요했다는 보고가 이어진다. 같은 증상은 초기 복제에서도 나오는데, 이 경우는 마킹을 빠뜨리면에서 다룬다.

앞의 두 스위치는 IS_PUSH_MODEL_ENABLED() 하나로 확인할 수 있다. WITH_PUSH_MODEL이 꺼진 빌드에서는 false로 정의되고, 켜진 빌드에서는 Net.IsPushModelEnabled 값을 돌려준다(Net/Core/Public/Net/Core/PushModel/PushModel.h). 서버가 시작할 때 로그로 남겨 두면 패키지 빌드가 조용히 폴링으로 도는 것을 바로 알 수 있다.

1
UE_LOG(LogTemp, Log, TEXT("Push Model: %s"), IS_PUSH_MODEL_ENABLED() ? TEXT("enabled") : TEXT("disabled"));

콘솔에서는 Net.IsPushModelEnabled를 값 없이 입력하면 현재 값이 나온다. bWithPushModel이 꺼진 빌드에서는 CVar 자체가 등록되지 않으므로 알 수 없는 명령으로 처리된다. 둘 다 지금의 CVar 값을 보여 줄 뿐이라, 세션 도중에 바꿨다면 이미 만들어진 FRepLayout과 다를 수 있다.

세 번째 스위치인 프로퍼티별 등록은 이 방법으로 확인되지 않는다. 프로퍼티가 실제로 push로 동작하는지는 Network Profiler의 프로퍼티별 비교 횟수로 볼 수 있다(아래 절). push 기반이 아닌 프로퍼티는 값이 바뀌지 않아도 매번 비교된다.

마킹은 비트 하나를 세운다#

1
void AMyActor::SetHealth(float NewHealth)
2
{
3
  COMPARE_ASSIGN_AND_MARK_PROPERTY_DIRTY(AMyActor, Health, NewHealth, this);
4
}

MARK_PROPERTY_DIRTY_FROM_NAME은 UHT가 생성한 ENetFields_Private로 프로퍼티의 RepIndex를 컴파일 시간에 구하고, 오브젝트의 push 상태에 비트 하나를 세운다(Net/Core/Private/Net/Core/PushModel/PushModel.cpp의 MarkPropertyDirty). 값을 읽는 것은 복제 시점이므로 대입과 마킹의 순서는 상관없다. 같은 프레임에 여러 번 마킹해도 결과는 같다. 비교하는 값도 복제 시점의 마지막 값이라 복제 주기 사이의 중간 값은 클라이언트에 가지 않는다. COMPARE_ASSIGN_AND_MARK_PROPERTY_DIRTY는 새 값이 기존 값과 다를 때만 대입하고 마킹한다. 엔진의 AController::SetPawn_Direct도 이 매크로를 쓴다.

int32 Values[4] 같은 고정 크기 배열은 원소마다 RepIndex가 따로 있다. 원소 하나는 MARK_PROPERTY_DIRTY_FROM_NAME_STATIC_ARRAY_INDEX로, 배열 전체는 MARK_PROPERTY_DIRTY_FROM_NAME_STATIC_ARRAY로 마킹한다. 뒤의 매크로는 WITH_PUSH_MODEL이 꺼진 빌드에서 인자 수가 달라진다. 켜진 쪽은 (ClassName, PropertyName, Object) 3개, 꺼진 쪽의 빈 매크로는 ArrayIndex가 낀 4개다(PushModel.h). 에디터에서 문제없던 호출이 bWithPushModel이 꺼진 타깃에서는 인자 수가 맞지 않게 된다. 이 때문에 컴파일이 실패한다는 보고가 2026년 3월 수정 PR과 함께 포럼에 올라와 Epic이 접수했고(포럼 글), 5.8.3 소스에는 아직 그대로 남아 있다. 원소 수만큼 _STATIC_ARRAY_INDEX를 부르면 피할 수 있다.

오브젝트가 아직 복제 등록 전이면 마킹은 아무 일도 하지 않는다. 대신 처음 등록될 때 모든 프로퍼티가 dirty인 상태로 시작한다(Net/Core/Private/Net/Core/PushModel/Types/PushModelPerObjectState.h의 생성자가 DirtiedThisFrame을 true로 채운다). 그래서 스폰 직후에 설정한 값은 마킹이 없어도 첫 복제에 실린다.

비교 단계에서 dirty가 아닌 push 프로퍼티만 건너뛴다#

1
static bool IsPropertyDirty(...)
2
{
3
  return SharedParams.bForceCompareProperties ||
4
    !(*SharedParams.PushModelProperties)[ParentIndex] || // non-push model properties are always considered dirty
5
    SharedParams.PushModelState->IsPropertyDirty(ParentIndex) ||
6
    (bRecentlyCollectedGarbage &&
7
      EnumHasAnyFlags(SharedParams.Parents[ParentIndex].Flags, ERepParentFlags::HasObjectProperties | ERepParentFlags::IsNetSerialize));
8
}

push 기반이 아닌 프로퍼티는 항상 dirty로 취급되어 매번 비교한다. push 기반 프로퍼티는 마킹됐을 때만 비교한다. 예외는 GC 직후다. 오브젝트 참조를 가지거나 NetSerialize를 쓰는 프로퍼티는 GC가 끝난 다음 비교에서 마킹과 상관없이 비교한다.

Full 클래스는 이 판정조차 프로퍼티마다 하지 않는다. dirty 비트가 켜진 인덱스만 순회한다(RepLayout.cpp의 CompareParentProperties, TConstSetBitIterator). 바뀐 것이 없으면 비교 루프가 거의 돌지 않는다.

dirty여도 비교는 한다#

마킹은 “보내라”가 아니라 “비교해 봐라”는 표시다. dirty 프로퍼티도 PropertiesAreIdentical로 shadow state와 비교하고 같으면 changelist에 넣지 않는다. 같은 값으로 마킹하면 비교 비용만 들고 아무것도 전송되지 않는다.

이 때문에 REPNOTIFY_Always도 Push Model과 무관하게 동작한다. 엔진은 이 값을 다음과 같이 정의한다.

REPNOTIFY_Always: Always Call the property’s RepNotify function when it is received from the server

CoreUObject/Public/UObject/CoreNetTypes.h

조건은 “서버에서 받았을 때”다. 받은 값이 클라이언트의 로컬 값과 같아도 RepNotify를 부른다는 수신 쪽 규칙이고(RepLayout.cpp의 ReceivePropertyHelper), 서버가 무엇을 보낼지에는 관여하지 않는다. 서버가 같은 값을 다시 마킹해도 보낸 것이 없으므로 클라이언트에서 RepNotify는 불리지 않는다. 처음에 나는 이 경우 RepNotify가 불릴 거라고 생각했는데, 보내는 쪽과 받는 쪽의 규칙을 섞어서 본 것이었다.

비교가 끝나면 그 오브젝트의 dirty 비트는 지워진다. 비교는 오브젝트당 한 번이고 결과는 연결들이 공유한다. 그래서 dirty 비트도 연결마다 따로 두지 않는다. 조건부 프로퍼티는 비교 단계에서 조건을 보지 않고 모두 비교한 뒤 연결별로 걸러 낸다.

대신 NetDriver마다는 따로 둔다. 마킹은 오브젝트의 비트 배열에 먼저 쌓이고, NetDriver가 그 오브젝트를 읽을 때 NetDriver별 사본으로 옮겨진다(PushModelPerObjectState.h의 PushDirtyStateToNetDrivers). 리플레이를 녹화하는 DemoNetDriver가 게임 NetDriver와 함께 돌아도 각자 자기 사본을 비교하고 지우므로 한쪽이 다른 쪽의 변경을 지우지 않는다.

언제 복제할지는 바꾸지 않는다#

Push Model은 무엇을 비교할지만 바꾼다. 액터를 언제 복제 검토 대상으로 볼지는 NetUpdateFrequency, ForceNetUpdate, Dormancy, 관련성 검사가 그대로 정한다. 마킹은 ForceNetUpdate를 부르지 않으므로 마킹한 값도 다음 복제 주기를 기다린다. 바로 보내야 하는 변경이라면 마킹과 함께 ForceNetUpdate를 부른다. ForceNetUpdate는 잠든 액터의 Dormancy도 flush한다(Engine/Private/Actor.cpp). Dormancy와 Push Model을 같은 조건에서 비교한 결과는 측정 절에 있다.

실험 구성#

측정 환경은 다음과 같다.

템플릿 캐릭터만으로는 측정할 대상이 거의 없어서 별도 액터를 추가했다. 대표 코드는 다음과 같다.

1
UCLASS()
2
class APushLabActor : public AActor
3
{
4
  GENERATED_BODY()
5

6
public:
7
  APushLabActor()
8
  {
9
    bReplicates = true;
10
    bAlwaysRelevant = true;
11
    SetReplicatingMovement(false);
12
    SetNetUpdateFrequency(100.0f);
13
  }
14

15
  virtual void GetLifetimeReplicatedProps(TArray<FLifetimeProperty>& OutLifetimeProps) const override
16
  {
17
    Super::GetLifetimeReplicatedProps(OutLifetimeProps);
18

19
    FDoRepLifetimeParams Params;
20
    Params.bIsPushBased = true;
21
    DOREPLIFETIME_WITH_PARAMS_FAST(APushLabActor, Int00, Params);
22
    // ... int32 8개, float 4개, FVector 4개
23
  }
24

25
  UFUNCTION(NetMulticast, Unreliable)
26
  void MulticastPing();
27

28
protected:
29
  UPROPERTY(Replicated) int32 Int00 = 0;
30
  // ...
31
};

• 액터 클래스는 세 가지다. 16개를 모두 push로 등록한 Full 클래스, 여기에 바뀌지 않는 폴링 프로퍼티 하나를 더한 Partial 클래스, 그리고 Carrier 클래스다. Carrier 클래스는 액터 본체에 폴링 프로퍼티 하나만 두고, 16개 프로퍼티는 Full 컴포넌트에 담아 붙였다.
• 서버는 액터 1000개를 스폰하고, 매 프레임 “초당 변경 비율 × 액터 수 × DeltaTime”을 누적해 1이 넘을 때마다 무작위 액터의 무작위 프로퍼티 하나에 새 값을 쓰고 마킹한다. 액터는 중복을 허용해 고르므로 변경 비율은 “액터당 평균 초당 쓰기 횟수”다. 1%면 액터 하나가 평균 100초에 한 번, 3000%면 평균 초당 30번 바뀐다. 난수 시드는 고정했다.
• 측정 구간에는 CSV 캡처와 Insights 리전 PushLab.Measure를 건다.
• 서버를 에디터 바이너리로 띄운 것은 런처판 5.8에서 Push Model이 켜진 Server 타깃을 빌드할 수 없어서다.
• 같은 조건을 반복해도 실행마다 결과가 ±10%가량 흔들려서, 서버와 클라이언트를 서로 다른 코어에 고정해 간섭을 줄였다.
• 대역폭 제한을 기본값(100 KB/s)으로 두면 3000% 조건에서 연결이 포화되어 연결당 프레임마다 처리하는 액터가 1000개에서 24개로 줄었다. 그 상태에서는 CPU가 아니라 대역폭 한계를 재게 된다.
• 서버 프레임은 실행에 따라 33~47 ms(약 21~30 Hz)였고, 그에 따라 연결당 프레임마다 처리한 액터 수도 774~1,005개로 달라졌다. 프레임당 시간으로 나눠도 프레임마다 한 일의 양까지 같아지지는 않으므로, 메인 조건은 ReplicateActor 1회당 시간으로도 함께 비교했다.

서버와 클라이언트는 다음처럼 띄웠다. 실험용 인자(액터 수, 변경 비율 등)는 뺐다.

1
# 데디케이티드 서버: 에디터 바이너리로 uncooked 실행
2
UnrealEditor.exe ThirdPerson.uproject /Game/ThirdPerson/Lvl_ThirdPerson -server -log -NoVerifyGC
3

4
# 클라이언트: 렌더링과 사운드 없이 접속
5
UnrealEditor.exe ThirdPerson.uproject 127.0.0.1 -game -nullrhi -nosound -log

대역폭 제한 설정은 다음과 같다. 클라이언트가 요청하는 속도와 서버가 허용하는 속도를 모두 올려야 하므로 서버와 클라이언트 양쪽에 적용한다.

1
[/Script/Engine.Player]
2
; 클라이언트가 요청하는 연결 속도 (bytes/s, 기본값 100000)
3
ConfiguredInternetSpeed=100000000
4
ConfiguredLanSpeed=100000000
5

6
[/Script/OnlineSubsystemUtils.IpNetDriver]
7
; 서버가 연결마다 허용하는 최대 속도 (bytes/s, 기본값 100000)
8
MaxClientRate=100000000
9
MaxInternetClientRate=100000000

조건마다 서버를 새로 띄우고 Net.IsPushModelEnabled와 net.PushModelSkipUndirtiedReplication만 바꿨다. 같은 바이너리를 쓰므로 빌드 차이는 결과에 섞이지 않는다.

측정 전 예측#

측정 전에 나는 Push 끔, Push 켬, Push + Skip의 비율을 100 : 95 : 90 정도로 예상했다. 프로퍼티 비교는 원래 싼 작업이고, 복제 비용의 대부분은 관련성 검사, 우선순위 계산, 직렬화 같은 다른 곳에서 나올 거라고 봤다.

메인 조건의 측정 결과#

메인 조건(Full 클래스 1000개, 초당 1% 변경, 클라이언트 2개)을 조건당 5회씩 번갈아 실행하는 세트를 두 번 돌렸다. 첫 세트의 프레임 시간이 실행마다 33~47 ms로 흔들려서 둘째 세트를 추가했는데, 둘째 세트도 42~47 ms로 흔들렸다. 표의 평균은 10회 평균이다.

프레임당 시간으로는 100 : 87 : 74로, 예상한 100 : 95 : 90보다 이득이 컸다. 프레임 시간이 흔들리면 프레임마다 처리한 액터 수도 달라지므로 ReplicateActor 1회당 시간으로도 비교했는데, 10회 평균의 비율은 100 : 88 : 73으로 거의 같았다. 다만 5회 세트 하나만 보면 Push 켬의 1회당 비율은 93과 83 사이를 오갔다. Push Model만 켰을 때의 13%는 ±5포인트쯤의 해상도로 읽어야 한다. skip CVar까지 켠 쪽은 두 세트와 두 지표에서 모두 71~74 사이였다. 다만 “비교는 원래 싸다”는 판단 자체는 맞았다. 아래 Insights 시간 분해에서 비교는 전체의 14%였다. 차이는 skip CVar가 비교가 아니라 연결별 작업을 줄이는 데서 나왔다.

Unreal Insights로 시간 분해하기#

서버를 다음 인자로 띄워 트레이스를 기록하고 Unreal Insights로 열었다.

1
UnrealEditor.exe ThirdPerson.uproject /Game/ThirdPerson/Lvl_ThirdPerson -server -log `
2
    -trace=cpu,frame,bookmark,region,log `
3
    -statnamedevents `
4
    -tracefile="D:/Traces/main_off.utrace"

-statnamedevents가 있어야 STAT_ 계열 스코프가 Timing 뷰에 이벤트로 나온다. region 채널은 서버 코드에서 TRACE_BEGIN_REGION(TEXT("PushLab.Measure"))로 건 측정 구간을 기록한다.

① 서버 코드에서 건 PushLab.Measure 리전이 Timing Regions 트랙에 30초 막대로 나온다. ② 눈금자에서 이 막대의 양끝을 드래그해 같은 범위를 선택하면 Timers와 Callees 패널이 선택 구간만 집계한다. 타이머 검색창에 Replicat을 넣고 ServerReplicateActors Time을 고르면 Callees 패널에 하위 호출 트리가 나온다.

Push Model을 끈 상태다.

• ① Replicate Actor Time은 30초 동안 1,283,628회 불렸다. 액터 1000개 × 연결 2개 × 프레임 640개와 거의 같다.
• ② Dynamic Property Compare Time은 638,526회로 그 절반이다. 연결이 2개여도 비교는 오브젝트당 한 번이라는 앞의 설명이 호출 수로 확인된다. 합계는 362.6 ms다.
• ③ STAT_NetDeletedSubObjects가 1,277,549회, 218.64 ms다. ReplicateActor마다 삭제된 서브오브젝트를 확인하는 연결별 작업으로, 비교 시간의 60%에 이른다.

Push Model을 켰다.

① 비교 호출 수는 637,682회로 그대로이고 합계가 81.9 ms로 줄었다. 호출은 오브젝트마다 하지만 dirty 비트가 없으면 바로 빠져나온다. 나머지 행은 거의 변하지 않았다.

skip CVar까지 켰다.

• ① Replicate Actor Time 호출은 1,278,753회로 그대로 남았다. skip은 이 함수 안에서 일어난다.
• ② STAT_NetDeletedSubObjects도 209.42 ms로 남았다. 앞의 소스대로 skip과 상관없이 매번 실행된다.
• ③ 비교는 599회로 줄었다. 실제로 값이 바뀐 액터만 비교한다. 직렬화(Dynamic Property Rep Time)도 1,198회, 2.49 ms로 거의 사라졌다.

같은 트레이스에서 타이머별 exclusive 시간을 CSV로 내보내 프레임당 값으로 나눴다. Insights는 UI 없이 트레이스를 분석한 뒤 명령을 실행할 수 있고, -region과 -threads로 측정 구간과 스레드를 지정할 수 있다.

1
UnrealInsights.exe -OpenTraceFile="D:/Traces/main_off.utrace" -AutoQuit -NoUI `
2
    -ExecOnAnalysisCompleteCmd="TimingInsights.ExportTimerStatistics D:/Traces/main_off.timers.csv -region=PushLab.Measure -threads=GameThread"

결과는 다음과 같다. 트레이스를 기록한 1회 실행의 값이라 앞의 CSV 10회 평균과 합계가 조금 다르다.

합계는 ServerReplicateActors 전체 시간이고, 위 다섯 항목에 넣지 않은 작은 스코프가 0.06 ms가량 더 들어 있다.

Push Model은 비교 칸을 0.58 ms에서 0.14 ms로 줄였다. 비교는 처음부터 전체의 14%였으므로 Push Model 단독으로 줄일 수 있는 폭도 그 정도다. skip CVar는 직렬화 칸과 연결별 액터 처리 칸의 일부를 줄였다. 가장 큰 칸인 연결별 액터 처리는 skip CVar를 켜도 2.13 ms가 남는다.

-statnamedevents는 µs 단위 스코프마다 이벤트를 기록하므로 측정값을 부풀릴 수 있다. 같은 조건에서 추적 없이 CSV만 기록한 10회 평균은 4.57 ms, 추적한 실행 1회는 4.28 ms였다. 추적 실행이 1회뿐이고 그 값이 추적 없는 실행의 범위(4.05~5.28 ms) 안에 있어서, 이번 비교로는 추적 비용과 실행 간 편차를 분리하지 못했다. 분해 표는 세 조건의 상대 비교에만 쓴다.

호출 하나하나의 길이도 봤다. TimingInsights.ExportTimingEvents로 이벤트를 내보내 분포를 만들었다. 명령은 response file(main_off.events.rsp)에 쓰고 @= 접두사로 넘긴다.

1
TimingInsights.ExportTimingEvents "D:/Traces/main_off.events.csv" -columns="TimerName,Duration" -threads="GameThread" -timers="Replicate Actor Time,Dynamic Property Compare Time" -region="PushLab.Measure"

1
UnrealInsights.exe -OpenTraceFile="D:/Traces/main_off.utrace" -AutoQuit -NoUI `
2
    -ExecOnAnalysisCompleteCmd="@=D:/Traces/main_off.events.rsp"

타이머 이름처럼 공백이 든 인자는 명령줄에서 따옴표가 겹치므로 response file로 넘긴다. 파일 안의 경로는 슬래시로 쓴다. 역슬래시는 이스케이프로 처리되어 사라진다.

skip CVar를 켜면 ReplicateActor의 61%가 1 µs 미만에 모인다. 비교 호출 수에는 캐릭터와 컨트롤러 같은 다른 액터도 포함된다. Push + Skip 조건에서 남은 비교는 실제로 바뀐 오브젝트의 비교라서 1회당 시간은 오히려 길다.

값을 바꾸는 빈도에 따른 차이#

1%를 뺀 나머지는 1회씩 측정했으므로 ±10% 안의 차이는 잡음으로 본다. 100%까지는 Push + Skip이 꾸준히 25% 안팎 앞섰다. 액터당 초당 30회 바뀌는 조건에서는 한 프레임에 액터 대부분이 한 번 이상 바뀌어 skip할 replicator가 거의 없고, skip CVar의 효과가 사라졌다. 이때도 Push Model을 켠 쪽이 끈 쪽보다 느리지는 않았다.

연결 수에 따른 차이#

비교를 연결들이 공유하는데도 전체 시간은 연결 수에 거의 비례해 늘었다. 복제 비용의 대부분이 연결별 작업이라는 뜻이다. skip CVar가 줄이는 몫도 그 연결별 작업의 일부다. 연결이 늘수록 감소율이 조금 낮아진 것은 skip CVar가 건드리지 않는 연결별 작업이 함께 늘기 때문으로 보인다.

Partial 클래스와 컴포넌트로 옮기기#

폴링 프로퍼티 하나가 섞인 Partial 클래스는 skip CVar를 켜도 skip되지 않았다. ACharacter를 상속한 캐릭터가 이 경우다.

그래서 캐릭터처럼 Partial일 수밖에 없는 액터라면 자주 바뀌지 않는 상태를 Full 컴포넌트로 옮겨 그 컴포넌트만이라도 skip을 받게 하면 되지 않을까 생각했다. Carrier 클래스가 그 구성이다. 컴포넌트는 실제로 skip됐지만(프레임당 1,998회) 전체는 5.10 ms로 Partial(3.79 ms)보다 35% 느렸다. 액터마다 replicator가 하나 더 생기고 서브오브젝트 처리 비용이 붙는 것이 skip으로 아끼는 몫보다 컸다. 이 측정에서는 skip을 노리고 상태를 쪼개는 것이 손해였다.

unreliable multicast 한 번이 skip을 끈다#

워밍업 중간에 모든 액터에서 MulticastPing()을 한 번씩 호출한 뒤 같은 조건으로 측정했다.

skip CVar를 켰는데도 ① 직렬화가 1,273,410회 돌고 ② 비교도 636,705회 돈다. skip된 replicator는 프레임당 1,998개에서 0.1개로 떨어졌고 ServerReplicateActors는 3.74 ms로 Push Model만 켠 수준이 됐다. 앞에서 본 GetNumBits() >= 0 조건 그대로다. multicast를 보낸 것은 측정 시작 10초 전이었고, 그 뒤로는 RPC를 보내지 않았다.

대역폭은 바뀌지 않는다#

Push Model이 네트워크 트래픽을 줄인다는 설명도 있어서 Networking Insights로 확인했다. 서버를 다음처럼 띄우면 패킷과 프로퍼티 단위의 비트 수가 기록된다.

1
UnrealEditor.exe ThirdPerson.uproject /Game/ThirdPerson/Lvl_ThirdPerson -server -log `
2
    -trace=net,frame,bookmark,region,log `
3
    -NetTrace=2 `
4
    -tracefile="D:/Traces/rate1_off_net.utrace"

-NetTrace는 net trace의 상세 수준이다(0 꺼짐, 1 Trace, 2 Verbose, 3 VeryVerbose). net trace는 기록량이 많아서 이 실행은 CPU 수치 비교에는 쓰지 않았다.

① 서버 인스턴스의 Connection 0에서 방향을 Outgoing으로 바꾸고, ② 패킷 막대를 클릭한 뒤 Shift-클릭해 초기 복제 이후의 패킷 985개를 골랐다. 초당 100%의 액터 값이 바뀌는 조건이다. 시드가 고정되어 있어서 두 실행은 같은 순서로 값을 쓴다.

폴링이든 push든 보내는 것은 바뀐 프로퍼티뿐이므로 송신 내용은 같다. FVector 프로퍼티는 200 bits, int32와 float은 40 bits로 두 실행이 같았다. 3000% 조건의 CSV에서도 프레임당 송신량은 37.26 KB, 37.27 KB, 37.24 KB로 같았다. Push Model이 줄이는 것은 서버 CPU다.

Network Profiler로 비교 횟수 세기#

Networking Insights 이전부터 있던 Network Profiler도 아직 남아 있다. Shipping과 Test가 아닌 빌드에서 동작하고(USE_NETWORK_PROFILER), 서버 명령줄에 networkprofiler=true를 주거나 콘솔에서 netprofile enable을 실행하면 Saved/Profiling에 .nprof 파일이 기록된다. 파일은 Engine/Binaries/DotNET/NetworkProfiler.exe로 연다. 런처로 설치한 5.8에는 이 실행 파일이 없어서 소스 빌드에서 만든 것을 썼다.

이 도구에는 Insights에 없는 값이 두 가지 있다. 하나는 오브젝트와 프로퍼티별 비교 횟수이고, 다른 하나는 액터별 Waste다. 비교 횟수는 Net.ProfilerUseComparisonTracking(기본값 0)을 켜야 기록된다. 이번에는 메인 조건(액터 1000개, 클라이언트 2개, 초당 1%)에서 30초 측정 구간에만 기록이 걸리도록 하네스가 다음 콘솔 명령을 실행했다.

1
Net.ProfilerUseComparisonTracking 1
2
netprofile enable
3
; 30초 측정
4
netprofile disable

프로파일러는 복제할 때마다 기록을 남기므로 이 실행의 시간 값에는 기록 비용이 들어 있다. 시간은 세 조건끼리만 비교하고 앞의 CPU 측정과는 섞지 않는다.

All Objects 탭의 왼쪽은 클래스별 합계, 오른쪽은 선택한 클래스의 프로퍼티별 횟수다. Push Model을 끄면 ① PushLabActor의 비교가 640,366회, 비교 시간이 517.5 ms다. 프레임마다 액터 1000개를 한 번씩 비교한 횟수로, 클라이언트가 2개여도 두 배가 되지 않는다. 비교는 오브젝트당 한 번이고 결과를 연결들이 공유한다는 앞의 설명과 맞는다. ② 프로퍼티도 모두 640,366회씩 비교했지만 실제로 바뀐 것은 프로퍼티마다 11~26회였다.

Push Model을 켜도 ① 오브젝트 단위 비교 호출은 639,368회로 거의 같다. Full 클래스라도 skip CVar가 없으면 매 프레임 비교 함수에 들어가기 때문이다. 대신 비교 시간은 139.0 ms로 줄었다. ② 프로퍼티별 비교 횟수가 바뀐 횟수와 같아졌고, AActor에서 물려받은 프로퍼티는 한 번도 비교하지 않았다. dirty가 아닌 push 프로퍼티를 건너뛰는 동작이 이 숫자로 그대로 보인다.

skip CVar까지 켜면 오브젝트 단위 비교 호출이 601회로 줄어든다. dirty가 없는 액터는 ReplicateProperties에 들어가지 않으므로 비교 함수도 부르지 않는다. 시드가 고정되어 있어서 세 실행의 프로퍼티별 변경 횟수는 같았다.

Waste는 ReplicateActor를 부른 횟수 중 아무것도 보내지 않은 비율이다. 뷰어는 100 - Rep HZ / Update HZ × 100으로 계산한다(Engine/Source/Programs/NetworkProfiler/NetworkProfiler/PartialNetworkStream.cs). ① Push + Skip에서 PushLabActor는 초당 43,724회 처리되었고 그중 20.07회만 무언가를 보냈다. Waste는 99.95다.

Waste는 세 조건에서 같았다. Push Model은 보낼지 판단하는 방법을 바꿀 뿐 보내는 내용을 바꾸지 않는다. skip으로 건너뛴 호출도 TrackReplicateActor로 기록되므로(Engine/Private/DataChannel.cpp의 ReplicateActor) 분모에서 빠지지 않는다. 그래서 Waste가 그대로라고 Push Model이 효과가 없다고 읽으면 안 된다. 효과는 ReplicateActor에 쓴 시간인 MS 열에서 보인다. Push Model만 켜면 8% 줄었고 skip CVar까지 켜면 82% 줄었다. 앞의 CPU 측정보다 감소율이 훨씬 큰 데는 두 가지 이유가 있다. MS 열은 ServerReplicateActors 전체가 아니라 ReplicateActor 안쪽만 재므로 skip CVar가 건드리지 않는 후보 수집과 우선순위 계산이 빠져 있고, 비교와 직렬화마다 프로파일러가 기록을 남기므로 skip으로 건너뛴 호출에서는 그 기록 비용까지 함께 사라진다. 이 열은 세 조건의 상대 비교에만 쓴다.

Dormancy와 비교하면#

시간 분해에서 가장 큰 칸은 연결별 액터 처리였고, Push + Skip에서도 2.13 ms가 남았다. 이 칸은 액터가 ReplicateActor에 들어가는 한 남는다. 액터를 복제 검토 대상에서 아예 빼는 기능은 Dormancy다. DORM_DormantAll인 액터는 모든 연결에서 채널이 닫히면 활성 네트워크 오브젝트 목록에서 빠지고, FlushNetDormancy나 ForceNetUpdate로 깨울 때만 다시 복제된다.

같은 실험에 Dormancy 조건을 더했다. 워밍업 5초 시점에 액터 1000개를 모두 DORM_DormantAll로 바꾸고, 값을 쓸 때마다 먼저 깨운 뒤 값을 바꾸고 마킹했다.

1
// 깨운 다음에 바꾼다
2
Actor->FlushNetDormancy();
3
Actor->SetHealth(NewHealth); // 내부에서 마킹한다

메인 조건(초당 1% 변경)을 조건당 3회 측정한 평균은 다음과 같다.

Push + Skip의 약 5%다. 측정 중 활성 네트워크 오브젝트는 프레임당 평균 10.9개였다. 잠든 액터는 비교도 직렬화도 하지 않으므로 Push Model과 skip CVar 설정에 따른 차이도 사라졌다.

값을 바꾸는 빈도를 올리면 결과가 뒤집힌다.

활성 오브젝트는 Dormancy 조건의 값이다. Push Model을 끈 Dormancy는 0.16, 0.42, 4.14, 24.91 ms로 Push + Skip과 비슷했다.

액터가 평균 10초에 한 번 바뀌는(10%) 조건까지는 Dormancy가 크게 앞섰다. 1초에 한 번(100%)이면 Push + Skip이 앞섰고, 초당 30회(3000%)면 Dormancy가 약 3배 느렸다.

같은 100% 조건의 트레이스에서 차이가 난 곳은 직렬화였다. 깨어 있는 Push + Skip에서 Dynamic Property Rep Time은 호출당 0.75 µs, 프레임당 0.12 ms였다. Dormancy에서는 호출당 9.84 µs, 프레임당 2.09 ms였다. 깨어난 액터는 채널을 새로 열고(채널 생성이 프레임당 85.6회), 호출당 시간이 13배인 것으로 보아 바뀐 프로퍼티 하나가 아니라 상태 전체를 다시 직렬화하는 것으로 보인다. 송신 패킷도 프레임당 2.0개에서 17.4개로 늘었고, 3000% 조건의 프레임당 송신량은 37.2 KB에서 80.1 KB가 됐다.

표의 수치 밖에서 드는 비용도 있다. ServerReplicateActors 다음에 도는 UNetConnection::Tick의 채널 Tick(STAT_NetConnection_TickChannels)이 깨어 있을 때 0.004 ms에서 0.92 ms로 늘었고, 게임 코드에서 부른 FlushNetDormancy에 0.25 ms가 더 들었다.

깨우는 순서는 Epic의 Actor Network Dormancy 문서를 따랐다. 문서는 깨울 때 shadow state를 현재 값으로 다시 만들기 때문에 깨운 다음에 바꾸라고 한다. 순서를 바꿔 값을 먼저 바꾸고 flush하는 probe도 돌려 봤는데, 이번 실험의 일반 프로퍼티는 1000개 모두 전달됐다. 문서는 이 동작을 기대면 안 되는 구현 세부로 보고, FastArray는 이 순서에서 변경이 전달되지 않을 수 있다고 적는다. 다음 절에서 볼 UE-226689도 Dormancy 해제와 마킹이 엮인 문제다.

다른 측정과 비교하면#

영어권에 공개된 측정으로는 Kieran Newland의 글이 있다(Push Model Networking, UE 5.3.2). 그 측정에서는 Push Model만 켰을 때 -17%, skip CVar까지 켰을 때 -54%였다. 이번 측정의 -13%와 -26%보다 skip CVar의 효과가 훨씬 크다.

그 측정은 X와 Y로 20칸씩 도는 격자에 액터를 스폰하고(글의 TotalRowsCols 값이 20이라 20×20으로 보인다), 액터마다 컴포넌트 20개를 붙여 컴포넌트마다 float 하나를 복제하는 구성이다. 클라이언트는 4개이고, 값은 약 200 ms 구간의 NetBroadcastTickTime이다. 복제 대상 대부분이 서브오브젝트다. 서브오브젝트는 skip되면 그 서브오브젝트의 처리를 일찍 끝내지만, 액터 본체는 ReplicateProperties 한 줄만 건너뛰고 나머지 연결별 작업이 남는다. 이번 실험은 프로퍼티가 액터 본체에 있는 구성이라 남는 몫이 컸다. 같은 CVar의 효과가 -54%와 -26%로 갈린 것도 그 때문으로 보인다. 두 숫자 중 어느 한쪽이 맞다기보다, skip CVar의 효과는 상태가 액터 본체에 있는지 서브오브젝트에 있는지에 따라 달라진다고 본다.

마킹 누락을 막는 구조#

복제 프로퍼티를 private으로 두고 값을 바꾸는 경로를 setter로 모으면 마킹을 빠뜨릴 자리가 setter 안으로 줄어든다. FInventorySlot은 ItemId와 Count를 가진 USTRUCT다. Health와 Slots는 앞에서 본 것처럼 bIsPushBased로 등록했다고 가정한다.

1
UCLASS()
2
class AInventoryActor : public AActor
3
{
4
  GENERATED_BODY()
5

6
public:
7
  void SetHealth(float NewHealth)
8
  {
9
    // 값이 다를 때만 대입하고 마킹한다
10
    COMPARE_ASSIGN_AND_MARK_PROPERTY_DIRTY(AInventoryActor, Health, NewHealth, this);
11
  }
12

13
  void SetSlotCount(int32 SlotIndex, int32 NewCount)
14
  {
15
    // 배열 원소는 직접 비교하고, 바뀌었으면 배열 프로퍼티 전체를 마킹한다
16
    FInventorySlot& Slot = Slots[SlotIndex];
17
    if (Slot.Count != NewCount)
18
    {
19
      Slot.Count = NewCount;
20
      MARK_PROPERTY_DIRTY_FROM_NAME(AInventoryActor, Slots, this);
21
    }
22
  }
23

24
  // 여러 원소를 한 번에 고쳐야 할 때는 참조를 넘기는 순간 마킹한다
25
  TArray<FInventorySlot>& GetSlots_Mutable()
26
  {
27
    MARK_PROPERTY_DIRTY_FROM_NAME(AInventoryActor, Slots, this);
28
    return Slots;
29
  }
30

31
private:
32
  UPROPERTY(Replicated) float Health = 100.0f;
33
  UPROPERTY(Replicated) TArray<FInventorySlot> Slots;
34
};

Push Model에서는 프로퍼티 단위로 마킹하므로 배열 원소 하나를 바꿔도 배열 프로퍼티 전체가 다음 비교 대상이 된다. 실제로 보내는 원소는 비교에서 달라진 것뿐이다. GetSlots_Mutable()처럼 참조를 넘기면서 마킹하는 방식은 엔진도 쓴다. AActor::GetReplicatedMovement_Mutable()이 ReplicatedMovement를 마킹한 뒤 참조를 돌려준다(Engine/Private/Actor.cpp). 값을 바꾸지 않고 마킹만 해도 비교 비용만 들고 전송은 없다는 것은 앞에서 확인했다.

클래스 이름과 this를 매번 적는 게 번거롭다면 프로젝트 공용 헤더에 래퍼 매크로를 둘 수 있다. ThisClass는 GENERATED_BODY()가 클래스마다 선언하는 별칭이다.

1
#define MARK_DIRTY(PropertyName) MARK_PROPERTY_DIRTY_FROM_NAME(ThisClass, PropertyName, this)
2
#define SET_AND_MARK(PropertyName, NewValue) COMPARE_ASSIGN_AND_MARK_PROPERTY_DIRTY(ThisClass, PropertyName, NewValue, this)
3

4
// 앞의 AInventoryActor::SetHealth를 매크로로 줄이면 다음과 같다
5
void SetHealth(float NewHealth)
6
{
7
  SET_AND_MARK(Health, NewHealth);
8
}

이 매크로는 부모 클래스에서 선언한 프로퍼티에 쓸 때 함정이 있다. 마킹 매크로는 RepIndex를 ThisClass::ENetFields_Private에서 읽는데, UHT는 복제 프로퍼티가 있는 클래스마다 자기 프로퍼티만 담은 ENetFields_Private를 만든다. 자식 클래스에 복제 프로퍼티가 없으면 enum이 없으니 부모의 enum을 찾아가서 컴파일된다. 자식에 복제 프로퍼티를 하나라도 추가하는 순간 자식의 enum이 부모의 enum을 가리고, 멀쩡하던 마킹 코드가 컴파일 오류로 바뀐다. ThirdPerson 프로젝트에서 두 경우를 빌드해 확인했다. 부모 프로퍼티는 선언한 클래스 이름을 직접 적거나 부모의 setter를 거쳐 마킹한다.

다만 GetSlots_Mutable()로 받은 참조를 보관했다가 다음 프레임 이후에 고치는 경우는 이 구조로도 막지 못한다. 마킹은 이미 비교에서 소비된 뒤라 변경이 전달되지 않는다. 이런 경로는 검증용 CVar로 찾는다.

검증 CVar#

개발 중에는 켜 두고, 성능을 잴 때는 끈다.

1
[SystemSettings]
2
; 모든 push 프로퍼티를 비교해서 마킹되지 않은 변경이 있으면 경고한다 (기본값 0)
3
; 모든 프로퍼티를 비교하므로 켠 상태로는 Push Model의 이득이 사라진다
4
net.PushModelValidateProperties=1
5
; skip할 수 있다고 판단한 오브젝트가 실제로 데이터를 썼는지 검사한다 (기본값 0)
6
; 검사하려고 skip하지 않고 복제하므로 이것도 측정 때는 끈다
7
net.PushModelValidateSkipUpdate=1

net.PushModelValidateProperties는 Shipping과 Test 빌드에는 들어가지 않는다(Net/Core/Public/Net/Core/PushModel/PushModelMacros.h의 WITH_PUSH_VALIDATION_SUPPORT).