.NET Framework 4에는 성능에 많은 투자를 한 Windows Workflow Foundation(WF)의 주요 수정 버전이 포함되어 있습니다. 이 새로운 수정 버전에서는 .NET Framework 3.0 및 .NET Framework 3.5의 일부로 제공된 이전 버전의 WF에서 중요한 디자인 변경을 도입했습니다. 성능과 유용성을 크게 향상시키기 위해 프로그래밍 모델, 런타임 및 도구의 핵심에서 다시 설계되었습니다. 이 항목에서는 이러한 수정 버전의 중요한 성능 특성을 보여 주고 이전 버전과 비교합니다.
개별 워크플로 구성 요소 성능은 WF3에서 WF4로 전환하면서 수십 배 증가했습니다. 따라서 손으로 코딩된 WCF(Windows Communication Foundation) 서비스와 WCF 워크플로 서비스 간의 간격은 매우 작습니다. WF4에서 워크플로 대기 시간이 크게 감소했습니다. 지속성 성능은 2.5배에서 3.0배로 증가했습니다. 워크플로 추적을 통해 상태 모니터링은 오버헤드가 훨씬 적습니다. 이는 애플리케이션에서 WF4로 마이그레이션하거나 채택해야 하는 강력한 이유입니다.
용어
.NET Framework 4에 도입된 WF 버전은 이 항목의 나머지 부분에 대해 WF4라고 합니다. WF는 .NET Framework 3.0에서 도입되었으며 .NET Framework 3.5 SP1을 통해 몇 가지 사소한 수정이 있었습니다. .NET Framework 3.5 버전의 Workflow Foundation은 이 항목의 나머지 부분에 대해 WF3이라고 합니다. WF3은 .NET Framework 4에서 WF4와 나란히 제공됩니다. WF3 아티팩트에서 WF4로 마이그레이션하는 방법에 대한 자세한 내용은 Windows Workflow Foundation 4 마이그레이션 가이드를 참조하세요.
WCF(Windows Communication Foundation)는 서비스 지향 애플리케이션을 빌드하기 위한 Microsoft의 통합 프로그래밍 모델입니다. WF3과 함께 .NET Framework 3.0의 일부로 처음 도입되었으며 이제는 .NET Framework의 주요 구성 요소 중 하나입니다.
Windows Server AppFabric은 IIS에서 실행되는 웹 및 복합 애플리케이션을 보다 쉽게 빌드, 크기 조정 및 관리할 수 있는 통합 기술 집합입니다. 서비스 및 워크플로를 모니터링하고 관리하기 위한 도구를 제공합니다. 자세한 내용은 Windows Server AppFabric 1.0을 참조하세요.
목표
이 항목의 목표는 다양한 시나리오에 대해 측정된 데이터를 사용하여 WF4의 성능 특성을 표시하는 것입니다. 또한 WF4와 WF3 간의 자세한 비교를 제공하므로 이 새로운 수정 버전에서 크게 개선된 내용을 보여 줍니다. 이 문서에 제시된 시나리오 및 데이터는 WF4 및 WF3의 다양한 측면의 기본 비용을 정량화합니다. 이 데이터는 WF4의 성능 특성을 이해하는 데 유용하며 WF3에서 WF4로의 마이그레이션을 계획하거나 애플리케이션 개발에서 WF4를 사용하는 데 유용할 수 있습니다. 그러나 이 문서에 제시된 데이터에서 가져온 결론에 주의를 기울여야 합니다. 복합 워크플로 애플리케이션의 성능은 워크플로가 구현되는 방법과 다양한 구성 요소가 통합되는 방식에 따라 크게 달라집니다. 각 애플리케이션을 측정하여 해당 애플리케이션의 성능 특성을 확인해야 합니다.
WF4 성능 향상 개요
WF4는 다음 섹션에 설명된 고성능 및 확장성으로 신중하게 설계 및 구현되었습니다.
WF 런타임
WF 런타임의 핵심은 워크플로에서 활동의 실행을 구동하는 비동기 스케줄러입니다. 작업에 대해 성능이 좋은 예측 가능한 실행 환경을 제공합니다. 환경에는 실행, 연속, 완료, 취소, 예외 및 예측 가능한 스레딩 모델에 대해 잘 정의된 계약이 있습니다.
WF3에 비해 WF4 런타임에는 더 효율적인 스케줄러가 있습니다. 일괄 처리된 작업 항목을 실행하는 데 매우 효율적인 WCF에 사용되는 동일한 I/O 스레드 풀을 활용합니다. 내부 작업 항목 스케줄러 큐는 가장 일반적인 사용 패턴에 최적화되어 있습니다. 또한 WF4 런타임은 최소한의 동기화 및 이벤트 처리 논리를 사용하여 매우 간단한 방식으로 실행 상태를 관리하지만, WF3는 상태 전환에 대한 복잡한 동기화를 수행하기 위해 무거운 이벤트 등록 및 호출에 의존합니다.
데이터 스토리지 및 흐름
WF3에서 활동과 연결된 데이터는 형식 DependencyProperty에 의해 구현된 종속성 속성을 통해 모델링됩니다. 종속성 속성 패턴은 WPF(Windows Presentation Foundation)에서 도입되었습니다. 일반적으로 이 패턴은 쉬운 데이터 바인딩 및 기타 UI 기능을 지원하기에 매우 유연합니다. 그러나 이 패턴을 사용하려면 워크플로 정의에서 속성을 정적 필드로 정의해야 합니다. WF 런타임이 속성 값을 설정하거나 가져올 때마다 가중치가 큰 조회 논리가 포함됩니다.
WF4는 명확한 데이터 범위 지정 논리를 사용하여 워크플로에서 데이터가 처리되는 방식을 크게 향상시킵니다. 변수와 인수라는 두 가지 개념을 사용하여 활동 경계를 넘어 흐르는 데이터와 활동에 저장된 데이터를 구분합니다. 변수 및 "In/Out/InOut" 인수에 대해 명확한 계층적 범위를 사용하면 활동의 데이터 사용 복잡성이 크게 줄어들고 데이터의 수명 범위도 자동으로 지정됩니다. 활동에는 해당 인수로 설명된 잘 정의된 서명이 있습니다. 단순히 활동을 검사하여 수신할 것으로 예상되는 데이터와 해당 실행 결과로 생성될 데이터를 확인할 수 있습니다.
WF3에서는 워크플로를 만들 때 활동이 초기화되었습니다. WF에서 4 활동은 해당 활동이 실행되는 경우에만 초기화됩니다. 이렇게 하면 새 워크플로 인스턴스를 만들 때 초기화/초기화 해제 작업을 수행하지 않고도 작업 수명 주기가 더 간단해지므로 효율성이 향상됩니다.
제어 흐름
모든 프로그래밍 언어와 마찬가지로 WF는 시퀀싱, 루프, 분기 및 기타 패턴에 대한 제어 흐름 활동 집합을 도입하여 워크플로 정의에 대한 제어 흐름을 지원합니다. WF3에서 동일한 활동을 다시 실행해야 할 때마다 새 ActivityExecutionContext가 생성되며, 이는 BinaryFormatter를 기반으로 한 복잡한 직렬화 및 역직렬화 과정을 통해 복제됩니다. 일반적으로 반복 제어 흐름의 성능은 일련의 작업을 실행하는 것보다 훨씬 느립니다.
WF4는 이를 매우 다르게 처리합니다. 작업 템플릿을 사용하고, 새 ActivityInstance 개체를 만들고, 스케줄러 큐에 추가합니다. 이 전체 프로세스는 명시적 개체 만들기만 포함하며 매우 가볍습니다.
비동기 프로그래밍
애플리케이션은 일반적으로 I/O 또는 분산 컴퓨팅 작업과 같은 장기 실행 차단 작업을 위한 비동기 프로그래밍을 사용하여 성능과 확장성을 향상합니다. WF4는 기본 작업 유형을 AsyncCodeActivityAsyncCodeActivity<TResult>통해 비동기 지원을 제공합니다. 런타임은 기본적으로 비동기 작업을 이해하므로 비동기 작업이 뛰어난 동안 인스턴스를 지속되지 않는 영역에 자동으로 배치할 수 있습니다. 사용자 지정 활동은 워크플로 스케줄러 스레드를 유지하고 병렬로 실행할 수 있는 모든 활동을 차단하지 않고 이러한 형식에서 파생되어 비동기 작업을 수행할 수 있습니다.
메시징
처음에 WF3는 외부 이벤트 또는 웹 서비스 호출을 통해 매우 제한된 메시징 지원을 받았습니다. .NET Framework 3.5에서 워크플로는 WCF 클라이언트로 구현되거나 WCF 서비스 SendActivity 로 노출될 수 있습니다 ReceiveActivity. WF4에서는 WCF 메시징 논리를 WF에 긴밀하게 통합하여 워크플로 기반 메시징 프로그래밍의 개념을 더욱 강화했습니다.
.NET 4의 WCF에 제공된 통합 메시지 처리 파이프라인은 WF4 서비스가 WF3보다 성능과 확장성을 훨씬 향상하는 데 도움이 됩니다. 또한 WF4는 복잡한 MEP(메시지 교환 패턴)를 모델링할 수 있는 보다 풍부한 메시징 프로그래밍 지원을 제공합니다. 개발자는 형식화된 서비스 계약을 사용하여 직렬화 비용을 지불하지 않고도 간편한 프로그래밍 또는 형식화되지 않은 서비스 계약을 통해 더 나은 성능을 달성할 수 있습니다. WF4의 클래스를 통한 SendMessageChannelCache 클라이언트 쪽 채널 캐싱 지원을 통해 개발자는 최소한의 노력으로 빠른 애플리케이션을 빌드할 수 있습니다. 자세한 내용은 보내기 활동에 대한 캐시 공유 수준 변경을 참조하세요.
선언적 프로그래밍
WF4는 비즈니스 프로세스 및 서비스를 모델링하는 깨끗하고 간단한 선언적 프로그래밍 프레임워크를 제공합니다. 프로그래밍 모델은 코드 옆에 없는 완전히 선언적인 활동 구성을 지원하므로 워크플로 작성이 크게 간소화됩니다. .NET Framework 4에서 XAML 기반 선언적 프로그래밍 프레임워크는 WPF와 WF를 모두 지원하기 위해 단일 어셈블리 System.Xaml.dll 통합되었습니다.
WF4에서 XAML은 진정한 선언적 환경을 제공하며, .NET을 사용하여 빌드된 활동 및 형식을 참조하여 XML 태그에 워크플로의 전체 정의를 정의할 수 있도록 합니다. 사용자 지정 코드 숨김 논리를 포함하지 않고는 XOML 형식으로 WF3에서 이 작업을 수행하는 것이 어려웠습니다. .NET 4의 새 XAML 스택은 워크플로 아티팩트를 직렬화/역직렬화하는 데 있어 성능이 훨씬 향상되었으며 선언적 프로그래밍을 더 매력적이고 견고하게 만듭니다.
워크플로 디자이너
WF4에 대한 완전 선언적 프로그래밍 지원은 대규모 워크플로의 디자인 타임 성능에 대해 더 높은 요구 사항을 명시적으로 적용합니다. WF4의 워크플로 디자이너는 WF3보다 큰 워크플로의 확장성이 훨씬 우수합니다. UI 가상화를 지원하면 디자이너는 몇 초 안에 1,000개의 대규모 작업 워크플로를 쉽게 로드할 수 있지만 WF3 디자이너를 사용하여 수백 개의 활동 워크플로를 로드하는 것은 거의 불가능합니다.
구성 요소 수준 성능 비교
이 섹션에는 WF3 및 WF4 워크플로의 개별 활동 간 직접 비교에 대한 데이터가 포함되어 있습니다. 지속성과 같은 주요 영역은 개별 활동 구성 요소보다 성능에 더 큰 영향을 줍니다. WF4의 개별 구성 요소의 성능 향상은 중요하지만 구성 요소는 이제 손으로 코딩된 오케스트레이션 논리와 비교할 수 있을 만큼 빠르기 때문입니다. 그 예는 다음 섹션인 "서비스 컴퍼지션 시나리오"에서 다룹니다.
환경 설정
위의 그림에서는 구성 요소 수준 성능 측정에 사용되는 컴퓨터 구성을 보여 줍니다. 하나의 1Gbps 이더넷 네트워크 인터페이스를 통해 연결된 단일 서버와 5개의 클라이언트. 쉽게 측정할 수 있도록 서버는 Windows Server 2008 x86을 실행하는 이중 프록시/쿼드 코어 서버의 단일 코어를 사용하도록 구성됩니다. 시스템 CPU 사용률은 거의 100%유지됩니다.
테스트 세부 정보
WF3 CodeActivity은 WF3 워크플로에 사용할 수 있는 가장 간단한 활동일 수 있습니다. 이 활동은 워크플로 프로그래머가 사용자 지정 코드를 넣을 수 있는 코드 숨김에서 메서드를 호출합니다. WF4에서는 동일한 기능을 제공하는 WF3 CodeActivity 과 직접적인 아날로그가 없습니다. WF4에는 CodeActivity WF3 CodeActivity과 관련이 없는 기본 클래스가 있습니다. 워크플로 작성자는 사용자 지정 활동을 만들고 XAML 전용 워크플로를 빌드하는 것이 좋습니다. 아래 테스트에서는 WF4 워크플로에서 빈 Comment 대신 CodeActivity 활동이 사용됩니다. 활동의 코드 Comment 는 다음과 같습니다.
[ContentProperty("Body")]
public sealed class Comment : CodeActivity
{
public Comment()
: base()
{
}
[DefaultValue(null)]
public Activity Body
{
get;
set;
}
protected override void Execute(CodeActivityContext context)
{
}
}
빈 워크플로
이 테스트는 자식 활동이 없는 시퀀스 워크플로를 사용합니다.
단일 작업
워크플로는 하나의 자식 활동을 포함하는 시퀀스 워크플로입니다. 활동은 WF3 사례에서는 코드가 없는 CodeActivity이고, WF4 사례에서는 Comment 활동입니다.
1000번 반복하는 동안
시퀀스 워크플로에는 하나의 While 활동과 루프에 포함된 작업을 수행하지 않는 하나의 자식 활동이 있습니다.
복제자와 ParallelForEach 비교
ReplicatorActivity WF3의 경우 순차적 및 병렬 실행 모드가 있습니다. 순차 모드에서 활동의 성능은 WhileActivity와 유사합니다. 병렬 실행에 ReplicatorActivity이 가장 유용합니다. 이에 대한 WF4 아날로그는 ParallelForEach<T> 활동입니다.
다음 다이어그램은 이 테스트에 사용되는 워크플로를 보여 줍니다. WF3 워크플로가 왼쪽에 있고 WF4 워크플로가 오른쪽에 있습니다.
5개의 활동이 있는 순차 워크플로
이 테스트는 여러 활동을 순서대로 실행하는 효과를 보여 줍니다. 시퀀스에는 5개의 작업이 있습니다.
트랜잭션 범위
트랜잭션 범위 테스트는 모든 반복에 대해 새 워크플로 인스턴스가 만들어지지 않는다는 점에서 다른 테스트와 약간 다릅니다. 대신 워크플로는 작업을 수행하지 않는 단일 활동을 포함하는 TransactionScope 활동과 함께 while 루프로 구성됩니다. while 루프를 통한 50회 반복 일괄 처리의 각 실행은 단일 작업으로 계산됩니다.
보상
WF3 워크플로에는 하나의 보상 가능한 활동 이름이 있습니다 WorkScope. 활동은 단순히 인터페이스를 ICompensatableActivity 구현합니다.
class WorkScope :
CompositeActivity, ICompensatableActivity
{
public WorkScope() : base() { }
public WorkScope(string name)
{
this.Name = name;
}
public ActivityExecutionStatus Compensate(
ActivityExecutionContext executionContext)
{
return ActivityExecutionStatus.Closed;
}
}
오류 처리기는 WorkScope 활동을 대상으로 지정합니다. WF4 워크플로도 똑같이 단순합니다. A CompensableActivity 에는 본문과 보정 처리기가 있습니다. 명시적 보상은 시퀀스에서 다음 순서입니다. 본문 작업 및 보정 처리기 작업은 모두 빈 구현입니다.
public sealed class CompensableActivityEmptyCompensation : CodeActivity
{
public CompensableActivityEmptyCompensation()
: base() { }
public Activity Body { get; set; }
protected override void Execute(CodeActivityContext context) { }
}
public sealed class CompensableActivityEmptyBody : CodeActivity
{
public CompensableActivityEmptyBody()
: base() { }
public Activity Body { get; set; }
protected override void Execute(CodeActivityContext context) { }
}
다음 다이어그램에서는 기본 보정 워크플로를 보여 있습니다. WF3 워크플로가 왼쪽에 있고 WF4 워크플로가 오른쪽에 있습니다.
성능 테스트 결과
모든 테스트는 트랜잭션 범위 테스트를 제외하고 초당 워크플로로 측정됩니다. 위에서 볼 수 있듯이, WF 런타임 성능은 특히 while 루프와 같은 동일한 작업의 여러 실행을 필요로 하는 영역에서 전반적으로 개선되었습니다.
서비스 컴퍼지션 시나리오
이전 섹션인 "구성 요소 수준 성능 비교"에 표시된 것처럼 WF3과 WF4 간에 오버헤드가 크게 감소했습니다. 이제 WCF 워크플로 서비스는 손으로 코딩한 WCF 서비스의 성능과 거의 일치할 수 있지만 여전히 WF 런타임의 모든 이점을 누릴 수 있습니다. 이 테스트 시나리오는 WCF 서비스를 WF4의 WCF 워크플로 서비스와 비교합니다.
온라인 스토어 서비스
Windows Workflow Foundation의 장점 중 하나는 여러 서비스를 사용하여 프로세스를 작성하는 기능입니다. 이 예제에서는 주문을 구매하기 위해 두 개의 서비스 호출을 오케스트레이션하는 온라인 스토어 서비스가 있습니다. 첫 번째 단계는 주문 유효성 검사 서비스를 사용하여 주문의 유효성을 검사하는 것입니다. 두 번째 단계는 Warehouse 서비스를 사용하여 주문을 채우는 것입니다.
두 백 엔드 서비스인 Order Validating Service 및 Warehouse Service는 두 테스트 모두에서 동일하게 유지됩니다. 변경되는 부분은 오케스트레이션을 수행하는 온라인 스토어 서비스입니다. 한 경우 서비스는 WCF 서비스로 직접 코딩됩니다. 다른 경우의 경우 서비스는 WF4에서 WCF 워크플로 서비스로 작성됩니다. 추적 및 지속성과 같은 WF 관련 기능은 이 테스트에 대해 꺼져 있습니다.
환경
클라이언트 요청은 여러 컴퓨터에서 HTTP를 통해 온라인 스토어 서비스에 요청됩니다. 단일 컴퓨터는 세 가지 서비스를 모두 호스팅합니다. 온라인 스토어 서비스와 백 엔드 서비스 간의 전송 계층은 TCP 또는 HTTP입니다. 작업/초의 측정은 온라인 스토어 서비스에 대한 완료된 PurchaseOrder 호출 수를 기반으로 합니다. 채널 풀링이 WF4에서 사용할 수 있는 새로운 기능입니다. 이 테스트 채널 풀링의 WCF 부분에서는 기본 제공되지 않으므로 온라인 스토어 서비스에서 간단한 풀링 기술의 손으로 코딩된 구현이 사용되었습니다.
성능
채널 풀링 없이 백 엔드 TCP 서비스에 연결하는 WF 서비스는 처리량에 17.2% 영향을 줍니다. 채널 풀링을 사용하면 패널티는 약 23.8%입니다. HTTP의 경우 영향이 훨씬 적습니다. 풀링이 없는 경우 4.3%, 풀링이 있는 경우 8.1%입니다. 또한 HTTP를 사용할 때 채널 풀링이 거의 이점을 제공하지 않는다는 점에 유의해야 합니다.
이 테스트에서 손으로 코딩한 WCF 서비스와 비교하여 WF4 런타임의 오버헤드가 있지만 최악의 시나리오로 간주될 수 있습니다. 이 테스트의 두 백 엔드 서비스는 거의 작동하지 않습니다. 실제 엔드 투 엔드 시나리오에서 이러한 서비스는 데이터베이스 호출과 같은 비용이 많이 드는 작업을 수행하여 전송 계층의 성능 영향을 덜 중요하게 만듭니다. WF4에서 사용할 수 있는 기능의 이점과 함께 Workflow Foundation은 오케스트레이션 서비스를 만들기 위한 실행 가능한 선택입니다.
주요 성능 고려 사항
interop을 제외한 이 섹션의 기능 영역은 WF3과 WF4 간에 크게 변경되었습니다. 이는 워크플로 애플리케이션의 디자인과 성능에 영향을 줍니다.
워크플로 활성화 대기 시간
WCF 워크플로 서비스 애플리케이션에서 새 워크플로를 시작하거나 기존 워크플로를 로드하는 대기 시간은 차단될 수 있으므로 중요합니다. 이 테스트 사례는 일반적인 시나리오에서 WF4 XAMLX 호스트에 대해 WF3 XOML 호스트를 측정합니다.
환경 설정
테스트 설정
이 시나리오에서 클라이언트 컴퓨터는 컨텍스트 기반 상관 관계를 사용하여 WCF 워크플로 서비스에 연결합니다. 컨텍스트 상관 관계에는 특별한 컨텍스트 바인딩이 필요하며 컨텍스트 헤더 또는 쿠키를 사용하여 메시지를 올바른 워크플로 인스턴스와 연결합니다. 상관 관계 ID가 메시지 헤더에 있으므로 메시지 본문을 구문 분석할 필요가 없다는 장점이 있습니다.
서비스는 요청을 사용하여 새 워크플로를 만들고 즉시 응답을 보내 대기 시간 측정에 워크플로를 실행하는 데 소요된 시간이 포함되지 않도록 합니다. WF3 워크플로는 코드 숨김이 있는 XOML이고 WF4 워크플로는 전적으로 XAML입니다. WF4 워크플로는 다음과 같습니다.
활동은 Receive 워크플로 인스턴스를 만듭니다. 받은 메시지에 전달된 값이 회신 메시지에 에코됩니다. 회신 뒤의 시퀀스에는 나머지 워크플로가 포함됩니다. 위의 경우 하나의 주석 활동만 표시됩니다. 워크플로 복잡성을 시뮬레이션하기 위해 주석 작업 수가 변경되었습니다. 주석 활동은 작업을 수행하지 않는 WF3 CodeActivity 과 동일합니다. 주석 작업에 대한 자세한 내용은 이 문서의 앞부분에 있는 "구성 요소 수준 성능 비교" 섹션을 참조하세요.
테스트 결과
WCF 워크플로 서비스의 차가운 및 따뜻한 지연 시간:
이전 차트에서 콜드는 지정된 워크플로에 대한 기존 WorkflowServiceHost 항목이 없는 경우를 나타냅니다. 즉, 콜드 대기 시간은 워크플로를 처음으로 사용하고 XOML 또는 XAML을 컴파일해야 하는 경우입니다. 워밍업 대기 시간은 워크플로 유형이 이미 컴파일된 경우, 새 워크플로 인스턴스를 생성하는 데 필요한 시간입니다. 워크플로의 복잡성은 WF4 사례에서 거의 차이가 없지만 WF3 사례에서는 선형 진행이 있습니다.
상관 관계 처리량
WF4에는 새로운 콘텐츠 기반 상관 관계 기능이 도입되었습니다. WF3는 컨텍스트 기반 상관 관계만 제공했습니다. 컨텍스트 기반 상관 관계는 특정 WCF 채널 바인딩을 통해서만 수행할 수 있습니다. 워크플로 ID는 이러한 바인딩을 사용할 때 메시지 헤더에 삽입됩니다. WF3 런타임은 ID로만 워크플로를 식별할 수 있습니다. 콘텐츠 기반 상관 관계를 사용하면 워크플로 작성자가 계정 번호 또는 고객 ID와 같은 관련 데이터에서 상관 관계 키를 만들 수 있습니다.
컨텍스트 기반 상관 관계는 상관 관계 키가 메시지 헤더에 있다는 측면에서 성능 이점이 있습니다. 키는 직렬화 해제/메시지 복사 없이 메시지에서 읽을 수 있습니다. 콘텐츠 기반 상관 관계에서 상관 관계 키는 메시지 본문에 저장됩니다. XPath 식은 키를 찾는 데 사용됩니다. 이 추가 처리 비용은 메시지 크기, 본문의 키 깊이 및 키 수에 따라 달라집니다. 이 테스트는 컨텍스트 및 콘텐츠 기반 상관 관계를 비교하고 여러 키를 사용할 때 성능 저하를 보여 줍니다.
환경 설정
테스트 설정
이전 워크플로는 지속성 섹션에서 사용된 워크플로와 동일합니다. 지속성이 없는 상관 관계 테스트의 경우 런타임에 지속성 공급자가 설치되어 있지 않습니다. 상관 관계는 CreateOrder와 CompleteOrder의 두 위치에서 발생합니다.
테스트 결과
이 그래프는 콘텐츠 기반 상관 관계에 사용되는 키 수가 증가함에 따라 성능이 감소했음을 보여 줍니다. TCP와 HTTP 간의 곡선 유사성은 이러한 프로토콜과 연결된 오버헤드를 나타냅니다.
지속성과 상관 관계
지속형 워크플로를 사용하면 콘텐츠 기반 상관 관계의 CPU 압력이 워크플로 런타임에서 SQL 데이터베이스로 이동합니다. SQL 지속성 공급자의 저장 프로시저는 키를 일치시켜 적절한 워크플로를 찾는 작업을 수행합니다.
컨텍스트 기반 상관 관계는 콘텐츠 기반 상관 관계보다 더 빠릅니다. 그러나 지속성이 상관 관계보다 성능에 더 많은 영향을 주기 때문에 그 차이는 덜 두드러집니다.
복잡한 워크플로 처리량
워크플로의 복잡성은 활동 수에 의해서만 측정되지 않습니다. 복합 활동에는 많은 자식이 포함될 수 있으며 이러한 자식은 복합 활동일 수도 있습니다. 중첩 수준 수가 증가함에 따라 현재 실행 상태에 있을 수 있는 활동 수와 상태에 있을 수 있는 변수의 수도 증가합니다. 이 테스트는 복잡한 워크플로를 실행할 때 WF3과 WF4 사이의 처리량을 비교합니다.
테스트 설정
이러한 테스트는 Windows Server 2008 x64를 실행하는 4GB RAM이 있는 Intel Xeon X5355 @ 2.66GHz 4방향 컴퓨터에서 실행되었습니다. 테스트 코드는 코어당 하나의 스레드가 있는 단일 프로세스에서 실행되며% CPU 사용률 100%에 도달합니다.
이 테스트에 대해 생성된 워크플로에는 각 시퀀스의 깊이 및 활동 수라는 두 가지 주요 변수가 있습니다. 각 깊이 수준에는 병렬 활동, 루프, 의사 결정, 할당, 시퀀스가 포함되어 있습니다. 아래 그림의 WF4 디자이너에서 최상위 흐름도가 그려집니다. 각 순서도 작업은 주 순서도와 유사합니다. 깊이가 테스트의 매개 변수로 제한되는 이 워크플로를 그리는 경우 프랙탈을 생각하는 것이 도움이 될 수 있습니다.
지정된 테스트의 활동 수는 시퀀스당 활동 수와 깊이에 따라 결정됩니다. 다음 수식은 WF4 테스트의 활동 수를 계산합니다.
WF3 테스트의 활동 수는 추가 시퀀스로 인해 약간 다른 수식으로 계산할 수 있습니다.
여기서 d는 깊이이고 a는 시퀀스당 활동 수입니다. 이러한 수식의 논리는 첫 번째 상수에 a를 곱한 값이 시퀀스 수이고 두 번째 상수는 현재 수준의 정적 활동 수라는 것입니다. 각 순서도에는 세 가지 하위 작업이 있습니다. 가장 하위 깊이 수준에서 이러한 순서도는 비어 있지만, 다른 수준에서는 메인 순서도의 복사본입니다. 각 테스트 변형의 워크플로 정의에 있는 활동 수는 다음 표에 표시됩니다.
워크플로 정의의 활동 수는 각 깊이 수준에 따라 급격히 증가합니다. 그러나 지정된 워크플로 인스턴스에서 의사 결정 지점당 하나의 경로만 실행되므로 실제 활동의 작은 하위 집합만 실행됩니다.
WF3에 해당하는 워크플로가 만들어졌습니다. WF3 디자이너는 중첩 대신 디자인 영역에 전체 워크플로를 표시하므로 이 항목에 표시하기에는 너무 큽합니다. 워크플로의 코드 조각은 다음과 같습니다.
극단적인 경우 중첩을 실행하기 위해 이 테스트의 일부인 다른 워크플로는 100개의 중첩 시퀀스를 사용합니다. 가장 안쪽 시퀀스에서는 단일 Comment 또는 CodeActivity.
추적 및 지속성은 이 테스트의 일부로 사용되지 않습니다.
테스트 결과
깊이가 많고 활동이 많은 복잡한 워크플로에서도 성능 결과는 이 문서의 앞부분에 표시된 다른 처리량 수와 일치합니다. WF4의 처리량은 수십 배 더 빠르며, 로그 척도로 비교해야 합니다.
메모리
Windows Workflow Foundation의 메모리 오버헤드는 워크플로 복잡성과 워크플로 정의 수의 두 가지 주요 영역으로 측정됩니다. 메모리 측정은 Windows 7 64비트 워크스테이션에서 수행되었습니다. 성능 카운터 모니터링, Environment.WorkingSet 폴링 또는 VMMap에서 사용할 수 있는 VMMap과 같은 도구를 사용하는 등 작업 집합 크기를 측정하는 방법에는 여러 가지가 있습니다. 메서드의 조합은 각 테스트의 결과를 가져오고 확인하는 데 사용되었습니다.
워크플로 복잡성 테스트
워크플로 복잡성 테스트는 워크플로의 복잡성에 따라 작업 집합 차이를 측정합니다. 이전 섹션에서 사용된 복잡한 워크플로 외에도 단일 작업 워크플로와 1000개의 활동이 있는 시퀀스의 두 가지 기본 사례를 포함하도록 새로운 변형이 추가됩니다. 이러한 테스트의 경우 워크플로가 초기화되고 1분 동안 단일 직렬 루프에서 완료되도록 실행됩니다. 각 테스트 변형은 세 번 실행되고 기록된 데이터는 이 세 실행의 평균입니다.
두 가지 새로운 기본 테스트에는 아래와 같은 워크플로가 있습니다.
위에 표시된 WF3 워크플로에서는 빈 CodeActivity 활동이 사용됩니다. 위의 WF4 워크플로는 Comment 활동을 사용합니다. 이 작업은 이 Comment 문서의 앞부분에 있는 구성 요소 수준 성능 비교 섹션에 설명되어 있습니다.
이 그래프에서 확인할 수 있는 명확한 추세 중 하나는 중첩이 WF3 및 WF4의 메모리 사용량에 상대적으로 최소한의 영향을 미친다는 것입니다. 가장 중요한 메모리 영향은 지정된 워크플로의 활동 수에서 비롯됩니다. 시퀀스 1000, 복잡한 깊이 5 시퀀스 5 및 복합 깊이 7 시퀀스 1 변형의 데이터를 감안할 때 활동 수가 수천 개에 들어가면 메모리 사용량이 더 눈에 띄게 됩니다. 최대 29K 활동이 있는 극단적인 경우(깊이 7 시퀀스 1)에서 WF4는 WF3보다 거의 79% 적은 메모리를 사용합니다.
다중 워크플로 정의 테스트
워크플로 정의당 메모리 측정은 WF3 및 WF4에서 워크플로를 호스팅하는 데 사용할 수 있는 옵션 때문에 두 가지 테스트로 나뉩니다. 테스트는 지정된 워크플로가 인스턴스화되고 정의당 한 번만 실행된다는 점에서 워크플로 복잡성 테스트와는 다른 방식으로 실행됩니다. 이는 워크플로 정의와 해당 호스트가 AppDomain의 수명 동안 메모리에 남아 있기 때문입니다. 가비지 수집 중에 지정된 워크플로 인스턴스를 실행하는 데 사용되는 메모리를 정리해야 합니다. WF4에 대한 마이그레이션 지침에는 호스팅 옵션에 대한 자세한 정보가 포함되어 있습니다. 자세한 내용은 WF 마이그레이션 쿡북: 워크플로 호스팅을 참조하세요.
워크플로 정의 테스트에 대한 많은 워크플로 정의를 만드는 작업은 여러 가지 방법으로 수행할 수 있습니다. 예를 들어 코드 생성을 사용하여 이름을 제외하고 동일한 1000개의 워크플로 집합을 만들고 각 워크플로를 별도의 파일에 저장할 수 있습니다. 이 방법은 콘솔 호스팅 테스트를 위해 수행되었습니다. WF3 WorkflowRuntime 에서 클래스는 워크플로 정의를 실행하는 데 사용되었습니다. WF4는 WorkflowApplication를 사용하여 단일 워크플로 인스턴스를 만들거나, WorkflowInvoker를 메서드 호출처럼 직접 사용하여 작업을 실행할 수 있습니다. WorkflowApplication 는 단일 워크플로 인스턴스의 호스트이며 이 테스트에서 사용된 것과 더 가까운 기능 패리티 WorkflowRuntime 를 가집니다.
IIS에서 워크플로를 호스팅하는 경우 모든 XAMLX 또는 XOML 파일을 생성하는 대신 새 VirtualPathProvider 워크플로를 만드는 데 사용할 WorkflowServiceHost 수 있습니다. 들어오는 VirtualPathProvider 요청을 처리하고 데이터베이스에서 로드하거나 즉석에서 생성할 수 있는 "가상 파일"로 응답합니다. 따라서 1000 물리적 파일을 만들 필요가 없습니다.
콘솔 테스트에 사용된 워크플로 정의는 단일 활동이 있는 간단한 순차 워크플로였습니다. 단일 활동은 WF3 사례에 대해 비어 있는 CodeActivity였고, WF4 사례에 대해서는 Comment 활동이었습니다. IIS 호스팅 사례는 메시지 수신을 시작하고 회신 보내기로 끝나는 워크플로를 사용했습니다.
다음 이미지는 ReceiveActivity가 있는 WF3 워크플로와 요청/응답 패턴이 있는 WF4 워크플로를 보여 줍니다.
다음 표에서는 단일 워크플로 정의와 1001 정의 간의 작업 집합의 델타를 보여 줍니다.
| 호스팅 옵션 | WF3 작업 집합 델타 | WF4 작업 집합 델타 |
|---|---|---|
| 콘솔 애플리케이션 호스팅 워크플로 | 18MB | 9MB |
| IIS 호스티드 워크플로 서비스 | 446MB | 364MB |
IIS에서 워크플로 정의를 호스팅하면 자세한 WCF 서비스 아티팩트 및 호스트와 연결된 메시지 처리 논리로 인해 WorkflowServiceHost훨씬 더 많은 메모리가 사용됩니다.
WF3에서 콘솔 호스팅의 경우 워크플로는 XOML 대신 코드로 구현되었습니다. WF4에서 기본값은 XAML을 사용하는 것입니다. XAML은 어셈블리에 포함된 리소스로 저장되고 런타임 중에 컴파일되어 워크플로의 구현을 제공합니다. 이 프로세스와 관련된 오버헤드가 있습니다. WF3과 WF4를 공정하게 비교하기 위해 XAML 대신 코딩된 워크플로가 사용되었습니다. WF4 워크플로 중 하나의 예는 다음과 같습니다.
public class Workflow1 : Activity
{
protected override Func<Activity> Implementation
{
get
{
return new Func<Activity>(() =>
{
return new Sequence
{
Activities = {
new Comment()
}
};
});
}
set
{
base.Implementation = value;
}
}
}
메모리 소비에 영향을 줄 수 있는 다른 많은 요인이 있습니다. 모든 관리되는 프로그램에 대해 동일한 조언이 계속 적용됩니다. IIS 호스팅 환경에서 WorkflowServiceHost 워크플로 정의에 대해 만든 개체는 애플리케이션 풀이 재활용될 때까지 메모리에 유지됩니다. 확장을 작성할 때는 이 점을 염두에 두어야 합니다. 또한 "전역" 변수(전체 워크플로로 범위가 지정된 변수)를 방지하고 가능한 경우 변수 범위를 제한하는 것이 가장 좋습니다.
워크플로 런타임 서비스
고집
WF3 및 WF4는 모두 SQL 지속성 공급자와 함께 제공됩니다. WF3 SQL 지속성 공급자는 워크플로 인스턴스를 직렬화하고 Blob에 저장하는 간단한 구현입니다. 이러한 이유로 이 공급자의 성능은 워크플로 인스턴스의 크기에 따라 크게 달라집니다. WF3에서는 이 문서의 앞에서 설명한 대로 여러 가지 이유로 인스턴스 크기가 증가할 수 있습니다. 데이터베이스에 직렬화된 인스턴스를 저장하면 워크플로 상태를 볼 수 없으므로 많은 고객이 기본 SQL 지속성 공급자를 사용하지 않도록 선택합니다. 워크플로 ID를 모르고 특정 워크플로를 찾으려면 지속된 각 인스턴스를 역직렬화하고 내용을 검사해야 합니다. 많은 개발자는 이 장애물을 극복하기 위해 자체 지속성 공급자를 작성하는 것을 선호합니다.
WF4 SQL 지속성 공급자는 이러한 문제 중 일부를 해결하려고 했습니다. 지속성 테이블은 활성 책갈피 및 승격 가능한 속성과 같은 특정 정보를 노출합니다. WF4의 새로운 콘텐츠 기반 상관 관계 기능은 WF3 SQL 지속성 접근 방식을 사용하여 잘 수행되지 않으며, 이로 인해 지속형 워크플로 인스턴스의 조직이 약간 변경되었습니다. 이렇게 하면 지속성 공급자의 작업이 더 복잡해지고 데이터베이스에 추가적인 스트레스가 가해집니다.
환경 설정
테스트 설정
향상된 기능 집합과 더 나은 동시성 처리에도 불구하고 WF4의 SQL 지속성 공급자는 WF3의 공급자보다 빠릅니다. 이를 소개하기 위해 WF3 및 WF4에서 기본적으로 동일한 작업을 수행하는 두 워크플로를 아래와 비교합니다.
두 워크플로는 모두 받은 메시지에 의해 만들어집니다. 초기 회신을 보낸 후에는 워크플로가 유지됩니다. WF3의 경우 빈 TransactionScopeActivity 항목이 지속성을 시작하는 데 사용됩니다. 활동을 "닫을 때 지속"으로 표시하여 WF3에서도 동일한 작업을 수행할 수 있습니다. 상호 관련된 두 번째 메시지가 워크플로를 완료합니다. 워크플로는 유지되지만 언로드되지는 않습니다.
테스트 결과
클라이언트와 중간 계층 간의 전송이 HTTP인 경우 WF4의 지속성은 2.6배 개선된 것으로 표시됩니다. TCP 전송은 해당 요소를 3.0배로 증가합니다. 모든 경우에 중간 계층의 CPU 사용률은 98% 이상입니다. WF4 처리량이 더 큰 이유는 더 빠른 워크플로 런타임 때문입니다. 직렬화된 인스턴스의 크기는 두 경우 모두 낮으며 이 상황에서 주요 기여 요소가 아닙니다.
이 테스트의 WF3 및 WF4 워크플로는 모두 활동을 사용하여 지속성이 발생하는 시기를 명시적으로 나타냅니다. 이렇게 하면 워크플로를 언로드하지 않고 유지할 수 있습니다. WF3에서는 TimeToUnload 기능을 사용하여 지속시킬 수 있지만, 이 경우 워크플로 인스턴스가 메모리에서 제거됩니다. WF3을 사용하는 개발자가 워크플로가 특정 지점에서 유지되도록 하려는 경우 워크플로 정의를 변경하거나 워크플로 인스턴스를 언로드하고 다시 로드하는 데 드는 비용을 지불해야 합니다. WF4의 새로운 기능을 사용하면 언로드하지 않고도 유지할 수 있습니다 TimeToPersist. 이 기능을 사용하면 워크플로 인스턴스를 유휴 상태로 유지하지만 임계값이 충족되거나 실행이 다시 시작될 때까지 TimeToUnload 메모리에 유지됩니다.
WF4 SQL 지속성 공급자는 데이터베이스 계층에서 더 많은 작업을 수행합니다. SQL 데이터베이스는 병목 상태가 될 수 있으므로 CPU 및 디스크 사용량을 모니터링하는 것이 중요합니다. 성능 테스트 워크플로 애플리케이션인 경우 SQL 데이터베이스에서 다음 성능 카운터를 포함해야 합니다.
PhysicalDisk\%Disk 디스크 읽기 시간
PhysicalDisk\% 디스크 시간
PhysicalDisk\% 디스크 쓰기 시간
PhysicalDisk\% 평균 디스크 큐 길이
PhysicalDisk\Avg. 디스크 읽기 대기열 길이
물리 디스크\평균 디스크 쓰기 대기열 길이
PhysicalDisk\현재 디스크 대기열 길이
프로세서 정보\% 프로세서 시간
SQLServer:Latches\평균 래치 대기 시간(ms)
SQLServer:Latches\래치 대기 횟수/초
추적
워크플로 추적을 사용하여 워크플로의 진행률을 추적할 수 있습니다. 추적 이벤트에 포함된 정보는 추적 프로필에 의해 결정됩니다. 추적 프로필이 복잡할수록 추적 비용이 더 많이 듭니다.
SQL 기반 추적 서비스와 함께 제공되는 WF3입니다. 이 서비스는 일괄 처리 및 비 일괄 처리 모드에서 작동할 수 있습니다. 일괄 처리되지 않은 모드에서는 추적 이벤트가 데이터베이스에 직접 기록됩니다. 일괄 처리 모드에서 추적 이벤트는 워크플로 인스턴스 상태와 동일한 일괄 처리로 수집됩니다. 일괄 처리 모드는 가장 광범위한 워크플로 디자인에 가장 적합한 성능을 제공합니다. 그러나 워크플로가 지속되지 않고 많은 활동을 실행하고 해당 활동을 추적하는 경우 일괄 처리는 성능에 부정적인 영향을 미칠 수 있습니다. 이는 일반적으로 루프에서 발생하며 이 시나리오를 방지하는 가장 좋은 방법은 지속성 지점을 포함하도록 큰 루프를 디자인하는 것입니다. 지속성 지점을 루프에 도입하면 성능에도 부정적인 영향을 줄 수 있으므로 각 비용을 측정하고 균형을 유지하는 것이 중요합니다.
WF4는 SQL 추적 서비스와 함께 제공되지 않습니다. 추적 정보를 .NET Framework에 기본 제공하지 않고 애플리케이션 서버에서 SQL 데이터베이스에 기록하는 것이 더 효율적으로 처리될 수 있습니다. 따라서 이제 AppFabric에서 SQL 추적을 처리합니다. WF4의 기본 추적 공급자는 ETW(Windows용 이벤트 추적)를 기반으로 합니다.
ETW는 Windows에 기본 제공되는 커널 수준의 짧은 대기 시간 이벤트 시스템입니다. 실제로 소비자가 있을 때만 이벤트 추적에 대한 페널티를 발생시키는 공급자/소비자 모델을 사용합니다. 프로세서, 디스크, 메모리 및 네트워크 사용과 같은 커널 이벤트 외에도 많은 애플리케이션이 ETW를 활용합니다. ETW 이벤트는 애플리케이션에 맞춰 사용자 지정할 수 있어, 성능 카운터보다 더 강력합니다. 이벤트에는 워크플로 ID 또는 정보 메시지와 같은 텍스트가 포함될 수 있습니다. 또한 이벤트는 비트 마스크로 분류되므로 특정 이벤트 하위 집합을 사용하면 모든 이벤트를 캡처하는 것보다 성능에 미치는 영향이 줄어듭니다.
SQL 대신 추적에 ETW를 사용하는 방법의 이점은 다음과 같습니다.
추적 이벤트의 컬렉션은 다른 프로세스로 구분할 수 있습니다. 이렇게 하면 이벤트가 기록되는 방식이 더 유연합니다.
ETW 추적 이벤트는 WCF ETW 이벤트 또는 SQL Server 또는 커널 공급자와 같은 다른 ETW 공급자와 쉽게 결합됩니다.
워크플로 작성자는 WF3 SQL 추적 서비스의 일괄 처리 모드와 같은 특정 추적 구현에서 더 잘 작동하도록 워크플로를 변경할 필요가 없습니다.
관리자는 호스트 프로세스를 재활용하지 않고도 추적을 켜거나 끌 수 있습니다.
ETW 추적의 성능 이점은 단점이 있습니다. 시스템이 리소스 압박이 심한 경우 ETW 이벤트가 손실될 수 있습니다. 이벤트 처리는 정상적인 프로그램 실행을 차단하기 위한 것이 아니므로 모든 ETW 이벤트가 구독자에게 브로드캐스트되는 것은 아닙니다. 따라서 ETW 추적은 상태 모니터링에 적합하지만 감사에는 적합하지 않습니다.
WF4에는 SQL 추적 공급자가 없지만 AppFabric은 그렇게 합니다. AppFabric의 SQL 추적 방법은 이벤트를 일괄 처리하고 빠른 삽입을 위해 설계된 SQL 테이블에 쓰는 Windows 서비스를 사용하여 ETW 이벤트를 구독하는 것입니다. 별도의 작업은 이 테이블의 데이터를 추출하여 AppFabric 대시보드에서 볼 수 있는 보고 테이블로 변환합니다. 즉, 추적 이벤트의 일괄 처리는 제공된 워크플로와 독립적으로 처리되므로 기록되기 전에 지속성 지점을 기다릴 필요가 없습니다.
ETW 이벤트는 logman 또는 xperf와 같은 도구를 사용하여 기록할 수 있습니다. 압축 ETL 파일은 xperfview와 같은 도구를 사용하여 보거나 추적을 사용하여 XML과 같이 더 읽기 쉬운 형식으로 변환할 수 있습니다. WF3에서 SQL 데이터베이스 없이 추적 이벤트를 가져오는 유일한 옵션은 사용자 지정 추적 서비스를 만드는 것입니다. ETW에 대한 자세한 내용은 Windows 및 이벤트 추적용 WCF 서비스 및 이벤트 추적- Windows 애플리케이션을 참조하세요.
워크플로 추적을 사용하도록 설정하면 다양한 수준의 성능에 영향을 줍니다. 아래 벤치마크는 logman 도구를 사용하여 ETW 추적 이벤트를 수집하여 ETL 파일에 기록합니다. AppFabric의 SQL 추적 비용은 이 문서의 범위에 포함되지 않습니다. AppFabric에도 사용되는 기본 추적 프로필이 이 벤치마크에 표시됩니다. 상태 모니터링 이벤트만 추적하는 비용도 포함됩니다. 이러한 이벤트는 문제를 해결하고 시스템의 평균 처리량을 결정하는 데 유용합니다.
환경 설정
테스트 결과
상태 모니터링은 처리량에 약 3%의 영향을 미칩니다. 기본 프로필의 비용은 약 8%.
Interop
WF4는 WF의 거의 완전한 재작성이므로 WF3 워크플로 및 활동은 WF4와 직접 호환되지 않습니다. Windows Workflow Foundation을 조기에 채택한 많은 고객은 사내 또는 타사 워크플로 정의 및 WF3에 대한 사용자 지정 활동을 갖게 됩니다. WF4로의 전환을 용이하게 하는 한 가지 방법은 WF4 워크플로 내에서 WF3 활동을 실행할 수 있는 Interop 작업을 사용하는 것입니다. 필요한 경우에만 활동을 사용하는 것이 좋습니다 Interop . WF4로 마이그레이션하는 방법에 대한 자세한 내용은 WF4 마이그레이션 지침을 확인하세요.
환경 설정
테스트 결과
다음 표에서는 다양한 구성에서 순서대로 5개의 작업이 포함된 워크플로를 실행한 결과를 보여 줍니다.
| 테스트 | 처리량(workflows/sec) |
|---|---|
| WF3 런타임에서의 WF3 시퀀스 | 1,576 |
| Interop을 사용하는 WF4 런타임의 WF3 시퀀스 | 2,745 |
| WF4 시퀀스 | 153,582 |
직선 WF3을 통해 Interop을 사용하는 경우 주목할 만한 성능이 향상되었습니다. 그러나 WF4 활동과 비교할 때 증가는 무시할 수 있습니다.
요약
WF4의 성과에 대한 막대한 투자는 많은 중요한 분야에서 성과를 거두었습니다. 개별 워크플로 구성 요소 성능은 간결한 WF 런타임으로 인해 WF3에 비해 WF4에서 수백 배 더 빠른 경우도 있습니다. 대기 시간 숫자도 훨씬 더 좋습니다. 즉, WF를 사용하는 추가적인 이점을 고려할 때 WCF 오케스트레이션 서비스를 직접 코딩하는 것과 달리 WF 사용에 대한 성능 저하는 매우 작습니다. 지속성 성능은 2.5배에서 3.0배로 증가했습니다. 워크플로 추적을 통해 상태 모니터링을 수행하면 오버헤드가 거의 없습니다. WF3에서 WF4로 이동하는 것을 고려하는 경우 포괄적인 마이그레이션 가이드 집합을 사용할 수 있습니다. 이 모든 것은 WF4를 복잡한 애플리케이션을 작성하기 위한 매력적인 옵션으로 만들어야 합니다.
GitHub에서 Microsoft와 공동 작업
이 콘텐츠의 원본은 GitHub에서 찾을 수 있으며, 여기서 문제와 끌어오기 요청을 만들고 검토할 수도 있습니다. 자세한 내용은 참여자 가이드를 참조하세요.
.NET