Bahmni 성능 테스트 여정(상위 수준 요약)

1. 기준선 보고서와 새 소프트웨어 구성 요소로 업그레이드했을 때의 이점을 게시합니다.
2. 용량 계획 보고서를 게시하고, 하드웨어 조건별 시설당 클라우드 운영 비용을 예측할 수 있게 합니다.
3. 성능을 크게 개선하거나 시설당 비용을 줄일 수 있는 다음 실험 또는 기능의 로드맵을 게시합니다.
4. 성능 테스트 실행을 Bahmni 배포와 통합하여 커뮤니티 누구나 자신의 Bahmni 배포를 수정하고 실행하며 벤치마킹할 수 있게 합니다.

자세한 내용은 여기를 참조하십시오.관련 문서: 성능 벤치마킹 및 용량 계획

이 전략은 다음 기준을 유지하면서 Bahmni LITE 환경에서 현실적인 스트레스 테스트를 수행하는 데 중점을 둡니다.

1. 각 사용자 상호 작용 사이에 대기 시간을 두어 페르소나별 여유 시간을 유지합니다.
2. 페르소나별 여유 시간에 따라 전체 부하를 각 페르소나에 분배합니다.
3. 각 테스트의 시작과 끝에 사용자를 점진적으로 늘리고 줄입니다.
4. 각 테스트는 의사가 테스트 시작부터 진료를 시작할 수 있도록 환자 집합을 준비한 상태에서 시작합니다.
5. 환자 등록과 진료 시나리오가 끊김 없이 이어지도록 합니다.
6. 전체 테스트 시간을 제어하도록 테스트 종료 시점을 명확히 제한합니다.

자세한 내용은 여기를 참조하십시오.관련 문서: 성능 테스트 설계

성능 테스트 모음에는 다음 테스트 시나리오가 구현되어 있습니다.

1. 신규 환자 - 등록 - OPD 방문 시작
2. 기존 환자 - 환자 검색 - OPD 방문 시작
3. 환자 문서 업로드
4. 의사 진료 및 관찰값 흐름

자세한 내용은 여기를 참조하십시오.관련 문서: Bahmni 성능 테스트 시나리오

성능 테스트 환경은 AWS의 Kubernetes에서 실행됩니다.

• Bahmni Kubernetes Installation용 별도 네임스페이스를 만듭니다.
• 기존 RDS를 성능 테스트 네임스페이스와 공유합니다.
• 모니터링을 위해 Grafana 및 JVM Dashboard를 추가합니다.

자세한 내용은 여기를 참조하십시오.관련 문서: here

사전 요구 사항 JDK 11

Gradle

Nodejs

Newman

Aws credentials(클라우드에서 테스트를 실행할 때만 필요)

GitHub Actions 액세스 권한(클라우드에서 테스트를 실행할 때만 필요)

Yourkit Java profiler(Infra Team에서 라이선스 받기)

네트워크 대역폭 제어기 - Wondershaper

• Wondershaper
• test-data-generator
• performance-test-suite

보관 보고서 경로 - GH Pages

모든 저장소를 복제합니다.

필요한 경우에만 Wondershaper로 네트워크 속도를 설정합니다.

테스트 데이터 생성기를 실행하여 새 환자를 만들고 업로드합니다.

/output의 registrations.csv 파일을 /src/gatling/resources로 복사합니다.

시뮬레이션 유형, 사용자 수, 테스트 시간을 지정하여 테스트를 시작합니다.

다른 환경을 대상으로 테스트하려면 다음 파일의 해당 환경 속성을 업데이트합니다.

• src/gatling/scala/configurations/protocols.scala 및 src/gatling/scala/api/constants.scala

클라우드에서 테스트하려면 GH Actions의 트리거를 사용합니다.

자세한 내용은 관련 두 문서를 참조하십시오.관련 문서: Bahmni 테스트 데이터 생성기here

성능 테스트 실행 중 JVM을 프로파일링하기 위해 YourKit 프로파일링 도구를 사용했습니다.

