EMS Builder 성능 테스트 설명서

설명서 버전: v1.1
현재 통계 규칙: 횟수 기반 샘플링에서 처음과 마지막을 위해 2회를 추가 수집하고 공식 결과에는 중간 샘플만 집계합니다.

테스트 안내: 실제 계량기, PLC 또는 시리얼 게이트웨이를 연결하지 않고 모두 Modbus TCP 시뮬레이션 장치를 사용합니다. 결과는 이상적인 통신 조건에서의 Edge-EMS Builder 처리 능력이며 실제 현장의 종단 간 성능을 의미하지 않습니다.

1. 테스트 내용

테스트 내용	확인할 질문
데이터 수집	EMS Builder가 초당 몇 개의 데이터 포인트를 안정적으로 처리할 수 있는가?
Trigger	Lua 작업이 계획대로 실행되며 소요 시간이 안정적인가?
MQTT / 협업 작업	작업 수가 목표를 충족하며 지연이나 실패가 발생하는가?
데이터 저장	실시간 저장과 변경 기반 저장이 성능에 어떤 영향을 주는가?
시스템 리소스	CPU, 메모리 및 디스크가 한계에 가까워지는가?
안정성	장기 실행 시 비정상 종료, 재시작 또는 지속적인 적체가 발생하는가?

2. 테스트 부하

2.1 EMS Builder가 동시에 수행하는 작업

부하	테스트 내용
데이터 수집	시뮬레이션 Slave 20개에서 데이터 포인트 읽기
집계 연산	Lua로 수집 데이터 계산
Trigger	Lua 스크립트를 주기적으로 실행하여 쓰기, 알람 및 MQTT 동작 생성
MQTT 작업	MQTT 메시지 주기적 생성 및 발행
협업 작업	장치 간 공유 및 협업 처리 실행
데이터 저장	수집 데이터, 계산 결과 및 작업 기록 저장

2.2 Trigger의 각 Lua 스크립트가 수행하는 작업

내용	실행당 수량	역할
기본 계산 반복	100회	수학 계산, 조건 판단, 반복, 문자열 및 테이블 조작
원본 포인트 쓰기	2회	테스트 포인트 `小数据0` 및 `小数据1`에 각각 쓰기
집계 포인트 쓰기	1회	테스트 집계 포인트 `Agg`에 쓰기
로컬 알람	2회	1단계 알람 두 개 생성
MQTT 알람	1회	2단계 MQTT 알람 하나 생성

2.3 초당 발생하는 실제 부하

지표	계산	초당
Lua 스크립트 실행	Trigger 작업: `50 × 1s + 5 × 100ms = 100/s`, MQTT 작업: `50/s`, 집계 연산: `50/s`, 공유 작업: `10/s`	210회
Trigger 기본 계산 반복	`100 × 100`	10,000회
Trigger 원본 포인트 쓰기	`100 × 2`	200회
Trigger 집계 포인트 쓰기	`100 × 1`	100회
Trigger 로컬 알람	`100 × 2`	200회
Trigger MQTT 알람	`100 × 1`	100회
Trigger 전체 쓰기 동작	`100 × 6`	600회
MQTT 메시지 발행	`50 × 1`	50회
데이터 변경으로 트리거되는 집계 연산	`50 × 1`	50회
데이터 공유 작업	`10 × 1`	10회

3. 표준 시나리오

계산 방식:

Trigger 횟수/초 = 1s Trigger 수 + 100ms Trigger 수 × 10

시나리오	수집 포인트/초	집계	1s Trigger	100ms Trigger	Trigger/초	MQTT/초	협업/초	저장	시간
S1	500	10	10	0	10	5	0	실시간	30분
S2	2,000	20	20	2	40	10	2	실시간	30분
S2.5	2,000	20	20	2	40	10	2	변경 기반	30분
S3	5,000	30	50	4	90	20	10	실시간	30분
S3.5	5,000	30	50	4	90	20	10	변경 기반	30분
S4	10,000	30	100	10	200	40	20	변경 기반	30분
S5	20,000	40	200	10	300	60	40	변경 기반	30분
S6	5,000	20	50	10	150	30	15	실시간	72시간

저장 방식	설명
실시간 저장	설정에 따라 모든 수집 결과 저장
변경 기반 저장	값이 바뀌면 즉시 저장하고, 바뀌지 않아도 10초마다 한 번 이상 저장

S5는 성능 한계를 찾는 데 사용하며 S6는 실제로 72시간 실행해야 합니다.

4. 샘플링 및 통계 규칙

4.1 횟수 기반 샘플링

단시간 성능 재검증은 고정 횟수 샘플링을 사용하며, 횟수는 해당 배치 보고서를 따릅니다. 다음은 시나리오별로 1초 간격으로 1,002회 수집하는 예제입니다. AFE-E630 보고서 v1.3은 2,002회 수집하여 유효 샘플 2,000개를 사용합니다.

1번째: 경계 샘플, 집계에서 제외
2～1001번째: 유효 샘플, 총 1,000개
1002번째: 경계 샘플, 집계에서 제외

