이 페이지가 유용했습니까?
이 콘텐츠에 대한 여러분의 의견은 중요합니다. 의견을 알려주십시오.
추가 의견
1500자 남음
내보내기(0) 인쇄
모두 확장

서비스 버스 조정된 메시징을 사용한 성능 개선 모범 사례

업데이트 날짜: 2015년 6월

이 항목에서는 Microsoft Azure 서비스 버스를 사용하여 조정된 메시지를 교환할 때 성능을 최적화하는 방법을 설명합니다. 이 항목의 앞부분에서는 성능을 개선하는 데 사용할 수 있도록 제공되는 다양한 메커니즘에 대해 설명합니다. 뒷부분에서는 지정된 시나리오에서 성능을 최적화할 수 있는 방식으로 서비스 버스를 사용하는 방법에 대한 지침을 제공합니다.

이 항목 전체에서 "클라이언트"라는 용어는 서비스 버스에 액세스하는 엔터티를 지칭합니다. 클라이언트는 발신자 또는 수신자 역할을 수행할 수 있습니다. "발신자"라는 용어는 서비스 버스 큐 또는 항목에 메시지를 보내는 서비스 버스 큐 또는 항목 클라이언트에 사용됩니다. "수신자"라는 용어는 서비스 버스 큐 또는 구독에서 메시지를 받는 서비스 버스 큐 또는 구독 클라이언트를 지칭합니다.

이 섹션에서는 서비스 버스에서 성능을 높이기 위해 사용하는 몇 가지 개념을 소개합니다.

클라이언트는 서비스 버스에서 두 가지 프로토콜, 즉 서비스 버스 클라이언트 프로토콜과 HTTP를 통해 메시지를 보내고 받을 수 있습니다. 서비스 버스 클라이언트 프로토콜은 메시지 팩터리가 있으면 서비스 버스 서비스에 대한 연결을 유지하므로 보다 효율적입니다. 이 프로토콜은 일괄 처리 및 프리페치도 구현합니다. 서비스 버스 클라이언트 프로토콜은 .NET 관리 API를 사용하는 .NET 응용 프로그램용으로 제공됩니다.

명시적인 언급이 없으면 이 항목의 모든 내용에서는 서비스 버스 클라이언트 프로토콜을 사용한다고 가정합니다.

Microsoft.ServiceBus.Messaging.QueueClient 또는 Microsoft.ServiceBus.Messaging.MessageSender와 같은 서비스 버스 클라이언트 개체는 내부 연결 관리 기능도 제공하는 MessagingFactory 개체를 통해 생성됩니다. 메시지를 보낸 후에 메시징 팩터리나 큐, 항목 및 구독 클라이언트를 닫았다가, 다음 메시지를 보낼 때 해당 클라이언트 또는 팩터리를 다시 만들어서는 안 됩니다. 메시징 팩터리를 닫으면 서비스 버스 서비스에 대현 연결이 삭제되며 팩터리를 다시 만들 때 새 연결이 설정됩니다. 연결 설정은 비용이 많이 드는 작업인데, 여러 작업에 대해 같은 팩터리 및 클라이언트 개체를 다시 사용하면 이러한 작업을 수행하지 않아도 됩니다.

