다음을 통해 공유

Service Bus 메시징을 사용한 성능 향상의 모범 사례

  • 아티클

이 문서에서는 조정된 메시지를 교환할 때 Azure Service Bus를 사용하여 성능을 최적화하는 방법에 대해 설명합니다. 이 문서의 첫 번째 부분에서는 성능 향상을 위한 다양한 메커니즘에 대해 설명합니다. 두 번째 부분은 특정 시나리오에서 최고의 성능을 제공하는 방식으로 Service Bus를 사용하는 지침을 제공합니다.

이 문서 전반적으로 “클라이언트”라는 용어는 Service Bus에 액세스하는 모든 엔터티를 가리킵니다. 클라이언트는 발신기 또는 수신기의 역할을 수행할 수 있습니다. "발신기"라는 용어는 Service Bus 큐 클라이언트 또는 Service Bus 큐나 항목에 메시지를 보내는 항목 클라이언트에 사용됩니다. "수신기"라는 용어는 Service Bus 큐 또는 구독에서 메시지를 받는 Service Bus 큐 클라이언트 또는 구독 클라이언트를 나타냅니다.

리소스 계획 및 고려 사항

다른 기술 리소싱과 마찬가지로, Azure Service Bus가 애플리케이션에서 기대하는 성능을 제공하도록 하는 데 있어서 가장 중요한 요인은 신중한 계획 과정입니다. Service Bus 네임스페이스에 적합한 구성 또는 토폴로지는 애플리케이션 아키텍처와 관련된 다양한 요소 및 각 Service Bus 기능이 사용되는 방식에 따라 달라집니다.

가격 책정 계층

Service Bus는 다양한 가격 책정 계층을 제공합니다. 애플리케이션 요구 사항에 적합한 계층을 선택하는 것이 좋습니다.

  • 표준 계층 - 개발자/테스트 환경이나 애플리케이션이 제한의 영향을 받지 않는 낮은 처리량 시나리오에 적합합니다.

  • 프리미엄 계층 - 예측 가능한 대기 시간과 처리량이 요구되는 다양한 처리량 요구 사항이 있는 프로덕션 환경에 적합합니다. 또한 프리미엄 네임스페이스를 자동으로 스케일링하고 Service Bus를 처리량 급증을 수용하도록 설정할 수 있습니다.

참고 항목

올바른 계층을 선택하지 않으면 제한될 수 있는 Service Bus 네임스페이스가 과도하게 발생할 위험이 있습니다.

제한으로 인해 데이터가 손실되지는 않습니다. Service Bus SDK를 활용하는 애플리케이션은 기본 재시도 정책을 사용하여 데이터가 Service Bus에서 최종적으로 수락되도록 할 수 있습니다.

프리미엄 처리량 계산

Service Bus로 전송되는 데이터는 이진으로 직렬화된 다음, 수신자가 받았을 때 역직렬화됩니다. 따라서 애플리케이션은 메시지를 작업의 원자성 단위로 생각하는 반면, Service Bus는 바이트(또는 메가바이트)를 기준으로 처리량을 측정합니다.

처리량 요구 사항을 계산할 때 Service Bus(수신)로 전송되는 데이터 및 Service Bus(송신)에서 수신되는 데이터를 고려합니다.

예상대로, 함께 일괄로 처리할 수 있는 더 작은 메시지 페이로드의 경우 처리량이 더 높습니다.

벤치마크

다음은 Service Bus 네임스페이스에 대해 수신되는 예상 처리량을 확인하기 위해 실행할 수 있는 GitHub 샘플입니다. 이 벤치마크 테스트에서는 수신 및 송신의 MU(메시징 단위)당 약 4MB/초가 확인되었습니다.

벤치마킹 샘플에서는 고급 기능을 사용하지 않으므로 애플리케이션에서 확인되는 처리량은 시나리오에 따라 다릅니다.

컴퓨팅 고려 사항

