RENDIMIENTO DE MENSAJES HL7V2 DE INTERSYSTEMS ENSEMBLE

Transcripción

1 W H I T E P A P E R I N T E RS Y S T E M S RENDIMIENTO DE MENSAJES HL7V2 DE INTERSYSTEMS ENSEMBLE Rendimiento y Escalabilidad para HL7v2 de Ensemble (v , build 503); Diciembre de 2010 Autores: Vik Nagjee y David Loveluck Products Managers InterSystems Corporation

2 RENDIMIENTO DE MENSAJES HL7V2 DE INTERSYSTEMS ENSEMBLE Resumen Ejecutivo InterSystems Ensemble es una plataforma de integración y desarrollo rápido con capacidades integradas para el procesamiento a alta velocidad de mensajes HL7. KLAS 1, una de las más importantes organizaciones de analistas de Tecnologías de la Información para sanidad con sede central en Estados Unidos, lo ha considerado el primer y segundo motor de interfaz para gestión sanitaria cada año desde InterSystems ha completado recientemente un banco de pruebas de rendimiento y escalabilidad de la versión de Ensemble (versión de mantenimiento 1) centrado en la mensajería HL7v2 (Health Level 7 versión 2). En este documento se describen las características observadas y se proporcionan directrices sobre la configuración general y el tamaño de los sistemas en los que se emplea Ensemble como motor de interfaz para la mensajería HL7v2. El banco de pruebas simula cargas de trabajo que se han diseñado de manera que sean muy parecidas a los entornos reales de funcionamiento. Los detalles de la simulación se describen en la sección Descripción de la carga de trabajo y metodología. Las cargas de trabajo probadas estaban formadas por mensajes HL7v2 Patient Administration (ADT) y Observation Result (ORU), e incluyen transformaciones y enrutamientos. Entrantes Salientes Total (entrantes + salientes ) Por Día Por Segundo Por Hora Por Día Por Segundo Por Hora Por Día TABLA 1: TASAS DIARIAS SOSTENIBLES DE MENSAJES HL7 CON ENSEMBLE Tal como indica la Tabla 1, se ha demostrado que es sostenible (en un periodo de 10 horas) una cifra superior a 58 millones de mensajes entrantes y salientes combinados por día en un sistema utilizando un procesador de 12 núcleos. Esta carga de trabajo se describe más adelante en este documento como batería de pruebas T4, incluyendo una lógica de enrutado que envía mensajes modificados separadamente a cada uno de los cuatro destinos. Para estas pruebas, Ensemble se configuró para mantener el orden FIFO (primero en entrar/primero en salir), así como para persistir toda la información de mensajes y colas para cada mensaje entrante y saliente. Guardando las colas y los mensajes, Ensemble proporciona tolerancia a fallos en el caso de una caída del sistema, así como capacidades completas de búsqueda y reenvío para todos los mensajes. Además, en el apéndice de este documento se describen las directrices de configuración, que ayudarán a elegir una configuración y una implantación correctas 1

3 para cubrir de forma adecuada las necesidades de rendimiento y escalabilidad de su carga de trabajo. Los resultados demuestran que Ensemble puede soportar necesidades de mensajería a gran escala con un hardware (instalación) bastante reducido, lo cual permite que un solo servidor pequeño proporcione potencialmente soporte de mensajería HL7 para toda la organización. Resumen de Resultados Se utilizaron tres baterías de pruebas para representar diversos aspectos de la actividad de Ensemble: n La batería de prueba T1 utilizó mensajes HL7, con un mensaje de salida por cada mensaje de entrada. Los mensajes se transmitieron directamente de un Business Service a un Business Operation, sin lógica de enrutameinto. No se utilizaron reglas de enrutamiento y no se ejecutaron transformaciones. Se creó únicamente una instancia de mensaje HL7 en base de datos por cada mensaje entrante. n La batería de pruebas T2 utilizó una lógica de enrutamiento y transformación para modificar una media de 4 segmentos del mensaje entrante y enrutarlo a una sola interfaz de salida (1 a 1 con una transformación). Para cada mensaje entrante se ejecutó una transformación de datos y se crearon dos objetos de mensaje HL7 en la base de datos. n La batería de pruebas T4 utilizó una lógica de enrutamiento y transformación para enrutar mensajes modificados separadamente para cada una de las interfaces de salida. De media se modificaron 4 segmentos del mensaje entrante en cada transformación (1 a 4 con transformaciones). Para cada mensaje entrante se ejecutaron cuatro transformaciones, se enviaron cuatro mensajes y se crearon cinco objetos de mensaje HL7 en la base de datos. Las tres baterías de pruebas se ejecutaron en entornos de 6 y 12 núcleos. Los datos se presentan como el número de mensajes de entrada por segundo (y por hora), el número de mensajes de salida por segundo (y por hora) y el total de mensajes (de entrada y de salida) en una jornada de 10 horas. Además, la utilización de CPU se presenta como una medición de los recursos del sistema disponibles en un nivel de rendimiento determinado. Se utilizaron 16 interfaces de entrada y 16 de salida en todos los casos. ESCALABILIDAD CON 6 NÚCLEOS Prueba Entrantes Salientes Por Segundo Por Día Por Segundo Por Hora Utilización de CPU Total mensajes (entrantes + salientes)/dia T % T % T % EN LA TABLA 2 SE RESUMEN LOS MEJORES ESCENARIOS EN LA CONFIGURACIÓN DE 6 NÚCLEOS:

4 ESCALABILIDAD CON 12 NÚCLEOS En la Tabla 3 se resumen los mejores escenarios para cada una de las tres cargas de trabajo en la configuración de 12 núcleos: Prueba Entrantes Salientes Por Segundo Por Día Por Segundo Por Hora Utilización de CPU Total mensajes (entrantes + salientes)/dia T % T % T % TABLA 3: ESCALABILIDAD PARA HL7V2 DE ENSEMBLE CON 12 NÚCLEOS Finalmente, tal y como se ilustra en la Figura 1, Ensemble puede escalarse casi de forma lineal para cada tipo de prueba cuando el número de núcleos se duplica de 6 a 12. Ensemble 20,0.2 (Maintenance Release 1) HL7v2 Scalability 70,000,000 Total messages/day (10 hours) 60,000,000 50,000,000 40,000,000 30,000,000 20,000,000 10,000,000 6 cores 12 cores T1 T2 T4 44,352,000 23,904,000 25,920,000 66,600,000 48,816,000 58,680,000 FIGURA 1: PERFILES DE ESCALABILIDAD DE ENSEMBLE EN CONFIGURACIONES DE 6 Y 12 NÚCLEOS

5 Descripción de las Baterías de Prueba y Metodología Las cargas de trabajo probadas incluyen mensajes HL7v2 de Patient Administration (ADT) y Observation Result (ORU), que tenían un tamaño medio de 1,2 KB y una media de 14 segmentos. Se han modificado unos 4 segmentos mediante las transformaciones (para las cargas de trabajo T2 y T4). Las pruebas representan 16 interfaces de entrada y 16 de salida que reciben y envían mensajes por TCP/IP. La escalabilidad se midió aumentando de manera gradual el tráfico en cada interfaz. Las pruebas en las que se variaba el número de interfaces no marcaron una gran diferencia con el rendimiento global, por lo que para estas pruebas se utilizaron las 16 interfaces entrantes y salientes. Una prueba aceptable demostró un estado estable mantenido con un número de mensajes en cola mínimo. Un número de mensajes en cola alto es indicativo de una baja calidad de servicio para los mensajes, y puede provocar un retraso en el procesamiento y la entrega de un mensaje al sistema o sistemas de destino. La metodología de la prueba rechazó aquellas con un número de mensajes en cola que pudiese provocar un retraso de más de 1 segundo en un mensaje. Además, en general las pruebas con una utilización de CPU por encima del 75% se rechazaron. Los resultados publicados en este documento incluyen también un ajuste suponiendo una penalización por benchmarking (20%) teniendo en cuenta la variación entre un sistema de pruebas y uno de producción. La realización de pruebas previas demostró que el tipo de mensaje HL7 utilizado no es significativo para el rendimiento o la escalabilidad de Ensemble; los factores que sí son significativos son el número de mensajes entrantes, el tamaño de los mensajes entrantes y salientes, el número de nuevos mensajes creados durante la lógica de enrutamiento y el número de segmentos modificados. Además, las pruebas previas demostraron que procesar campos individuales de un mensaje HL7 en una transformación de datos no suele ser significativo para el rendimiento. Las transformaciones de estas pruebas utilizaron asignaciones bastante sencillas para crear mensajes nuevos. Se observó que el procesamiento complejo (por ejemplo la utilización de consultas SQL que hagan un uso intensivo de recursos en una transformación de datos) puede hacer que los resultados varíen. Las pruebas realizadas con anterioridad también comprobaron que el procesamiento de reglas no suele ser significativo. Los conjuntos de reglas de enrutamiento utilizados en estas pruebas tenían una media de 32, todas ellas simples. Se estableció una configuración para no evaluar obligatoriamente a todas, y todas las reglas en los conjuntos reglas se ejecutaron con la misma frecuencia. Hay que tener en cuenta que el uso de conjuntos de reglas muy grandes o complejos puede hacer que los resultados varíen. Hardware Utilizado En las pruebas se ha utilizado un servidor con procesadores dual hexa core Intel Xeon X5670 Westmere (12 núcleos a 2,93 GHz, 2 chips, 6 núcleos por chip, 2 hebras por núcleo), con un tamaño de RAM de 32 GB. El sistema operativo utilizado fue Red Hat Enterprise Linux Server versión 5.5 (Tikanga).