보내기, 받기, 삭제 등의 작업을 수행하려면 다소 시간이 걸립니다. 이 시간에는 요청 및 회신에 대한 대기 시간 외에 서비스 버스 서비스의 작업 처리 시간도 포함됩니다. 시간당 작업 수를 늘리려면 작업을 동시에 실행해야 합니다. 다음과 같은 여러 방법으로 작업을 동시에 실행할 수 있습니다.

  • 비동기 작업: 클라이언트는 비동기 작업을 수행하여 작업을 파이프라인합니다. 다음 요청은 이전 요청이 완료되기 전에 시작됩니다. 비동기 send 작업의 예는 다음과 같습니다.

    BrokeredMessage m1 = new BrokeredMessage(body);
    BrokeredMessage m2 = new BrokeredMessage(body);
    
    Task send1 = queueClient.SendAsync(m1).ContinueWith((t) => 
      {
        Console.WriteLine("Sent message #1");
      });
    Task send2 = queueClient.SendAsync(m2).ContinueWith((t) => 
      {
        Console.WriteLine("Sent message #2");
      });
    Task.WaitAll(send1, send2);
    Console.WriteLine("All messages sent");
    
    
    
    
    
    
    
    
    
    
    
    비동기 receive 작업의 예는 다음과 같습니다.

    Task receive1 = queueClient.ReceiveAsync().ContinueWith(ProcessReceivedMessage);
    Task receive2 = queueClient.ReceiveAsync().ContinueWith(ProcessReceivedMessage);
    
    Task.WaitAll(receive1, receive2);
    Console.WriteLine("All messages received");
    
    async void ProcessReceivedMessage(Task<BrokeredMessage> t)
    {
      BrokeredMessage m = t.Result;
      Console.WriteLine("{0} received", m.Label);
      await m.CompleteAsync();
      Console.WriteLine("{0} complete", m.Label);
    }
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
  • 여러 팩터리: 같은 팩터리를 사용하여 작성되는 모든 클라이언트(발신자와 수신자)는 TCP 연결 하나를 공유합니다. 최대 메시지 처리량은 이 TCP 연결을 통과할 수 있는 작업의 수에 따라 제한됩니다. 단일 팩터리를 통해 얻을 수 있는 처리량은 TCP 왕복 시간 및 메시지 크기에 따라 크게 달라집니다. 처리량 속도를 높이려면 여러 메시징 팩터리를 사용해야 합니다.

큐 또는 구독 클라이언트를 만들 때는 수신 모드를 미리 보기-잠금 또는 수신 및 삭제 중에서 지정할 수 있습니다. 기본 수신 모드는 PeekLock입니다. 이 모드에서 작동할 때 클라이언트는 서비스 버스에서 메시지를 받기 위한 요청을 보냅니다. 클라이언트는 메시지를 받은 후에 메시지 완료 요청을 보냅니다.

수신 모드를 ReceiveAndDelete로 설정하면 이 두 단계가 단일 요청으로 결합되므로 전체 작업 수가 감소하며 전반적인 메시지 처리량을 높일 수 있습니다. 그러나 이처럼 성능이 개선되는 반면 메시지가 손실될 위험도 있습니다.

서비스 버스에서는 수신 및 삭제 작업에 대한 트랜잭션을 지원하지 않습니다. 또한 클라이언트가 메시지를 지연시키거나 배달 못한 편지로 지정하려는 시나리오에서는 미리 보기-잠금 의미 체계를 사용해야 합니다.

클라이언트 쪽 일괄 처리를 사용하면 큐 또는 항목 클라이언트에서 일정 기간 동안 메시지 보내기를 연기할 수 있습니다. 클라이언트는 이 기간 동안 추가 메시지를 보내는 경우 단일 일괄 처리를 통해 메시지를 전송합니다. 또한 클라이언트 쪽 일괄 처리 사용 시에는 큐/구독 클라이언트가 여러 Complete 요청을 단일 요청으로 일괄 처리합니다. 일괄 처리는 비동기 SendComplete 작업에만 사용할 수 있습니다. 동기 작업은 서비스 버스 서비스로 즉시 전송됩니다. 미리 보기나 수신 작업의 경우 또는 클라이언트 간에는 일괄 처리가 수행되지 않습니다.

일괄 처리가 최대 메시지 크기를 초과하면 마지막 메시지가 일괄 처리에서 제거되며 클라이언트가 일괄 처리를 즉시 전송합니다. 이 마지막 메시지는 다음 일괄 처리의 첫 번째 메시지가 됩니다. 기본적으로 클라이언트는 일괄 처리 간격으로 20ms를 사용합니다. 메시징 팩터리를 만들기 전에 BatchFlushInterval 속성을 설정하여 일괄 처리 간격을 변경할 수 있습니다. 이 설정은 이 팩터리에서 생성된 모든 클라이언트에 영향을 줍니다.

일괄 처리를 비활성화하려면 BatchFlushInterval 속성을 TimeSpan.Zero로 설정합니다. 예를 들면 다음과 같습니다.

MessagingFactorySettings mfs = new MessagingFactorySettings();
mfs.TokenProvider = tokenProvider;
mfs.NetMessagingTransportSettings.BatchFlushInterval = TimeSpan.FromSeconds(0.05);
MessagingFactory messagingFactory = MessagingFactory.Create(namespaceUri, mfs);