Service Bus는 컴퓨팅 사용률에 영향을 미칠 수 있는 여러 백그라운드 프로세스를 운영합니다. 여기에는 타이머, 일정 및 메트릭 방출이 포함되지만 이에 국한되지는 않습니다. 또한 특정 Service Bus 기능을 사용하려면 예상 처리량을 줄일 수 있는 컴퓨팅 사용률이 필요합니다. 이러한 기능 중 일부는 다음과 같습니다.

  1. 세션.
  2. 단일 항목에 대해 여러 구독으로 팬아웃
  3. 단일 구독에서 많은 필터 실행
  4. 예약된 메시지
  5. 지연된 메시지
  6. 트랜잭션.
  7. 중복 제거 및 과거 기간
  8. 전달(한 엔터티에서 다른 엔터티로 전달)

애플리케이션에서 위의 기능을 활용하며, 사용자가 예상된 처리량을 받지 못하는 경우 CPU 사용량 메트릭을 검토하고 Service Bus 프리미엄 네임스페이스를 스케일 업하는 것을 고려할 수 있습니다. Azure Monitor를 활용하여 Service Bus 네임스페이스를 자동으로 스케일링할 수도 있습니다. 최적의 성능을 보장하려면 CPU 사용량이 70%를 초과하는 경우 MU(메시지 단위) 수를 늘리는 것이 좋습니다.

네임스페이스 간 분할

네임스페이스에 할당된 컴퓨팅(메시징 단위)을 확장하는 것이 더 쉬운 솔루션이지만, 처리량이 선형으로 증가하지 않을 수 있습니다. 처리량을 제한할 수 있는 Service Bus 내부(스토리지, 네트워크 등) 때문입니다.

이 경우 해결 방법은 여러 Service Bus 프리미엄 네임스페이스에서 엔터티(큐 및 토픽)를 분할하는 것입니다. 다른 Azure 지역의 여러 네임스페이스에서 분할을 고려할 수도 있습니다.

프로토콜

Service Bus를 사용하면 클라이언트에서 세 가지 프로토콜 중 하나를 통해 메시지를 보내고 받을 수 있습니다.

  1. AMQP(고급 메시지 큐 프로토콜)
  2. SBMP(Service Bus 메시징 프로토콜)
  3. HTTP(Hypertext Transfer Protocol)

AMQP는 Service Bus에 대한 연결을 유지하기 때문에 가장 효율적입니다. 또한 일괄 처리 및 프리페치를 구현합니다. 명시적으로 언급하지 않는 한 이 문서의 모든 내용에서는 AMQP 또는 SBMP를 사용하는 것으로 가정합니다.

Important

SBMP 프로토콜은 .NET Framework에만 사용할 수 있습니다. AMQP는 .NET Standard의 기본값입니다.

2026년 9월 30일에 Azure Service Bus에 대한 SBMP 프로토콜 지원이 사용 중지되므로 2026년 9월 30일 이후에는 더 이상 이 프로토콜을 사용할 수 없습니다. 해당 날짜 이전에 중요한 보안 업데이트와 개선된 기능을 제공하는 AMQP 프로토콜을 사용하여 최신 Azure Service Bus SDK 라이브러리로 마이그레이션하세요.

자세한 내용은 사용 중지 공지 지원을 참조하세요.

적절한 Service Bus .NET SDK 선택

Azure.Messaging.ServiceBus 패키지는 2020년 11월부터 사용 가능한 최신 Azure Service Bus .NET SDK입니다. 2026년 9월 30일까지 중요한 버그 수정을 계속 받을 수 있는 두 가지 이전 .NET SDK가 있지만 대신 최신 SDK를 사용하는 것이 좋습니다. 이전 SDK에서 이동하는 방법에 대한 자세한 내용은 마이그레이션 가이드를 참조하세요.

