Bahmni Lite 장시간 성능 기준선

다음 상황에서 여러 기준선 스냅샷을 기록하고 지속적으로 갱신하는 문서입니다.

• Troubleshooting and applying a patchChanging Software or 네트워크 configurationsAdding new scenarios and changing load share

소스 코드: https://github.com/Bahmni/performance-test

• Gatling, Scala

성능 환경은 단일 노드 AWS EKS 클러스터에서 실행되었습니다.

노드(EC2: m5-xlarge)

• RAM 16GB4 vCPU 100GB 보조 스토리지AWS LINUX x86_64

데이터베이스(AWS RDS: db.t3.xlarge)

• RAM 16GB, 4 vCPU (2 core, 2.5 GHz Intel Scalable Processor)100GB 보조 스토리지MySQL, max_connections = 1304

OpenMRS Tomcat - 서버

OpenMRS - 힙

• 초기 힙: 256 MB최대 힙: 768 MB

-Xms256m -Xmx768m -XX:PermSize=256m -XX:MaxPermSize=512m

OpenMRS 연결 풀링

성능 테스트 시뮬레이션(Gatling)은 클라이언트 머신에서 실행됩니다.

클라이언트(EC2: c5-xlarge)

• RAM 8GB 4 vCPU 8GB 스토리지AWS LINUX x86_64

• 네트워크: 60 MBPS부하 증가 시간: 5 분데이터베이스 사전 상태: 543 환자

OpenMRS JVM 구성:

보고서 링크: https://bahmni.github.io/performance-test/longduration_report-20221124061027477_40users_8hrs/index.html

보고서 관찰 결과:

분석 필요Red

📗 50 동시 사용자 - 8 시간note네트워크: 60 MBPS

Ramp Up: 5분

데이터베이스 사전 상태: 2464 환자

OpenMRS JVM 구성:

보고서 링크: https://bahmni.github.io/performance-test/longduration_report-20221125061309057_50users_8hrs/index.html

보고서 관찰 결과:

모니터링 필요Yellow

분석 필요Red

📕 70 동시 사용자 - 8 시간70usersnote네트워크: 60 MBPS

Ramp Up: 5분

데이터베이스 사전 상태: 8361 환자

OpenMRS JVM 구성:

보고서 링크: https://bahmni.github.io/performance-test/longduration_report-20221117114025035_70users_8hrs/index.html

보고서 관찰 결과:

40 동시 사용자 - 구성하드웨어Performance environment was running on AWS EKS Custer with single node

노드(EC2: t3-large)

• RAM 8GB2 vCPU 100GB 보조 스토리지AWS LINUX x86_64

데이터베이스(AWS RDS: db.t3.xlarge)

• RAM 16GB, 4 vCPU (2 core, 2.5 GHz Intel Scalable Processor)100GB 보조 스토리지MySQL, max_connections = 1304

OpenMRS Tomcat - 서버

OpenMRS - 힙

• 초기 힙: 1024 MB최대 힙: 1536 MB

-Xms1024m -Xmx1536m -XX:NewSize=512m -XX:MaxNewSize=512m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=1024m -XX:InitialCodeCacheSize=64m -XX:ReservedCodeCacheSize=96m -XX:SurvivorRatio=4 -XX:TargetSurvivorRatio=40 -XX:+UseParNewGC -XX:ParallelGCThreads=2 -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+CMSCompactWhenClearAllSoftRefs -XX:CMSInitiatingOccupancyFraction=85 -XX:+CMSScavengeBeforeRemark -XX:+UseGCOverheadLimit -XX:+UseStringDeduplication

OpenMRS 연결 풀링

• 네트워크: 60 Mbps기간: 24 hours부하 증가 시간: 5 분데이터베이스 사전 상태: 75000 환자 레코드

보고서 링크: https://bahmni.github.io/performance-test/longduration_report-20230130141239257_40users_24hrs_all_omods_afterhipfix/index.html

보고서 관찰 결과:

분석 필요Red

70 동시 사용자 - 구성하드웨어Performance environment was running on AWS EKS Custer with single node

노드(EC2: m5-xlarge)

• RAM 16GB4 vCPU 100GB 보조 스토리지AWS LINUX x86_64

데이터베이스(AWS RDS: db.t3.xlarge)

• RAM 16GB, 4 vCPU (2 core, 2.5 GHz Intel Scalable Processor)100GB 보조 스토리지MySQL, max_connections = 1304

OpenMRS Tomcat - 서버

OpenMRS - 힙

• 초기 힙: 1024 MB최대 힙: 2536 MB

-Xms1024m -Xmx2536m -XX:NewSize=512m -XX:MaxNewSize=512m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=1024m -XX:InitialCodeCacheSize=64m -XX:ReservedCodeCacheSize=96m -XX:SurvivorRatio=4 -XX:TargetSurvivorRatio=40 -XX:+UseParNewGC -XX:ParallelGCThreads=2 -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+CMSCompactWhenClearAllSoftRefs -XX:CMSInitiatingOccupancyFraction=85 -XX:+CMSScavengeBeforeRemark -XX:+UseGCOverheadLimit -XX:+UseStringDeduplication

OpenMRS 연결 풀링

• 네트워크: 60 Mbps기간: 24 hours부하 증가 시간: 5 분데이터베이스 사전 상태: 90500 환자 레코드