일괄 처리는 청구 가능한 메시징 작업의 수에는 영향을 주지 않으며 서비스 버스 클라이언트 프로토콜에 대해서만 사용할 수 있습니다. HTTP 프로토콜은 일괄 처리를 지원하지 않습니다.

큐/항목/구독의 처리량을 높이기 위해 서비스 버스 서비스는 내부 저장소에 쓸 때 여러 메시지를 일괄 처리합니다. 큐 또는 항목에 대해 일괄 처리가 사용하도록 설정된 경우 저장소로의 메시지 쓰기가 일괄 처리됩니다. 큐 또는 구독에 대해 일괄 처리가 사용하도록 설정된 경우에는 저장소의 메시지 삭제가 일괄 처리됩니다. 엔터티에 대해 일괄 처리 방식 저장소 액세스가 사용하도록 설정된 경우 서비스 버스는 해당 엔터티에 대한 저장소 쓰기 작업을 최대 20ms까지 연기합니다. 이 간격 동안 수행되는 추가 저장소 작업은 일괄 처리에 추가됩니다. 일괄 처리 방식 저장소 액세스는 SendComplete 작업에만 적용되며 수신 작업에는 적용되지 않습니다. 일괄 처리 방식 저장소 액세스는 엔터티에 대한 속성입니다. 즉, 일괄 처리 방식 저장소 액세스를 사용할 수 있는 모든 엔터티에서 일괄 처리가 수행됩니다.

새 큐, 항목 또는 구독을 만들 때는 일괄 처리 방식 저장소 액세스가 기본적으로 사용하도록 설정됩니다. 일괄 처리 방식 저장소 액세스를 사용하지 않으려면 엔터티를 만들기 전에 EnableBatchedOperations 속성을 false로 설정합니다. 예를 들면 다음과 같습니다.

QueueDescription qd = new QueueDescription();
qd.EnableBatchedOperations = false;
Queue q = namespaceManager.CreateQueue(qd);

일괄 처리 방식 저장소 액세스는 큐, 항목 또는 구독의 속성이며 청구 가능 메시징 작업의 수에는 영향을 주지 않습니다. 또한 클라이언트와 서비스 버스 서비스 간에 사용되는 프로토콜 및 수신 모드와도 별개입니다.

큐 또는 구독 클라이언트는 수신 작업을 수행할 때 프리페치를 통해 서비스에서 추가 메시지를 로드할 수 있습니다. 클라이언트는 로컬 캐시에 이러한 메시지를 저장합니다. 캐시의 크기는 Microsoft.ServiceBus.Messaging.QueueClient.PrefetchCountMicrosoft.ServiceBus.Messaging.SubscriptionClient.PrefetchCount 속성에 따라 결정됩니다. 프리페치를 사용할 수 있는 각 클라이언트는 자체 캐시를 유지합니다. 캐시는 클라이언트 간에 공유되지 않습니다. 클라이언트가 수신 작업을 시작할 때 해당 캐시가 비어 있으면 서비스는 메시지 일괄 처리를 전송합니다. 일괄 처리의 크기는 캐시의 크기 또는 256KB 중에서 더 작은 쪽에 해당합니다. 클라이언트가 수신 작업을 시작할 때 캐시에 메시지가 포함되어 있으면 캐시에서 해당 메시지를 가져옵니다.

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

기본 잠금 만료 시간으로 60초를 사용하는 경우 적절한 Microsoft.ServiceBus.Messaging.SubscriptionClient.PrefetchCount 값은 모든 팩터리 수신자의 최대 처리 속도x20입니다. 예를 들어 팩터리가 수신자 3개를 만들며 각 수신자는 초당 최대 10개의 메시지를 처리할 수 있습니다. 이 경우 프리페치 수는 20x3x10=600을 초과하지 않아야 합니다. 기본적으로 Microsoft.ServiceBus.Messaging.QueueClient.PrefetchCount는 0으로 설정되므로 서비스에서 추가 메시지를 가져오지 않습니다.

메시지 프리페치 시에는 전체 메시지 작업 수(왕복)가 감소하므로 큐 또는 구독에 대한 전반적인 처리량이 증가합니다. 그러나 메시지 크기가 커지므로 첫 번째 메시지를 가져오는 시간은 더 오래 걸립니다. 프리페치된 메시지는 클라이언트가 이미 다운로드한 상태이므로 더 빨리 수신됩니다.