NuGet 패키지 기본 네임스페이스 최소 플랫폼 프로토콜
Azure.Messaging.ServiceBus(최신) Azure.Messaging.ServiceBus
Azure.Messaging.ServiceBus.Administration		 .NET Core 2.0
.NET Framework 4.6.1
Mono 5.4
유니버설 Windows 플랫폼 10.0.16299		 AMQP
HTTP
Microsoft.Azure.ServiceBus Microsoft.Azure.ServiceBus
Microsoft.Azure.ServiceBus.Management		 .NET Core 2.0
.NET Framework 4.6.1
Mono 5.4
유니버설 Windows 플랫폼 10.0.16299		 AMQP
HTTP

최소 .NET Standard 플랫폼 지원에 대한 자세한 내용은 .NET 구현 지원을 참조하세요.

2026년 9월 30일에 Azure SDK 지침을 따르지 않는 Azure Service Bus SDK 라이브러리 WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus 및 com.microsoft.azure.servicebus를 사용 중지합니다. 또한 SBMP 프로토콜에 대한 지원이 종료되므로 2026년 9월 30일 이후에는 더 이상 이 프로토콜을 사용할 수 없습니다. 해당 날짜 마이그레이션에 중요한 보안 업데이트와 개선된 기능을 제공하는 최신 Azure SDK 라이브러리로 마이그레이션합니다.

이전 라이브러리는 2026년 9월 30일 이후에도 계속 사용할 수 있지만 더 이상 Microsoft로부터 공식 지원 및 업데이트를 받을 수 없습니다. 자세한 내용은 사용 중지 공지 지원을 참조하세요.

팩터리 및 클라이언트 다시 사용

ServiceBusClient, ServiceBusSender, ServiceBusReceiver 및 ServiceBusProcessor와 같이 서비스와 상호 작용하는 Service Bus 클라이언트는 종속성 주입을 위해 싱글톤(또는 한 번 인스턴스화되고 공유됨)으로 등록되어야 합니다. ServiceBusClient(팩터리)는 ServiceBusClientBuilderExtensions를 사용하여 종속성 주입을 위해 등록될 수 있습니다.

각 메시지를 보내거나 받은 후에는 이러한 클라이언트를 닫거나 삭제하지 않는 것이 좋습니다. 엔터티 관련 개체(ServiceBusSender/Receiver/Processor)를 닫거나 삭제하면 Service Bus 서비스에 대한 연결이 중단됩니다. ServiceBusClient를 삭제하면 Service Bus 서비스에 대한 연결이 중단됩니다.

이 지침은 수명이 세션 자체와 동일하기 때문에 ServiceBusSessionReceiver에는 적용되지 않습니다. ServiceBusSessionReceiver로 작업하는 애플리케이션의 경우 ServiceBusClient의 싱글톤 인스턴스를 사용하여 해당 세션에 바인딩된 새 ServiceBusSessionReceiver에 걸쳐 있는 각 세션을 수락하는 것이 좋습니다. 애플리케이션이 해당 세션 처리를 완료하면 연결된 ServiceBusSessionReceiver를 삭제해야 합니다.

다음 정보는 모든 SDK에 적용됩니다.

참고 항목

여러 작업에 대해 동일한 팩터리 또는 클라이언트 개체를 다시 사용하면 많은 비용이 드는 연결 작업을 하지 않아도 됩니다. 동시 비동기 작업에 대해 다중 스레드에서 이러한 클라이언트 개체를 안전하게 사용할 수 있습니다.

동시 작업

보내기, 받기, 삭제 등의 작업에는 다소 시간이 걸립니다. 이 시간에는 Service Bus 서비스가 작업을 처리하는 데 걸리는 시간과 요청 및 응답의 대기 시간이 포함됩니다. 시간당 작업 수를 늘리려면 작업이 동시에 실행되어야 합니다.

클라이언트가 비동기 작업을 수행하여 동시 작업을 예약합니다. 이전 요청이 완료되기 전에 다음 요청이 시작됩니다. 다음 코드 조각은 비동기 전송 작업의 예제입니다.

var messageOne = new ServiceBusMessage(body);
var messageTwo = new ServiceBusMessage(body);

var sendFirstMessageTask =
    sender.SendMessageAsync(messageOne).ContinueWith(_ =>
    {
        Console.WriteLine("Sent message #1");
    });
