서버 대 클라이언트 통신의 MSMQ

Question

고객 통신에 대한 지속적인 '푸시'서버를 위해 MSMQ를보고있었습니다. 서버 당 최대 1000 개의 클라이언트가있을 수 있습니다.

테스트 중 하나에서 300 명의 오프라인 클라이언트에게 작은 메시지를 보낸 다음 온라인 클라이언트에게 메시지를 보냈습니다. MSMQ가 배송 할 수없는 메시지 (MMC를 통해 관찰)를 통해 40 분 이상 지연되었습니다. 또한 잘 작동하는 리턴 경로에 MSMQ를 사용합니다.

오프라인 호스트에 연결하려는 시간을 줄임으로써 MSMQ 가이 사용 패턴에 맞게 만들 수있는 방법이 있습니까? 그렇지 않다면, 더 잘 맞을 다른 대기열 제품이 있습니까, 아니면 자신의 시간을 굴려 있습니까? 원시 처리량은 우선 순위가 아니지만, 클라이언트의 메모리 풋 프린트 (상당히 오래된 기계 일 수 있음)와 마찬가지로 발신 대기열과 예측 가능성/최대 대기 시간의 수입니다.

Answer 1

우리의 솔루션은 MSMQ의 관리 COM 인터페이스 중 하나를 통해 오프라인 인 컴퓨터 (이미 클라이언트가 UP가 증가하는지 알 수있는 UDP 메시지가 이미 있음)에 대한 대기열을 프로그래밍 방식으로 일시 중지하는 것이 었습니다.

알려진 분명한 호스트의 대기열이 잠시 멈추면서 MSMQ는 배송 할 수없는 메시지를 통해 훨씬 적은 시간을 보냈습니다.

기술 평가를위한 테스트를 생각할 때 약간의 측면 사고를 적용하는 것은 좋은 교훈이었습니다! 일반적 으로이 문제로 인해 서버에서 클라이언트 통신에 MSMQ를 권장하지 않을 것입니다. 고객의 폴링이 바람직하다고 말할 것입니다.

Answer 2

저널링을 비활성화하고 메시지를 다시 볼 수 없게 만들어 성능을 향상시킬 수 있습니다 ... 메시지가 손실되는 것을 신경 쓰지 않는 경우.

오프라인 시나리오에 대한 빠른 수정은 나가는 대기열 당 스레드를 사용하는 MSMQ에서 사용 가능한 스레드 수를 늘리는 것입니다. 각 오프라인 연결 시도는 시간이 걸리며 스레드를 차단합니다. http://technet.microsoft.com/en-us/library/cc957498.aspx 가능한 한 많은 스레드를 던지십시오.

내 동료들은 ActiveMQ와 협력했으며 더 잘 수행하면서 훨씬 더 유연하다고 말했습니다. 나는 개인적으로 그것과 함께 일하지 않았지만 .NET에 묶여 있지 않으면 조사 할 것입니다.