서버는 클라이언트에 메시지를 보낼 때 메시지의 TTL(Time to Live) 속성을 확인합니다. 그러나 클라이언트는 메시지를 받을 때 메시지의 TTL 속성을 확인하지 않습니다. 단, 클라이언트가 메시지를 캐시하는 동안 메시지의 TTL이 경과했더라도 메시지를 받을 수는 있습니다.

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

Express 엔터티를 사용하면 처리량을 높이고 대기 시간 시나리오를 줄일 수 있습니다. Express 엔터티 사용 시에는 큐나 항목으로 보내는 메시지가 메시징 저장소에 즉시 저장되는 대신 메모리에 캐시됩니다. 메시지가 몇 초 이상 큐에 유지되면 안정적 저장소에 자동으로 기록되어 중단으로 인한 손실로부터 보호할 수 있습니다. 메모리 캐시에 메시지를 쓰면 메시지 전송 시 안정적 저장소에 액세스하지 않으므로 대기 시간이 감소하며 처리량이 증가합니다. 몇 초 내에 사용되는 메시지는 메시징 저장소에 기록되지 않습니다. 다음 예에서는 Express 항목을 만듭니다.

TopicDescription td = new TopicDescription(TopicName);
td.EnableExpress = true;
namespaceManager.CreateTopic(td);

손실되면 안 되는 중요한 정보가 포함된 메시지를 Express 엔터티로 보낼 때 발신자는 ForcePersistence 속성을 true로 설정해 서비스 버스가 메시지를 안정적 저장소에 즉시 영구 보존하도록 강제 지정할 수 있습니다. 자세한 내용은 TechNet의 Azure SDK 2.3 릴리스(2014년 4월)의 새로운 기능.

서비스 버스는 내부적으로 같은 노드 및 메시징 저장소를 사용하여 메시징 엔터티(큐 또는 항목)에 대한 모든 메시지를 처리하고 저장합니다. 반면 분할된 큐나 항목은 여러 노드 및 메시징 저장소로 분산됩니다. 분할된 큐와 항목을 사용하는 경우 일반 큐 및 항목에 비해 처리량뿐만 아니라 가용성도 높일 수 있습니다. 분할된 엔터티를 만들려면 다음 예제에 나와 있는 것처럼 EnablePartitioning 속성을 true로 설정합니다. 분할된 엔터티 에 대한 자세한 내용은 메시징 엔터티 분할을 참조하세요.

// Create partitioned queue.
QueueDescription qd = new QueueDescription(QueueName);
qd.EnablePartitioning = true;
namespaceManager.CreateQueue(qd);

분할된 큐 또는 항목을 사용할 수 없거나 예상되는 부하를 분할된 큐 또는 항목 하나로는 처리할 수 없는 경우에는 여러 메시징 엔터티를 사용해야 합니다. 여러 엔터티를 사용할 때는 모든 엔터티에 대해 같은 클라이언트를 사용하는 대신 각 엔터티에 대해 전용 클라이언트를 만듭니다.

다음 섹션에서는 일반적인 메시징 시나리오에 대해 설명하고 기본 서비스 버스 설정을 간략하게 소개합니다. 처리량 속도는 낮음(<1msg/s 미만), 보통(1msg/s 이상 <100msg/s 미만) 및 높음(100msg/s 이상)으로 분류됩니다. 클라이언트 수는 적음(5개 이하), 보통(>5개 초과 20개 이하) 및 많음(>20개 초과)으로 분류됩니다.

목표: 단일 큐의 처리량을 최대화합니다. 발신자와 수신자 수는 적습니다.

  • 성능과 가용성을 높이기 위해 분할된 큐를 사용합니다.

  • 큐로 보내는 전반적인 속도를 높이려면 여러 메시지 팩터리를 사용하여 발신자를 만듭니다. 각 발신자에 대해 비동기 작업이나 여러 스레드를 사용합니다.

  • 큐에서 받는 전반적인 속도를 높이려면 여러 메시지 팩터리를 사용하여 수신자를 만듭니다.

  • 클라이언트 쪽 일괄 처리를 활용할 수 있도록 비동기 작업을 사용합니다.

  • 서비스 버스 클라이언트 프로토콜 전송 수를 줄일 수 있도록 일괄 처리 간격을 50ms로 설정합니다. 여러 발신자를 사용하는 경우에는 일괄 처리 간격을 100ms로 늘립니다.

  • 일괄 처리 방식 저장소 액세스를 사용 가능한 상태로 유지합니다. 그러면 메시지를 큐에 쓸 수 있는 전체 속도가 높아집니다.

  • 프리페치 개수를 팩터리 내 모든 수신자의 최대 처리 속도x20으로 설정합니다. 그러면 서비스 버스 클라이언트 프로토콜 전송의 수가 감소합니다.

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