var sendSecondMessageTask =
    sender.SendMessageAsync(messageTwo).ContinueWith(_ =>
    {
        Console.WriteLine("Sent message #2");
    });

await Task.WhenAll(sendFirstMessageTask, sendSecondMessageTask);
Console.WriteLine("All messages sent");

다음 코드는 비동기 수신 작업의 예제입니다.

var client = new ServiceBusClient(connectionString);
var options = new ServiceBusProcessorOptions 
{

      AutoCompleteMessages = false,
      MaxConcurrentCalls = 20
};
await using ServiceBusProcessor processor = client.CreateProcessor(queueName,options);
processor.ProcessMessageAsync += MessageHandler;
processor.ProcessErrorAsync += ErrorHandler;

static Task ErrorHandler(ProcessErrorEventArgs args)
{
    Console.WriteLine(args.Exception);
    return Task.CompletedTask;
};

static async Task MessageHandler(ProcessMessageEventArgs args)
{
    Console.WriteLine("Handle message");
    await args.CompleteMessageAsync(args.Message);
}

await processor.StartProcessingAsync();

수신 모드

큐 또는 구독 클라이언트를 만들 때 보기-잠금 또는 수신 및 삭제 중에서 수신 모드를 지정할 수 있습니다. 기본 수신 모드는 PeekLock입니다. 기본 모드에서 작동하는 경우 클라이언트가 Service Bus에서 메시지를 수신하기 위한 요청을 보냅니다. 클라이언트가 메시지를 받으면 메시지를 완료하기 위한 요청을 보냅니다.

수신 모드를 ReceiveAndDelete로 설정하면 이 두 단계가 단일 요청으로 결합되므로 그러면 전체 작업 수가 줄어들고 전체 메시지 처리량을 향상시킬 수 있습니다. 이와 같이 성능이 향상되지만 메시지 손실의 위험이 있습니다.

Service Bus는 수신 및 삭제 작업에 대한 트랜잭션을 지원하지 않습니다. 또한 클라이언트가 메시지를 연기하거나 배달 못 한 시나리오에서는 보기-잠금 의미 체계가 필요합니다.

프리페치

프리페치에서는 큐 또는 구독 클라이언트가 메시지를 수신할 때 서비스에서 추가 메시지를 로드할 수 있습니다. 클라이언트는 이러한 메시지를 로컬 캐시에 저장합니다. 캐시 크기는 ServiceBusReceiver.PrefetchCount 속성에 의해 결정됩니다. 프리페치를 사용할 수 있는 각 클라이언트는 각각의 캐시를 유지합니다. 캐시는 클라이언트 간에 공유되지 않습니다. 클라이언트가 수신 작업을 시작할 때 캐시가 비어 있으면 서비스에서 메시지의 배치를 전송합니다. 클라이언트가 수신 작업을 시작할 때 캐시에 메시지가 포함되어 있으면 캐시에서 해당 메시지를 가져옵니다.

메시지가 프리페치되는 경우 서비스는 프리페치된 메시지를 잠급니다. 잠금을 사용하면 프리페치된 메시지를 다른 수신기가 받을 수 없습니다. 잠금이 만료되기 전에 수신기가 메시지를 완료할 수 없는 경우 다른 수신기가 메시지를 사용할 수 있습니다. 프리페치된 메시지의 복사본은 캐시에 남아 있습니다. 만료 및 캐시된 복사본을 사용하는 수신기가 해당 메시지를 완료하려고 하면 예외를 수신합니다. 기본적으로 메시지 잠금은 60초 후에 만료됩니다. 이 값은 5분으로 연장할 수 있습니다. 만료된 메시지의 사용을 방지하려면 클라이언트가 잠금 제한 시간 간격 내에 사용할 수 있는 메시지 수보다 작은 캐시 크기를 설정합니다.

