우리는 tibco-ems JMS를 사용하여 메인 서버와주고받는 다수의 메시지를 클라이언트 연결에 전달하는 고성능 시스템을 실행 중입니다. 우리는 몇 가지 통계를 수행했으며 JMS가 많은 대기 시간을 초래하고 있음을 확인했습니다. 어떻게 tibco JMS를보다 효율적으로 만들 수 있습니까? 이 주제에 대해 좋은 토론을하는 자료가 있습니까?tibco JMS를보다 효율적으로 최적화하기 위해 수행 할 수있는 단계는 무엇입니까?
지속성이 필요하지 않은 경우 비 지속성 메시지를 사용하는 것이 하나의 옵션입니다. 당신이 지속성을 필요로 할 경우에도 주, 때로는 비 지속성 메시지를 사용하는 것이 좋습니다, 그리고 충돌의 경우
이 관련 (모든 메시지를 재전송 같은) 다른 복구 작업을 수행하는 경우 :
는 EMS도 지속적 몇 가지 메커니즘을 제공하지만, 적은 총알 증거는 고전 보장 배달 다음과 같습니다 :
이지속성이 필요한 경우 디스크 I/O가 주요 병목 현상이 될 가능성이 큽니다. 이것은 디스크 솔루션, SAN, SSD 디스크 등에 따라 달라집니다. 사소한 개선은 디스크 쓰기를 비동기로 만드는 것일 수 있습니다. – stoft
EMS는 병 목이어서는 안됩니다. 테스트를 마쳤으며 서버에서 처리량이 줄어 들었습니다.
병목이 어디에 있는지 확인해야합니다. 메시지 또는 소비자의 생산자 문제입니다. 메시지가 대기열에 쌓여 있습니까?
어떤 유형의 시나리오를하고 있습니까?
Pub/sup 또는 요청 답장? 임시 대기열이 쌓이고 있습니까? 임시 큐가 너무 많으면 성능 문제가 발생할 수 있습니다. (대부분 무언가를 제대로 닫지 않았기 때문에 주로 남아 있습니다.)
그렇다면 영구 가입자가있는 주제에 게시하고 있습니까? 주제를 브리징하여 대기열에 추가하고 그 주제에서 읽으십시오. 영구 가입자는 모든 메시지의 사본을 가진 사람을 추적해야하므로 성능면에서 약간의 문제가 발생할 수 있습니다.
송신 프로세스에 하나의 세션이 있고 해당 세션을 통해 여러 번 호출해야합니다. 각 작업에 대해 완전한 세션을 열지 마십시오. 가능한 경우 재사용하십시오. 소비자에게도 똑같이하십시오.
작업이 끝나면 닫을 것을 확인하십시오. EMS는 일을 정리하지 않습니다. 따라서 연결을 만들고 앱을 닫으면 연결이 여전히 남아있어 리소스를 낭비하게됩니다.
충돌시에도 분실 메시지에 대한 내역을 검토하십시오. 고객 응답을하고 있고 메시지 처리를 중단하는 경우 중요하지 않으며 자동으로 전환하십시오. 또한 당신이 (TEMS - Tibco EMS for WCF)를 사용한다면 세션 승인에 문제가 있다고 생각합니다.그래서 메시지가 전체 메시지에서 처리 될 때만 클라이언트 ACK에서 DUP를 확인하고 더 잘 작동하는 것으로 전환했습니다.
Tibco에게 묻기 시도 했습니까? 그것은 여전히 상용 제품이 아닙니까? 최고의 정보는 그들로부터 올 것입니다. 보고있는 대기 시간과 현재 수행중인 테스트를 게시 할 수 있습니까? 예 : 지속성을 사용할 수 있습니까? 나는 그들이 작은 메시지에 대해 약 1ms가 될 것으로 기대한다. –
지속성을 활성화했습니다. 아마 대기 시간을 줄이기 위해 우리가 취할 첫 번째 단계 일 것입니다. 다른 하나는 로깅 수준을 줄이는 것입니다. Tibco에게 묻는 것이 좋습니다. 감사합니다 – richs
Tib의 버전은 무엇입니까? – Joel