여러 큐에서 처리량을 최대화하려면 여기서 소개하는 설정을 사용하여 단일 큐의 처리량을 최대화합니다. 또한 서로 다른 여러 팩터리를 사용하여 각기 다른 큐에서 송신 또는 수신하는 클라이언트를 만듭니다.

목표: 큐 또는 항목의 종단 간 대기 시간을 최소화합니다. 발신자와 수신자 수는 적습니다. 큐의 처리량은 낮음 또는 보통입니다.

  • 가용성을 높이기 위해 분할된 큐를 사용합니다.

  • 클라이언트 쪽 일괄 처리는 사용하지 않도록 설정합니다. 그러면 클라이언트가 메시지를 즉시 보냅니다.

  • 일괄 처리 방식 저장소 액세스를 사용하지 않도록 설정합니다. 그러면 서비스가 저장소에 메시지를 즉시 씁니다.

  • 단일 클라이언트를 사용하는 경우 프리페치 개수를 수신자의 처리 속도x20으로 설정합니다. 동시에 여러 메시지가 큐에 도착하는 경우 서비스 버스 클라이언트 프로토콜은 모든 메시지를 동시에 전송합니다. 따라서 클라이언트에서 다음 메시지를 받을 때 해당 메시지는 로컬 캐시에 이미 있는 상태입니다. 캐시는 작아야 합니다.

  • 여러 클라이언트를 사용하는 경우에는 프리페치 개수를 0으로 설정합니다. 이렇게 하면 첫 번째 클라이언트가 첫 번째 메시지를 계속 처리하는 동안 두 번째 클라이언트가 두 번째 메시지를 받을 수 있습니다.

목표: 발신자 수가 많은 큐 또는 항목의 처리량을 최대화합니다. 각 발신자는 보통 속도로 메시지를 보내며 수신자 수는 적습니다.

서비스 버스는 메시징 엔터티에 대한 동시 연결을 최대 1000개(또는 AMQP를 사용하는 경우 5000개) 활성화합니다. 이 제한은 네임스페이스 수준에서 적용되며, 큐/항목/구독은 네임스페이스당 동시 연결 수 제한으로 제한됩니다. 큐의 경우에는 수신자와 발신자 간에 이 연결 수를 공유합니다. 발신자가 1000개 연결을 모두 사용해야 하는 경우에는 큐를 항목 및 단일 구독으로 바꿔야 합니다. 항목은 발신자의 동시 연결을 1000개까지 수락하는 반면 구독은 수신자의 동시 연결 1000개를 추가로 수락합니다. 필요한 동시 발신자의 수가 1000개보다 많은 경우 발신자는 HTTP를 통해 서비스 버스 프로토콜에 메시지를 보내야 합니다.

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

  • 성능과 가용성을 높이기 위해 분할된 큐를 사용합니다.

  • 각 발신자가 다른 프로세스에 있으면 프로세스당 팩터리를 하나만 사용합니다.

  • 클라이언트 쪽 일괄 처리를 활용할 수 있도록 비동기 작업을 사용합니다.

  • 서비스 버스 클라이언트 프로토콜 전송 수를 줄일 수 있도록 기본 일괄 처리 간격 20ms를 사용합니다.

  • 일괄 처리 방식 저장소 액세스를 사용 가능한 상태로 유지합니다. 그러면 메시지를 큐나 항목에 쓸 수 있는 전체 속도가 높아집니다.

  • 프리페치 개수를 팩터리 내 모든 수신자의 최대 처리 속도x20으로 설정합니다. 그러면 서비스 버스 클라이언트 프로토콜 전송의 수가 감소합니다.

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