기본 잠금 만료 시간인 60초를 사용하는 경우 적절한 PrefetchCount 값은 모든 팩터리 수신기의 최대 처리 속도의 20배입니다. 예를 들어 팩터리에서 수신기 3개를 만들 경우 각 수신기는 초당 최대 10개의 메시지를 처리할 수 있습니다. 프리페치 수가 20 X 3 X 10 = 600을 초과해서는 안 됩니다. 기본적으로 PrefetchCount은(는) 서비스에서 추가 메시지를 페치하지 않음을 의미하는 0으로 설정되어 있습니다.

메시지를 프리페치할 경우 전체 메시지 작업 수 또는 왕복 수가 감소하므로 큐 또는 구독에 대한 전체 처리량이 증가합니다. 그러나 첫 번째 메시지를 가져오는 데는 메시지 크기가 증가하기 때문에 시간이 더 오래 걸립니다. 프리페치한 메시지를 클라이언트가 이미 다운로드했기 때문에 캐시에서 받는 것이 더 빠릅니다.

메시지의 TTL(Time to Live) 속성은 서버가 클라이언트에 메시지를 보낼 때 서버에 의해 확인됩니다. 클라이언트는 메시지를 수신할 때 메시지의 TTL 속성을 검사하지 않습니다. 대신, 클라이언트가 메시지를 캐시한 동안에는 메시지의 TTL이 경과된 경우에도 메시지를 수신할 수 있습니다.

프리페치는 청구 가능 메시징 작업의 수에 영향을 주지 않으며 Service Bus 클라이언트 프로토콜에 대해서만 사용할 수 있습니다. HTTP 프로토콜은 프리페치를 지원하지 않습니다. 프리페치는 동기 및 비동기 수신 작업에 사용할 수 있습니다.

자세한 내용은 다음 PrefetchCount 속성을 참조하세요.

ServiceBusReceiverOptions 또는 ServiceBusProcessorOptions에서 이러한 속성에 대한 값을 설정할 수 있습니다.

프리페치 및 receiveMessagesAsync

여러 메시지를 함께 프리페치하는 개념은 메시지를 일괄 처리(ReceiveMessagesAsync)로 처리하는 것과 유사한 의미를 갖지만 이러한 접근 방식을 함께 사용할 때 염두에 두어야 할 사소한 차이점이 있습니다.

프리페치는 ServiceBusReceiver의 구성(또는 모드)이고 ReceiveMessagesAsync는 작업(요청-응답 의미 체계 포함)입니다.

이러한 방식을 함께 사용하는 중에는 다음과 같은 경우를 고려합니다.

  • 프리페치는 ReceiveMessagesAsync에서 받을 것으로 예상되는 메시지 수보다 크거나 같아야 합니다.
  • 프리페치는 초당 처리된 메시지 수의 최대 n/3 배가 될 수 있습니다. 여기서 n은 기본 잠금 기간입니다.

과대 접근 방식을 사용하는 데는 몇 가지 문제가 있습니다. 즉, 메시지가 특정 수신자에게 잠겨 있음을 의미하기 때문에 프리페치 수를 높게 유지하는 것입니다. 앞에서 언급한 임계값 사이에 있는 프리페치 값을 시도하고 적합한 값을 식별하는 것이 좋습니다.

여러 큐 또는 토픽

단일 큐 또는 토픽으로 예상된 메시지를 수를 처리할 수 없는 경우에는 여러 메시징 엔터티를 사용합니다. 여러 엔터티를 사용할 때는 모든 엔터티에 동일한 클라이언트를 사용하는 대신 각 엔터티의 전용 클라이언트를 만듭니다.

큐나 토픽이 많다는 것은 배포 시 관리할 엔터티가 더 많다는 것을 의미합니다. 확장성 관점에서 볼 때 Service Bus는 이미 내부적으로 여러 로그에 부하를 분산시키기 때문에 실제로는 큰 차이가 없습니다. 따라서 6개의 큐나 토픽을 사용하거나 2개의 큐나 토픽을 사용하더라도 큰 차이는 없습니다.