CPU 및 메모리 사용량 분석, API 응답을 느리게 하는 코드 문제 해결, 잠재적 교착 상태 찾기 등에 도움이 되었습니다.

원격 장비에 YourKit을 설정하는 방법은 관련 문서를 참조하십시오.관련 문서: YourKit을 이용한 원격 Java 프로파일링

OpenMRS는 기본적으로 메모리 사용량이 큰 애플리케이션에 최적화되지 않은 Open JVM 메모리 관리를 사용합니다. 따라서 최소 환자 데이터에서 GC 일시 정지 시간을 줄이고 처리량을 높인 CMS(Concurrent Mark Sweep)로 전환했습니다. - BAH-2660.

최소·최대 힙 크기와 병렬 GC 스레드를 구성했습니다.

이 변경으로 사용자 90명 테스트에서 진료를 저장하는 POST API 호출의 최대 시간이 4149ms에서 1551ms로 줄었습니다.

기준선 테스트 보고서의 자세한 내용은 관련 문서를 참조하십시오.관련 문서: AWS 및 Gatling 기반 Bahmni Lite 성능 기준선

1. Groovy parse class 함수 때문에 진료 페이지 저장 시간이 길었습니다. 이를 비활성화하여 단일 API 호출의 응답 시간을 2.5초에서 1초로 줄였습니다. - BAH-2870.
2. HIP 상태 확인 모듈이 5초마다 OpenMRS 환자 및 방문 API를 호출하여 환자 수가 125k에 도달하면 지속적인 Out-of-Memory Exception으로 환경이 중단되었습니다. - BAH-2441, BAH-2783(수정됨). 수정 후 사용자 70명 테스트에서 진료 저장 POST API의 최대 시간이 60초에서 4초로 줄었습니다.
3. HIP 및 Crater Atom Feed도 이벤트 피드를 조회하려고 OpenMRS를 계속 호출하여 GC 일시 정지가 길어지고 CPU 사용률이 급증했습니다. - BAH-2801, BAH-2912.
4. GC 전략을 CMS에서 G1GC로 변경하여 CPU 급증을 제어했습니다.
5. HIP와 Crater Atom Feed 없이 업데이트된 G1GC 설정을 사용하면 99번째 백분위수가 1.5초로 줄었습니다.

JVM 구성, 인프라 설정 및 장시간 테스트에 대한 자세한 내용은 Bahmni Lite Performance Long Duration Simulation Baselining에서 확인할 수 있습니다.관련 문서: Bahmni Lite 장시간 성능 기준선

장시간 테스트 결과와 해당 AWS 사용 요금을 기준으로 비용 계산기를 만들었습니다. 링크: Bahmni Lite 운영 비용 예상.관련 문서: Bahmni Lite 인프라 비용 추정(성능 테스트 기반)

사용자 수, 클리닉당 사용자 수, 운영 시간을 입력하여 Bahmni LITE 설치의 클라우드 비용을 누구나 추정할 수 있습니다.

부하 패턴은 테스트 모음을 기준으로 가정합니다. 시설에서 수행하는 작업이 테스트 모음의 시나리오와 다르면 결과가 그대로 일치하지 않습니다. 팀이 수행한 성능 작업을 더 잘 이해하려면 테스트 시나리오를 검토하십시오.관련 문서: Bahmni 성능 테스트 시나리오

문제 해결/개선 작업

1. 다중 테넌시 환경 테스트.
2. 애플리케이션의 최신 변경 사항으로 테스트 모음 업데이트 - BAH-2903.
3. HIP 및 Crater Atom Feed가 OpenMRS에 미치는 영향 감소 - BAH-2948.
4. API 응답 시간 최적화 - BAH-2871, BAH-2890, BAH-2891, BAH-2892, BAH-2893.
5. 애플리케이션 메모리 관리 최적화 - BAH-2949.
6. 중복 SQL 쿼리 최적화 - BAH-2716.
7. 백로그 작업 목록.관련 문서: list