6 Para ello se habilitó la tecnología HyperThreading (HT). Se llevaron a cabo una serie de pruebas para comprobar el impacto de HT en el rendimiento de Ensemble. La conclusión fue que HT en el procesador Intel Xeon 5670 (Westmere) proporciona un impacto positivo en el rendimiento disminuyendo el tiempo necesario para completar una batería de pruebas. Hay que tener en cuenta que activar HT en otras arquitecturas y otros chips puede tener un efecto negativo (o neutro) sobre el rendimiento, y que se debe tener cuidado al evaluar el rendimiento en esas plataformas antes de habilitar HT. Además, para esta prueba se utilizó una configuración de disco relativamente modesta, en la cual todos los archivos de base de datos, los ficheros de Journal y WIJ (Write Image Journal) se configuraron en un disco interno para lograr simplicidad (no recomendado para los sistemas de producción). Apéndice: Directrices de Configuración Además de las directrices estándar de configuración y ajuste específicas de la plataforma de InterSystems para InterSystems Caché y Ensemble, son aplicables las directrices siguientes. CONFIGURACIÓN DE CPU Standard Performance Evaluation Corporation (SPEC) proporciona bancos de pruebas estandarizados que pueden facilitar una línea base para la configuración en distintas plataformas. Uno de los componentes de los bancos de prueba de SPEC es CINT2006, que prueba el rendimiento de procesamiento de números enteros de una CPU determinada. SPEC define un tiempo de ejecución de base para los programas de banco de pruebas, que es conocido como tiempo de referencia. A continuación se ejecutan pruebas de tiempo en varios sistemas de prueba, esos números se comparan con el tiempo de referencia y se calcula un ratio. Este ratio se denomina puntuación SPECint2006 (también conocida como puntuación CINT2006 ) para esa prueba. La puntuación SPECint suele usarse para comparar configuraciones en varias plataformas. El sistema que probamos estaba configurado con dos procesadores Intel Xeon X5670 (2,93 GHz) con seis núcleos. Este procesador tiene una puntuación de línea base CINT2006de 36,6, que es la puntuación de un núcleo de procesamiento. Por lo tanto, la configuración de 12 núcleos tendría una puntuación de línea base CINT2006 de 439,2 (36,6 x 12). Estas cifras pueden usarse como directriz para comparar otras plataformas y determinar la potencia de proceso que necesitan para soportar los niveles logrados en la plataforma Intel Xeon X5670. Por ejemplo, el procesador Intel Xeon X5550 (2,66 GHz) tiene una puntuación de línea base CINT2006 de 29,7, que indica que su rendimiento es aproximadamente un 19% menor (29,7/36,6) que el del sistema Intel Xeon X5670 probado. Por lo tanto, si configura un sistema comparable con el procesador Intel Xeon X5550 en lugar del procesador Intel Xeon X5670, en principio se espera que Ensemble procese aproximadamente un 19% menos de mensajes.

7 CONFIGURACIÓN DEL DISCO Tal como se ha mencionado anteriormente, los mensajes que pasan por Ensemble se guardan en su totalidad en el disco (persistencia de mensajes). Para la carga de trabajo de T4 descrita en este documento, cada mensaje HL7 entrante genera unos 50 KB de datos, que se pueden desglosar tal como se describe aquí. Procedencia Datos de Segmentos Objetos de Mensaje HL7 Cabecera de Mensaje Registro de Reglas de Direccionamiento Journaling (en Archivo de Journal de Caché) Total Requisitos de Datos 4,5 KB 2 KB 1,0 KB 0,5 KB 42 KB 50 KB TABLA 4: REQUISITOS DE DISCO POR MENSAJE HL7 ENTRANTE DE P4 Recordar que la carga de trabajo de T4 utilizó una lógica de enrutamiento para direccionar mensajes modificados separados para cada una de las cuatro interfaces salientes. De media se modificaron 4 segmentos del mensaje entrante en cada transformación (1 a 4 con transformaciones). Para cada mensaje entrante se ejecutaron cuatro transformaciones de datos, se enviaron cuatro mensajes de salida y se crearon cinco objetos de mensajes HL7 en la base de datos. Al configurar sistemas para su utilización en producción, las necesidades netas deben calcularse teniendo en cuenta los volúmenes entrantes diarios, así como la planificación del purgado de mensajes HL7. Además, debe configurarse un espacio para archivos de Journal adecuado en el sistema para evitar que se llene el disco. Los archivos de Journal deben encontrarse en un disco separado físicamente de los archivos de la base de datos, por cuestiones de rendimiento y fiabilidad.

8 InterSystems Corporation World Headquarters One Memorial Drive Cambridge, MA Tel: Fax: InterSystems.com InterSystems Iberia S.L. Oficina en España Avda. de Europa, 12 Edif. Mónaco Parque Empresarial de la Moraleja (Madrid) Telf: Fax: InterSystems.es InterSystems Ensemble e InterSystems Caché son marcas comerciales de InterSystems Corporation. InterSystems DeepSee e InterSystems HealthShare son marcas comerciales de InterSystems Corporation. Otros nombres de producto son marcas comerciales de sus respectivos proveedores. Copyright 2011 InterSystems Corporation. Todos los derechos reservados D03 07/11