사용하는 서비스 계층은 성능 예측 가능성에 영향을 줍니다. 표준 계층을 선택하는 경우 처리량 및 대기 시간은 공유 다중 테넌트 인프라에 비해 가장 좋습니다. 동일한 클러스터의 다른 테넌트는 처리량에 영향을 미칠 수 있습니다. 프리미엄을 선택하면 예측 가능한 성능을 제공하는 리소스가 확보되고 여러 큐 또는 토픽이 해당 리소스 풀에서 처리됩니다. 자세한 내용은 가격 책정 계층을 참조하세요.

분할된 네임스페이스

분할된 프리미엄 계층 네임스페이스를 사용하는 경우 MU(메시징 단위)가 낮은 다중 파티션은 MU가 높은 단일 파티션에 비해 더 나은 성능을 제공합니다.

시나리오

다음 섹션에서는 일반적인 메시징 시나리오에 대해 설명하고 기본 Service Bus 설정에 대해 간단히 소개합니다. 처리량 속도는 적음(초당 1개 메시지 미만), 보통(초당 1개 메시지 이상, 초당 100개 메시지 미만), 높음(초당 100개 메시지 이상)으로 분류됩니다. 클라이언트 수는 적음(5개 이하), 보통(5개 초과, 20개 이하), 많음(20개 초과)으로 분류됩니다.

처리량이 높은 큐

목표: 단일 큐의 처리량을 최대화합니다. 발신기와 수신기의 수가 작습니다.

  • 큐에 대한 전반적 전송 속도를 높이려면 여러 메시지 팩터리를 만들어 발신기를 만듭니다. 각 발신기에 대해 비동기 작업이나 여러 스레드를 사용합니다.
  • 큐에서 전반적 수신 속도를 높이려면 여러 메시지 팩터리를 만들어 수신기를 만듭니다.
  • 프리페치 수를 모든 팩터리 수신기의 최대 처리 속도의 20배로 설정합니다. 이렇게 하면 Service Bus 클라이언트 프로토콜 전송 횟수가 줄어듭니다.

처리량이 높은 복수 큐

목표: 여러 큐의 전체 처리량을 극대화합니다. 개별 큐의 처리량은 보통 또는 높음입니다.

여러 큐에서 최대 처리량을 얻으려면 여기에서 설명하는 설정을 사용하여 단일 큐의 처리량을 최대화합니다. 또한 다른 팩터리를 사용하여 다양한 큐에서 보내거나 받는 클라이언트를 만듭니다.

대기 시간이 짧은 큐

목표: 큐 또는 토픽의 대기 시간을 최소화합니다. 발신기와 수신기의 수가 작습니다. 큐의 처리량은 적음 또는 보통입니다.

  • 단일 클라이언트를 사용하는 경우 프리페치 수를 수신기의 처리 속도의 20배로 설정합니다. 동시에 여러 메시지가 큐에 도착할 경우 Service Bus 클라이언트 프로토콜은 이러한 메시지를 동시에 전송합니다. 클라이언트가 다음 메시지를 수신하면 해당 메시지는 이미 로컬 캐시에 있는 것입니다. 캐시는 작아야 합니다.
  • 여러 클라이언트를 사용하는 경우 프리페치 수를 0으로 설정합니다. 이렇게 하면 첫 번째 클라이언트가 아직 첫 번째 메시지를 처리하는 동안 두 번째 클라이언트가 두 번째 메시지를 수신할 수 있습니다.

발신기 수가 많은 큐

목표: 발신기 수가 많은 큐 또는 토픽의 처리량 극대화 각 발신기는 보통 속도의 메시지를 전송합니다. 수신기의 수가 작습니다.

Service Bus를 사용하면 메시징 엔터티에 최대 1,000개의 동시 연결을 사용할 수 있습니다. 이 제한은 네임스페이스 수준에서 적용되며 큐, 항목 또는 구독은 네임스페이스당 동시 연결 수로 제한됩니다. 큐의 경우 이 숫자는 발신기와 수신기 사이에 공유됩니다. 보낸 사람에게 1,000개의 연결이 모두 필요한 경우 큐를 토픽 및 단일 구독으로 바꿉니다. 토픽은 보낸 사람으로부터 최대 1,000개의 동시 연결을 허용합니다. 구독은 수신기에서 1,000개의 추가 동시 연결을 허용합니다. 1,000명 이상의 동시 보낸 사람이 필요한 경우 보낸 사람이 HTTP를 통해 Service Bus 프로토콜로 메시지를 보내야 합니다.

