Estamos utilizando mirth connect para la transformación de mensajes de hl7 a texto y almacenando los mensajes transformados en la base de datos azure sql. Nuestro rendimiento actual es de 45000 mensajes por hora.

La configuración de la máquina es de 8 GB de RAM y 2 núcleos de CPU. La memoria asignada a la alegría es -XMS = 6122MB

No tenemos idea de cuáles podrían ser los parámetros de rendimiento para Mirth con las configuraciones anteriores. ¿Alguien tiene idea sobre los puntos de referencia de rendimiento para Mirth connect?

2
vidyak 25 dic. 2016 a las 19:03

3 respuestas

La mejor respuesta

Recomiendo buscar en la opción Max Processing Threads en la versión 3.4 y superior. Es configurable en la Configuración de fuente (pestaña Fuente). De manera predeterminada, se establece en 1, lo que significa que solo un mensaje uno puede procesarse a través del hilo de procesamiento principal del canal en un momento dado. Esto es importante para ciertas interfaces donde el orden de los mensajes es primordial, pero obviamente limita el rendimiento.

Tenga en cuenta que cualquier cliente que envíe los mensajes de su canal también debe reconfigurarse para enviar varios mensajes en paralelo. Por ejemplo, si tiene un proceso de subproceso único que envía los mensajes de su canal a través de TCP / MLLP uno tras otro en secuencia, aumentar los subprocesos máximos de procesamiento no necesariamente va a ayudar porque el cliente todavía tiene un subproceso único. Pero, por ejemplo, si coloca a 10 clientes que envían a su canal simultáneamente, definitivamente obtendrá los beneficios de aumentar los hilos de procesamiento máximos.

Si su conector de origen es un tipo de sondeo, como un lector de archivos, aún puede beneficiarse de esto activando la cola de origen y aumentando los hilos de procesamiento máximo. Cuando la cola de origen está habilitada y tiene múltiples subprocesos de procesamiento, se inician múltiples consumidores de cola y todos leen y procesan desde la cola de origen al mismo tiempo.

Otra cosa a tener en cuenta es la cola de destino. En la configuración de cola Avanzado (icono de llave inglesa), hay una opción similar para aumentar el número de Subprocesos de cola de destino. De manera predeterminada, cuando tiene habilitada la cola de destino, solo hay un subproceso de cola que procesa los mensajes en una secuencia FIFO. Nuevamente, es bueno para el orden de los mensajes, pero dificulta el rendimiento.

Si do necesita que se ordenen mensajes y desea maximizar el rendimiento paralelo (también tenga su pastel y cómelo), puede usar la variable de asignación de subprocesos junto con múltiples hilos de cola de destino. Esto le permite preservar el orden entre los mensajes con el mismo identificador único, mientras que los mensajes relacionados con diferentes identificadores pueden procesarse simultáneamente. Un caso de uso común es utilizar el MRN del paciente para esto, de modo que todos los mensajes de un paciente determinado se procesen en el orden en que fueron recibidos, pero los mensajes longitudinales entre diferentes pacientes pueden procesarse simultáneamente.

3
Nick Rupley 17 nov. 2017 a las 20:15

Corremos el mismo proceso. Mirth -> Azure SQL Database. Estamos realizando pruebas de rendimiento en este momento y hemos estado atascados a 12-15 mensajes / segundo (43000-54000 por hora).

Hemos realizado pruebas en cada canal y encontramos esto: 1 fuente de canal: lector de archivos -> destino: Azure SQL DB era de aproximadamente 36k por hora Fuente de 2 canales: lector de archivos -> destino: Azure SQL DB era de aproximadamente 59k por hora de 3 canales origen: lector de archivos -> destino: Azure SQL DB era de aproximadamente 80k por hora

Hemos agregado subprocesos múltiples (2,4,8) a la fuente y al destino en 1 canal sin aumento de rendimiento. Mirth se ejecuta en 8 GB de memoria y 2 núcleos con un tamaño de almacenamiento dinámico establecido en 2048 MB.

Ahora vamos a realizar algunas pruebas con alegría ejecutando un "hardware" similar al C4.4xlarge, que en Azure tiene 16 núcleos y 32 GB de memoria. También hay 200 gb de SSD disponibles.

Nuestro objetivo es 100k mensajes por hora por canal.

1
cdes 9 oct. 2018 a las 20:03

Estamos utilizando una instancia de AWS EC2 4c.4xlarge para probar un límite de rendimiento de prueba de concepto. Obtuvimos unos 50 msgs / seg sin cuellos de botella obvios en cpu / memory / network / disk io / db io y etc. Deseamos aumentar los límites. Por favor comparta sus observaciones si las hay.

1
Denis Wang 17 nov. 2017 a las 18:20