서비스 버스에서는 엔터티에 대한 동시 연결을 1000개까지 사용할 수 있습니다. 큐에 필요한 수신자 수가 1000개보다 많으면 큐를 항목 및 여러 구독으로 바꿔야 합니다. 각 구독은 동시 연결을 1000개까지 지원할 수 있습니다. 수신자는 HTTP 프로토콜을 통해 큐에 액세스할 수도 있습니다.

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

  • 성능과 가용성을 높이기 위해 분할된 큐를 사용합니다.

  • 각 수신자가 다른 프로세스에 있으면 프로세스당 팩터리를 하나만 사용합니다.

  • 수신자는 동기 또는 비동기 작업을 사용할 수 있습니다. 개별 수신자의 수신 속도가 보통일 때 Complete 요청의 클라이언트 쪽 일괄 처리는 수신자 처리량에 영향을 주지 않습니다.

  • 일괄 처리 방식 저장소 액세스를 사용 가능한 상태로 유지합니다. 이렇게 하면 엔터티의 전체 부하가 줄어듭니다. 또한 메시지를 큐나 항목에 쓸 수 있는 전체 속도도 높아집니다.

  • 프리페치 개수는 작은 값으로 설정합니다(예: PrefetchCount = 10). 그러면 다른 수신자가 많은 수의 메시지를 캐시하는 동안 수신자가 유휴 상태로 유지되지 않습니다.

목표: 구독 수가 적은 항목의 처리량을 최대화합니다. 메시지는 여러 구독에서 수신되므로 모든 구독에 대해 결합된 수신 속도가 송신 속도보다 더 높습니다. 발신자 수는 적습니다. 구독당 수신자 수는 적습니다.

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

  • 성능과 가용성을 높이기 위해 분할된 항목을 사용합니다.

  • 항목으로 보내는 전반적인 속도를 높이려면 여러 메시지 팩터리를 사용하여 발신자를 만듭니다. 각 발신자에 대해 비동기 작업이나 여러 스레드를 사용합니다.

  • 구독에서 받는 전반적인 속도를 높이려면 여러 메시지 팩터리를 사용하여 수신자를 만듭니다. 각 수신자에 대해 비동기 작업이나 여러 스레드를 사용합니다.

  • 클라이언트 쪽 일괄 처리를 활용할 수 있도록 비동기 작업을 사용합니다.

  • 서비스 버스 클라이언트 프로토콜 전송 수를 줄일 수 있도록 기본 일괄 처리 간격 20ms를 사용합니다.

  • 일괄 처리 방식 저장소 액세스를 사용 가능한 상태로 유지합니다. 그러면 메시지를 항목에 쓸 수 있는 전체 속도가 높아집니다.

  • 프리페치 개수를 팩터리 내 모든 수신자의 최대 처리 속도x20으로 설정합니다. 그러면 서비스 버스 클라이언트 프로토콜 전송의 수가 감소합니다.

목표: 구독 수가 많은 항목의 처리량을 최대화합니다. 메시지는 여러 구독에서 수신되므로 모든 구독에 대해 결합된 수신 속도가 송신 속도보다 훨씬 더 높습니다. 발신자 수는 적습니다. 구독당 수신자 수는 적습니다.

모든 메시지가 모든 구독으로 라우팅되는 경우 구독 수가 많은 항목의 처리량은 일반적으로 낮습니다. 각 메시지가 여러 번 수신되며 항목 및 모든 해당 구독에 포함된 모든 메시지가 같은 저장소에 저장되기 때문입니다. 구독당 발신자 및 수신자의 수는 적다고 가정합니다. 서비스 버스에서는 항목당 구독을 2,000개까지 지원합니다.

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

  • 성능과 가용성을 높이기 위해 분할된 항목을 사용합니다.

  • 클라이언트 쪽 일괄 처리를 활용할 수 있도록 비동기 작업을 사용합니다.

  • 서비스 버스 클라이언트 프로토콜 전송 수를 줄일 수 있도록 기본 일괄 처리 간격 20ms를 사용합니다.

  • 일괄 처리 방식 저장소 액세스를 사용 가능한 상태로 유지합니다. 그러면 메시지를 항목에 쓸 수 있는 전체 속도가 높아집니다.

  • 프리페치 개수를 예상 수신 속도(초)x20으로 설정합니다. 그러면 서비스 버스 클라이언트 프로토콜 전송의 수가 감소합니다.

표시:
© 2015 Microsoft