처리량을 최대화하려면 다음 단계를 수행합니다.

  • 각 발신기가 다른 프로세스에 있는 경우 프로세스당 하나의 팩터리만 사용합니다.
  • 프리페치 수를 모든 팩터리 수신기의 최대 처리 속도의 20배로 설정합니다. 이렇게 하면 Service Bus 클라이언트 프로토콜 전송 횟수가 줄어듭니다.

수신기 수가 많은 큐

목표: 수신기 수가 많은 큐 또는 구독의 수신 속도를 극대화합니다. 각 수신자는 보통 속도로 메시지를 받습니다. 발신기의 수가 작습니다.

Service Bus를 사용하면 엔터티에 대해 최대 1,000개의 동시 연결을 사용할 수 있습니다. 큐에 1,000개 이상의 수신기가 필요한 경우 큐를 토픽 및 여러 구독으로 바꿉니다. 각 구독은 최대 1,000개의 동시 연결을 지원할 수 있습니다. 또는 수신자가 HTTP 프로토콜을 통해 큐에 액세스할 수 있습니다.

처리량을 최대화하려면 다음 지침을 따릅니다.

  • 각 수신기가 다른 프로세스에 있는 경우 프로세스당 하나의 팩터리만 사용합니다.
  • 프리페치 수를 작은 값으로 설정합니다(예: PrefetchCount = 10). 이렇게 하면 발신기에 많은 수의 메시지가 캐시된 동안 수신기가 유휴 상태가 되지 않습니다.

구독 수가 적은 항목

목표: 구독 수가 적은 항목의 처리량을 최대화합니다. 여러 구독에서 메시지를 수신합니다. 즉, 모든 구독의 수신 속도를 결합한 속도가 전송 속도보다 큼을 의미합니다. 발신기의 수가 작습니다. 구독당 수신기의 수가 작습니다.

처리량을 최대화하려면 다음 지침을 따릅니다.

  • 토픽에 대한 전반적 전송 속도를 높이려면 여러 메시지 팩터리를 만들어 발신기를 만듭니다. 각 발신기에 대해 비동기 작업이나 여러 스레드를 사용합니다.
  • 구독에서 전반적 수신 속도를 높이려면 여러 메시지 팩터리를 만들어 수신기를 만듭니다. 각 수신기에 대해 비동기 작업이나 여러 스레드를 사용합니다.
  • 프리페치 수를 모든 팩터리 수신기의 최대 처리 속도의 20배로 설정합니다. 이렇게 하면 Service Bus 클라이언트 프로토콜 전송 횟수가 줄어듭니다.

구독 수가 많은 토픽

목표: 구독 수가 많은 토픽의 처리량을 최대화합니다. 여러 구독에서 메시지를 수신합니다. 즉, 모든 구독의 수신 속도를 결합한 속도가 전송 속도보다 큼을 의미합니다. 발신기의 수가 작습니다. 구독당 수신기의 수가 작습니다.

모든 메시지가 모든 구독으로 라우팅될 경우 구독 수가 많은 토픽은 일반적으로 전반적 처리량이 감소합니다. 각 메시지가 여러 번 수신되고 항목의 모든 메시지와 모든 구독이 동일한 저장소에 저장되기 때문입니다. 여기서는 구독당 발신기 수와 수신기 수가 적은 경우를 가정합니다. Service Bus는 토픽당 최대 2,000개의 구독을 지원합니다.

처리량을 최대화하려면 다음 단계를 시도해 보십시오.

  • 프리페치 수를 메시지가 수신되는 예상 속도의 20배로 설정합니다. 이렇게 하면 Service Bus 클라이언트 프로토콜 전송 횟수가 줄어듭니다.