성능(Service Broker)
Service Broker 응용 프로그램의 성능은 일반적으로 다음 두 가지 요인에 따라 결정됩니다.
지정된 기간 내에 도착하는 메시지 수
응용 프로그램이 각 메시지를 처리하는 속도
이러한 두 가지 요인을 모니터링하는 것이 응용 프로그램의 성능을 이해하는 데 핵심이 됩니다.
Service Broker는 자체 작업에 대한 정보를 제공하는 성능 카운터 집합을 제공합니다. 또한 Service Broker는 심각한 오류를 SQL Server 오류 로그와 Windows 응용 프로그램 이벤트 로그에 기록합니다. Service Broker의 성능 카운터, 동적 관리 뷰 및 추적 이벤트에 대한 자세한 내용은 모니터링(Service Broker)을 참조하십시오.
Service Broker 저장 프로시저 튜닝
대부분의 경우 Service Broker를 사용하는 저장 프로시저를 튜닝하는 것은 다른 저장 프로시저를 튜닝하는 것과 다르지 않지만 추가로 고려해야 할 사항이 몇 가지 있습니다.
먼저 WAITFOR 절을 사용합니다. 메시지가 도착하는 간격은 거의 예측할 수가 없습니다. 저장 프로시저가 메시지를 처리하는 속도와 거의 같은 속도로 메시지가 도착하는 서비스의 경우에도 메시지를 사용할 수 없는 경우가 있습니다. 따라서 프로시저는 RECEIVE 문이나 GET CONVERSATION GROUP 문에 WAITFOR 절을 사용해야 합니다. WAITFOR를 사용하지 않으면 이러한 문은 큐에 사용할 수 있는 메시지가 없을 경우 즉시 반환됩니다. 저장 프로시저의 구현에 따라 프로시저는 해당 문에 루프백을 수행하여 리소스를 불필요하게 사용하게 될 수 있거나 즉시 다시 활성화할 때만 종료하여 계속해서 실행하기만 하는 경우보다 리소스를 더 사용하게 될 수 있습니다.
RECEIVE 또는 GET CONVERSATION GROUP 문에 WAITFOR 절을 사용하여 타이밍의 예측 불가능성을 고려합니다. 응용 프로그램이 백그라운드 서비스로 계속해서 실행되는 경우 WAITFOR 문에 제한 시간을 지정하지 않습니다. 응용 프로그램이 Service Broker에 의해 활성화되거나 예약된 작업으로 실행되는 경우 제한 시간을 짧게(예: 500밀리초) 지정합니다. WAITFOR 문을 사용하는 응용 프로그램은 메시지 간의 예상할 수 없는 간격을 정상적으로 처리합니다. 마찬가지로 활성화된 응용 프로그램이 짧은 제한 시간 후 종료되는 경우 처리할 메시지가 없으면 리소스를 사용하지 않습니다.
Service Broker는 대화 그룹 식별자를 공유하는 대화 메시지를 한 번에 응용 프로그램의 한 인스턴스에서만 받을 수 있도록 합니다. 동기화를 위해 대화 그룹 잠금을 활용하도록 응용 프로그램을 설계합니다. 응용 프로그램이 상태를 유지 관리할 경우 대화 그룹 식별자를 사용하여 대화에 대한 상태를 식별하십시오. 대화 그룹의 여러 메시지를 같은 트랜잭션에서 처리합니다. 그러나 일반적으로는 지정된 트랜잭션의 단일 대화 그룹에 대한 메시지만 처리합니다. 이렇게 하면 대화 그룹 수가 비교적 적을 경우에도 응용 프로그램의 여러 인스턴스가 메시지를 처리할 수 있습니다.
또한 메시지 보존을 사용하지 마십시오. 메시지의 가장 중요한 정보가 저장되는 별도의 로그 테이블을 유지 관리하면 성능이 향상됩니다. 응용 프로그램이 정확한 메시지를 보내고 받아야 하는 경우에만 메시지 보존을 사용합니다.
그런 다음 태스크가 완료되면 대화를 종료합니다. Service Broker는 각 활성 대화에 대한 상태를 유지 관리합니다. 특정 대화에 대한 상태량이 적어도 대화를 종료하지 않는 응용 프로그램은 시간이 지남에 따라 성능이 저하될 수 있습니다.
끝으로 트랜잭션을 짧게 유지합니다. 예를 들어 서비스의 대화 패턴이 동일 대화 그룹에 대한 메시지를 많이 포함하는 경우 각 트랜잭션에서 처리되는 메시지 수를 제한하면 전체 처리량을 늘릴 수 있습니다.