우리는 hl7에서 텍스트로의 메시지 변환을 위해 mirth connect를 사용하고 변환 된 메시지를 azure SQL 데이터베이스에 저장합니다. 우리의 현재 성능은 시간당 45000 메시지입니다.출산 성능 벤치 마크
컴퓨터 구성은 8GB RAM 및 2 코어 CPU입니다. mirth에 할당 된 메모리는 -XMS = 6122MB입니다.
위의 구성에서 Mirth의 성능 매개 변수가 무엇인지에 대해 알지 못합니다. 누구든지 Mirth의 성능 벤치 마크에 대한 아이디어가 있습니까?
우리는 AWS EC2 4c.4xlarge 인스턴스를 사용하여 베어 본 펠로우 프 (Proof of Concept) 성능 제한을 테스트하고 있습니다. 우리는 CPU/메모리/네트워크/디스크 io/db io 등에서 명백한 병목 현상없이 약 50 msgs/sec를 얻었습니다. 제한을 더 높게 설정하고 싶습니다. 있다면 관측을 공유하십시오.
버전 3.4 이상의 Max Processing Threads 옵션을 살펴 보는 것이 좋습니다. 소스 설정 (소스 탭)에서 구성 할 수 있습니다. 기본적으로이 값은 1로 설정되어 있으므로 메시지 하나만 채널의 주 처리 스레드를 통해 처리 할 수 있습니다. 이는 메시지 순서가 가장 중요한 특정 인터페이스에서는 중요하지만 분명히 처리량을 제한합니다.
채널 메시지를 보내는 클라이언트가 무엇이든 도을 여러 개 병렬로 보내려면 다시 구성해야합니다. 예를 들어, TCP/MLLP를 통해 차례로 채널 메시지를 보내는 단일 스레드 프로세스가있는 경우 클라이언트가 여전히 단일 스레드이므로 최대 처리 스레드를 늘리는 것이 반드시 도움이되는 것은 아닙니다. 그러나 예를 들어, 명의 고객이 동시에 모든 채널로 보내는 경우 최대 처리 스레드를 늘릴 수 있다는 이점을 확실히 얻을 수 있습니다.
원본 커넥터가 파일 판독기와 같이 폴링 형식 인 경우 원본 큐를 켜고 최대 처리 스레드를 늘려도이 기능을 사용할 수 있습니다. 원본 큐가 활성화되어 있고 처리 스레드가 여러 개인 경우 여러 큐 소비자가 시작되고 동시에 소스 큐에서 읽히고 처리됩니다.
살펴볼 또 다른 사항은 대상 대기열입니다. 고급 (공구 모양 아이콘) 대기열 설정에는 대상 대기열 스레드의 수를 늘릴 수있는 유사한 옵션이 있습니다. 기본적으로 대상 큐를 사용하도록 설정 한 경우 메시지를 FIFO 시퀀스로 처리하는 큐 스레드가 하나만 있습니다. 메시지 순서는 좋지만 처리량을 저해합니다.
당신이 메시지를 필요로 할 경우
이 및이 (AKA 당신의 케이크를 가지고도 그것을 먹을) 병렬 처리량을 최대화 할 주문해야합니다, 당신은 여러 목적지 대기열 스레드와 함께 스레드 할당 변수를 사용할 수 있습니다. 이렇게하면 동일한 고유 식별자로 메시지 간의 순서를 유지할 수 있으며 다른 식별자에 속한 메시지는 동시에 처리 할 수 있습니다. 일반적인 사용 사례는 환자 MRN을 사용하여 주어진 환자의 모든 메시지가 수신 된 순서대로 처리되도록 보장하지만 여러 환자를 가로 지르는 메시지를 동시에 처리 할 수 있도록하는 것입니다.
HL7v2 메시지는 이미 일반 텍스트로되어 있으므로 사용자는 무엇을 변환해야하는지 궁금합니다. HL7v2 메시지를 구문 분석하고 구문 분석 된 필드를 저장하면 또 다른 이야기입니다. 설정 저장, 데이터 정리기 ... 모두 성능에 영향을줍니다. – Shamil
예 .. hl7 메시지를 구문 분석하고 구문 분석 된 필드를 데이터베이스에 저장합니다. – vidyak