공식 보고서는 반드시 raw_data에서 sample_no 기준으로 선택해야 하며, 워크북의 summary 시트에서 첫 번째와 마지막 샘플을 포함한 전체 집계값을 그대로 사용해서는 안 됩니다.

1초 간격으로 완전한 30분 테스트를 수행하려면 1,802회를 수집하고 중간 1,800회를 집계해야 합니다. S6의 72시간 안정성 테스트를 1,002회의 단시간 데이터로 대체할 수 없습니다.

4.2 EMS Builder 전체 리소스

다음 5개 서비스를 동일한 sample_no에서 먼저 합산한 후 통계 지표를 계산해야 합니다.

cb_core
cb_nginx
cb_backend
ems_backend
ems_postgresql

AEMS_CPU_raw(n) = 동일한 sample_no의 서비스 5개 CPU 사용량 합계
4코어_시스템_CPU(n) = AEMS_CPU_raw(n) ÷ 4
Edge-EMS Builder_메모리(n) = 동일한 sample_no의 서비스 5개 메모리 사용량 합계

보고서에는 최소한 평균, P95, P99 및 최고값이 포함되어야 합니다. 서로 다른 시점에 발생한 5개 서비스의 독립 최고값을 직접 합산해서는 안 됩니다.

4.3 Trigger 및 MQTT

trigger_per_sec 및 mqtt_per_sec를 시간 오름차순으로 정렬한 후 첫 번째와 마지막 초 버킷도 제외하여 데이터베이스 조회 구간 양끝의 불완전한 1초가 포함되지 않도록 합니다.

작업의 초 버킷과 리소스 샘플링 횟수는 엄격하게 일대일 대응하지 않을 수 있습니다. 특정 초에 기록이 없거나 작업 적체로 다음 초에 완료가 집중될 수 있습니다. 보고서에는 유효 초 버킷 수와 다음 정보를 모두 제시해야 합니다.

초당 처리량 평균 및 목표 대비 달성률
초당 평균 SpendTime의 평균, P50, P95 및 P99
모든 초 버킷에서 개별 SpendTime 최대값
초당 평균 SpendTime가 200 ms를 초과한 초의 수와 비율

완전한 1초 동안 작업 기록이 없으면 처리량 통계에서 0으로 처리해야 합니다. 해당 초에는 계산할 지연 시간이 없으므로 0 ms로 만들어 넣어서는 안 됩니다. 이후 모니터링 스크립트는 통계 구간 시작과 종료 시간을 명확히 출력하여 빈 초를 보완할 수 있도록 해야 합니다.

5. 관찰 지표

분류	집계할 항목
데이터 수집	설정 포인트 수, 성공 포인트 수, 실패 및 폐기
Trigger	목표 횟수, 실제 횟수, 평균 소요 시간, P50, P95, P99 및 최대값
MQTT / 협업	목표 횟수, 실제 횟수, 소요 시간 및 오류
CPU	전체 EMS Builder의 평균, P95 및 최고값
메모리	전체 EMS Builder의 평균, 최고값 및 변화 추세
디스크	읽기/쓰기 속도, I/O 대기 및 데이터베이스 쓰기 상태
Modbus	Slave별 읽기/쓰기 수, 실패, 제한 시간 초과 및 재시도
안정성	비정상 종료, OOM, 비정상 재시작 및 지속적인 적체

주요 계산:

정확도 = 성공 건수 ÷ (성공 건수 + 실패 건수 + 시간 초과 건수 + 폐기 건수)

달성률 = 실제 초당 평균 처리량 ÷ 시나리오 목표

SpendTime는 실제 작업 실행 시간을 나타냅니다. 간헐적인 긴 지연을 식별하려면 평균뿐 아니라 P95, P99 및 최대값도 반드시 제시해야 합니다.

6. 결과 판단

프로젝트 계약 또는 인수 기준을 우선하며, 별도 합의가 없으면 다음 참고값을 사용합니다.

항목	권장 기준
처리량	평균 달성률 ≥ 99%
Trigger / MQTT 소요 시간	P95 < 200 ms
CPU	4코어 장치 평균 사용률 < 80%, 지속적인 최대 부하 없음
메모리	전체 장치 평균 사용률 < 70%, 지속적인 증가 없음
정확도	≥ 99.99%, 설명되지 않은 폐기 없음
안정성	연속 72시간 비정상 종료, OOM 및 비정상 재시작 없음
복구 능력	부하 감소 후 5분 이내 안정 상태 복귀

6.1 테스트 무효 조건

상황	처리
테스트 시간 부족	“미완료” 표시
Slave 20개가 모두 참여하지 않음	재테스트
소수 Slave에 쓰기 집중	배분 조정 후 재테스트
부하 생성기 또는 네트워크가 병목	문제 해결 후 재테스트
성공, 실패 및 제한 시간 초과 데이터 누락	“데이터 불완전” 표시
S6를 72시간 실행하지 않음	“안정성 통과”로 기록 금지

S4와 S5는 부하 테스트입니다. 시스템 한계에 도달하면 “부하 한계 도달” 또는 “지속 운영 비권장”으로 기록하고 일반적인 용량 검증 통과로 표현해서는 안 됩니다.

모델별 보고서: