Page History

Versions Compared

...

한번도 못할수도 있지만 한번하면 한번만 하고 싶은 로드 테스트 과정 )

다음과 같은 수준을 통과했으며~ 로드테스트도 엄청난 비용이 수반되기때문에

꼭 이것이 표준은 아니며 프로덕트의 규모와 성격에따라 전략수준을 다양하게 채택할수 있습니다.

RampUp/Down Time을 설정하여 피크타임까지 사용자를 실제 시나리오와 유사하게 늘리고 뺌 -
목표 TPS만큼 테스트가 안되면 테스트 통과 실패 -
TPS가 높아도 목표 사용자수가 안되면 테스트 통과 실패 -
목표한 API 허용 에러률(1%)보다 높아도 테스트 통과 실패 (스크립트 오류및 테스트 노드장비 문제일수도 있음) -
로드 테스트를 너무 많이해서 DB FUll이 나서 테스트 통과 실패 -
알수없는 이유로 여러개의 노드중 1개의 노드가 Crash되어도 테스트 통과 실패 ( 에러율이 1%보다 높아짐) -
에러율이 낮아도 짧은기간에 에러 집중되면 테스트 통과 실패 -
테스트를 모두 통과해도, 평균 허용치 CPU(80%)사용율을 특정시간동안 지속되면 테스트 실패 -
코드수정및 스케일 아웃처리로 모든 로드 테스트를 통과해도, 이미 통과한 QA Sign OFF를 다시 받아야함, 이과정중 Codefix가 발생하면 다시 로드 테스트 수행 -
서버가 대용량 처리가 안정화 되어 ,장시간 테스트시 결국 분산 테스트툴보다 더 오래 버팀 (분산 테스트툴을 주기적으로 리셋해야되는 상황발생) -
이모든 장벽을 다통과해도 테스트 시나리오때 누락된 테스트항목으로 문제발생 ( 사용자 플래폼 변경에 따른 레거시 → 신규서비스 전환 테스트 미스) - 레거시 테스트 시나리오까지 작성하기 어려움 -

위와 같은 수준의 로드(퍼포먼스,스파크,안정성) 테스트 하게되면 노하우보다 예지력이 생길수도있으며
성능테스트는 사실 측정하지 않으면 개선할수 없습니다. 못하면 개선할수 없다가 기본전제이기때문에 고수준의 모니터링 툴이 사실 전제가 되어야합니다.

글로벌 특정 카테고리기준 Top트래픽에 속했던 프로덕트의 측정과정의 수치를 공개합니다.

...