보고서 링크: https://bahmni.github.io/performance-test/longduration_report-20230213133118638_70users_24hours_AfterHIPfix_m5xlarge/index.html

보고서 관찰 결과:

분석 필요Red

🔰 관찰 결과:

• 의사 진료: 동시 사용자 40명 및 70명 테스트 모두에서 이 작업의 최대 응답 시간이 상당히 높았습니다. 관련 서비스를 분석 중이며 성능 개선 우선순위에 포함할 예정입니다.

100 동시 사용자 - 구성하드웨어Performance environment was running on AWS EKS Custer with single node

노드(EC2: m5-xlarge)

• RAM 16GB4 vCPU 100GB 보조 스토리지AWS LINUX x86_64

데이터베이스(AWS RDS: db.t3.xlarge)

• RAM 16GB, 4 vCPU (2 core, 2.5 GHz Intel Scalable Processor)100GB 보조 스토리지MySQL, max_connections = 1304

OpenMRS Tomcat - 서버

OpenMRS - G1GC 힙

• 초기 힙: 1024 MB최대 힙: 4096 MB

-Dfile.encoding=UTF-8 -server -Xms1024m -Xmx4096m -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=25 -XX:G1MaxNewSizePercent=50 -XX:SurvivorRatio=8 -XX:MaxMetaspaceSize=512m -XX:ReservedCodeCacheSize=256m -XX:CompressedClassSpaceSize=256m -XX:MaxGCPauseMillis=200 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./java.hprof -Xloggc:/usr/local/tomcat/logs/gc.log -XX:+UseStringDeduplication -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

• 네트워크: 60 Mbps기간: 24 hours부하 증가 시간: 5 분데이터베이스 사전 상태: 189500 환자 레코드

보고서 링크: https://bahmni.github.io/performance-test/longduration_report-20230330120855322_100users_24_hrs_g1gc/index.html

보고서 관찰 결과:

분석 필요Red

🔰 관찰 결과:

• HIP 및 Crater Atomfeed Pod를 제거하고 G1GC 메모리 관리를 도입한 결과 전체 응답 시간과 CPU 사용률이 감소했습니다.

100 동시 사용자 - 구성하드웨어Performance environment was running on AWS EKS Custer with single node

노드(EC2: m5-xlarge)

• RAM 16GB4 vCPU 100GB 보조 스토리지AWS LINUX x86_64

데이터베이스(AWS RDS: db.t3.xlarge)

• RAM 16GB, 4 vCPU (2 core, 2.5 GHz Intel Scalable Processor)100GB 보조 스토리지MySQL, max_connections = 1304

OpenMRS Tomcat - 서버

OpenMRS - G1GC 힙

• 초기 힙: 1024 MB최대 힙: 4096 MB

-Dfile.encoding=UTF-8 -server -Xms1024m -Xmx4096m -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=25 -XX:G1MaxNewSizePercent=50 -XX:SurvivorRatio=8 -XX:MaxMetaspaceSize=512m -XX:ReservedCodeCacheSize=256m -XX:CompressedClassSpaceSize=256m -XX:MaxGCPauseMillis=200 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./java.hprof -Xloggc:/usr/local/tomcat/logs/gc.log -XX:+UseStringDeduplication -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

• 네트워크: 60 Mbps기간: 24 hours부하 증가 시간: 5 분데이터베이스 사전 상태: 223722 환자 레코드

보고서 링크: https://bahmni.github.io/performance-test/longduration_report-20230425092521626_100users_24hours_after-hip-atomfeed-fix/index.html

보고서 관찰 결과:

분석 필요Red

📗 120 동시 사용자 - 24 시간120 동시 사용자 - 구성하드웨어Performance environment was running on AWS EKS Custer with single node

노드(EC2: m5-xlarge)

• RAM 16GB4 vCPU 100GB 보조 스토리지AWS LINUX x86_64

데이터베이스(AWS RDS: db.t3.xlarge)

• RAM 16GB, 4 vCPU (2 core, 2.5 GHz Intel Scalable Processor)100GB 보조 스토리지MySQL, max_connections = 1304

OpenMRS Tomcat - 서버

OpenMRS - G1GC 힙

• 초기 힙: 1024 MB최대 힙: 4096 MB

-Dfile.encoding=UTF-8 -server -Xms1024m -Xmx4096m -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=25 -XX:G1MaxNewSizePercent=50 -XX:SurvivorRatio=8 -XX:MaxMetaspaceSize=512m -XX:ReservedCodeCacheSize=256m -XX:CompressedClassSpaceSize=256m -XX:MaxGCPauseMillis=200 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./java.hprof -Xloggc:/usr/local/tomcat/logs/gc.log -XX:+UseStringDeduplication -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

• 네트워크: 60 Mbps기간: 24 hours부하 증가 시간: 5 분데이터베이스 사전 상태: 238182 환자 레코드

보고서 링크: https://bahmni.github.io/performance-test/longduration_report_20230427094905338_120users_24hours_after-hip-atomfeed-fix/index.html

보고서 관찰 결과:

분석 필요Red

참고: 이 테스트는 실제 임상 활동과 비교할 때 Bahmni Lite 사용자에게 가장 높은 부하가 걸리는 상황을 가정했습니다. 따라서 일부 작업의 최대 응답 시간이 아직 최적이 아니더라도 클러스터에서는 제안된 동시 사용자 수로 안전하게 구현할 수 있다고 판단합니다.